Re: GPL-licensed software linked against libssl on buildds!
On Tue, Feb 02, 2010 at 07:59:53AM +0100, Lucas Nussbaum wrote: On 02/02/10 at 01:07 +0100, Wouter Verhelst wrote: At any rate, here are some facts: - A package that builds differently because something is (or is not) installed on the build system is buggy. Period. It has nothing to do with the build system, it's the package. ... but I question that it is a bug that we want to spend time fixing. - A clean chroot takes time and processing power. You need to drop and recreate the chroot between builds, upgrade the same Build-Essential packages every time you do an upgrade, copy the apt cache in and out of the chroot (or keep downloading the same packages over and over), and various other things. LVM snapshots fix some, though not all, of those problems, and introduce a few of their own. I don't know about you, but I'd rather have the buildd spend processing power on building packages. Having it fail at producing a good package because the maintainer didn't do a good enough job is nothing new -- they do that all the time. I think that the question is whether we would rather have the maintainer spend time fixing those issues, or the buildd spend time dealing with the consequences of using LVM snapshots. The crux of the problem is that we can provably build all packages in a clean minimal chroot, at the expense of not necessarily having all potential Build-Conflicts identified. If we build in a dirty chroot, we might potentially trip up over the odd missing Build- Conflict, but we can't prove that they are correct unless we test building with /every/ possible combination of additional packages (which is not practical, and wastes a lot of CPU time for little to no real benefit). i.e. we can have provably correct Build-Depends, but realistically /not/ Build-Conflicts. The whole point of Build-Depends/Conflicts is to be able to reliably build a package. If we start from a clean state, the need for Build-Conflicts is no longer there, except for things the developer notices on their system. It's just not worth the developer time to identify potentially conflicting packages if they aren't a problem in reality, and by starting from a clean slate we effectively reduce the need for Build-Conflicts altogether. I personally think that if we have a way to use CPU time to solve a problem that would require maintainer time otherwise, we should use it. Well, from my experience, LVM snapshots use /less/ CPU time than plain chroots. sbuild needs to clean up the chroot after a build, and this means removing all of the build-deps installed at the start. This can take a lot of time, certainly much more than the time taken to delete a snapshot. snapshots are copy-on-write, which makes creation very fast, and deleting them is similarly quick (and we completely skip the chroot cleanup). The obvious advantage is that cleanup can fail, and leave the chroot in a dirty state; snapshots guarantee an identical initial state for every build. In short, starting each build from a known clean base chroot is not an additional overhead in any cases I've seen. We also have the ability to use unionfs/aufs in place of snapshots, which are perhaps even more lightweight. And once we have btrfs subvolume snapshots (work in progress), they will be even more efficient. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 10:37:48PM +1300, Lucas Nussbaum wrote: On 20/01/10 at 00:48 -0800, Steve Langasek wrote: On Wed, Jan 20, 2010 at 02:22:33PM +1300, Lucas Nussbaum wrote: Why spend a lot of time on tasks that provide little benefit, and also some disadvantages (in some cases, the fixes might be non-obvious, and requires changes to the packaging that tend to obscure it, for example by using --disable-foo for each and every option we don't want)? I'm not asking anyone to spend time on this task, but I still consider missing build-conflicts a bug. Ignoring these bugs by insisting on clean chroot environments for all official package builds is no solution - what if one of your build-dependencies pulls in one of these other packages, resulting in an undistributable (license-incompatible) misbuild? If the build-conflicts had been declared, or if the --without-foo option had been passed, we would not have to worry about such a misbuild. If the chroot env is clean, I hate to break the news, but no build environment (look, full word) is ever clean. There are environment variables, other processes running on the same system, and various other things that can influence it. Granted, rogue environment variables are rarely going to be a problem on a buildd host, but clock skew or rogue processes from previous builds might not be. Okay, that's a stretch. Still. At any rate, here are some facts: - A package that builds differently because something is (or is not) installed on the build system is buggy. Period. It has nothing to do with the build system, it's the package. - When a package has a buggy debian/rules and/or debian/control file, and it gets built on 11 architectures, surely one of those architectures is going to hit that bug. - A clean chroot takes time and processing power. You need to drop and recreate the chroot between builds, upgrade the same Build-Essential packages every time you do an upgrade, copy the apt cache in and out of the chroot (or keep downloading the same packages over and over), and various other things. LVM snapshots fix some, though not all, of those problems, and introduce a few of their own. I don't know about you, but I'd rather have the buildd spend processing power on building packages. Having it fail at producing a good package because the maintainer didn't do a good enough job is nothing new -- they do that all the time. As such, I'm rather unconvinced of the merits of this LVM snapshot thing... -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On 02/02/10 at 01:07 +0100, Wouter Verhelst wrote: At any rate, here are some facts: - A package that builds differently because something is (or is not) installed on the build system is buggy. Period. It has nothing to do with the build system, it's the package. ... but I question that it is a bug that we want to spend time fixing. - A clean chroot takes time and processing power. You need to drop and recreate the chroot between builds, upgrade the same Build-Essential packages every time you do an upgrade, copy the apt cache in and out of the chroot (or keep downloading the same packages over and over), and various other things. LVM snapshots fix some, though not all, of those problems, and introduce a few of their own. I don't know about you, but I'd rather have the buildd spend processing power on building packages. Having it fail at producing a good package because the maintainer didn't do a good enough job is nothing new -- they do that all the time. I think that the question is whether we would rather have the maintainer spend time fixing those issues, or the buildd spend time dealing with the consequences of using LVM snapshots. I personally think that if we have a way to use CPU time to solve a problem that would require maintainer time otherwise, we should use it. (I am fully aware that putting more load on the buildds might require adding buildds. However, I have the impression that the time required to maintain several identical buildds doesn't grow linearly, so it wouldn't be a too big problem.) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote:
Because we want our users to be able to patch and rebuild our software to
suit their needs. Asking them to set up a chroot build environment is
asking quite a lot.
AOL. Yesterday night I drafted a reply (which has lingered in my Draft
box) and was almost word-by-word identical to this.
In parallel to this, we should probably make easier than now to rebuild
packages properly for our users (sysadms are not necessarily packagers),
and that is proceeding quite well with recent schroot improvements, if
you ask me.
On Tue, Jan 19, 2010 at 04:36:36PM -0800, Russ Allbery wrote:
There are two ways to attack that problem:
(1) We decide that we want to provide the guarantee that packages build
the correct way in unclean envs. That mean making such bugs RC,
basically, and making efforts to find such bugs.
(2) We decide that it would be nice if packages don't do too crazy
things when built in unclean envs, but provide no guarantee, and
recommend the use of pbuilder and schroot + tarballs/lvm when people
need guarantees.
I don't understand why you insist on this aut-aut. Ideally, your (1) is
the right one, but as of know it is (still?) hard to pursue, we put it
as an ideal goal and we proceed towards it. Bugs in package should be
filed (especially in the original case of this thread: heck, they
resulted in two incompatible licenses linked together!), they are not
RC, but they are still bugs. The day we will have a suitable / sure way
to identify this bug in the first place, we will start enforcing it.
On the same line, this whole issue is one of the reason why we have
relationships like Build-Conflicts. Why having a non-declared
Build-Conflicts shouldn't be a bug?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 02:22:33PM +1300, Lucas Nussbaum wrote: Why spend a lot of time on tasks that provide little benefit, and also some disadvantages (in some cases, the fixes might be non-obvious, and requires changes to the packaging that tend to obscure it, for example by using --disable-foo for each and every option we don't want)? I'm not asking anyone to spend time on this task, but I still consider missing build-conflicts a bug. Ignoring these bugs by insisting on clean chroot environments for all official package builds is no solution - what if one of your build-dependencies pulls in one of these other packages, resulting in an undistributable (license-incompatible) misbuild? If the build-conflicts had been declared, or if the --without-foo option had been passed, we would not have to worry about such a misbuild. In that case, the missing build-conflicts /is/ an RC bug on the package. Most of the time, it won't be, which is why I don't think we should prioritize filing bugs about all such cases. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
Package: netatalk Version: 2.0.5-2 Severity: important Holger Levsen: how about the compromise and doing both, except that for (1) we file the bugs with severity important? Hi Jonas, as recently pointed out on debian-devel [1], the netatalk package is accidently linked against libssl on some arches due to dirty buildd chroots. To avoid this license violation, explicit Build-Conflicts against libssl-dev should be added and only be removed if $DEB_BUILD_OPTIONS contains openssl. Cheers, Fabian [1] http://lists.debian.org/debian-devel/2010/01/msg00354.html -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
On Wed, Jan 20, 2010 at 09:55:35AM +0100, Fabian Greffrath wrote: as recently pointed out on debian-devel [1], the netatalk package is accidently linked against libssl on some arches due to dirty buildd chroots. To avoid this license violation, explicit Build-Conflicts against libssl-dev should be added and only be removed if $DEB_BUILD_OPTIONS contains openssl. ...or netatalk build routines tightened to not link against openssl even if available, I assume. Thanks for pointing this out. I'll deal with it! - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 02:36:08PM -0800, Russ Allbery wrote: Neil McGovern ne...@debian.org writes: On Tue, Jan 19, 2010 at 11:59:35AM -0800, Russ Allbery wrote: This is a bug in the netatalk Debian packaging. You cannot assume the package will be built in a clean chroot; among other things, the buildd software explicitly does not guarantee that all packages will be removed. Would it be time to start looking at LVM snapshops + sbuild perhaps? Well, I would argue that proper package builds in dirty environments is something we want in Debian anyway, and while this isn't the ideal method to find it, it would be a bug regardless of how the buildds worked. I'm not arguing that finding these issues isn'[t something worth doing, but the headache of a broken chroot is (from the wrok I'm involved in) a much larger problem for us. Perhaps there could be a release goal / giant cluster-o-doom rebuild of the archive with commonly problematic libraries? Neil -- * Tolimar votes for debconf7 to be somewhere where he speaks the language. Tolimar That would a veto for switzerland ;) Ganneff Tolimar: that also vetos germany -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 11:32:17PM +0100, Martin Zobel-Helas wrote: Would it be time to start looking at LVM snapshops + sbuild perhaps? we already have two or three buildds doing that... The buildd team (esp. HE) working on that and if it works out to be stable enough, we can see if we can roll out it to all buildds. Excellent, thanks for this. Neil -- automake: the emo of Debian software. You just don't understand me. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
On Wed, Jan 20, 2010 at 10:25:01AM +0100, Jonas Smedegaard wrote: On Wed, Jan 20, 2010 at 09:55:35AM +0100, Fabian Greffrath wrote: as recently pointed out on debian-devel [1], the netatalk package is accidently linked against libssl on some arches due to dirty buildd chroots. To avoid this license violation, explicit Build-Conflicts against libssl-dev should be added and only be removed if $DEB_BUILD_OPTIONS contains openssl. ...or netatalk build routines tightened to not link against openssl even if available, I assume. The latter is definitely preferred since DEB_BUILD_OPTIONS can't change the value of Build-Conflicts... Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 04:04:07PM -0800, Russ Allbery wrote: hu? since when do we have a broader interest in people patching and rebuilding packages? I know that there are *some* people interested in that (me included) but I don't see that a broader audience wants to support that. Uh, since as long as I've been part of the project. I think this is at least the third time that I recall the same topic coming up on -devel. Wow. How often a topic comes up on -devel is an indicator how representative a given idea is in the whole developer body? It might be a sign that the people who want it tend to ask for it a lot. Apart from this it seems quiet illusionary to support every possible circumstance under which a dirty build environment could affect a build. For the most part, these problems are caused by Autoconf scripts that automatically detect features during the configure stage of the build. For the most part, Debian wants to enable all of those features anyway, so there isn't a serious problem. In the cases where we don't, there is usually an explicit --disable-X or --without-X flag that can be given to configure. Where there isn't, that's an upstream bug that is usually worthwhile to work with upstream to fix. Well, I can't tell if most packages use autoconf. Probably they do. But there are plenty of other build systems around, all with its own caveats. So my statement ... illussionary to support /every/ possible circumstance ... is still true. That does not mean that we shouldn't fix such bugs if they arise (obviously we should) but having priority on it is a different thing. This really isn't that horribly difficult in most cases. In cases where it is difficult, Build-Conflicts can be used to ensure a reasonable build environment when a package would otherwise insist on picking up an incorrect dependency. In some pathological cases, it may be difficult enough to not be worth it, but in that case I think it's a wontfix bug, not a non-bug. Bug or not: For the binary packages we provide (which is after all still the main priority as a binary distribution) we really want that they are built properly in either case. So providing a build environment as clean as it could be is really a good thing. sbuild has never provided this in the history of the project. I really have to question the emphasis put on this given that we've lived for all these years without having that and by fixing the packages to do the right thing. Eh.. what? I'm using sbuild to build my packages before uploading them locally. It uses schroot and schroot supports LVM snapshots. Which is what I'm using. Probably it has never been deployed on our buildds but that has nothing to do with what sbuild can provide. People do occasionally test whether packages rebuild properly in dirty environments and file bugs when they don't. Being absolutely certain it will always work is, of course, hard, but I think fixing the bug when we detect it is the right idea, rather than treating it as a bug in the build environment. Rebuild tests in dirty environments? I'm aware of rebuild tests in clean environments to make sure that build-depends are fine etc. but I never heard of such efforts. Could you give a pointer to that? http://lists.debian.org/debian-devel/2008/01/msg00869.html It was the second hit in Google for the obvious search. There was a long thread that worked through some of the problems with the initial method of checking, and there is further discussion of this same question there (why do we want this, shouldn't we just always use clean build environments, etc.). Oh, well, after I read the link I even remember it. Yes, if we are aware of problems there is reason to fix them. That doesn't mean that we should always build in dirty chrooots, though. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On 20/01/10 at 00:48 -0800, Steve Langasek wrote: On Wed, Jan 20, 2010 at 02:22:33PM +1300, Lucas Nussbaum wrote: Why spend a lot of time on tasks that provide little benefit, and also some disadvantages (in some cases, the fixes might be non-obvious, and requires changes to the packaging that tend to obscure it, for example by using --disable-foo for each and every option we don't want)? I'm not asking anyone to spend time on this task, but I still consider missing build-conflicts a bug. Ignoring these bugs by insisting on clean chroot environments for all official package builds is no solution - what if one of your build-dependencies pulls in one of these other packages, resulting in an undistributable (license-incompatible) misbuild? If the build-conflicts had been declared, or if the --without-foo option had been passed, we would not have to worry about such a misbuild. If the chroot env is clean, the build process is likely to be very similar on your system and on the buildds. So even without build-conflicts, it is likely that no additional build-deps will be pulled. It's true that that isn't a full guarantee (differences between archs, binNMUs done later in the package lifecycle), but clean chroot environments offer much more guarantee than the current situation, which is based only on the maintainer disabling all unused options or adding all the proper build-conflict. That is hard and error-prone:: among the packages you maintain, for example, sqsh picks up an additional dep on tcl8.4 if tcl-dev is installed. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On 20/01/10 at 09:30 +0100, Stefano Zacchiroli wrote: On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote: Because we want our users to be able to patch and rebuild our software to suit their needs. Asking them to set up a chroot build environment is asking quite a lot. AOL. Yesterday night I drafted a reply (which has lingered in my Draft box) and was almost word-by-word identical to this. In parallel to this, we should probably make easier than now to rebuild packages properly for our users (sysadms are not necessarily packagers), and that is proceeding quite well with recent schroot improvements, if you ask me. What's the problem with documentation such as https://wiki.ubuntu.com/PbuilderHowto (except it's an Ubuntu documentation)? I think that the process of building with pbuilder is reasonably well documented. On Tue, Jan 19, 2010 at 04:36:36PM -0800, Russ Allbery wrote: There are two ways to attack that problem: (1) We decide that we want to provide the guarantee that packages build the correct way in unclean envs. That mean making such bugs RC, basically, and making efforts to find such bugs. (2) We decide that it would be nice if packages don't do too crazy things when built in unclean envs, but provide no guarantee, and recommend the use of pbuilder and schroot + tarballs/lvm when people need guarantees. I don't understand why you insist on this aut-aut. Ideally, your (1) is the right one, but as of know it is (still?) hard to pursue, we put it as an ideal goal and we proceed towards it. Bugs in package should be filed (especially in the original case of this thread: heck, they resulted in two incompatible licenses linked together!), they are not RC, but they are still bugs. The day we will have a suitable / sure way to identify this bug in the first place, we will start enforcing it. On the same line, this whole issue is one of the reason why we have relationships like Build-Conflicts. Why having a non-declared Build-Conflicts shouldn't be a bug? Feel free to start filing bugs. A good start would be the list of source packages[1] from 2008 that probably have a missing build-conflict, since they produced different binary packages (according to debdiff) in an unclean chroot. (that list contains some false positives) [1] http://people.debian.org/~lucas/logs/2008/01/22/bdfh/debdiffs/ -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 10:13:46PM +1300, Lucas Nussbaum wrote:
What's the problem with documentation such as
https://wiki.ubuntu.com/PbuilderHowto (except it's an Ubuntu
documentation)? I think that the process of building with pbuilder is
reasonably well documented.
Let's be realistic. We still have Debian developers not using pbuilder
cowbuilder, are you really arguing that _users_ will use it invariably
to rebuild their packages? I don't have numbers, but I'm reasonably sure
apt-get source -b is still the most used tool to rebuild packages
together with the magic recipe fakeroot debian/rules binary.
Additionally, if you have to debug build failures, rebuilding in a real
system is still handier.
On the same line, this whole issue is one of the reason why we have
relationships like Build-Conflicts. Why having a non-declared
Build-Conflicts shouldn't be a bug?
Feel free to start filing bugs. A good start would be the list of source
packages[1] from 2008 that probably have a missing build-conflict, since
they produced different binary packages (according to debdiff) in an
unclean chroot. (that list contains some false positives)
You're cheating now :-) I was just arguing that your aut-aut was not
warranted, that we can live with a mixed environment in which those bugs
are not RC (and hence should not be pursued as actively as we do for RC
ones), but are still bug that ought to be filed. Be assured that I'll
file the one that will cross my path.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
On Wed, Jan 20, 2010 at 01:28:49AM -0800, Steve Langasek wrote: On Wed, Jan 20, 2010 at 10:25:01AM +0100, Jonas Smedegaard wrote: On Wed, Jan 20, 2010 at 09:55:35AM +0100, Fabian Greffrath wrote: as recently pointed out on debian-devel [1], the netatalk package is accidently linked against libssl on some arches due to dirty buildd chroots. To avoid this license violation, explicit Build-Conflicts against libssl-dev should be added and only be removed if $DEB_BUILD_OPTIONS contains openssl. ...or netatalk build routines tightened to not link against openssl even if available, I assume. The latter is definitely preferred since DEB_BUILD_OPTIONS can't change the value of Build-Conflicts... True. Other (more complex) mechanisms like using a debian/control.in.in file is possible, however. Unfortunately I already set --without-openssl-dir which apparently had no effect. I will try setting --with-openssl-dir=/dev/null :-/ - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#565969: Info received (Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!])
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Jonas Smedegaard d...@jones.dk If you wish to submit further information on this problem, please send it to 565...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 565969: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565969 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 10:37:48PM +1300, Lucas Nussbaum wrote: I'm not asking anyone to spend time on this task, but I still consider missing build-conflicts a bug. Ignoring these bugs by insisting on clean chroot environments for all official package builds is no solution - what if one of your build-dependencies pulls in one of these other packages, resulting in an undistributable (license-incompatible) misbuild? If the build-conflicts had been declared, or if the --without-foo option had been passed, we would not have to worry about such a misbuild. If the chroot env is clean, the build process is likely to be very similar on your system and on the buildds. This very likely and $2 buys you a cup of coffee. I have seen cases of build-dep skew across architectures resulting in binaries in the archive with different dependencies. It's true that that isn't a full guarantee (differences between archs, binNMUs done later in the package lifecycle), binNMUs are a non-negligible use case. I've seen packages end up with wrong dependencies across binNMUs due to this issue as well. but clean chroot environments offer much more guarantee than the current situation, which is based only on the maintainer disabling all unused options or adding all the proper build-conflict. No, *neither* is a guarantee, which is why it's warranted to use *both* approaches to minimize the occurrence of bugs. Suppose that libcups2-dev adds a dependency on libssl-dev, because it starts to provide two versions of libcups - the default lib still using gnutls, and an alternative lib linked against openssl. The majority of packages will get no new dependencies, because libcups.so will still link against gnutls; but netatalk will wind up with a dependency on openssl and will be RC buggy as a result. Where does the bug lie, and when did it appear? Is it a bug in libcups-dev for depending on libssl-dev? No, no one would insist that the cups maintainer revert this change (at least not for this reason). Is it a bug in the maintainer for not having checked first that no reverse-deps build in wrong ways as a result of this change? Well, that's at least as hard and error-prone as doing more general unclean-chroot checks, if not moreso. No, the bug is in the netatalk package for building differently when different packages are installed. The severity of the bug may vary over time, but it's already latent in the package before the cups maintainers make their change. The operative principle that's been in place since Build-Depends and Build-Conflicts were first formulated was that these + build-essential should provide *all* the information needed for package builds to be reproducible. We may fall short of that standard from time to time, but that's not a reason to abandon as unsupported anyone building packages in an environment other than an empty chroot. That is hard and error-prone:: Yes. But I don't think this is a reason to abandon the principle, especially given the class of bug described above. Anyway, if you're going to insist that everyone do all their builds in clean chroots, I could just as well insist the opposite - that everyone build all their packages in cluttered chroots, to ensure no missing Build-Conflicts. ;) among the packages you maintain, for example, sqsh picks up an additional dep on tcl8.4 if tcl-dev is installed. Oh, thanks for the info. This seems to be due to a namespace collision between tcl-dev and a commercial library that sqsh supports building against; I'll add a build-conflicts. And I don't think the existence of bugs in my packages disproves my argument. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
tags 565969 pending thanks On Wed, Jan 20, 2010 at 11:15:23AM +0100, Jonas Smedegaard wrote: On Wed, Jan 20, 2010 at 01:28:49AM -0800, Steve Langasek wrote: On Wed, Jan 20, 2010 at 10:25:01AM +0100, Jonas Smedegaard wrote: On Wed, Jan 20, 2010 at 09:55:35AM +0100, Fabian Greffrath wrote: as recently pointed out on debian-devel [1], the netatalk package is accidently linked against libssl on some arches due to dirty buildd chroots. To avoid this license violation, explicit Build-Conflicts against libssl-dev should be added and only be removed if $DEB_BUILD_OPTIONS contains openssl. ...or netatalk build routines tightened to not link against openssl even if available, I assume. The latter is definitely preferred since DEB_BUILD_OPTIONS can't change the value of Build-Conflicts... True. Other (more complex) mechanisms like using a debian/control.in.in file is possible, however. Unfortunately I already set --without-openssl-dir which apparently had no effect. I will try setting --with-openssl-dir=/dev/null :-/ Ahh, problem isolated: The proper option to use is --with-openssl-dir=no - so the convenient DEB_BUILD_OPTIONS=openssl will be preserved :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: GPL-licensed software linked against libssl on buildds!
* Lucas Nussbaum lu...@lucas-nussbaum.net [100120 01:26]: There are two ways to attack that problem: (1) We decide that we want to provide the guarantee that packages build the correct way in unclean envs. That mean making such bugs RC, basically, and making efforts to find such bugs. If you s/unclean/non-minimal/ then I think that is already the status quo. A package building indeterministic in non-minimal builds was in practise indeterministic and when catched got the appropiate bug reports. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
Ahh, problem isolated: The proper option to use is --with-openssl-dir=no - so the convenient DEB_BUILD_OPTIONS=openssl will be preserved :-) Sure?! # ./configure --with-openssl-dir=no|grep -i ssl checking for SSL... /usr (enabling RANDNUM and DHX support) SSL: CFLAGS = -I/usr/include/openssl -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#565969: Re: Bug#565969: netatalk: Please avoid accidental linking against libssl [was: GPL-licensed software linked against libssl on buildds!]
On Wed, Jan 20, 2010 at 04:15:26PM +0100, Fabian Greffrath wrote: Ahh, problem isolated: The proper option to use is --with-openssl-dir=no - so the convenient DEB_BUILD_OPTIONS=openssl will be preserved :-) Sure?! Nope. I went offline (train ride to Copenhagen an hour from my home) where I realized that this wasn' the proper fix. Changing to --without-ssl-dir (i.e. s/openssl/ssl/ works, however. Thanks for double-checking :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: GPL-licensed software linked against libssl on buildds!
Patrick Schoenfeld schoenf...@debian.org writes: On Tue, Jan 19, 2010 at 04:04:07PM -0800, Russ Allbery wrote: Uh, since as long as I've been part of the project. I think this is at least the third time that I recall the same topic coming up on -devel. Wow. How often a topic comes up on -devel is an indicator how representative a given idea is in the whole developer body? It might be a sign that the people who want it tend to ask for it a lot. Each time we had this discussion previously, my perception of the consensus was what I stated earlier. Well, I can't tell if most packages use autoconf. Probably they do. But there are plenty of other build systems around, all with its own caveats. So my statement ... illussionary to support /every/ possible circumstance ... is still true. It's illusory to assume we can remove all bugs from our packages, for any type of significant bug that you care to mention. That doesn't mean we should stop fixing bugs. That does not mean that we shouldn't fix such bugs if they arise (obviously we should) but having priority on it is a different thing. Then I'm not sure that you're disagreeing with me? All I said was that it's a bug that should normally be fixed. If you also agree that it's a bug that should normally be fixed, you may want to consider whether you're fighting shadows here. :) I didn't say it was RC, and I didn't say it needed to be a priority over other bugs, necessarily. sbuild has never provided this in the history of the project. I really have to question the emphasis put on this given that we've lived for all these years without having that and by fixing the packages to do the right thing. Eh.. what? I'm using sbuild to build my packages before uploading them locally. It uses schroot and schroot supports LVM snapshots. Which is what I'm using. Probably it has never been deployed on our buildds but that has nothing to do with what sbuild can provide. I didn't say anything about what sbuild *could* provide. I said that it *has not* provided that, in the sense that the buildds have never previously done what you describe above. The project has not collapsed. Clearly it's possible to, in general, fix these problems when they arise without using guaranteed-clean chroots. Separately, I do agree that having better guarantees around the chroots is a good idea. I'm just pointing out that there's no reason to make that the only solution to the problem, and in fact the project has not historically needed this and still has done an okay job with such bugs. Steve made the same point with fewer words and more precision. Oh, well, after I read the link I even remember it. Yes, if we are aware of problems there is reason to fix them. That doesn't mean that we should always build in dirty chrooots, though. I think we may not actually be disagreeing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 10:30:13AM -0800, Russ Allbery wrote: That does not mean that we shouldn't fix such bugs if they arise (obviously we should) but having priority on it is a different thing. Then I'm not sure that you're disagreeing with me? Oh I don't. However in one of your first mails you sounded quiet different. Somewhere in the line of we do not need buildds with clean environments, because after all we want packages to be buildable in dirty environments as well. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Patrick Schoenfeld schoenf...@debian.org writes: On Wed, Jan 20, 2010 at 10:30:13AM -0800, Russ Allbery wrote: That does not mean that we shouldn't fix such bugs if they arise (obviously we should) but having priority on it is a different thing. Then I'm not sure that you're disagreeing with me? Oh I don't. However in one of your first mails you sounded quiet different. Somewhere in the line of we do not need buildds with clean environments, because after all we want packages to be buildable in dirty environments as well. Hm, well, I re-read all of my messages to this thread and I'm not seeing it, but I certainly apologize for giving you that impression! That's not what I was trying to communicate at all. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote: Lucas Nussbaum lu...@lucas-nussbaum.net writes: On 19/01/10 at 14:36 -0800, Russ Allbery wrote: Well, I would argue that proper package builds in dirty environments is something we want in Debian anyway, and while this isn't the ideal method to find it, it would be a bug regardless of how the buildds worked. Why would we want that? I mean, it's very difficult to guarantee that packages build correctly in dirty envs. I don't really see the point of enforcing that when we have the technology (pbuilder, sbuild + lvm snapshots) there to ignore that problem. Because we want our users to be able to patch and rebuild our software to suit their needs. Asking them to set up a chroot build environment is asking quite a lot. That is certainly a good goal, but I think it should be done outside the scope of autobuilding, where we want clean, reproducable builds. Something like an occasional archive-wide rebuild using a specially prepared, overly-tainted (with -dev libraries) chroot and comparing to a second run with clean chroot would be more worthwhile I think (albeit more work as well). Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GPL-licensed software linked against libssl on buildds!
Hi, it seems that some buildds occasionally have libssl-dev installed in their chroot. A friend of mine has found out that the netatalk package depends on libssl0.9.8 [sparc] in sid and [hppa, mipsel] in squeeze. Other architectures are not affected. For GPL-licensed software like netatalk this is IMHO to be considered a license violation and thus RC! If you have a look at the build logs on e.g. sparc, you will see that indeed the configure script detects an OpenSSL installation and builds the package against it: https://buildd.debian.org/fetch.cgi?pkg=netatalk;ver=2.0.5-2;arch=sparc;stamp=1259628740 This doesn't happen on other archs: https://buildd.debian.org/pkg.cgi?pkg=netatalk I guess the buildds for the affected archs need their chroots cleaned up and netatalk needs bin-NMUs scheduled, right? Cheers, Fabian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Fabian Greffrath fab...@greffrath.com writes: it seems that some buildds occasionally have libssl-dev installed in their chroot. A friend of mine has found out that the netatalk package depends on libssl0.9.8 [sparc] in sid and [hppa, mipsel] in squeeze. Other architectures are not affected. For GPL-licensed software like netatalk this is IMHO to be considered a license violation and thus RC! If you have a look at the build logs on e.g. sparc, you will see that indeed the configure script detects an OpenSSL installation and builds the package against it: https://buildd.debian.org/fetch.cgi?pkg=netatalk;ver=2.0.5-2;arch=sparc;stamp=1259628740 This doesn't happen on other archs: https://buildd.debian.org/pkg.cgi?pkg=netatalk I guess the buildds for the affected archs need their chroots cleaned up and netatalk needs bin-NMUs scheduled, right? This is a bug in the netatalk Debian packaging. You cannot assume the package will be built in a clean chroot; among other things, the buildd software explicitly does not guarantee that all packages will be removed. The packaging needs to prevent the package from being linked with OpenSSL if that's what the resulting binary packages are supposed to be like, even if OpenSSL is installed. If the changes to the packaging are too invasive to do the right thing no matter what's installed, you can add a Build-Conflicts. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 11:59:35AM -0800, Russ Allbery wrote: This is a bug in the netatalk Debian packaging. You cannot assume the package will be built in a clean chroot; among other things, the buildd software explicitly does not guarantee that all packages will be removed. Would it be time to start looking at LVM snapshops + sbuild perhaps? Neil -- tore Jump in and have a quim! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Hi Neil, On Tue Jan 19, 2010 at 22:29:25 +, Neil McGovern wrote: On Tue, Jan 19, 2010 at 11:59:35AM -0800, Russ Allbery wrote: This is a bug in the netatalk Debian packaging. You cannot assume the package will be built in a clean chroot; among other things, the buildd software explicitly does not guarantee that all packages will be removed. Would it be time to start looking at LVM snapshops + sbuild perhaps? we already have two or three buildds doing that... The buildd team (esp. HE) working on that and if it works out to be stable enough, we can see if we can roll out it to all buildds. Greetings Martin -- Martin Zobel-Helas zo...@debian.org | Debian System Administrator Debian GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Neil McGovern ne...@debian.org writes: On Tue, Jan 19, 2010 at 11:59:35AM -0800, Russ Allbery wrote: This is a bug in the netatalk Debian packaging. You cannot assume the package will be built in a clean chroot; among other things, the buildd software explicitly does not guarantee that all packages will be removed. Would it be time to start looking at LVM snapshops + sbuild perhaps? Well, I would argue that proper package builds in dirty environments is something we want in Debian anyway, and while this isn't the ideal method to find it, it would be a bug regardless of how the buildds worked. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On 19/01/10 at 14:36 -0800, Russ Allbery wrote: Neil McGovern ne...@debian.org writes: On Tue, Jan 19, 2010 at 11:59:35AM -0800, Russ Allbery wrote: This is a bug in the netatalk Debian packaging. You cannot assume the package will be built in a clean chroot; among other things, the buildd software explicitly does not guarantee that all packages will be removed. Would it be time to start looking at LVM snapshops + sbuild perhaps? Well, I would argue that proper package builds in dirty environments is something we want in Debian anyway, and while this isn't the ideal method to find it, it would be a bug regardless of how the buildds worked. Why would we want that? I mean, it's very difficult to guarantee that packages build correctly in dirty envs. I don't really see the point of enforcing that when we have the technology (pbuilder, sbuild + lvm snapshots) there to ignore that problem. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Hi, On Dienstag, 19. Januar 2010, Martin Zobel-Helas wrote: we already have two or three buildds doing that... The buildd team (esp. HE) working on that and if it works out to be stable enough, we can see if we can roll out it to all buildds. very cool. thank you! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: GPL-licensed software linked against libssl on buildds!
Lucas Nussbaum lu...@lucas-nussbaum.net writes: On 19/01/10 at 14:36 -0800, Russ Allbery wrote: Well, I would argue that proper package builds in dirty environments is something we want in Debian anyway, and while this isn't the ideal method to find it, it would be a bug regardless of how the buildds worked. Why would we want that? I mean, it's very difficult to guarantee that packages build correctly in dirty envs. I don't really see the point of enforcing that when we have the technology (pbuilder, sbuild + lvm snapshots) there to ignore that problem. Because we want our users to be able to patch and rebuild our software to suit their needs. Asking them to set up a chroot build environment is asking quite a lot. People do occasionally test whether packages rebuild properly in dirty environments and file bugs when they don't. Being absolutely certain it will always work is, of course, hard, but I think fixing the bug when we detect it is the right idea, rather than treating it as a bug in the build environment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Hi, On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote: Why would we want that? I mean, it's very difficult to guarantee that packages build correctly in dirty envs. I don't really see the point of enforcing that when we have the technology (pbuilder, sbuild + lvm snapshots) there to ignore that problem. Because we want our users to be able to patch and rebuild our software to suit their needs. Asking them to set up a chroot build environment is asking quite a lot. hu? since when do we have a broader interest in people patching and rebuilding packages? I know that there are *some* people interested in that (me included) but I don't see that a broader audience wants to support that. Apart from this it seems quiet illusionary to support every possible circumstance under which a dirty build environment could affect a build. Bug or not: For the binary packages we provide (which is after all still the main priority as a binary distribution) we really want that they are built properly in either case. So providing a build environment as clean as it could be is really a good thing. People do occasionally test whether packages rebuild properly in dirty environments and file bugs when they don't. Being absolutely certain it will always work is, of course, hard, but I think fixing the bug when we detect it is the right idea, rather than treating it as a bug in the build environment. Rebuild tests in dirty environments? I'm aware of rebuild tests in clean environments to make sure that build-depends are fine etc. but I never heard of such efforts. Could you give a pointer to that? Regards, Patrick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On Wed, Jan 20, 2010 at 00:48:15 +0100, Patrick Schoenfeld wrote: hu? since when do we have a broader interest in people patching and rebuilding packages? I know that there are *some* people interested in that (me included) but I don't see that a broader audience wants to support that. Just about when we started being interested in free software. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Patrick Schoenfeld schoenf...@debian.org writes: On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote: Because we want our users to be able to patch and rebuild our software to suit their needs. Asking them to set up a chroot build environment is asking quite a lot. hu? since when do we have a broader interest in people patching and rebuilding packages? I know that there are *some* people interested in that (me included) but I don't see that a broader audience wants to support that. Uh, since as long as I've been part of the project. I think this is at least the third time that I recall the same topic coming up on -devel. Apart from this it seems quiet illusionary to support every possible circumstance under which a dirty build environment could affect a build. For the most part, these problems are caused by Autoconf scripts that automatically detect features during the configure stage of the build. For the most part, Debian wants to enable all of those features anyway, so there isn't a serious problem. In the cases where we don't, there is usually an explicit --disable-X or --without-X flag that can be given to configure. Where there isn't, that's an upstream bug that is usually worthwhile to work with upstream to fix. This really isn't that horribly difficult in most cases. In cases where it is difficult, Build-Conflicts can be used to ensure a reasonable build environment when a package would otherwise insist on picking up an incorrect dependency. In some pathological cases, it may be difficult enough to not be worth it, but in that case I think it's a wontfix bug, not a non-bug. Bug or not: For the binary packages we provide (which is after all still the main priority as a binary distribution) we really want that they are built properly in either case. So providing a build environment as clean as it could be is really a good thing. sbuild has never provided this in the history of the project. I really have to question the emphasis put on this given that we've lived for all these years without having that and by fixing the packages to do the right thing. People do occasionally test whether packages rebuild properly in dirty environments and file bugs when they don't. Being absolutely certain it will always work is, of course, hard, but I think fixing the bug when we detect it is the right idea, rather than treating it as a bug in the build environment. Rebuild tests in dirty environments? I'm aware of rebuild tests in clean environments to make sure that build-depends are fine etc. but I never heard of such efforts. Could you give a pointer to that? http://lists.debian.org/debian-devel/2008/01/msg00869.html It was the second hit in Google for the obvious search. There was a long thread that worked through some of the problems with the initial method of checking, and there is further discussion of this same question there (why do we want this, shouldn't we just always use clean build environments, etc.). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
On 19/01/10 at 16:04 -0800, Russ Allbery wrote: People do occasionally test whether packages rebuild properly in dirty environments and file bugs when they don't. Being absolutely certain it will always work is, of course, hard, but I think fixing the bug when we detect it is the right idea, rather than treating it as a bug in the build environment. Rebuild tests in dirty environments? I'm aware of rebuild tests in clean environments to make sure that build-depends are fine etc. but I never heard of such efforts. Could you give a pointer to that? http://lists.debian.org/debian-devel/2008/01/msg00869.html It was the second hit in Google for the obvious search. There was a long thread that worked through some of the problems with the initial method of checking, and there is further discussion of this same question there (why do we want this, shouldn't we just always use clean build environments, etc.). Yes, and this never resulted in any bug filing as far as I remember, due to the number of bugs I would have had to file. There are two ways to attack that problem: (1) We decide that we want to provide the guarantee that packages build the correct way in unclean envs. That mean making such bugs RC, basically, and making efforts to find such bugs. (2) We decide that it would be nice if packages don't do too crazy things when built in unclean envs, but provide no guarantee, and recommend the use of pbuilder and schroot + tarballs/lvm when people need guarantees. The current situation, where we don't do (1), but still build the packages we provide in unclean envs, is not an acceptable compromise (especially now that we have the technical means to solve that issue). It means that some packages in the archive are silently being built with additional deps, without any coordinated effort to track them down. Of course, I'm in favor of doing (2) and building in clean envs on our own buildds. But we could do (1), and spend a lot of time on this nit-picking project. Might be fun. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Lucas Nussbaum lu...@lucas-nussbaum.net writes: On 19/01/10 at 16:04 -0800, Russ Allbery wrote: People do occasionally test whether packages rebuild properly in dirty environments and file bugs when they don't. Being absolutely certain it will always work is, of course, hard, but I think fixing the bug when we detect it is the right idea, rather than treating it as a bug in the build environment. Rebuild tests in dirty environments? I'm aware of rebuild tests in clean environments to make sure that build-depends are fine etc. but I never heard of such efforts. Could you give a pointer to that? http://lists.debian.org/debian-devel/2008/01/msg00869.html It was the second hit in Google for the obvious search. There was a long thread that worked through some of the problems with the initial method of checking, and there is further discussion of this same question there (why do we want this, shouldn't we just always use clean build environments, etc.). Yes, and this never resulted in any bug filing as far as I remember, due to the number of bugs I would have had to file. I've seen bugs filed by other people for dirty build environment problems, but I suspect they were mostly one-offs. Sorry to have implied it was directly related to your effort. There are two ways to attack that problem: (1) We decide that we want to provide the guarantee that packages build the correct way in unclean envs. That mean making such bugs RC, basically, and making efforts to find such bugs. (2) We decide that it would be nice if packages don't do too crazy things when built in unclean envs, but provide no guarantee, and recommend the use of pbuilder and schroot + tarballs/lvm when people need guarantees. The current situation, where we don't do (1), but still build the packages we provide in unclean envs, is not an acceptable compromise (especially now that we have the technical means to solve that issue). It means that some packages in the archive are silently being built with additional deps, without any coordinated effort to track them down. Of course, I'm in favor of doing (2) and building in clean envs on our own buildds. But we could do (1), and spend a lot of time on this nit-picking project. Might be fun. For the record, (2) is what I'd prefer as well, although I'm not sure (1) is as big of a problem as that. But I do agree with the idea that we want to simultaneously improve the reliability of our binary packages and fix, where possible, bugs in building our source packages in other than pristine environments. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: GPL-licensed software linked against libssl on buildds!
Hi, On Mittwoch, 20. Januar 2010, Lucas Nussbaum wrote: There are two ways to attack that problem: how about the compromise and doing both, except that for (1) we file the bugs with severity important? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: GPL-licensed software linked against libssl on buildds!
On 20/01/10 at 01:49 +0100, Holger Levsen wrote: On Mittwoch, 20. Januar 2010, Lucas Nussbaum wrote: There are two ways to attack that problem: how about the compromise and doing both, except that for (1) we file the bugs with severity important? There are a lot of more useful QA tasks that are waiting for someone with more time. (like, I think, piuparts, which could always benefit from more manpower, even if you recent work has been great) Why spend a lot of time on tasks that provide little benefit, and also some disadvantages (in some cases, the fixes might be non-obvious, and requires changes to the packaging that tend to obscure it, for example by using --disable-foo for each and every option we don't want)? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
