On Fri, Jun 01, 2012 at 08:35:55AM +0200, Natanael Copa wrote: > On Fri, 1 Jun 2012 09:37:55 +0800 > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, May 31, 2012 at 05:08:46PM +0200, Natanael Copa wrote: > > > On Wed, 30 May 2012 20:31:06 +0800 > > > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > On Wed, May 30, 2012 at 10:20:50AM +0200, Natanael Copa wrote: > > > > > Hi, > > > > > > > > > > Would it be possible to create a git hook that looks for > > > > > usbip-utils version number changes (like this: > > > > > https://lkml.org/lkml/2011/7/7/62) and then run "make dist-xz" > > > > > and uploads the tarball to some http server? Maybe some place > > > > > under http://www.kernel.org/pub/linux/utils/usb/ > > > > > > > > > > That would be *very* helpful for distro packagers. > > > > > > > > Ideally, we should release this as a separate tarball, as you have > > > > pointed out. > > > > > > > > But, why not just build it directly from the kernel source, > > > > incrementing the version number with every kernel release, > > > > > > Because not doing "the right thing" tends to come back and bite me > > > in future. > > > > > > What if upstream finally realizes that too and switches back > > > to separate tarballs. Why did not the package upgrade from 3.4.x to > > > 1.2.x? Why are suddenly glib and the other usbip-utils pulled in > > > bye the build scripts for kernel? Why do i need 300MB free space to > > > build the tiny usbip-utils? > > > > > > I normally end up doing releases for upstream. (seems like make > > > dist-xz is not including all header files btw) It's no problem if > > > you maintain <20 packages to spend 5 mins instead of 6-7 seconds for > > > upgrading, but extremely annoying when you maintain 1000+. > > > > I understand, but if you change your packaging to just pull directly > > from the kernel tree, like the perf package does, all of your problems > > will be solved, right? > > I'd still need to make a snapshot tarball for the caches. and since gz > stores timestamp the next person using the same build script will get > checksum error. (this is how all this started in first place) or I will > redesign the build scripts to not store and check upstream source > integrity which again will lead to another interesting problems... I have no idea what you are referring to here at all, sorry. > The github generation tend to be too lazy to do releases. I usually > tend to end up do the releases for upstream and store at some archive. The Linux kernel developers do not use github for the kernel development process. > > > > like you are probably doing today with other tools in the kernel > > > > source tree, like 'perf'? > > > > > > I don't have perf yet. > > > > It's in the kernel tree, you already have it :) > > Like i already have usbip-utils. not packaged. Then create a package for it for your distro. I don't understand the problem here. > > > > That way no one has to make any changes or remember to upload > > > > anything. > > > > > > That's why I suggested a git hook that does it for you so no-one > > > needs to remember do it. > > > > Where exactly would that git hook reside? > > On the usbip-utils' maintainers box, on git push or similar. Looking at > who is doing the version number change, that would be matt mooney. I'd > say its his responsability to do this. No, again, it's part of the kernel tree, build it from there as a package if you need it that way. Again, look at how distros package up the perf tool, and do the same if you want to create a package for the usbip-utils tools. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
