Re: Building in chroots hides bugs?
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: Outside the chroot, where you probably have auto* installed the invocation suddenly works and you get a different generated file that might or might not fail. They would immediately fail anyway on the autobuilds. -- ciao, Marco NO. As said in the part you didn't paste the auto* invocation fails but the build continous anyway and then succeeds. That realy does happen and isn't even that uncommon. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
* martin f krafft [EMAIL PROTECTED] [060801 18:17]: also sprach Bernhard R. Link [EMAIL PROTECTED] [2006.08.01.1701 +0100]: Missing $(DESTDIR)s in Makefiles are an example. Especially when the install part was DESTDIRified, but the test before if the file is already there (as make install does not want to overwrite a config file) was forgotten. This leads to a corrupt package when build on a system where the package is already installed, i.e. is hidden away in any clean chroot. This makes zero sense to me. Consider (in Makefile.in): install: [...] [...] -if [ ! -f $(sysconfdir)/Bla ]; then \ $(INSTALL) -m644 $(srcdir)/Bla $(DESTDIR)$(sysconfdir)/Bla \ fi This is clearly a bug, most likely someone added DESTDIR later and forgot it in the test. But unless that package build depends on itself, you will never find it when building in a clean chroot. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs?
Neil McGovern [EMAIL PROTECTED] writes: On Tue, Aug 01, 2006 at 05:37:58PM +0200, Goswin von Brederlow wrote: martin f krafft [EMAIL PROTECTED] writes: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing Build-Conflicts aren't found. Auto* scripts fail to run because they aren't installed. Users, Groups, dirs, binaries don't exist that would outisde which can influence configure. If a package failts to build from source in a chroot environment, it will fail to build on the autobuilders, and should thus be considered RC buggy. Neil That are the simple cases. But many packages don't want to run auto*, don't Build-Depend on them and their invocation fails but gets ignored. The package then build fine. Outside the chroot, where you probably have auto* installed the invocation suddenly works and you get a different generated file that might or might not fail. Is that clearer? He was asking for things that work inside but fail outside. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs?
On Aug 04, Goswin von Brederlow [EMAIL PROTECTED] wrote: Outside the chroot, where you probably have auto* installed the invocation suddenly works and you get a different generated file that might or might not fail. They would immediately fail anyway on the autobuilds. -- ciao, Marco signature.asc Description: Digital signature
Building in chroots (was: Successful and unsuccessful Debian development tools)
[EMAIL PROTECTED] (Marco d'Itri) wrote: On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Building in chroots *hides* bugs. Of course. However, not building in chroots also hides bugs. Why do you think it's better to build in a chroot? I think a package should be built on the developer's system (which, hopefully, is a typical example for the environment were the package will be used and built), and in a clean chroot. It should be tested (in the sense of: Can it be installed? Does it run at all?) in a chroot, and also on the developer's system. Of course the amount of testing needed depends on the extent of the changes. But not testing at all in a clean environment isn't a good idea, at least with the packages that I work with. In particular because I frequently have locally changed configuration files, which may hide some bugs, too. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system emacs sucks, literally, not an insult, just a comment that it's large enough to have a noticeable gravitational pull... -- mercury on #debian-devel signature.asc Description: Digital signature (GPG/PGP)
Re: Building in chroots (was: Successful and unsuccessful Debian development tools)
#include hallo.h * Frank Küster [Tue, Aug 01 2006, 01:55:14PM]: [EMAIL PROTECTED] (Marco d'Itri) wrote: On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Argh, the smiley was there for a reason... Building in chroots *hides* bugs. Of course. However, not building in chroots also hides bugs. Why do you think it's better to build in a chroot? After all, I think after comparing pros and cons the bill will be even. But at much higher processing costs. I am sceptical about pbuilder because of it, and because it leads to too much thrust into the tool instead of thinking about possible consequences of changes. I think a package should be built on the developer's system (which, hopefully, is a typical example for the environment were the package will be used and built), and in a clean chroot. It should be tested (in I think it should be working in both, therefore I like the general concept of building in normal environment and uploading package as source trough the auto-builder. the sense of: Can it be installed? Does it run at all?) in a chroot, and also on the developer's system. Of course the amount of testing needed depends on the extent of the changes. Testing is not always enough to catch all possible bugs. Eduard. -- Ich bin sicher, käme Jesus heute, würde er von der Kirche nicht erkannt, sondern wahrscheinlich verfolgt und wieder zu Tode gemartert werden. -- Henry Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
On 8/1/06, martin f krafft [EMAIL PROTECTED] wrote: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. The only example I can think of is programs that use configure to include support for anything they can find installed. So you get different results depending on what's installed in the buildd. It's a bug in the packaging though, the maintainer should be doing --enable-* or --disable-* for every option. The point being that if you only build in a clean chroot you'll never notice the problem. That's how I understand it anyway, Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs?
martin f krafft [EMAIL PROTECTED] writes: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing Build-Conflicts aren't found. Auto* scripts fail to run because they aren't installed. Users, Groups, dirs, binaries don't exist that would outisde which can influence configure. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Frank Küster [Tue, Aug 01 2006, 01:55:14PM]: [EMAIL PROTECTED] (Marco d'Itri) wrote: On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Argh, the smiley was there for a reason... Building in chroots *hides* bugs. Of course. However, not building in chroots also hides bugs. Why do you think it's better to build in a chroot? After all, I think after comparing pros and cons the bill will be even. But at much higher processing costs. I am sceptical about pbuilder because of it, and because it leads to too much thrust into the tool instead of thinking about possible consequences of changes. Yeah. I always develope outside (or in an unclean) chroot and when I want to release I mangle the source through a clean chroot / buildd again for a final test. I think a package should be built on the developer's system (which, hopefully, is a typical example for the environment were the package will be used and built), and in a clean chroot. It should be tested (in I think it should be working in both, therefore I like the general concept of building in normal environment and uploading package as source trough the auto-builder. That won't test your binary-all target as small as that part is. the sense of: Can it be installed? Does it run at all?) in a chroot, and also on the developer's system. Of course the amount of testing needed depends on the extent of the changes. Testing is not always enough to catch all possible bugs. But not testing is a sure way to overlook them. :) Eduard. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
* martin f krafft [EMAIL PROTECTED] [060801 15:29]: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing $(DESTDIR)s in Makefiles are an example. Especially when the install part was DESTDIRified, but the test before if the file is already there (as make install does not want to overwrite a config file) was forgotten. This leads to a corrupt package when build on a system where the package is already installed, i.e. is hidden away in any clean chroot. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
also sprach Bernhard R. Link [EMAIL PROTECTED] [2006.08.01.1701 +0100]: Missing $(DESTDIR)s in Makefiles are an example. Especially when the install part was DESTDIRified, but the test before if the file is already there (as make install does not want to overwrite a config file) was forgotten. This leads to a corrupt package when build on a system where the package is already installed, i.e. is hidden away in any clean chroot. This makes zero sense to me. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system eine schlechte sache erregt, eine gute verträgt viel kritik. -- charles tschopp signature.asc Description: Digital signature (GPG/PGP)
Re: Building in chroots hides bugs?
On Tue, Aug 01, 2006 at 05:37:58PM +0200, Goswin von Brederlow wrote: martin f krafft [EMAIL PROTECTED] writes: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing Build-Conflicts aren't found. Auto* scripts fail to run because they aren't installed. Users, Groups, dirs, binaries don't exist that would outisde which can influence configure. If a package failts to build from source in a chroot environment, it will fail to build on the autobuilders, and should thus be considered RC buggy. Neil -- gwolf bah Germans. You just put 100 DDs in one country and then they all become friends of each other. signature.asc Description: Digital signature
Re: Building in chroots hides bugs?
Martijn == Martijn van Oosterhout [EMAIL PROTECTED] writes: Martijn The only example I can think of is programs that use Martijn configure to include support for anything they can find Martijn installed. So you get different results depending on Martijn what's installed in the buildd. It's a bug in the Martijn packaging though, the maintainer should be doing Martijn --enable-* or --disable-* for every option. The point Martijn being that if you only build in a clean chroot you'll Martijn never notice the problem. In my experience these bugs generally occur when a user installs a library that I have never used/heard of before - as such I generally miss them regardless of the build environment. Even if I did happen to have that library accidently installed for the build - I probably wouldn't notice that there is a minor (perhaps obsolete) feature enabled with no corresponding build-depends. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
