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, 06:59 PM
Russ Allbery
 
Default GPL-licensed software linked against libssl on buildds!

Fabian Greffrath <fabian@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 (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, 09:29 PM
Neil McGovern
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-19-2010, 09:32 PM
Martin Zobel-Helas
 
Default GPL-licensed software linked against libssl on buildds!

Hi Neil,

On Tue Jan 19, 2010 at 22:29:25 +0000, 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 <zobel@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-19-2010, 09:36 PM
Russ Allbery
 
Default GPL-licensed software linked against libssl on buildds!

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.

--
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, 10:05 PM
Lucas Nussbaum
 
Default GPL-licensed software linked against libssl on buildds!

On 19/01/10 at 14:36 -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.

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
| 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, 10:35 PM
Holger Levsen
 
Default 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
 
Old 01-19-2010, 10:40 PM
Russ Allbery
 
Default GPL-licensed software linked against libssl on buildds!

Lucas Nussbaum <lucas@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 (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, 10:48 PM
Patrick Schoenfeld
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-19-2010, 10:57 PM
Julien Cristau
 
Default 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-19-2010, 11:04 PM
Russ Allbery
 
Default GPL-licensed software linked against libssl on buildds!

Patrick Schoenfeld <schoenfeld@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 (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
 

Thread Tools




All times are GMT. The time now is 01:10 PM.

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