Re: More pbuilder use!
On Wed, 24 Aug 2005 06:15:08 +1000, Paul TBBle Hampson [EMAIL PROTECTED] said: On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarães wrote: ** Bastian Blank :: You have a linux kernel ready, which allows chroot as normal user? Please share it with us. It's called QEMU :-) Or pbuilder-uml, once someone gets onto the user-mode-linunx package (and kernel-patch-uml) and brings them back into shape so that the pbuilder-uml package can be re-enabled. I build in SELinux UML's. And, since kernel-package now supports building uml images, there is no need to have a single user-mode-linux package -- you can have multiple linux-uml packages of different versions installed. Someone just needs to change thepbuilder-uml dependencies to accept kernel-uml packages instead. manoj -- America, how can I write a holy litany in your silly mood? Allen Ginsberg Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 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]
Re: More pbuilder use!
Roger Leigh [EMAIL PROTECTED] writes: The chroot is not really suitable for anything but exclusive use by sbuild (otherwise you risk messing it up by installing random stuff so that it's no better than the host environment...). You could always use a separate chroot for user access, but I don't personally have the need (nor the free disk space). Regards, Roger I have debfoster installed automaticaly in all my chroots (as part of the create a chroot script) and I just run this every now and then: sudo debfoster -f -o RemoveCmd=apt-get --purge remove -y Remember that sbuild does not always clean up properly. Debfoster is my maid that does serious cleanup while sbuild just tries not to mess things up too bad. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On 8/23/05, Joe Smith [EMAIL PROTECTED] wrote: Actually perhaps software should be built outside of clean chroots. Why? Did someone suggest to disallow that? Why can't you do both?
Re: More pbuilder use!
Joe Smith writes: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. The probability that the developer has the particular package that will cause the build to fail installed is small, so the bug will most likely manifest itself on a user's system anyway. To find these bugs you need to get your package built on a variety of real world installations. Perhaps users of Unstable should be encouraged to build packages locally whenever convenient. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote: Actually perhaps software should be built outside of clean chroots. Why? Do I need to have root on the debian developer machines? I currently use that machines to build packages for architectures I don't own. Bastian -- The best diplomat I know is a fully activated phaser bank. -- Scotty signature.asc Description: Digital signature
Re: More pbuilder use!
** Joe Smith :: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. If a package Fails To Build From Source on a end-user system it is an RC bug. By bug definitions i would say a minimum of 'serious', but 'critical' would be better. Why? Simple: If users can make the changes they want, than Debian is NOT free. If it is not free, it has failed. I vehemently disagree. I think exactly the opposite: debbuild and/or dpkg-buildpackage should *always* build a package inside a clean and minimal chroot jail. This way, (1) every package will predictably build from (unchanged) source and (2) every variation that the user *wants* in his package becomes documented in the debian/* files. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote: I vehemently disagree. I think exactly the opposite: debbuild and/or dpkg-buildpackage should *always* build a package inside a clean and minimal chroot jail. This way, (1) every package will predictably build from (unchanged) source and (2) every variation that the user *wants* in his package becomes documented in the debian/* files. You have a linux kernel ready, which allows chroot as normal user? Please share it with us. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, The Corbomite Maneuver, stardate 1514.0 signature.asc Description: Digital signature
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 05:28:22PM +0200, Bastian Blank wrote: On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote: I vehemently disagree. I think exactly the opposite: debbuild and/or dpkg-buildpackage should *always* build a package inside a clean and minimal chroot jail. This way, (1) every package will predictably build from (unchanged) source and (2) every variation that the user *wants* in his package becomes documented in the debian/* files. You have a linux kernel ready, which allows chroot as normal user? Please share it with us. Not a kernel feature, but see http://packages.debian.org/unstable/admin/schroot (or check out http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/schroot/?cvsroot=buildd-tools) I have patches to make sbuild use schroot for building. http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2005-July/63.html I have been using sbuild to build all my packages for upload for several months now. It certainly does avoid brown paper bag uploads, and I definitely think it significantly improves the quality of my packaging work due to catching other bugs (additional/missing packages installed on the host system intefering with the build). Future plans include - LVM snapshot support (easy) - Xen support (also using LVM snapshots) (harder--you can't just open a shell, AFAICS) which will mean sbuild (and hence buildd) can start with a clean environment for each build, and at the end, you just throw away the snapshot. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tuesday 23 of August 2005 17:28, Bastian Blank wrote: On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote: I vehemently disagree. I think exactly the opposite: debbuild and/or dpkg-buildpackage should *always* build a package inside a clean and minimal chroot jail. This way, (1) every package will predictably build from (unchanged) source and (2) every variation that the user *wants* in his package becomes documented in the debian/* files. You have a linux kernel ready, which allows chroot as normal user? Please share it with us. Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the packages without root privileges. -- .''`.Piotr Roszatycki, Netia SA : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `-
Re: More pbuilder use!
** Bastian Blank :: You have a linux kernel ready, which allows chroot as normal user? Please share it with us. It's called QEMU :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote: On Tuesday 23 of August 2005 17:28, Bastian Blank wrote: On Tue, Aug 23, 2005 at 12:06:41PM -0300, Humberto Massa Guimarães wrote: I vehemently disagree. I think exactly the opposite: debbuild and/or dpkg-buildpackage should *always* build a package inside a clean and minimal chroot jail. This way, (1) every package will predictably build from (unchanged) source and (2) every variation that the user *wants* in his package becomes documented in the debian/* files. You have a linux kernel ready, which allows chroot as normal user? Please share it with us. Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the packages without root privileges. We all use fakeroot. The question was about the chroot system call which fakeroot does (and can not) not fake. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 07:26:25PM +0200, Wouter Verhelst wrote: On Tue, Aug 23, 2005 at 06:01:24PM +0200, Piotr Roszatycki wrote: Use fakechroot. Yes, it is ugly hack, but it allows me to recompile the ^^^ packages without root privileges. We all use fakeroot. The question was about the chroot system call ^ which fakeroot does (and can not) not fake. Ugh. Sorry, need to be more careful next time. But still. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Smith [EMAIL PROTECTED] writes: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. This is incorrect. Since the chroot environment is a full Debian installation in its own right, this is wrong. At least for me with by sbuild/schroot setup, I have a set of chroots, currently: $ schroot --list default sarge sid stable unstable But you can't build with sbuild until you have a .dsc, which means you first need to build /outside/ the chroot, and then queue it for building once you have done a successful build on the host system. Hence your concern is unjustified. You could do the initial build in the chroot, but because it's a minimal environment it's not geared for development, just building, which makes it impractical (no editors, for example). Bugs in a clean chroot build are generally build dependency issues, and the same issues are also present on the host system, but are not always detectable, particularly if configure picks enables some feature at random because of some random package being present. Uploading stuff not built in a chroot means the build is not independently reproducible, and might be different to the autobuilt version the other 10 architectures got. In this respect, i386 is kind of a second-class arch WRT the package build quality. Autobuilding all packages (whether or not we do source only uploads) would remove this cause of hard-to-find bugs and random breakage. If users can make the changes they want, than Debian is NOT free. I think you got that backwards ;-) Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFDC24RVcFcaSW/uEgRAqFJAKCMD3VD41IBQXhgKLlP3O14Nn26VgCfQf3m BBDT/v97/gGgTQ7ZukAVOYU= =bs/I -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote: Not a kernel feature, but see http://packages.debian.org/unstable/admin/schroot Does not help, each chroot needs to be setup by root and you need root priviledges to install packages in it. Bastian -- Madness has no purpose. Or reason. But it may have a goal. -- Spock, The Alternative Factor, stardate 3088.7 signature.asc Description: Digital signature
Re: More pbuilder use!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bastian Blank [EMAIL PROTECTED] writes: On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote: Not a kernel feature, but see http://packages.debian.org/unstable/admin/schroot Does not help, each chroot needs to be setup by root and you need root priviledges to install packages in it. You can give root privs to users just inside the chroot. That's what root_groups is for in the config file. The user doesn't need full root access to the host system (like with plain sbuild, which requires full sudo privs), though obviously it's still possible to subvert, but not as simple as with sudo. Either way, not something for untrusted users to have access to, but schroot does at least give you a bit more safety. Once it has Xen capability, it will give each user their own personal Xen instance. This will be created on the fly from e.g. an LVM snapshot or unionfs, but this can be configurable. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFDC4NYVcFcaSW/uEgRAnSAAKCKdscIjxyrTl3cOVOEPX/BdI7GlACgg5xo pYpCULVsUC42xO0rOqcYmA0= =ObRb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarães wrote: ** Bastian Blank :: You have a linux kernel ready, which allows chroot as normal user? Please share it with us. It's called QEMU :-) Or pbuilder-uml, once someone gets onto the user-mode-linunx package (and kernel-patch-uml) and brings them back into shape so that the pbuilder-uml package can be re-enabled. (Or at least, that's _my_ understanding of the situation...) -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpilvcCxIN5h.pgp Description: PGP signature
Re: More pbuilder use!
Nathanael Nerode [EMAIL PROTECTED] writes: Sven Luther wrote: All packages should be built by official debian buildds anyway, not on developper machines with random cruft and unsecure packages installed, or even possibly experimental or home-modified stuff. Actually, it's better yet if the packages are built on developer machines inside a clean pbuilder chroot. Rather than relying on the buildds, run your own better-than-buildd. ;-) Nobody should be uploading packages built outside a chroot. And yet so many many DDs do. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
Roberto C. Sanchez [EMAIL PROTECTED] writes: On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. If a package Fails To Build From Source on a end-user system it is an RC bug. By bug definitions i would say a minimum of 'serious', but 'critical' would be better. Why? Simple: If users can make the changes they want, than Debian is NOT free. If it is not free, it has failed. So, if I try to compile a random package with icc and it fails, that is How would it build with icc? icc is neither gcc nor cc. You have to use clean build scripts with a clean environment. I always suggest debuild since that cleans up automaticaly before calling dpkg-buildpackage. If you replace build-essential apckages with something custom and that breaks the source that is then obviously your problem. Worth reporting in case of icc but not with normal FTBFS priority. RC? That doesn't really make sense. At some point you need to draw the line. I think the clean-chroot build policy should be maintained. If users discover that a package does not build with some strange or non-standard combination of packages, then they are free to submit patches. However, the existence of such problems should not be considered RC since Debian is a binary distro. Build-Depends (and imho that includes Build-Conflicts) were a RC criterium for sarge and no doubt will be again for etch. Any failure to build on a system with only debian packages installed is imho a FTBFS bug with the severity layed out for FTBFS (i.e. RC if it did build before). Think about it. I could have maintained gcc-2.95 on my system becuase I like it (or need it/whatever). If tried to build some of the bleeding edge packages with it, it will likely fail. That does not make it RC since Debian doesn't even ship 2.95 anymore as the default. No it won't fail. You are required to have a current sid build-essential package installed which will upgrade gcc and pull in gcc-4.0. That implicit Build-Depends you have to have. If not then you are right, it isn't a bug in the package but in the user. Any installed gcc-2.95 would not be used by the build with a current build-essential unless it is a bug. -Roberto MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
Roger Leigh [EMAIL PROTECTED] writes: Joe Smith [EMAIL PROTECTED] writes: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. This is incorrect. Since the chroot environment is a full Debian installation in its own right, this is wrong. At least for me with by sbuild/schroot setup, I have a set of chroots, currently: $ schroot --list default sarge sid stable unstable But you can't build with sbuild until you have a .dsc, which means you first need to build /outside/ the chroot, and then queue it for building once you have done a successful build on the host system. Hence your concern is unjustified. debuild -S; sbuild You can circumvent it easy enough if you try. I often do debuild -us -uc -nc outside the chroot till i get the package to build and then build just source and dump it into the local buildd to confirm a full, clean build works too. You could do the initial build in the chroot, but because it's a minimal environment it's not geared for development, just building, which makes it impractical (no editors, for example). xemacs /mnt/chroot/home/mrvn/pkg/foo.c Not realy a problem. Bugs in a clean chroot build are generally build dependency issues, and the same issues are also present on the host system, but are not always detectable, particularly if configure picks enables some feature at random because of some random package being present. Uploading stuff not built in a chroot means the build is not independently reproducible, and might be different to the autobuilt version the other 10 architectures got. In this respect, i386 is kind of a second-class arch WRT the package build quality. Autobuilding all packages (whether or not we do source only uploads) would remove this cause of hard-to-find bugs and random breakage. Agreed. I fully support you there. If users can make the changes they want, than Debian is NOT free. I think you got that backwards ;-) Regards, Roger MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
Bastian Blank [EMAIL PROTECTED] writes: On Tue, Aug 23, 2005 at 05:04:57PM +0100, Roger Leigh wrote: Not a kernel feature, but see http://packages.debian.org/unstable/admin/schroot Does not help, each chroot needs to be setup by root and you need root priviledges to install packages in it. Bastian The fakechroot description says it is good enough to bootstrap. So that is not a problem. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow [EMAIL PROTECTED] writes: Roger Leigh [EMAIL PROTECTED] writes: I often do debuild -us -uc -nc outside the chroot till i get the package to build and then build just source and dump it into the local buildd to confirm a full, clean build works too. I do this also. You could do the initial build in the chroot, but because it's a minimal environment it's not geared for development, just building, which makes it impractical (no editors, for example). xemacs /mnt/chroot/home/mrvn/pkg/foo.c Not realy a problem. Sure, editors were just one thing. The point I failed to make was that for a dedicated sbuild chroot, you won't have the build-deps installed anyway, so without a lot of manual messing you won't be able to build in the chroot until you have a properly built package to feed to sbuild, which will then install and purge the deps for you. The chroot is not really suitable for anything but exclusive use by sbuild (otherwise you risk messing it up by installing random stuff so that it's no better than the host environment...). You could always use a separate chroot for user access, but I don't personally have the need (nor the free disk space). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQFDC5ExVcFcaSW/uEgRAo73AJ9ZRarGSvmkYkNUXQPjM3CPCBXlPACcDVra 4u4ILxgtcuASU3yR4a7xSXE= =eDfR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
More pbuilder use!
Sven Luther wrote: All packages should be built by official debian buildds anyway, not on developper machines with random cruft and unsecure packages installed, or even possibly experimental or home-modified stuff. Actually, it's better yet if the packages are built on developer machines inside a clean pbuilder chroot. Rather than relying on the buildds, run your own better-than-buildd. ;-) Nobody should be uploading packages built outside a chroot. -- Nathanael Nerode [EMAIL PROTECTED] [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. If a package Fails To Build From Source on a end-user system it is an RC bug. By bug definitions i would say a minimum of 'serious', but 'critical' would be better. Why? Simple: If users can make the changes they want, than Debian is NOT free. If it is not free, it has failed. -- If Debian is not free, it has failed. - Joe Smith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More pbuilder use!
On Tue, Aug 23, 2005 at 12:40:18AM -0400, Joe Smith wrote: Actually perhaps software should be built outside of clean chroots. Why? Because if there is a possibility that a dirty chroot will cause the package to fail, there is a bug in some peice of software. It could prevent a user from recompiling on his own system, which thusly defeats the point of having the source in the first place. If a package Fails To Build From Source on a end-user system it is an RC bug. By bug definitions i would say a minimum of 'serious', but 'critical' would be better. Why? Simple: If users can make the changes they want, than Debian is NOT free. If it is not free, it has failed. So, if I try to compile a random package with icc and it fails, that is RC? That doesn't really make sense. At some point you need to draw the line. I think the clean-chroot build policy should be maintained. If users discover that a package does not build with some strange or non-standard combination of packages, then they are free to submit patches. However, the existence of such problems should not be considered RC since Debian is a binary distro. Think about it. I could have maintained gcc-2.95 on my system becuase I like it (or need it/whatever). If tried to build some of the bleeding edge packages with it, it will likely fail. That does not make it RC since Debian doesn't even ship 2.95 anymore as the default. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpRR9XdTqJmb.pgp Description: PGP signature
