On Mon, Dec 13, 2010 at 11:42 PM, Vincent Danjean wrote:
> On 12/12/2010 20:27, Olaf van der Spek wrote:
>> On Sat, Dec 11, 2010 at 6:25 PM, Lars Wirzenius wrote:
>>> On la, 2010-12-11 at 17:04 +0100, Olaf van der Spek wrote:
I agree it's not optimal, hence my push for auto linking.
>>>
>>>
On 12/12/2010 20:27, Olaf van der Spek wrote:
> On Sat, Dec 11, 2010 at 6:25 PM, Lars Wirzenius wrote:
>> On la, 2010-12-11 at 17:04 +0100, Olaf van der Spek wrote:
>>> I agree it's not optimal, hence my push for auto linking.
>>
>> Can you provide a link to a page giving a description of this
>>
On Mon, Dec 13, 2010 at 12:06 AM, David Weinehall wrote:
>> I agree it's not optimal, hence my push for auto linking.
>
> So, let me get this straight:
>
> Either Debian, and all other distributions that are to support boost,
> patch gcc (one of the most complex and most important codebases in the
On Sat, Dec 11, 2010 at 05:04:59PM +0100, Olaf van der Spek wrote:
> On Fri, Dec 10, 2010 at 7:52 PM, Vincent Danjean wrote:
> > Here, you are wrong. If I want to use the 'filesystem' part of boost,
> > I (as a user of the library) must be able to find all required info
> > only from the part of b
On Sat, Dec 11, 2010 at 6:25 PM, Lars Wirzenius wrote:
> On la, 2010-12-11 at 17:04 +0100, Olaf van der Spek wrote:
>> I agree it's not optimal, hence my push for auto linking.
>
> Can you provide a link to a page giving a description of this
> auto-linking stuff?
See "lib" at: http://msdn.micros
On la, 2010-12-11 at 17:04 +0100, Olaf van der Spek wrote:
> I agree it's not optimal, hence my push for auto linking.
Can you provide a link to a page giving a description of this
auto-linking stuff?
--
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/
On Fri, Dec 10, 2010 at 7:52 PM, Vincent Danjean wrote:
> Here, you are wrong. If I want to use the 'filesystem' part of boost,
> I (as a user of the library) must be able to find all required info
> only from the part of boost that I want to use.
> "pkg-config --libs boost_filesystem" is one stan
On 10/12/2010 16:59, Olaf van der Spek wrote:
> On Fri, Dec 10, 2010 at 3:28 PM, Vincent Danjean wrote:
>> [C] selection of the "tool chain"
>> Comment: this seems to be very boost specific!
>
> Not necessary at the moment.
>
>>For what I saw, there is the MT/no thread choice. Are there oth
On Fri, Dec 10, 2010 at 3:28 PM, Vincent Danjean wrote:
> [C] selection of the "tool chain"
> Comment: this seems to be very boost specific!
Not necessary at the moment.
> For what I saw, there is the MT/no thread choice. Are there others ?
> It is possible that boost will be used by differ
Hi,
On 10/12/2010 13:59, Olaf van der Spek wrote:
> On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh wrote:
>> People who do need this can build multiple versions, install them
>> into different prefixes and then set PKG_CONFIG_PATH to select
>> the variant they want at configure time. Unlike Boos
On Fri, Dec 10, 2010 at 1:09 PM, Roger Leigh wrote:
>> So?
>
> When we write code, we write it with the intention and expectation
> that it will be built using a standards-conforming compiler. I.e.
> one which implements the C and/or C++ language specification, and
> which also implements standar
On Thu, Dec 09, 2010 at 02:00:24PM +0100, Olaf van der Spek wrote:
> On Mon, Dec 6, 2010 at 4:34 PM, Roger Leigh wrote:
> >> I was wondering why you considered the auto linking stuff to be so
> >> horrible.
> >> IMO the best solution would be to get auto link support into GCC too.
> >
> > It's no
On Fri, Dec 10, 2010 at 2:38 AM, Fernando Lemos wrote:
> Hi Olaf, Roger
>
> On Thu, Dec 9, 2010 at 11:00 AM, Olaf van der Spek
> wrote:
> [...]
>>> Now, pkg-config isn't standardised /either/, but it's useful because
>>> it will work with any standards-conforming compiler. It's just a
>>> gener
Hi Olaf, Roger
On Thu, Dec 9, 2010 at 11:00 AM, Olaf van der Spek wrote:
[...]
>> Now, pkg-config isn't standardised /either/, but it's useful because
>> it will work with any standards-conforming compiler. It's just a
>> generalisation of existing practice (in the form of foo-config
>> scripts
On Mon, Dec 6, 2010 at 4:34 PM, Roger Leigh wrote:
>> I was wondering why you considered the auto linking stuff to be so horrible.
>> IMO the best solution would be to get auto link support into GCC too.
>
> It's non standard
> - it's not specified by ISO C
> - it's not specified by SUS/POSIX
So?
On 07/12/10 at 14:15 +0100, Loïc Minier wrote:
> On Tue, Dec 07, 2010, Lucas Nussbaum wrote:
> > Are you building on ext3 or ext4?
>
> ext4
I could reproduce the failure in a clean chroot generated with
debootstrap --variant=buildd. on IRC, Michael Bienia also said that he
was able to reproduce
On Tue, Dec 07, 2010, Lucas Nussbaum wrote:
> Are you building on ext3 or ext4?
ext4
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101207131552.
On 07/12/10 at 13:17 +0100, Loïc Minier wrote:
> On Tue, Dec 07, 2010, Loïc Minier wrote:
> > The apport failure as bugged me for a while, I tried to reproduce it
> > multiple times in the past and even just understanding the failure from
> > the source and error message, but couldn't figure it
On Tue, Dec 07, 2010, Loïc Minier wrote:
> The apport failure as bugged me for a while, I tried to reproduce it
> multiple times in the past and even just understanding the failure from
> the source and error message, but couldn't figure it out in the past;
Maybe the difference is in the order
On Mon, Dec 06, 2010, Lucas Nussbaum wrote:
> As I already told you on IRC, given that I could make apport fail two
> times on both i386 and amd64, and provided the build log, I think that
> the next step is for you to provide a build log, so we can diff them.
The apport failure as bugged me for
On Mon, Dec 06, 2010 at 02:57:59PM +0100, Olaf van der Spek wrote:
> On Mon, Dec 6, 2010 at 2:50 PM, Roger Leigh wrote:
> >> >> These are using proprietary vendor-specific #pragmas. It's pretty
> >> >
> >> > True, but IMO the concept seems pretty useful.
> >> >
> >> > Why do you think it's horrib
On Mon, Dec 6, 2010 at 2:50 PM, Roger Leigh wrote:
>> >> These are using proprietary vendor-specific #pragmas. It's pretty
>> >
>> > True, but IMO the concept seems pretty useful.
>> >
>> > Why do you think it's horrible? It appears to work well.
>> >
>> >> horrible, not to mention fragile--if an
On Mon, Dec 06, 2010 at 02:32:01PM +0100, Olaf van der Spek wrote:
> On Fri, Dec 3, 2010 at 11:38 PM, Olaf van der Spek
> wrote:
> > On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote:
> >>> > The header is just a text file. It doesn't contain any library
> >>> > dependency information (or vers
On Fri, Dec 3, 2010 at 11:38 PM, Olaf van der Spek wrote:
> On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote:
>>> > The header is just a text file. It doesn't contain any library
>>> > dependency information (or version information) at all, and there's
>>>
>>> boost/version.hpp
>>
>> We only c
On 06/12/10 at 03:33 +0100, Matthias Klose wrote:
> On 03.12.2010 08:43, Lucas Nussbaum wrote:
> >Hi,
> >
> >>From time to time, I do archive rebuilds for Ubuntu too, and I thought
> >that the results would be interesting for DDs as well, since a FTBFS in
> >Ubuntu might indicate that the package w
On 06/12/10 at 02:57 +0100, Matthias Klose wrote:
> On 03.12.2010 22:54, Erik de Castro Lopo wrote:
> >Lucas Nussbaum wrote:
> >
> >>Hi,
> >>
> >>> From time to time, I do archive rebuilds for Ubuntu too, and I thought
> >>that the results would be interesting for DDs as well, since a FTBFS in
> >>
On Vie 03 Dic 2010 04:43:23 Lucas Nussbaum escribió:
> Hi,
>
> >From time to time, I do archive rebuilds for Ubuntu too, and I thought
>
> that the results would be interesting for DDs as well, since a FTBFS in
> Ubuntu might indicate that the package will FTBFS in the future in
> Debian, due to
On 03.12.2010 08:43, Lucas Nussbaum wrote:
Hi,
From time to time, I do archive rebuilds for Ubuntu too, and I thought
that the results would be interesting for DDs as well, since a FTBFS in
Ubuntu might indicate that the package will FTBFS in the future in
Debian, due to toolchain changes for
On 03.12.2010 22:54, Erik de Castro Lopo wrote:
Lucas Nussbaum wrote:
Hi,
> From time to time, I do archive rebuilds for Ubuntu too, and I thought
that the results would be interesting for DDs as well, since a FTBFS in
Ubuntu might indicate that the package will FTBFS in the future in
Debian,
On Fri, Dec 03, 2010 at 02:28:32PM +, Roger Leigh wrote:
> On Fri, Dec 03, 2010 at 03:14:05PM +0100, Samuel Thibault wrote:
> > Roger Leigh, le Fri 03 Dec 2010 14:08:48 +, a écrit :
> > > While I do find this a rather annoying violation of encapsulation,
> > > you will find (e.g. with "nm -
Lucas Nussbaum wrote:
> Hi,
>>From time to time, I do archive rebuilds for Ubuntu too, and I thought
> that the results would be interesting for DDs as well, since a FTBFS in
> Ubuntu might indicate that the package will FTBFS in the future in
> Debian, due to toolchain changes for example.
> Be
* Michael Bienia [101204 12:26]:
> The problem lies 3 lines above that snippet:
> LDFLAGS="`${LOG4CPP_CONFIG} --libs` $LDFLAGS"
>
> using LIBS instead of LDFLAGS fixes the order as configure uses LIBS
> after the source file during linking.
>
> When one looks at the remaining configure.ac it a
On 2010-12-03 16:36:10 -0800, Russ Allbery wrote:
> Stefano Rivera writes:
> > gcc argument order:
> > g++ -o conftest -pthread -g -O2 -Wall -O2 -DNDEBUG -pthread -g -O2 -g -Wall
> > -O2 -O2 -DNDEBUG-L/usr/lib -llog4cpp -lnsl -Wl,-Bsymbolic-functions
> > conftest.cpp -lz >&5
>
> > This wi
On 03/12/10 at 23:30 +0100, Holger Levsen wrote:
> Hi,
>
> On Freitag, 3. Dezember 2010, Lucas Nussbaum wrote:
> > From time to time, I do archive rebuilds for Ubuntu too
>
> from time to time, I use my mail programm to mark a thread and all future
> replies as read. (very seldom, actually this
Stefano Rivera writes:
> gcc argument order:
> g++ -o conftest -pthread -g -O2 -Wall -O2 -DNDEBUG -pthread -g -O2 -g -Wall
> -O2 -O2 -DNDEBUG-L/usr/lib -llog4cpp -lnsl -Wl,-Bsymbolic-functions
> conftest.cpp -lz >&5
> /tmp/ccnWkLI6.o: In function `main':
> /tmp/buildd/opensaml2-2.3/confte
On Fri, Dec 3, 2010 at 11:22 PM, Roger Leigh wrote:
>> > The header is just a text file. It doesn't contain any library
>> > dependency information (or version information) at all, and there's
>>
>> boost/version.hpp
>
> We only care about SONAME versions, not release versions, and we only
> need
Hi,
On Freitag, 3. Dezember 2010, Lucas Nussbaum wrote:
> From time to time, I do archive rebuilds for Ubuntu too
from time to time, I use my mail programm to mark a thread and all future
replies as read. (very seldom, actually this is a first time, I send mail to
such a thread though ;)
and s
> On Fri, Dec 03, 2010 at 02:52:12PM -0200, Fernando Lemos wrote:
> > The requirement of linking to boost::system is an implementation
> > detail of boost::filesystem that package maintainers should *not*
> > have to worry about.
[Roger Leigh]
> We shouldn't have to worry about it, it should be a
Hi Russ (2010.12.03_19:25:06_+0200)
> >opensaml2 (U)
> I'm not sure what to make of these. The build failure says that it thinks
> it got a log4cpp that's older than version 1.0, but the version in Ubuntu
> is the same as the version in Debian.
gcc argument order:
g++ -o conftest -pthread -g
On Fri, Dec 03, 2010 at 11:09:01PM +0100, Olaf van der Spek wrote:
> On Fri, Dec 3, 2010 at 11:04 PM, Roger Leigh wrote:
> >> The header knows what version it is, so it can use that to link to the
> >> correct lib.
> >
> > The header is just a text file. It doesn't contain any library
> > depende
On Fri, Dec 3, 2010 at 11:04 PM, Roger Leigh wrote:
>> The header knows what version it is, so it can use that to link to the
>> correct lib.
>
> The header is just a text file. It doesn't contain any library
> dependency information (or version information) at all, and there's
boost/version.hpp
On Fri, Dec 03, 2010 at 10:57:59PM +0100, Olaf van der Spek wrote:
> >> BTW, got my mail about auto linking?
> >
> > I saw it, yes. I'm not sure how MSVC implements auto-linking, but
> > I would be concerned about the determinism of such behaviour,
> > especially when a given symbol could be satis
On Fri, Dec 3, 2010 at 10:38 PM, Roger Leigh wrote:
>> Wouldn't this only happen on a major version change of the Boost package?
>> Thus requiring a recompile?
>
> This is hopefully what would happen. But there's no guarantee that
> this would be the case, and that's really down to whatever polic
Lucas Nussbaum wrote:
> Hi,
>
> >From time to time, I do archive rebuilds for Ubuntu too, and I thought
> that the results would be interesting for DDs as well, since a FTBFS in
> Ubuntu might indicate that the package will FTBFS in the future in
> Debian, due to toolchain changes for example.
>
On Fri, Dec 3, 2010 at 10:27 PM, Roger Leigh wrote:
> Windows is even worse, but developers for that platform are
> masochistic by nature. They install multiple versions in separate
> directories, obviously not in standard locations because there are
> none, and hard code the paths in their sourc
On Fri, Dec 03, 2010 at 10:23:39PM +0100, Olaf van der Spek wrote:
> On Fri, Dec 3, 2010 at 10:09 PM, Roger Leigh wrote:
> > Now, consider what happens if libboost_filesystem drops its
> > libboost_system dependency. NOTE: we're not considering rebuilding
> > from source here, we're concerned wit
On Fri, Dec 03, 2010 at 03:54:49PM -0200, Fernando Lemos wrote:
> Hi Roger,
>
> On Fri, Dec 3, 2010 at 3:41 PM, Roger Leigh wrote:
> [...]
> > btag *does* use boost::system, even though you don't want to use it.
> > Right now, with the g++4.5 and/or the gold linker, you aren't linking
> > with a
On Fri, Dec 3, 2010 at 10:09 PM, Roger Leigh wrote:
> Now, consider what happens if libboost_filesystem drops its
> libboost_system dependency. NOTE: we're not considering rebuilding
> from source here, we're concerned with BINARY compatibility, i.e.
> our compiled program working with future boo
On Fri, Dec 03, 2010 at 03:58:13PM -0200, Fernando Lemos wrote:
> Hi, Olaf
>
> On Fri, Dec 3, 2010 at 3:49 PM, Olaf van der Spek
> wrote:
> > On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh wrote:
> >> Why? If you link indirectly today, and later on boost_filesystem
> >> drops its boost_system dep
Hi, Olaf
On Fri, Dec 3, 2010 at 3:49 PM, Olaf van der Spek wrote:
> On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh wrote:
>> Why? If you link indirectly today, and later on boost_filesystem
>> drops its boost_system dependency, your code will break because
>> those inlined functions are in *your*
Hi Roger,
On Fri, Dec 3, 2010 at 3:41 PM, Roger Leigh wrote:
[...]
> btag *does* use boost::system, even though you don't want to use it.
> Right now, with the g++4.5 and/or the gold linker, you aren't linking
> with a library you need. And I'm afraid that right at this point in
> time, it does
On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh wrote:
> Why? If you link indirectly today, and later on boost_filesystem
> drops its boost_system dependency, your code will break because
> those inlined functions are in *your* code, not the filesystem
> library. You'll get a link failure. By linki
On Fri, Dec 03, 2010 at 02:52:12PM -0200, Fernando Lemos wrote:
>
> On Fri, Dec 3, 2010 at 12:08 PM, Roger Leigh wrote:
> > While I do find this a rather annoying violation of encapsulation,
> > you will find (e.g. with "nm -C -D") your binary will have
> > boost::system symbols in it which are o
Lucas Nussbaum writes:
> Russ Allbery
>opensaml2 (U)
>shibboleth-sp2 (U)
>xmltooling (U)
I'm not sure what to make of these. The build failure says that it thinks
it got a log4cpp that's older than version 1.0, but the version in Ubuntu
is the same as the version in Debian.
--
Ru
Hi Roger,
On Fri, Dec 3, 2010 at 12:08 PM, Roger Leigh wrote:
> This is a bug in your package, unfortunately. While it might appear
> that you only use boost_system /indirectly/, your code is in fact
> using it /directly/ via inline functions in the boost_filesystem
> headers. You can see this
On Sat, Dec 04, 2010 at 12:41:50AM +0900, Osamu Aoki wrote:
>
> Baically, we need "locales-all" equivalent to build this package. I
> added "locales" to make this package cross buildable on Ubuntu. Sbuild
> log identifies both locales-all and locales are not available as
> started. It only trie
On Fri, Dec 03, 2010 at 08:43:23AM +0100, Lucas Nussbaum wrote:
> Osamu Aoki
>debian-reference
I checked http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi and I am
intrigued.
Build log seems to indicate it failed to build.
http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/debian-reference_2.44
On Fri, Dec 3, 2010 at 5:30 PM, Lucas Nussbaum wrote:
> On 03/12/10 at 16:00 +0800, Paul Wise wrote:
>
>> Would it be possible to get this listed in the Ubuntu box in the PTS?
>
> Erm, it would be possible, but that requires a bit of work. Also, I don't
> rebuild Ubuntu that frequently, so the dat
On Fri, Dec 3, 2010 at 3:28 PM, Roger Leigh wrote:
>> You can't make all application know what headers are doing, since that
>> could change.
>
> pkg-config support for Boost is a long-standing issue. Unfortunately,
> there's no usable alternative that provides this information, TTMOBK.
MSVC has
On Fri, Dec 03, 2010 at 03:14:05PM +0100, Samuel Thibault wrote:
> Roger Leigh, le Fri 03 Dec 2010 14:08:48 +, a écrit :
> > While I do find this a rather annoying violation of encapsulation,
> > you will find (e.g. with "nm -C -D") your binary will have
> > boost::system symbols in it which ar
Roger Leigh, le Fri 03 Dec 2010 14:08:48 +, a écrit :
> While I do find this a rather annoying violation of encapsulation,
> you will find (e.g. with "nm -C -D") your binary will have
> boost::system symbols in it which are only satisfied indirectly
> via libboost_filesystem and which would res
On Fri, Dec 03, 2010 at 10:16:03AM -0200, Fernando Lemos wrote:
> Hi Lucas,
>
> Thanks for generating this list.
>
> 2010/12/3 Lucas Nussbaum :
> > Fernando Tarlá Cardoso Lemos
> > btag
>
> This is not a bug in btag. The problem is that binutils-gold (used by
> Ubuntu) breaks every program th
On Fri, 03 Dec 2010 08:43:23 +0100, Lucas Nussbaum wrote:
> Felipe Sateler
>ladspa-sdk (U)
This one is broken by --as-needed. Since --as-needed works by processing
items on the commandline in order, all packages that specify libs before
built objects will fail to build.
--
Saludos,
Fe
Hi Lucas,
Thanks for generating this list.
2010/12/3 Lucas Nussbaum :
> Fernando Tarlá Cardoso Lemos
> btag
This is not a bug in btag. The problem is that binutils-gold (used by
Ubuntu) breaks every program that uses Boost (among other C++
libraries):
http://bugs.debian.org/cgi-bin/bugreport
On Fri, Dec 03, 2010 at 12:31:06PM +0100, Josselin Mouette wrote:
> Le vendredi 03 décembre 2010 à 12:28 +0100, Mike Hommey a écrit :
> > But I do agree that a -Bsymbolic default is dangerous. Upstream may want
> > to use them at their will, but this shouldn't be enforced by the
> > toolchain.
>
>
> Many packages (e.g. xfe, xfce-*) fails with
> "[LD_ERROR] ...: could not read symbols: Invalid operation"
> I know that the Xfe package fails because Ubuntu use:
> "-Bsymbolic-functions" by default by the linker.
> The reasons for the problems are redefinitions of some library functions
> in
Le vendredi 03 décembre 2010 à 12:28 +0100, Mike Hommey a écrit :
> But I do agree that a -Bsymbolic default is dangerous. Upstream may want
> to use them at their will, but this shouldn't be enforced by the
> toolchain.
OTOH -Bsymbolic should really be mandatory for loadable shared objects,
like
On Fri, Dec 03, 2010 at 11:11:18AM +, Roger Leigh wrote:
> On Fri, Dec 03, 2010 at 11:27:44AM +0100, Joachim Wiedorn wrote:
> > Lucas Nussbaum wrote on 2010-12-03 10:36:
> >
> > > No, sorry. I must admit that I didn't spend any time investigating the
> > > failures. However, my irssi backlog
Hello Lucas,
Lucas Nussbaum schrieb am 03.12.2010 08:43:
>>From time to time, I do archive rebuilds for Ubuntu too, and I thought
> that the results would be interesting for DDs as well, since a FTBFS in
> Ubuntu might indicate that the package will FTBFS in the future in
> Debian, due to toolchain
On Fri, Dec 03, 2010 at 11:27:44AM +0100, Joachim Wiedorn wrote:
> Lucas Nussbaum wrote on 2010-12-03 10:36:
>
> > No, sorry. I must admit that I didn't spend any time investigating the
> > failures. However, my irssi backlog says the two major changes in Ubuntu
> > that could cause failures are:
Lucas Nussbaum wrote on 2010-12-03 10:36:
> No, sorry. I must admit that I didn't spend any time investigating the
> failures. However, my irssi backlog says the two major changes in Ubuntu
> that could cause failures are:
> - --as-needed is now used by default by the linker
> - python2.7
Many p
On 03/12/10 at 10:36 +0100, Lucas Nussbaum wrote:
> No, sorry. I must admit that I didn't spend any time investigating the
> failures. However, my irssi backlog says the two major changes in Ubuntu
> that could cause failures are:
> - --as-needed is now used by default by the linker
> - python2.7
On 03/12/10 at 09:18 +0100, Ralf Treinen wrote:
> On Fri, Dec 03, 2010 at 08:43:23AM +0100, Lucas Nussbaum wrote:
>
> > >From time to time, I do archive rebuilds for Ubuntu too, and I thought
> > that the results would be interesting for DDs as well, since a FTBFS in
> > Ubuntu might indicate that
On 03/12/10 at 16:00 +0800, Paul Wise wrote:
> 2010/12/3 Lucas Nussbaum :
>
> > From time to time, I do archive rebuilds for Ubuntu too, and I thought
> > that the results would be interesting for DDs as well, since a FTBFS in
> > Ubuntu might indicate that the package will FTBFS in the future in
On Fri, Dec 03, 2010 at 08:43:23AM +0100, Lucas Nussbaum wrote:
> >From time to time, I do archive rebuilds for Ubuntu too, and I thought
> that the results would be interesting for DDs as well, since a FTBFS in
> Ubuntu might indicate that the package will FTBFS in the future in
> Debian, due to
2010/12/3 Lucas Nussbaum :
> From time to time, I do archive rebuilds for Ubuntu too, and I thought
> that the results would be interesting for DDs as well, since a FTBFS in
> Ubuntu might indicate that the package will FTBFS in the future in
> Debian, due to toolchain changes for example.
Would
76 matches
Mail list logo