Bug#418845: kernel-package insists on overwriting setlocalversion script
On Wed, 2007-05-09 at 23:57 -0500, Manoj Srivastava wrote: On Tue, 08 May 2007 10:52:57 +0200, Johannes Berg [EMAIL PROTECTED] said: On Mon, 2007-05-07 at 21:42 -0500, [EMAIL PROTECTED] wrote: Perhaps you should check out 11.001 before giving up on this? :) Hmm. I lost track of what you wanted/didn't want to do, but now I get this when starting from a modified git tree that has been built but without debian/ or stamp-* files: The UTS Release version in include/linux/utsrelease.h 2.6.21-g5209b1ef-dirty does not match current version: 2.6.21-g5209b1ef-dirty-g5209b1ef-dirty-dirty Please correct this. Yikes. I guess I overcompensated for the added -dirty string. I wonder why I am getting multiple versions of g5209b1ef-dirty. Haven't had a chance to dig yet, sorry. I'll keep you updated if I find anything. johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Tue, 08 May 2007 10:52:57 +0200, Johannes Berg [EMAIL PROTECTED] said: On Mon, 2007-05-07 at 21:42 -0500, [EMAIL PROTECTED] wrote: Perhaps you should check out 11.001 before giving up on this? :) Hmm. I lost track of what you wanted/didn't want to do, but now I get this when starting from a modified git tree that has been built but without debian/ or stamp-* files: The UTS Release version in include/linux/utsrelease.h 2.6.21-g5209b1ef-dirty does not match current version: 2.6.21-g5209b1ef-dirty-g5209b1ef-dirty-dirty Please correct this. Yikes. I guess I overcompensated for the added -dirty string. I wonder why I am getting multiple versions of g5209b1ef-dirty. manoj -- I love treason but hate a traitor. Gaius Julius Caesar Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Mon, 2007-05-07 at 21:42 -0500, [EMAIL PROTECTED] wrote: Perhaps you should check out 11.001 before giving up on this? :) Hmm. I lost track of what you wanted/didn't want to do, but now I get this when starting from a modified git tree that has been built but without debian/ or stamp-* files: The UTS Release version in include/linux/utsrelease.h 2.6.21-g5209b1ef-dirty does not match current version: 2.6.21-g5209b1ef-dirty-g5209b1ef-dirty-dirty Please correct this. johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Sat, 2007-05-05 at 20:09 -0500, Manoj Srivastava wrote: Well, the thing is, the generated packages try to conform to Debian policy, and thus, ./debian is created first, and then you run the other commands (./debian/rules build, ./debian/rules clean, etc.) [...] Ah, true. Not enough people are kernel hackers for that mode to be the default mode of operation. Yeah, I guess. Maybe I'll just patch my local kernel-package to not overwrite the file or something. Thanks for the discussion, johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
Hi, On Mon, 07 May 2007 10:48:33 +0200, Johannes Berg [EMAIL PROTECTED] said: On Sat, 2007-05-05 at 20:09 -0500, Manoj Srivastava wrote: Not enough people are kernel hackers for that mode to be the default mode of operation. Yeah, I guess. Maybe I'll just patch my local kernel-package to not overwrite the file or something. Thanks for the discussion, Perhaps you should check out 11.001 before giving up on this? :) manoj -- Economy makes men independent. Manoj Srivastava [EMAIL PROTECTED] [EMAIL PROTECTED] 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Sat, 05 May 2007 10:18:40 +0200, Johannes Berg [EMAIL PROTECTED] said: On Fri, 2007-05-04 at 21:02 -0500, Manoj Srivastava wrote: Well. I think I want to make a) work here as well. So, one thing I can do is if $(SHELL /bin/sh scripts/setlocalversion) is not null, then append -dirty to it (since make-kpkg does make changes to the Makefile there, so ./debian is not nuked during dpkg-buildpackage). I think this might work. Why not simply make the changes before control/changelog are generated? That way, -dirty will be present automatically. Well, the thing is, the generated packages try to conform to Debian policy, and thus, ./debian is created first, and then you run the other commands (./debian/rules build, ./debian/rules clean, etc.) Now, on make-kpkg clean, the package should be left as we found it; any changes take place in ./debian/rules build. This way, the kernel-image sources are pretty much what we found. Even the kernel-source is pretty pristine, except that we run make oldconfig on it first. Actually, what's wrong with simply re-generating the changelog/control files all the time and accepting whatever the kernel build process thinks the version is? Well, then all the things built by dpkg-buildpackage might get all out of skew, no? Also, ./debian/rules binary; ./debian/rules clean; ./debian/rules binary; is no longer idempotent. Not enough people are kernel hackers for that mode to be the default mode of operation. manoj -- As long as we're going to reinvent the wheel again, we might as well try making it round this time.- Mike Dennison Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Fri, 2007-05-04 at 21:02 -0500, Manoj Srivastava wrote: Well. I think I want to make a) work here as well. So, one thing I can do is if $(SHELL /bin/sh scripts/setlocalversion) is not null, then append -dirty to it (since make-kpkg does make changes to the Makefile there, so ./debian is not nuked during dpkg-buildpackage). I think this might work. Why not simply make the changes before control/changelog are generated? That way, -dirty will be present automatically. Well. This is a shortcoming I want to solve. You see, with all the localversion addenda possible now, and with the possibility someone will come up with other ways to much with version numbers, I wanted to just run make to determine what the localversion was. Ah. I'm beginning to understand the issue here. You could do as I said above, but then somebody could reconfigure the kernel and add a localversion in the config which would screw up make-kpkg again. Hmm. It seems that ought to be a clear case of don't do that then. Or actually, since make-kpkg requires that you configure the kernel before running it, it'd actually work to do the changes to scripts/ before generating control and changelog. Actually, what's wrong with simply re-generating the changelog/control files all the time and accepting whatever the kernel build process thinks the version is? johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Mon, 30 Apr 2007 14:12:35 +0200, Johannes Berg [EMAIL PROTECTED] said: Hi, The setlocalversion script goes and changes the version of the kernel _after_ ./debian/ has been populated, which causes the ./debian/changelog and ./debian/control files to be out of synch with what the kernel thinks the version is -- and thus preventing the .deb from building. In any case, the setlocal version script always adds the -dirty- string to the version name -- since the ./scripts stuff also unconditionally nukes ./debian (whether or not it created it), which means that dpkg-buildpackage suddenly gets rid of /debian right at the beginning unless we intervene -- and intervening makes stuff dirty, and that changes the version number. So, given the way that ./scripts stuff messes up the build process, setlocalversion is not supported by make-kpkg. All of this is true, but only if you invoke make-kpkg only once in the same kernel tree or after the kernel tree has already been built which typically happens in development trees. I am not sure I understand these words. It seems to me that the two cases you cite (invoking make-kpkg once, and invoking it again after the kernel has been built) cover all possible cases. If something is true in all possible cases, is it not true universally? However, I still don't see this as a reason to kill the setlocalversion script, make-kpkg could instead warn loudly when CONFIG_LOCALVERSION_AUTO is set and tell the user to not do that because it messes up the build process. What is the difference? make-kpkg clean restores the script, so it is not as if it is lost; and since the script messes up the make-kpkg build, why _not_ nuke it for the duration? manoj -- Where the system is concerned, you're not allowed to ask Why?. Manoj Srivastava [EMAIL PROTECTED] [EMAIL PROTECTED] 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Fri, 2007-05-04 at 14:10 -0500, [EMAIL PROTECTED] wrote: I am not sure I understand these words. It seems to me that the two cases you cite (invoking make-kpkg once, and invoking it again after the kernel has been built) cover all possible cases. If something is true in all possible cases, is it not true universally? Hmm? I don't think I understand that :) What is the difference? make-kpkg clean restores the script, so it is not as if it is lost; and since the script messes up the make-kpkg build, why _not_ nuke it for the duration? But I like having debian packages with the gX...X-dirty version :) What I usually did was hack on the kernel, make, make M=... until it all compiles, make again, then invoke make-kpkg kernel_image and install the result. This allows me to remove everything from the kernel in a clean way. This used to work very well, I got debian packages with version 2.6.21-g65c44b40-dirty and was generally happy with that. Now kernel-package kills the setlocalversion script leaving me with the package version 2.6.21 which is fairly useless since I have many versions of 2.6.21. From what I can tell, nuking setlocalversion seems to be done for the case where (1) the kernel source is pristine and wasn't built before, so setlocalversion wasn't invoked before (2) the user has for some stupid reason set CONFIG_LOCALVERSION_AUTO (3) that user is now trying to build a kernel with make-kpkg (2) is why I'm questioning the point of nuking setlocalversion, any sane debian kernel build surely won't be setting CONFIG_LOCALVERSION_AUTO since it'll possibly even be included in the resulting kernel binary as /proc/config[.gz] and simply be wrong because setlocalversion was nuked Right now I'm working around this by invoking make-kpkg, waiting until it has nuked setlocalversion, aborting it, putting setlocalversion back and invoking make-kpkg again :) johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Fri, 04 May 2007 21:40:24 +0200, Johannes Berg [EMAIL PROTECTED] said: But I like having debian packages with the gX...X-dirty version :) What I usually did was hack on the kernel, make, make M=... until it all compiles, make again, then invoke make-kpkg kernel_image and install the result. This allows me to remove everything from the kernel in a clean way. This used to work very well, I got debian packages with version 2.6.21-g65c44b40-dirty and was generally happy with that. Now kernel-package kills the setlocalversion script leaving me with the package version 2.6.21 which is fairly useless since I have many versions of 2.6.21. From what I can tell, nuking setlocalversion seems to be done for the case where (1) the kernel source is pristine and wasn't built before, so setlocalversion wasn't invoked before (2) the user has for some stupid reason set CONFIG_LOCALVERSION_AUTO (3) that user is now trying to build a kernel with make-kpkg (2) is why I'm questioning the point of nuking setlocalversion, any sane debian kernel build surely won't be setting CONFIG_LOCALVERSION_AUTO since it'll possibly even be included in the resulting kernel binary as /proc/config[.gz] and simply be wrong because setlocalversion was nuked Right now I'm working around this by invoking make-kpkg, waiting until it has nuked setlocalversion, aborting it, putting setlocalversion back and invoking make-kpkg again :) OK. Since you are using git kernels, perhaps you can try this experiment: Edit the file /usr/share/kernel-package/ruleset/targets/target.mk, change line 162 from: (echo #!/bin/sh; echo : echo ) scripts/setlocalversion) to (echo #!/bin/sh; echo : echo ) scripts/setlocalversion.1) That will prevent make-kpkg from nuking the setlocalversion script. Now, get a fresh kernel tree, and see if running make-kpkg works. I want to see if: a) running make-kpkg on a pristine git tree works b) make some change (add/delete whitespace, or something, so the tree is not pristine, and run make-kpkg again. Does it still work? c) Get another pristine git tree, where make-kpkg has not been run. Now make a change -- so the tree is dirty. _Then_ run make-kpkg. Does that work? If the only failure mode is when CONFIG_LOCALVERSION_AUTO is set, then I'll just detect that and halt early, and stop nuking the setlocalversion script. I think we want make-kpkg to still work out of the box for the three cases above. manoj -- wok, n.: Something to thwow at a wabbit. Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418845: kernel-package insists on overwriting setlocalversion script
Hi Manoj, OK. Since you are using git kernels, perhaps you can try this experiment: Sure. a) running make-kpkg on a pristine git tree works b) make some change (add/delete whitespace, or something, so the tree is not pristine, and run make-kpkg again. Does it still work? c) Get another pristine git tree, where make-kpkg has not been run. Now make a change -- so the tree is dirty. _Then_ run make-kpkg. Does that work? Ok, let's see. First run: CONFIG_LOCALVERSION_AUTO is set: $ sh scripts/setlocalversion -g65c44b40[no newline] a) running make-kpkg by itself creates debian/changelog with version 2.6.21-g65c44b40-pb1 (-pb1 is my local configuration) running it with kernel_image argument starts compiling, and UTS_RELEASE gets set to 2.6.21-g65c44b40-dirty; the kernel then builds and finally make-kpkg reports: The UTS Release version in include/linux/utsrelease.h 2.6.21-g65c44b40-dirty does not match current version: 2.6.21-g65c44b40 Please correct this. b) make-kpkg has already dirtied the tree (scripts/package/builddeb for example), just rerunning make-kpkg kernel_image gives: The changelog says we are creating 2.6.21-g65c44b40 However, I thought the version is 2.6.21-g65c44b40-dirty c) works just fine, creates version 2.6.21-g65c44b40-dirty-pb1 Now the same without CONFIG_LOCALVERSION_AUTO a) works fine, creates package version 2.6.21-pb1 b) same as before, the tree isn't pristine anyway after invoking make-kpkg. it still works fine and creates 2.6.21-pb1 again c) works fine, creates package version 2.6.21-pb1 So exactly as I claimed before, the problem you're trying to solve only happens when CONFIG_LOCALVERSION_AUTO is set and you're building from a git tree. My typical use case is (c), so I don't care that (a) and (b) don't work when CONFIG_LOCALVERSION_AUTO is set. If the only failure mode is when CONFIG_LOCALVERSION_AUTO is set, then I'll just detect that and halt early, and stop nuking the setlocalversion script. I'd very much appreciate a way out in that case :) I think we want make-kpkg to still work out of the box for the three cases above. Unfortunately CONFIG_LOCALVERSION_AUTO is set by default even though it only has an effect on git trees. Where do the default config files come from? make-kpkg doesn't work on a tree without a .config. johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
On Sat, 05 May 2007 02:27:00 +0200, Johannes Berg [EMAIL PROTECTED] said: Ok, let's see. First run: CONFIG_LOCALVERSION_AUTO is set: $ sh scripts/setlocalversion -g65c44b40[no newline] a) running make-kpkg by itself creates debian/changelog with version 2.6.21-g65c44b40-pb1 (-pb1 is my local configuration) running it with kernel_image argument starts compiling, and UTS_RELEASE gets set to 2.6.21-g65c44b40-dirty; the kernel then builds and finally make-kpkg reports: The UTS Release version in include/linux/utsrelease.h 2.6.21-g65c44b40-dirty does not match current version: 2.6.21-g65c44b40 Please correct this. b) make-kpkg has already dirtied the tree (scripts/package/builddeb for example), just rerunning make-kpkg kernel_image gives: The changelog says we are creating 2.6.21-g65c44b40 However, I thought the version is 2.6.21-g65c44b40-dirty c) works just fine, creates version 2.6.21-g65c44b40-dirty-pb1 Now the same without CONFIG_LOCALVERSION_AUTO a) works fine, creates package version 2.6.21-pb1 b) same as before, the tree isn't pristine anyway after invoking make-kpkg. it still works fine and creates 2.6.21-pb1 again c) works fine, creates package version 2.6.21-pb1 So exactly as I claimed before, the problem you're trying to solve only happens when CONFIG_LOCALVERSION_AUTO is set and you're building from a git tree. My typical use case is (c), so I don't care that (a) and (b) don't work when CONFIG_LOCALVERSION_AUTO is set. Well. I think I want to make a) work here as well. So, one thing I can do is if $(SHELL /bin/sh scripts/setlocalversion) is not null, then append -dirty to it (since make-kpkg does make changes to the Makefile there, so ./debian is not nuked during dpkg-buildpackage). I think this might work. Unfortunately CONFIG_LOCALVERSION_AUTO is set by default even though it only has an effect on git trees. Where do the default config files come from? make-kpkg doesn't work on a tree without a .config. Well. This is a shortcoming I want to solve. You see, with all the localversion addenda possible now, and with the possibility someone will come up with other ways to much with version numbers, I wanted to just run make to determine what the localversion was. But now, running make at the top level just causes kbuild to fail: , | __ make -f /usr/share/kernel-package/ruleset/kernel_version.mk debian_KERNELRELEASE | HOSTCC scripts/basic/fixdep | HOSTCC scripts/basic/docproc | HOSTCC scripts/kconfig/conf.o | HOSTCC scripts/kconfig/kxgettext.o | SHIPPED scripts/kconfig/zconf.tab.c | SHIPPED scripts/kconfig/lex.zconf.c | SHIPPED scripts/kconfig/zconf.hash.c | HOSTCC scripts/kconfig/zconf.tab.o | HOSTLD scripts/kconfig/conf | scripts/kconfig/conf -s arch/i386/Kconfig | *** | *** You have not yet configured your kernel! | *** | *** Please run some configurator (e.g. make oldconfig or | *** make menuconfig or make xconfig). | *** | make[2]: *** [silentoldconfig] Error 1 | make[1]: *** [silentoldconfig] Error 2 ` , | __ make include/config/kernel.release | HOSTCC scripts/basic/fixdep | HOSTCC scripts/basic/docproc | HOSTCC scripts/kconfig/conf.o | HOSTCC scripts/kconfig/kxgettext.o | SHIPPED scripts/kconfig/zconf.tab.c | SHIPPED scripts/kconfig/lex.zconf.c | SHIPPED scripts/kconfig/zconf.hash.c | HOSTCC scripts/kconfig/zconf.tab.o | HOSTLD scripts/kconfig/conf | scripts/kconfig/conf -s arch/i386/Kconfig | *** | *** You have not yet configured your kernel! | *** | *** Please run some configurator (e.g. make oldconfig or | *** make menuconfig or make xconfig). | *** | make[2]: *** [silentoldconfig] Error 1 | make[1]: *** [silentoldconfig] Error 2 | make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. ` I suppose I can just grab snippets from the top level Makefile and do my own version and localversion calculations instead of running make, but that can get rapidly tricky (like, I have to remember to make script). Alternately, I can check to see what the Major/Minor/sublevel values are, and call make defconfig for 2.6.18+ kernels -- andget rid of the abort when we do not have a .config file. manoj -- You don't drown by falling into water. You drown by staying there. Robert Allen Manoj Srivastava [EMAIL PROTECTED] http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418845: kernel-package insists on overwriting setlocalversion script
Hi, The setlocalversion script goes and changes the version of the kernel _after_ ./debian/ has been populated, which causes the ./debian/changelog and ./debian/control files to be out of synch with what the kernel thinks the version is -- and thus preventing the .deb from building. In any case, the setlocal version script always adds the -dirty- string to the version name -- since the ./scripts stuff also unconditionally nukes ./debian (whether or not it created it), which means that dpkg-buildpackage suddenly gets rid of /debian right at the beginning unless we intervene -- and intervening makes stuff dirty, and that changes the version number. So, given the way that ./scripts stuff messes up the build process, setlocalversion is not supported by make-kpkg. All of this is true, but only if you invoke make-kpkg only once in the same kernel tree or after the kernel tree has already been built which typically happens in development trees. However, I still don't see this as a reason to kill the setlocalversion script, make-kpkg could instead warn loudly when CONFIG_LOCALVERSION_AUTO is set and tell the user to not do that because it messes up the build process. johannes signature.asc Description: This is a digitally signed message part
Bug#418845: kernel-package insists on overwriting setlocalversion script
Package: kernel-package Version: 10.068 Severity: normal During development, I like to package my kernels so I always have a clear packaged version of the kernel that I'm running and can always go back to that version. For this, I like using kernel-package. However, recently, kernel-package started totally getting into my way by overwriting the setlocalversion script the kernel has. The setlocalversion fulfils a purpose here, it allows developers to track which git version the kernel had when it was compiled. Somebody apparently thought this was stupid: # work around idiocy in recent kernel versions [...] (echo #!/bin/sh; echo : echo ) scripts/setlocalversion) [...] Unfortunately, doing that defeats the purpose of the setlocalversion script. Since the setlocalversion script is only run when CONFIG_LOCALVERSION_AUTO is set, there doesn't seem to be a point in overwriting a script, packagers can simply not set CONFIG_LOCALVERSION_AUTO in the kernel configuration and there is no need to overwrite setlocalversion any more. I'd like to ask that this hack is removed as it hampers at least my use of the kernel-package tools. If this is not possible, could it be made optional by some configuration item that can be turned off? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.21-rc6-gf4e2dd4a-dirty Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii dpkg 1.13.25package maintenance system for Deb ii dpkg-dev 1.13.25package building tools for Debian ii file 4.20-4 Determines file type using magic ii gcc [c-compiler] 4:4.1.2-1 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-5The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-3The GNU C compiler ii gettext 0.16.1-1 GNU Internationalization utilities ii make 3.81-3 The GNU version of the make util ii perl 5.8.8-7Larry Wall's Practical Extraction ii po-debconf1.0.8 manage translated Debconf template Versions of packages kernel-package recommends: ii bzip2 1.0.3-6high-quality block-sorting file co ii libc6-dev [libc-dev] 2.5-0exp6 GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
