ar-cut with libraries used by third parties.
I believe Canonical also ships GPL-2-only programs linked (possibly
indirectly) to OpenSSL as part of their Linux distribution these days.
> As I understand it, it is meant only for binaries distributed by
> parties other than the one distributing
I understand it, it is meant only for binaries distributed by
parties other than the one distributing the system containing the
"system library". So third-party app distributors are fine to ignore
the incompatibility between a GPL app and a proprietary libc, but the
OS vendor can't include
is mainly to raise awareness of this issue and seek input from
> > the community.
>
> GPL code which linked against OpenSSL usually has a "gpl-exception
> clause for OpenSSL". This should be still accepted since it refers
> specifically to OpenSSL.
Many projects do
On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote:
> Hi Kurt, hi Luca, hi everyone,
Hi Michael,
> That said, I'm not a lawyer and reading license texts hurts my brain.
> So my goal is is mainly to raise awareness of this issue and seek input from
> the community.
GPL code whi
Hi Kurt, hi Luca, hi everyone,
regarding the impending transition to OpenSSL 3.0 in unstable (which is
now licensed under Apache 2.0), I wonder what that means for Debian,
given that apparently GPL-2 (and also LGPL-2) and Apache 2.0 are
incompatible with each other.
If I read Luca correctly
Hi folks,
I noticed today that methods/rsh.cc was GPL-2 only, which is an
outlier in the licensing that should be fixed, as it prevents GPL-3
components from making it into apt-pkg.
Apart from DonKult and me, we have the following contributors who
we need permission for relicensing from:
* Ben
Hello Jonas,
On Wed 21 Oct 2020 at 10:52am +02, Jonas Smedegaard wrote:
> tl;dr: I think Debian should _state_ current practice (not just omit
> stating obsolete practice), and state it towards our users (not only
> ourselves).
I just looked up old meeting minutes and the team does intend to iss
ral public
license(s) Debian now interpret differently - GPL-1 and/or GPL-2 and/or
GPL-3 and/or SSLeay and/or OpenSSL? - and how exactly.
If (as one notable speculative example) Debian now generally considers
OpenSSL code as integral part of the core system for the interpretation
of legal texts, t
Hello,
On Tue 20 Oct 2020 at 06:43pm +02, Jonas Smedegaard wrote:
> It would certainly be good to have an official clarification.
I applied a patch to the REJECT-FAQ about it yesterday (thanks to
Michael for the patch). Is that adequate?
https://salsa.debian.org/ftp-team/website/-/commit/c804b
24937#105
> > >
> > > Do I understand correctly that Debian now ignore OpenSSL
> > > incomatibilities with GPL?
> > >
> > > I.e. do we no longer need to either a) seek special exception for
> > > each and every piece of GPL-licensed code li
> > incomatibilities with GPL?
> >
> > I.e. do we no longer need to either a) seek special exception for
> > each and every piece of GPL-licensed code linking with current or
> > older OpenSSL code, or b) patch such code to instead link with some
> > alt
On Tue, Oct 20, 2020 at 1:16 PM Jonas Smedegaard wrote:
> This was just now brought to my attention:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105
The decision linked therein appears to be based on the GPL system
library exception and on the fact that Fedora is relying o
Am 20.10.20 um 15:16 schrieb Jonas Smedegaard:
> This was just now brought to my attention:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105
>
> Do I understand correctly that Debian now ignore OpenSSL
> incomatibilities with GPL?
>
> I.e. do we no longer n
This was just now brought to my attention:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105
Do I understand correctly that Debian now ignore OpenSSL
incomatibilities with GPL?
I.e. do we no longer need to either a) seek special exception for each
and every piece of GPL-licensed
Hi folks,
it is our plan to switch apt from GnuTLS to OpenSSL once OpenSSL
3.0 is out, making /usr/lib/apt/methods/http effectively a
GPL-3+ licensed binary. Or earlier, in case ftp masters decide
that the system library exception applies to OpenSSL.
I heard some concerns about such a change
ing the effective licence on the work as a
whole. It may still be the case that people can use the individual
files in ways that don't invoke the terms of the GPL (for example, using
them in isolation as example code), and it would be unfriendly for you
to make the licence on the Debian versi
On Tue, Sep 24, 2019 at 09:30:38PM +0200, Gard Spreemann wrote:
> Colin Watson writes:
> > On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote:
> >> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> >> including the current version
Sorry Gary,
i just make a mistake - you can't relicense MIT(X11) stuff - it would
work only with some BSD files. You could modify the license (just as in
ncurses) and be done with - i would like to recommend not to do so.
Cheers
Alf
❦ 24 septembre 2019 10:41 +02, Gard Spreemann :
> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> including the current version in the archives. Since then, upstream has
> switched to an MIT license, but with the caveat that many parts of the
> code has GPL depe
Plain no. If they are really interested they would know that they can
use every MIT part under GPL because of license compatibilty. Things
change dramatically if you would consider to change the licenses of the
files - if one would contribute to your now forked files the original
project would
Colin Watson writes:
> On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote:
>> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
>> including the current version in the archives. Since then, upstream has
>> switched to an MIT license, but with
Filippo Rusconi writes:
> Greetings,
>
> On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote:
>>Hello,
>>
>>A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
>>including the current version in the archives. Since then, upstream has
On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote:
> A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
> including the current version in the archives. Since then, upstream has
> switched to an MIT license, but with the caveat that many parts of the
>
Greetings,
On Tue, Sep 24, 2019 at 10:41:07AM +0200, Gard Spreemann wrote:
Hello,
A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
including the current version in the archives. Since then, upstream has
switched to an MIT license, but with the caveat that many parts of the
Hello,
A package I maintain (src:gudhi) was mostly under GPL-3+ up to and
including the current version in the archives. Since then, upstream has
switched to an MIT license, but with the caveat that many parts of the
code has GPL dependencies and that "for practical purposes this code is
On Sat, 17 Aug 2019 00:14:12 -0300, "Anderson Ribeiro [ MAD ]"
wrote:
>Good evening to all.
>Guys, I'm studying packaging.
>Because I am learning.
>
>I am trying to package it (Pulseaudio-version-12.99.2).
Aside from your original question, I would like to point you towards
the debian-mentors mai
Em sáb, 2019-08-17 às 07:24 +0200, Geert Stappers escreveu:
> On Sat, Aug 17, 2019 at 12:14:12AM -0300, Anderson Ribeiro [ MAD ]
> wrote:
> > Good evening to all.
> > Guys, I'm studying packaging.
> > Because I am learning.
> >
> > I am trying to package it (Pulseaudio-version-12.99.2).
> > In the
On Sat, Aug 17, 2019 at 12:14:12AM -0300, Anderson Ribeiro [ MAD ] wrote:
> Good evening to all.
> Guys, I'm studying packaging.
> Because I am learning.
>
> I am trying to package it (Pulseaudio-version-12.99.2).
> In the COPYRIGTH
> version is as follows.
>
> Copyrigth 2018-2019 Pali Rohár
>
>
Good evening to all.
Guys, I'm studying packaging.
Because I am learning.
I am trying to package it (Pulseaudio-version-12.99.2).
In the COPYRIGTH
version is as follows.
Copyrigth 2018-2019 Pali Rohár
PulseAudio is free software; you can redistribute
it and / or modify
under the terms of the GN
Control: tags -1 + pending
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> On Tue, Aug 06, 2019 at 08:30:56PM +0200, Holger Wansing wrote:
> > I was about to commit these changes, however it came to my mind if such
> > changes to the GPL are allowed?
> >
>
> > > > > See the English PDF at
> > > > > https://www.debian.org/releases/stable/amd64/install.pdf.en.
> > > > > Opening double quotes are rendered as right double quotes.
> > > > > And
> > > > > grave accents are ren
On Tue, Aug 06, 2019 at 08:30:56PM +0200, Holger Wansing wrote:
> I was about to commit these changes, however it came to my mind if such
> changes to the GPL are allowed?
>
> At least the English variant of the GPL is 'official' and is not to be
> changed, so what a
re rendered just as grave accents, not a left
> > > > single quotes.
> > >
> > > AIUI we should just replace "" and `' in the xml file with
> > > .
>
> I was about to commit these changes, however it came to my mind if
> such ch
//www.debian.org/releases/stable/amd64/install.pdf.en.
> > > Opening double quotes are rendered as right double quotes. And grave
> > > accents are
> > > rendered just as grave accents, not a left single quotes.
> >
> > AIUI we should just replace "" a
(debian-devel following Holger's advice, guessing all authors are subscribed)
On Thu, Jul 25, 2019 at 10:43:12PM -0300, Yao Wei (魏銘廷) wrote:
> What if, one of the upstream authors consider it violating GPL _without_ the
> clause? I mean, it could happen.
Indeed, and I'd argue
Ben Hutchings writes ("Re: nmap license is incompatible with GPL"):
> On Tue, 2018-04-10 at 11:42 +0200, Ansgar Burchardt wrote:
> > The license in particular also forbids front-ends parsing nmap's output
> > that are released under a license not compatible with n
On Tue, 2018-04-10 at 11:42 +0200, Ansgar Burchardt wrote:
> Hi,
>
> [ BCC'ed maintainers of packages mentioned below ]
>
> Chris Lamb pointed out that nmap uses a special version of the GPL-2
> which is incompatible with the standard GPL license:
>
> +---
>
Hi,
[ BCC'ed maintainers of packages mentioned below ]
Chris Lamb pointed out that nmap uses a special version of the GPL-2
which is incompatible with the standard GPL license:
+---
| Because this license imposes special exceptions to the GPL, Covered
| work may not be combined (even as pa
On Tue, Feb 20, 2018 at 07:21:21PM +0800, Paul Wise wrote:
> adequate has an incompatible-licenses tag that probably could be used
> for this. Just install all rdeps of cups and check all packages on the
> system with adequate.
piuparts.debian.org does this automatically (obviously only for stuff
On Tue, Feb 20, 2018 at 3:20 PM, Stuart Prescott wrote:
> I thought there might be something that could be done here.
adequate has an incompatible-licenses tag that probably could be used
for this. Just install all rdeps of cups and check all packages on the
system with adequate.
--
bye,
pabs
Didier 'OdyX' Raboud wrote:
> - What tools should I be using to identify which of these will be
> undistributable constructs? Aka: how, given a list of source packages,
> can I determine which are GPL-2-only in the codepaths that link against
> CUPS?
> [CUPS-links-t
(Adding d-legal)
Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to
proceed?"):
> tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
> "Apache-2.0"; how should the license incompatibilities be enforced?
This reply is g
tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to "Apache-2.0"; how
should the license incompatibilities be enforced?
As you might have heard [lwn][cups-apache], Apple has changed the CUPS license
away from a "GPL-2/LGPL-2 with exceptions" to plain Apa
On 08/30/2016 12:09 PM, Zlatan Todorić wrote:
> I don't know is it a time for GPLv4 which will explain to all
> corporations that THIS LICENSE mean you must participate with community
> and also make people aware that it is not only license but movement
> towards better humanity that cooperates all
On Tue, Sep 06, 2016 at 05:25:49PM -0400, Theodore Ts'o wrote:
> On Tue, Sep 06, 2016 at 02:29:56AM +0200, Zlatan Todorić wrote:
... and we're discussing all this on debian-devel because ... ?
--
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor
sure that most of their dormant projects where only good
> because community gave a lot of love and care after it was killed
> mainstream. So even if they produce most of the code today, they are
> still hostile to GPL and entire philosophy.
Sure, if you look the first few years Linux
where only good
because community gave a lot of love and care after it was killed
mainstream. So even if they produce most of the code today, they are
still hostile to GPL and entire philosophy.
>
> [1] Linux Kernel Development: How Fast It is Going, Who is Doing It,
> What They are Doi
On Tue, Aug 30, 2016 at 12:09:35PM +0200, Zlatan Todorić wrote:
> For years and years companies are using community hard work and creating
> their "great" products without turning back
>
> People all over the world created Free software for decades and just
> small number of those people got em
On 08/30/2016 09:43 AM, Holger Levsen wrote:
> Hi,
>
> http://www.jonobacon.org/2016/08/29/linux-linus-bradley-open-source-protection/
> just popped up in my rss feed and I thought I'd share it with you… it's
> a comment on the recent GPL enforcement debate on the
Hi,
http://www.jonobacon.org/2016/08/29/linux-linus-bradley-open-source-protection/
just popped up in my rss feed and I thought I'd share it with you… it's
a comment on the recent GPL enforcement debate on the (upstream) kernel
list.
I basically agree with Jono here.
--
cheers,
On Fri, 24 Oct 2014 06:56:39 +0800 Paul Wise wrote:
[...]
> Bradley Kuhn says that for GPLv2-only works Debian should not consider
> OpenSSL to be a system library but for works where the GPLv3 can
> apply, SSL/TLS is likely a "Standard Interface" and thus subject to
> the "System Library" excepti
On Thu, Oct 23, 2014 at 4:11 PM, Florian Weimer wrote:
> But Fedora, whose policies Richard Fontana helped to shape over the
> years, considers OpenSSL to be a library covered by the system library
> exception.
We discussed this on #faif[1] and:
Richard Fontana says the OpenSSL-system library ex
On 23 Oct 2014 02:03, "Thorsten Glaser" wrote:
...
>
> > Where it is clear it is indeed a concern. Note that Fontana is both a
> > lawyer, and co-author of the GPLv3.
>
> And a RedHat employee.
Was :) http://en.m.wikipedia.org/wiki/Richard_Fontana
On Thu, Oct 23, 2014 at 10:11:41AM +0200, Florian Weimer wrote:
> But Fedora, whose policies Richard Fontana helped to shape over the
> years, considers OpenSSL to be a library covered by the system library
> exception.
But legal advice is not necessarily portable. As a project, we can
certainly d
co-author of the GPLv3.
But Fedora, whose policies Richard Fontana helped to shape over the
years, considers OpenSSL to be a library covered by the system library
exception.
In practice, the FSF seems to agree with this interpretation (for the
GPLv2) because Microsoft Services for UNIX link
On Thu, 2014-10-23 at 12:46 +1100, Brian May wrote:
> On 23 October 2014 04:03, Russ Allbery wrote:
> It's usually more immediately useful to just
> upload the package with an explanation of the issues in
> debian/copyright
> and see what the ftp-master team says.
>
On 23 October 2014 04:03, Russ Allbery wrote:
> It's usually more immediately useful to just
> upload the package with an explanation of the issues in debian/copyright
> and see what the ftp-master team says.
>
This is probably getting off-track, however I have a package that has been
stuck in N
project, who
> release their software under the terms of GPL-3, asking if I could
> provide an alternative to the OpenSSL-linked library so they can use it
> without causing a license conflict.
>
> Sadly librabbitmq only supports OpenSSL, there is rudimentary support
> for GnuTLS bu
Matthias Urlichs writes:
> Nevertheless, it is the forum where we-as-a-distribution are supposed to
> arrive at a rough consensus on what's OK, legally, and what is not, thus
> the discussion belongs there.
It's never been used that way for as long as I've been a project member.
Instead, it's a
On Oct 22, Matthias Urlichs wrote:
> > No, debian-legal is no body within Debian, just a random armchair
> > lawyer discussion list. But it may be Cc’d, sure.
> Nevertheless, it is the forum where we-as-a-distribution are supposed to
> arrive at a rough consensus on what's OK, legally, and what i
Hi,
Thorsten Glaser:
> Also, it’s normal that someone has a rosy sight on something they wrote.
>
> Note that the intent of the actual copyright owners counts
> *much* more than the intent of the licence writers when
> interpreting clauses.
>
Sure, but in many cases there is not much expression
On Wed, 22 Oct 2014, Henrique de Moraes Holschuh wrote:
> The problem is that Debian is the operating system distributing the system
> libraries, and that all packages Debian distributes are *also* part of that
> same operating system.
Wrong: “*as long as*
your GPL binary is not shipped
, at the end of
the day, the only really safe option is to require the license exception if
you're going to link GPL code to OpenSSL. And that is, AFAIK, the instance
the ftpmasters decided to adopt.
Anyway, this thread likely belongs more on debian-legal than on
debian-devel. Adding Cc:
under the GPL, so I don't really see why we have
to do this for other infrastructure components.
The long term solution is to rely on the system library exception to
regain GPL compatibility, just as Fedora does. It's really
unavoidable with libraries moving to (L)GPLv3 and the pre
Jelmer Vernooij dixit:
>Samba is unlikely to add such an exception.
So just make OpenSSL a system library finally.
bye,
//mirabilos
--
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the
On Tue, Oct 21, 2014 at 04:41:27PM +0200, Ondřej Surý wrote:
> Why just not add a license exception as many other GPL projects do?
> Something like (copied from our Knot DNS d/copyright):
>
> In addition, as a special exception, the author of this program gives
> permission to l
Why just not add a license exception as many other GPL projects do?
Something like (copied from our Knot DNS d/copyright):
In addition, as a special exception, the author of this program gives
permission to link the code of its release with the OpenSSL project's
"OpenSSL" l
Hi,
I'm the maintainer for src:librabbitmq and the binary package
librabbitmq1 is linked against libssl1.0.0 (OpenSSL).
Now I was approached by Julien Kerihuel from the OpenChange project, who
release their software under the terms of GPL-3, asking if I could
provide an alternative t
Package: wnpp
Severity: wishlist
Owner: "Aurélien Roux"
* Package name: tapeutape
Version : 0.1.1
Upstream Author : Florent Berthaut
* URL : http://hitmuri.net/index.php/Software/Tapeutape
* License : GPL
Programming Lang: C++
Descripti
On 05. april 2012 16:07, Gergely Nagy wrote:
> Then you will have to have a GPL-2 and a GPL-2+ License section, where
> one says:
>
> License: GPL-2+
> This program is free software; you can redistribute it and/or modify it
> under the terms of the GNU General Public Li
Andreas Noteng writes:
> Hello, in one of my packages I have multiple files paragraphs with
> license GPL-2+, at the end I have a standalone license paragraph labeled
> GPL-2, this generates a lintian warning about missing license paragraph
> GPL-2+. Shouldn't lintian ignore
Hello, in one of my packages I have multiple files paragraphs with
license GPL-2+, at the end I have a standalone license paragraph labeled
GPL-2, this generates a lintian warning about missing license paragraph
GPL-2+. Shouldn't lintian ignore the +, because it only means this
version or, at
Package: wnpp
Severity: wishlist
Owner: Marco Balmer
* Package name: aspsms-t
Version : 1.3.0
Upstream Author : Marco Balmer
* URL : http://github.com/micressor/aspsms-t
* License : GPL-2
Programming Lang: Perl
Description : aspsms-t is a jabber/xmpp
0 would be more appropriate?
Yes. Such a version number would be better.
> > > Upstream Author : Nokia Corporation and/or its subsidiary(-ies)
> > >
> > > * URL :
> > > ftp://ftp.heanet.ie/mirrors/ftp.trolltech.com/pub/qt/solutions/lgpl/*.
On 11-09-17 at 01:45am, Georges Khaznadar wrote:
> Sune Vuorela a écrit :
> > On Friday 16 September 2011 14:33:49 Georges Khaznadar wrote:
> > > Version : 1.0
> >
> > Where does this version number come from?
>
> This version number is arbitrary. 2009.0 would be more appropriate?
As invented-
Hello Sune,
Sune Vuorela a écrit :
> On Friday 16 September 2011 14:33:49 Georges Khaznadar wrote:
> > * Package name: qt-solutions2009-gpl
>
> You are aware that qt solutions is dead upstream, and this is a 2 years old
> copy of it?
Yes I am aware of it. The reason why
On Friday 16 September 2011 14:33:49 Georges Khaznadar wrote:
> * Package name: qt-solutions2009-gpl
You are aware that qt solutions is dead upstream, and this is a 2 years old
copy of it?
> Version : 1.0
Where does this version number come from?
> Upstream Autho
Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar
* Package name: qt-solutions2009-gpl
Version : 1.0
Upstream Author : Nokia Corporation and/or its subsidiary(-ies)
* URL :
ftp://ftp.heanet.ie/mirrors/ftp.trolltech.com/pub/qt/solutions/lgpl/*.tar.gz
Package: wnpp
Severity: wishlist
Owner: Christopher Baines
Package name: bluecove-gpl
Version : 2.1.0
Upstream Author : Mina Shokry and Vlad Skarzhevskyy
URL : http://bluecove.org/
License : GPL
Programming Lang: Java and C
Description : BlueCove
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
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 tha
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
On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote:
> Lucas Nussbaum 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
> >> me
Patrick Schoenfeld 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
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 fi
Patrick Schoenfeld 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 indica
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
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/inclu
* Lucas Nussbaum [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-minim
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 r
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
>
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 rep
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 lib
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. W
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.
>
>
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 pa
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.
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 t
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 w
On Tue, Jan 19, 2010 at 02:36:08PM -0800, Russ Allbery wrote:
> Neil McGovern 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, t
1 - 100 of 405 matches
Mail list logo
