Re: bug in tar 1.14-2.1
On Tue, 2006-03-28 at 05:27 +0200, Goswin von Brederlow wrote: Again? I wrote a bug about this years ago with a fix. I think is was just adding --rsh=/usr/bin/rsh to the configure call. Your patch in response to 185594 added an RSH environment variable definition to the configure invocation. The problem now is that if the 'make' invocation ends up re-running configure, that definition isn't present. So, the easy fix is to define the same environment variable for the make invocation. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
* Martin Zobel-Helas ([EMAIL PROTECTED]) [060324 16:00]: Looks like just rebuilding the security version resolves that error, for whatever reason. Julien and me just cross checked that and got the same result. If noone minds we reupload tar with a bumped version number to s-p-u. Is a binary-only upload enough? If so, why not just queue a binNMU by the buildd? (And one should check all the archs BTW, and also add a test suite one day :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Hi Andi, On Monday, 27 Mar 2006, you wrote: * Martin Zobel-Helas ([EMAIL PROTECTED]) [060324 16:00]: Looks like just rebuilding the security version resolves that error, for whatever reason. Julien and me just cross checked that and got the same result. If noone minds we reupload tar with a bumped version number to s-p-u. Is a binary-only upload enough? If so, why not just queue a binNMU by the buildd? (And one should check all the archs BTW, and also add a test suite one day :) as Julien and me found out, tar works only if either ssh is installed or the correct enviroment variables are set. As ssh is not installed per default in buildd enviroment we need to patch the rules-file to get the correct enviroment variables set. So, no, binNMU is not enough (only if you can persue all buildd maintainers to install ssh inside the changeroot per default ;) ) Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Martin Zobel-Helas [EMAIL PROTECTED] writes: Hi Andi, On Monday, 27 Mar 2006, you wrote: * Martin Zobel-Helas ([EMAIL PROTECTED]) [060324 16:00]: Looks like just rebuilding the security version resolves that error, for whatever reason. Julien and me just cross checked that and got the same result. If noone minds we reupload tar with a bumped version number to s-p-u. Is a binary-only upload enough? If so, why not just queue a binNMU by the buildd? (And one should check all the archs BTW, and also add a test suite one day :) as Julien and me found out, tar works only if either ssh is installed or the correct enviroment variables are set. As ssh is not installed per default in buildd enviroment we need to patch the rules-file to get the correct enviroment variables set. So, no, binNMU is not enough (only if you can persue all buildd maintainers to install ssh inside the changeroot per default ;) ) Greetings Martin Again? I wrote a bug about this years ago with a fix. I think is was just adding --rsh=/usr/bin/rsh to the configure call. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
On Fri, 2006-03-24 at 22:07 +0100, Julien Danjou wrote: Finally, I solved it this way: diff -u tar-1.14/debian/rules tar-1.14/debian/rules --- tar-1.14/debian/rules +++ tar-1.14/debian/rules @@ -16,7 +16,7 @@ build-stamp: dh_testdir - $(MAKE) + RSH=/usr/bin/rsh CFLAGS=-O2 -g -Wall $(MAKE) (cd tests ; $(MAKE) check-TESTS) touch build-stamp It certainly seems to make sense to provide the same environment to make that we're using for configure, so I'll add this to my CVS for the next upload to unstable. If that is sufficient to ensure a clean build of a 1.14-2.2 version on all architectures affected by the bug in question, I have no problem with that change being included for the next stable update. However, I don't immediately understand why the auto* tools are being invoked by make during this build? Reviewing the tar changelog, I made explicit reference for 1.14-1 that autoconf and automake build dependencies were elminated. Nothing I changed for 1.14-2 should have affected that, and it's not obvious that anything in the diff between -2 and -2.1 should have affected that either. However, I left in place the code in the debian/rules file that updates config.sub and config.guess in the 'clean' target *if* autotools-dev is installed. So, I wonder if the underlying problem is that those files are being updated and somehow triggering this behavior? Goswin indicates in his reply to this message that we should touch the files in the right order, but I'm not sure what that refers to in this case? For 1.15.1-4, I re-introduced a dependency on autoconf in response to #354194. In hindsight, that may not have been the right thing to do... and even if it was the right thing to do, I'm not sure it was really sufficient. It would seem desireable to not run the auto* tools on every build if we don't need to, yet if we're going to then there should probably be an autotools-dev build dependency, etc? For whatever reason, I'm having a hard time thinking clearly about this today, and so advice and/or suggested patches for the version currently in unstable to do the right thing in the future would be appreciated. Regards, Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
On 2006-03-25 Bdale Garbee [EMAIL PROTECTED] wrote: [...] However, I don't immediately understand why the auto* tools are being invoked by make during this build? [...] [EMAIL PROTECTED]:/tmp$ lsdiff -z tar_1.14-2.1.diff.gz | \ egrep -v '/debian/|/src/' tar-1.14/config/config.guess tar-1.14/config/config.sub tar-1.14/po/de.po tar-1.14/configure.ac tar-1.14/doc/tar.texi You are patching configure.ac, which causes auto* to try to regenerate ./configure. Remove the patchlet and it should build fine. As you are not shipping the corresponding change to ./configure the thing is ineffictive anyway, unless you are rebuildung on a system that has the whole auto* shebang installed.[1] hth, cu andreas [1] It actually FTBFS for me, with auto* installed: cd . /bin/bash /tmp/tar-1.14/config/missing --run aclocal-1.8 -I m4 aclocal: m4/gettext.m4: 378: macro `AM_LC_MESSAGES' not found in library aclocal: macro `jm_GLIBC21' required but not defined make: *** [aclocal.m4] Error 1 -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Andreas Metzler [EMAIL PROTECTED] writes: On 2006-03-25 Bdale Garbee [EMAIL PROTECTED] wrote: [...] However, I don't immediately understand why the auto* tools are being invoked by make during this build? [...] [EMAIL PROTECTED]:/tmp$ lsdiff -z tar_1.14-2.1.diff.gz | \ egrep -v '/debian/|/src/' tar-1.14/config/config.guess tar-1.14/config/config.sub tar-1.14/po/de.po tar-1.14/configure.ac tar-1.14/doc/tar.texi You are patching configure.ac, which causes auto* to try to regenerate ./configure. Remove the patchlet and it should build fine. As you are not shipping the corresponding change to ./configure the thing is ineffictive anyway, unless you are rebuildung on a system that has the whole auto* shebang installed.[1] hth, cu andreas [1] It actually FTBFS for me, with auto* installed: cd . /bin/bash /tmp/tar-1.14/config/missing --run aclocal-1.8 -I m4 aclocal: m4/gettext.m4: 378: macro `AM_LC_MESSAGES' not found in library aclocal: macro `jm_GLIBC21' required but not defined make: *** [aclocal.m4] Error 1 And remeber, if you ship a patch for configure and configure.ac then the files will have timestamps in the same order as they are in the diff, which is probably random. To make sure the timestamps fit you have to touch configure.ac; touch configure in rules then. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
On Sat, 2006-03-25 at 18:36 +0100, Andreas Metzler wrote: On 2006-03-25 Bdale Garbee [EMAIL PROTECTED] wrote: [...] However, I don't immediately understand why the auto* tools are being invoked by make during this build? [...] [EMAIL PROTECTED]:/tmp$ lsdiff -z tar_1.14-2.1.diff.gz | \ egrep -v '/debian/|/src/' tar-1.14/config/config.guess tar-1.14/config/config.sub tar-1.14/po/de.po tar-1.14/configure.ac tar-1.14/doc/tar.texi You are patching configure.ac, which causes auto* to try to regenerate ./configure. Remove the patchlet and it should build fine. Aha! Thanks. Somehow, I missed that. The only change was part of a patch from upstream to replace a buggy use of valloc with use of malloc instead, such that configure no longer needed to test for the presence of valloc. I can see no problem with undoing that change in configure.ac and touching configure. [1] It actually FTBFS for me, with auto* installed: Interesting. I'm not very motivated to chase that down in 1.14, if for no other reason than unstable is using 1.15 at this point. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
Hi mollo, On Sunday, 19 Mar 2006, you wrote: On Tue, 7 Mar 2006 15:19:58 +0100 using tar 1.14-2.1 fw:/home/mathieu# tar --rmt-command=/usr/sbin/rmt -cvf '[EMAIL PROTECTED]:/home/mathieu/test.tgz' /etc tar: [EMAIL PROTECTED]:/home/mathieu/test.tgz: Cannot open: Input/output error tar: Error is not recoverable: exiting now ack, same here. i can reproduce that error. using old tar 1.14-2 : fw:/home/mathieu# tar.ori --rmt-command=/usr/sbin/rmt -cvf '[EMAIL PROTECTED]:/home/mathieu/test.tgz' /etc/ssh Password: tar.ori: Removing leading `/' from member names /etc/ssh/ Looks like just rebuilding the security version resolves that error, for whatever reason. Julien and me just cross checked that and got the same result. If noone minds we reupload tar with a bumped version number to s-p-u. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
On Fri, 2006-03-24 at 15:53 +0100, Martin Zobel-Helas wrote: If noone minds we reupload tar with a bumped version number to s-p-u. Ok with me. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: bug in tar 1.14-2.1
On Fri, Mar 24, 2006 at 03:53:03PM +0100, Martin Zobel-Helas wrote: Looks like just rebuilding the security version resolves that error, for whatever reason. Julien and me just cross checked that and got the same result. We tried to reproduce the bug with zobel, and finally discovered the Truth. I'll try to explain: $ apt-get source tar=1.14-2.1 $ cd tar-1.14 $ debuild ../first-build.log $ grep REMOTE_SHELL config.h /* #undef REMOTE_SHELL */ $ debuild ../second-build.log $ grep REMOTE_SHELL config.h #define REMOTE_SHELL /usr/bin/rsh And with the diff between log files it is obvious, in the first run we can see: /usr/bin/make make[1]: Entering directory `/home/tar-1.14' cd . /bin/sh /home/tar-1.14/config/missing --run aclocal-1.8 -I m4 /home/tar-1.14/config/missing: line 52: aclocal-1.8: command not found WARNING: `aclocal-1.8' is missing on your system. You should only need it if you modified `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . /bin/sh /home/tar-1.14/config/missing --run automake-1.8 --gnits /home/tar-1.14/config/missing: line 52: automake-1.8: command not found WARNING: `automake-1.8' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . /bin/sh /home/tar-1.14/config/missing --run autoconf /home/tar-1.14/config/missing: line 52: autoconf: command not found WARNING: `autoconf' is missing on your system. You should only need it if you modified `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. /bin/sh ./config.status --recheck [...] So ./configure is launched again without $RSH environment variable set correctly. Finally, I solved it this way: diff -u tar-1.14/debian/rules tar-1.14/debian/rules --- tar-1.14/debian/rules +++ tar-1.14/debian/rules @@ -16,7 +16,7 @@ build-stamp: dh_testdir - $(MAKE) + RSH=/usr/bin/rsh CFLAGS=-O2 -g -Wall $(MAKE) (cd tests ; $(MAKE) check-TESTS) touch build-stamp Happy birthday Martin ! ;-) Regards, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: bug in tar 1.14-2.1
Julien Danjou [EMAIL PROTECTED] writes: On Fri, Mar 24, 2006 at 03:53:03PM +0100, Martin Zobel-Helas wrote: Looks like just rebuilding the security version resolves that error, for whatever reason. Julien and me just cross checked that and got the same result. We tried to reproduce the bug with zobel, and finally discovered the Truth. I'll try to explain: $ apt-get source tar=1.14-2.1 $ cd tar-1.14 $ debuild ../first-build.log $ grep REMOTE_SHELL config.h /* #undef REMOTE_SHELL */ $ debuild ../second-build.log $ grep REMOTE_SHELL config.h #define REMOTE_SHELL /usr/bin/rsh And with the diff between log files it is obvious, in the first run we can see: /usr/bin/make make[1]: Entering directory `/home/tar-1.14' cd . /bin/sh /home/tar-1.14/config/missing --run aclocal-1.8 -I m4 /home/tar-1.14/config/missing: line 52: aclocal-1.8: command not found WARNING: `aclocal-1.8' is missing on your system. You should only need it if you modified `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . /bin/sh /home/tar-1.14/config/missing --run automake-1.8 --gnits /home/tar-1.14/config/missing: line 52: automake-1.8: command not found WARNING: `automake-1.8' is missing on your system. You should only need it if you modified `Makefile.am', `acinclude.m4' or `configure.ac'. You might want to install the `Automake' and `Perl' packages. Grab them from any GNU archive site. cd . /bin/sh /home/tar-1.14/config/missing --run autoconf /home/tar-1.14/config/missing: line 52: autoconf: command not found WARNING: `autoconf' is missing on your system. You should only need it if you modified `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. /bin/sh ./config.status --recheck [...] You should touch the files in the right order so the timestamps match. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
