FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-19-2010, 11:24 PM
Lucas Nussbaum
 
Default 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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-19-2010, 11:36 PM
Russ Allbery
 
Default GPL-licensed software linked against libssl on buildds!

Lucas Nussbaum <lucas@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-19-2010, 11:49 PM
Holger Levsen
 
Default 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
 
Old 01-20-2010, 12:22 AM
Lucas Nussbaum
 
Default 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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2010, 07:30 AM
Stefano Zacchiroli
 
Default 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
zack@{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
 
Old 01-20-2010, 07:48 AM
Steve Langasek
 
Default 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 01-20-2010, 08:13 AM
Lucas Nussbaum
 
Default 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
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2010, 08:28 AM
Neil McGovern
 
Default GPL-licensed software linked against libssl on buildds!

On Tue, Jan 19, 2010 at 02:36:08PM -0800, Russ Allbery wrote:
> Neil McGovern <neilm@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2010, 08:28 AM
Neil McGovern
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2010, 08:32 AM
Patrick Schoenfeld
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 08:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org