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?
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
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? (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?
> "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]
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 -- 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? (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? (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
Eduard Bloch <[EMAIL PROTECTED]> writes: > #include > * 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?
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 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 (was: Successful and unsuccessful Debian development tools)
#include * 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]
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)
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)
