Re: Building architecture:all packages

[Adam Borowski]

On Sun, Dec 04, 2016 at 07:39:44PM +0100, Christoph Biedl wrote:
> Adam Borowski wrote...
> > I see two problems in that code:
> > * it's Launchpad-specific
> > * it supports only a single build-indep architecture rather than a list
> 
> Um, yes, perhaps, no. The important thing to me is there's already
> something around that solves a problem I have. Of course this header
> should see a formalization, and certainly this should be a list. I've
> filed #846970.

Looks great, thanks!

> > With my 3270font maintainer hat on: I wouldn't even know of this if not for
> > the reproducible builds project, despite doing lots of rebuilds on various
> > architectures (albeit not really for this package).  I guess there's a lot
> > of other arch-dependant failures for arch:all packages.
> 
> Err, hi. I admit I deliberately did not notice you beforehand - mostly
> to keep you out of some hazzle you are not responsible for at all. Since
> however even the recent fontforge upgrade did not change the situation,
> I might ask you to include that header once the above process has come
> to a result.

Actually, I wonder if it's a good idea to differentiate somehow between
transient bugs and architectures the package is not supposed to build on.
Some kind of annotation?

As for finding currently failing packages, it's a matter of looking at
existing archive rebuild logs.

-- 
u-boot problems can be solved with the help of your old SCSI manuals, the
parts that deal with goat termination.  You need a black-handled knife, and
an appropriate set of candles (number and color matters).  Or was it a
silver-handled knife?  Crap, need to look that up.

Re: Building architecture:all packages

[Christoph Biedl]

Adam Borowski wrote...

> I see two problems in that code:
> * it's Launchpad-specific
> * it supports only a single build-indep architecture rather than a list

Um, yes, perhaps, no. The important thing to me is there's already
something around that solves a problem I have. Of course this header
should see a formalization, and certainly this should be a list. I've
filed #846970.

> With my 3270font maintainer hat on: I wouldn't even know of this if not for
> the reproducible builds project, despite doing lots of rebuilds on various
> architectures (albeit not really for this package).  I guess there's a lot
> of other arch-dependant failures for arch:all packages.

Err, hi. I admit I deliberately did not notice you beforehand - mostly
to keep you out of some hazzle you are not responsible for at all. Since
however even the recent fontforge upgrade did not change the situation,
I might ask you to include that header once the above process has come
to a result.

Regards,
Christoph


signature.asc
Description: Digital signature

Re: Building architecture:all packages

[Colin Watson]

On Sat, Nov 12, 2016 at 06:27:55PM +0100, Johannes Schauer wrote:
> Quoting Colin Watson (2016-11-12 18:09:22)
> > > * it supports only a single build-indep architecture rather than a list
> > 
> > Not so; you have misread the code.  It is a list of architectures that
> > architecture-independent binary packages can be on.
> > 
> > > I propose the new field to be a list per the usual architecture syntax.
> > 
> > Fortunately, since it already is, there is no need for a new field.
> 
> so, the field also supports architecture wildcards? So I can say:
> 
> Build-Indep-Architecture: any
> 
> or:
> 
> Build-Indep-Architecture: linux-any

Yes.

> And in an utopic feature, maybe even:
> 
> Build-Indep-Architecture: any-gnu-any-any
> 
> (to build on any glibc based architecture)

We'd need to have a dpkg-architecture that supports quadruplets on the
server side, and I'm not sure we currently do, but in principle yes.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Building architecture:all packages

[Colin Watson]

On Sat, Nov 12, 2016 at 05:47:00PM +, Ben Hutchings wrote:
> On Sat, 2016-11-12 at 15:13 +0100, Adam Borowski wrote:
> > If manually specifying that is needed, pixfrogger is another case that
> > should declare a list rather than a single arch: i386 is basically gone
> > other than hardware emulation on amd64, armhf is a better supported 32-bit
> > arch these days (at least counting porters and new gear).
> 
> Simpler solution: remove fenix, pixbros and pixfrogger.  The world
> doesn't need a 32-bit only game library and 2 derivative games.
> (fenix is dead upstream - homepage is still up but the links are all
> broken; it's never had a new upstream version in Debian.)

I have no particular attachment to pixfrogger et al, but the underlying
problem isn't new and isn't likely to be fixed by whack-a-mole.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Building architecture:all packages

[Ben Hutchings]

On Sat, 2016-11-12 at 15:13 +0100, Adam Borowski wrote:
[...]
> If manually specifying that is needed, pixfrogger is another case that
> should declare a list rather than a single arch: i386 is basically gone
> other than hardware emulation on amd64, armhf is a better supported 32-bit
> arch these days (at least counting porters and new gear).
[...]

Simpler solution: remove fenix, pixbros and pixfrogger.  The world
doesn't need a 32-bit only game library and 2 derivative games.
(fenix is dead upstream - homepage is still up but the links are all
broken; it's never had a new upstream version in Debian.)

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



signature.asc
Description: This is a digitally signed message part

Re: Building architecture:all packages

[Johannes Schauer]

Hi,

Quoting Colin Watson (2016-11-12 18:09:22)
> > * it supports only a single build-indep architecture rather than a list
> 
> Not so; you have misread the code.  It is a list of architectures that
> architecture-independent binary packages can be on.
> 
> > I propose the new field to be a list per the usual architecture syntax.
> 
> Fortunately, since it already is, there is no need for a new field.

so, the field also supports architecture wildcards? So I can say:

Build-Indep-Architecture: any

or:

Build-Indep-Architecture: linux-any

And in an utopic feature, maybe even:

Build-Indep-Architecture: any-gnu-any-any

(to build on any glibc based architecture)

I didn't read the launchpad code but only found four packages using the
Build-Indep-Architecture field in the Ubuntu Yakkety Sources file and all four
of them use either amd64 or i386 but no wildcards.

If the field doesn't support architecture wildcards, then I wouldn't call it "a
list per the usual architecture syntax".

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Building architecture:all packages

[Colin Watson]

On Sat, Nov 12, 2016 at 03:13:54PM +0100, Adam Borowski wrote:
> On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> > Colin Watson wrote...
> > > We know this not to have been the case in the past.
> > > https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of
> > > palo (hppa), openhackware (powerpc), and openbios-sparc (sparc).
> 
> I see two problems in that code:
> * it's Launchpad-specific

Er, obviously it's part of Launchpad.  That's not a "problem" when I was
presenting it merely as an example.

That said, most of the hard work is done in
lib/lp/soyuz/adapters/buildarch.py:determine_architectures_to_build,
which uses no other parts of Launchpad and could easily be transposed to
some other system.

The problem for somebody implementing this in Debian would not be that
the logical implementation of this field is Launchpad-specific; it would
be the different overall models for dispatching builds.  Nevertheless, I
don't believe I've ever heard a serious developer complain about having
too much example code.

> * it supports only a single build-indep architecture rather than a list

Not so; you have misread the code.  It is a list of architectures that
architecture-independent binary packages can be on.

> As the code has to be rewritten for DAK/w-b/etc anyway, and the XS- prefix
> can't be used because it's officially "unofficial",

No.  XS- doesn't mean "unofficial"; rather, it means "copy this
user-defined field to the output .dsc file" (see
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s5.7).
There is precedent for newly-defined fields starting out this way until
they become well-established enough that dpkg copies them by default and
they're added to policy, for example Vcs-*.  The objection that this new
field cannot be used because it's been introduced using the perfectly
normal way to introduce new fields is not a reasonable one.

> I propose the new field to be a list per the usual architecture
> syntax.

Fortunately, since it already is, there is no need for a new field.

> > > There is currently one package in the Debian archive (pixfrogger) that
> > > declares "Build-Indep-Architecture: i386" in its .dsc because, even
> > > though it builds an architecture-independent binary package, building it
> > > requires a package that's only available on 32-bit architectures.
> 
> Isn't this what dose3 is employed for?  I'd expect it to notice the
> build-deps are uninstallable on amd64, and move it to a (non-existant)
> i386/armhf/... arch:all buildd.

dose is used only to determine whether a source can be moved from
BD-Uninstallable to Needs-Build in the context of a given set of Sources
and Packages files.  The rest of this sounds a lot harder to do in the
context of wanna-build than it is to say; even if it were implemented,
it would no doubt require some way for maintainers to control it.

(This would all be a lot easier if wanna-build had adopted the model of
simply having a flag on each build that says whether it should build the
arch-indep parts in addition to the arch-dep parts, and dispensing with
the separate Architecture: all buildds.  Then maintainers wouldn't have
to worry so much about making arch-indep-only builds work, which were
fairly novel at the point when these buildds were introduced, and doing
this kind of thing wouldn't require setting up a separate buildd on each
architecture.)

> If manually specifying that is needed, pixfrogger is another case that
> should declare a list rather than a single arch: i386 is basically gone
> other than hardware emulation on amd64, armhf is a better supported 32-bit
> arch these days (at least counting porters and new gear).

I agree that pixfrogger should declare a list of architectures in
Build-Indep-Architecture, perhaps simply matching those declared in
fenix's Architecture field (since there's no suitable wildcard syntax
for "any 32-bit Linux architecture").

> My cursory reading of code that deals with the actual field disagrees, but
> that's moot as the code can't be applied to Debian without a rewrite.

As mentioned above, your reading is incorrect.  Of course a rewrite is
needed, but unless somebody demonstrates an actual incompatibility then
there's no need to pick a gratuitously different name.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Building architecture:all packages

[Steve Langasek]

On Sat, Nov 12, 2016 at 01:50:32PM +, Colin Watson wrote:
> > > There is currently one package in the Debian archive (pixfrogger) that
> > > declares "Build-Indep-Architecture: i386" in its .dsc because, even
> > > though it builds an architecture-independent binary package, building it
> > > requires a package that's only available on 32-bit architectures.

> > *That* is really helpful as it provides a generic solution for my
> > problem: The maintainer can provide an architecture hint for any
> > rebuilder. Is there a more formal specification around? I understand
> > the comment in the diff[0] the header may carry a list of
> > architectures, not just just a single one. That's the right thing.

> > [0] 
> > http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17338/lib/lp/soyuz/tests/test_build_set.py

> I don't know.  CCing William and Steve since maybe they do.

I don't have links to any more formal specification, sorry - I just used the
field as Adam and William told me it would work :)

-- 
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: PGP signature

Re: Building architecture:all packages

[Adam Borowski]

On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> Colin Watson wrote...
> > On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> > > That's a good theoretical argument. But in practice, I think the subset
> > > of architectures for which bar works correctly will always include
> > > amd64, and John D. Rebuilder will have access to such a box for sure.
> > 
> > We know this not to have been the case in the past.
> > https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of
> > palo (hppa), openhackware (powerpc), and openbios-sparc (sparc).

I see two problems in that code:
* it's Launchpad-specific
* it supports only a single build-indep architecture rather than a list

The latter has next to no practical effect, but I still feel it wrong to
knowingly write incomplete metadata when it'd be trivial to do it right.

As the code has to be rewritten for DAK/w-b/etc anyway, and the XS- prefix
can't be used because it's officially "unofficial", I propose the new field
to be a list per the usual architecture syntax.

> > (People often suggest cross-compiling for this, and that can certainly
> > be a good solution in some cases, but please bear in mind that in the
> > general case that still only reduces the problem to "can only build on
> > architectures where somebody's uploaded the necessary cross tools".)
> 
> That's a slightly different scenario since I'm just about to rebuild
> arch:all packages, so there's no need for cross tools.

Any arch:all package that ships some kind of BIOS/etc does require either
specific-native or cross tools.  Having qemu and co depend on ten or so
foreign arch packages, some from second-class archs, is not a good idea.

> > There is currently one package in the Debian archive (pixfrogger) that
> > declares "Build-Indep-Architecture: i386" in its .dsc because, even
> > though it builds an architecture-independent binary package, building it
> > requires a package that's only available on 32-bit architectures.

Isn't this what dose3 is employed for?  I'd expect it to notice the
build-deps are uninstallable on amd64, and move it to a (non-existant)
i386/armhf/... arch:all buildd.

If manually specifying that is needed, pixfrogger is another case that
should declare a list rather than a single arch: i386 is basically gone
other than hardware emulation on amd64, armhf is a better supported 32-bit
arch these days (at least counting porters and new gear).
 
> *That* is really helpful as it provides a generic solution for my
> problem: The maintainer can provide an architecture hint for any
> rebuilder. Is there a more formal specification around? I understand
> the comment in the diff[0] the header may carry a list of
> architectures, not just just a single one. That's the right thing.
> 
> [0] 
> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17338/lib/lp/soyuz/tests/test_build_set.py

My cursory reading of code that deals with the actual field disagrees, but
that's moot as the code can't be applied to Debian without a rewrite.

> > As I allude to in
> > https://lists.debian.org/debian-devel/2016/11/msg00457.html, I think the
> > best answer is for Debian's buildd infrastructure to follow through on
> > implementing Build-Indep-Architecture.
> 
> Seems reasonable. My intention is rather to make the life easier for
> folks downstream, like rebuilding and backports.

And derivatives, most of which build only a subset of architectures,
sometimes just one, like Rasbian (armhf only).

> As there's a workaround available now, I feel less reluctant to reveal
> the real packages: "foo" is 3270font, "bar" is fontforge |
> fontforge-nox. The bugreport for the latter is #831425.

With my 3270font maintainer hat on: I wouldn't even know of this if not for
the reproducible builds project, despite doing lots of rebuilds on various
architectures (albeit not really for this package).  I guess there's a lot
of other arch-dependant failures for arch:all packages.


-- 
A true bird-watcher waves his tail while doing so.

Re: Building architecture:all packages

[Colin Watson]

On Sat, Nov 12, 2016 at 09:56:01AM +0100, Christoph Biedl wrote:
> Colin Watson wrote...
> > On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> > > That's a good theoretical argument. But in practice, I think the subset
> > > of architectures for which bar works correctly will always include
> > > amd64, and John D. Rebuilder will have access to such a box for sure.
> > 
> > We know this not to have been the case in the past.
> > https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of
> > palo (hppa), openhackware (powerpc), and openbios-sparc (sparc).
> > (People often suggest cross-compiling for this, and that can certainly
> > be a good solution in some cases, but please bear in mind that in the
> > general case that still only reduces the problem to "can only build on
> > architectures where somebody's uploaded the necessary cross tools".)
> 
> That's a slightly different scenario since I'm just about to rebuild
> arch:all packages, so there's no need for cross tools.

Right, I was just pre-emptively addressing something people often
suggest.

> > There is currently one package in the Debian archive (pixfrogger) that
> > declares "Build-Indep-Architecture: i386" in its .dsc because, even
> > though it builds an architecture-independent binary package, building it
> > requires a package that's only available on 32-bit architectures.
> 
> *That* is really helpful as it provides a generic solution for my
> problem: The maintainer can provide an architecture hint for any
> rebuilder. Is there a more formal specification around? I understand
> the comment in the diff[0] the header may carry a list of
> architectures, not just just a single one. That's the right thing.
> 
> [0] 
> http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17338/lib/lp/soyuz/tests/test_build_set.py

I don't know.  CCing William and Steve since maybe they do.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Building architecture:all packages

[Christoph Biedl]

Colin Watson wrote...

> On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:

> > That's a good theoretical argument. But in practice, I think the subset
> > of architectures for which bar works correctly will always include
> > amd64, and John D. Rebuilder will have access to such a box for sure.
> 
> We know this not to have been the case in the past.
> https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of
> palo (hppa), openhackware (powerpc), and openbios-sparc (sparc).
> (People often suggest cross-compiling for this, and that can certainly
> be a good solution in some cases, but please bear in mind that in the
> general case that still only reduces the problem to "can only build on
> architectures where somebody's uploaded the necessary cross tools".)

That's a slightly different scenario since I'm just about to rebuild
arch:all packages, so there's no need for cross tools.

> There is currently one package in the Debian archive (pixfrogger) that
> declares "Build-Indep-Architecture: i386" in its .dsc because, even
> though it builds an architecture-independent binary package, building it
> requires a package that's only available on 32-bit architectures.

*That* is really helpful as it provides a generic solution for my
problem: The maintainer can provide an architecture hint for any
rebuilder. Is there a more formal specification around? I understand
the comment in the diff[0] the header may carry a list of
architectures, not just just a single one. That's the right thing.

[0] 
http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17338/lib/lp/soyuz/tests/test_build_set.py

(aside, codesearch revealed there is a second source package: Also
edk2 uses "XS-Build-Indep-Architecture". For amd64, though.)

> As I allude to in
> https://lists.debian.org/debian-devel/2016/11/msg00457.html, I think the
> best answer is for Debian's buildd infrastructure to follow through on
> implementing Build-Indep-Architecture.

Seems reasonable. My intention is rather to make the life easier for
folks downstream, like rebuilding and backports.

As there's a workaround available now, I feel less reluctant to reveal
the real packages: "foo" is 3270font, "bar" is fontforge |
fontforge-nox. The bugreport for the latter is #831425.

Christoph


signature.asc
Description: Digital signature

Re: Building architecture:all packages

[Colin Watson]

On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote:
> On Nov 11 2016, Christoph Biedl  wrote:
> > b) This is a serious issue as John D. Rebuilder should be free to choose
> >on which architecture to build "src:foo".
> >
> > Personally, I tend to b) since
> >
> > * there is no sane way for the maintainer to tell the world which
> >   architecture should be used to rebuild this package. The .buildinfo
> >   file will solve this, still
> > * it is certainly rather unfriendly to expect John to have a box for
> >   that particular architecture just to be able to do the rebuilding.
> 
> That's a good theoretical argument. But in practice, I think the subset
> of architectures for which bar works correctly will always include
> amd64, and John D. Rebuilder will have access to such a box for sure.

We know this not to have been the case in the past.
https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of
palo (hppa), openhackware (powerpc), and openbios-sparc (sparc).
(People often suggest cross-compiling for this, and that can certainly
be a good solution in some cases, but please bear in mind that in the
general case that still only reduces the problem to "can only build on
architectures where somebody's uploaded the necessary cross tools".)

There is currently one package in the Debian archive (pixfrogger) that
declares "Build-Indep-Architecture: i386" in its .dsc because, even
though it builds an architecture-independent binary package, building it
requires a package that's only available on 32-bit architectures.  See
https://bugs.debian.org/534063.  Conceivably this particular case could
be handled by Multi-Arch: foreign, but requiring (re)builders to have a
suitable multi-arch setup available raises the bar for them and would
certainly considerably complicate buildd infrastructure.

As I allude to in
https://lists.debian.org/debian-devel/2016/11/msg00457.html, I think the
best answer is for Debian's buildd infrastructure to follow through on
implementing Build-Indep-Architecture.  I'm not sure how this interacts
with Debian's decision to make Architecture: all buildds separate
entities, since that means it isn't just a matter of setting a "build
the arch-indep portion as well" flag when a particular buildd takes a
build; but it should still be doable somehow.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Building architecture:all packages

[Paul Wise]

On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:

> implies "src:foo" must build on *all* architectures

In general, Debian does not define the build architecture for any
package, no matter what the Architecture of the package is.

In practice, arch:all packages must build on either amd64 (arch:all
buildds run that), or an architecture developers are able to build the
package from.

In practice, arch:any packages must build on one of the Debian/ports
arches (for the arch:any buildds), or on an architecture developers
are able to cross-build the package from.

Generally, we much prefer to have builds happen on the buildds than on
developer machines though.

We currently do not have any cross-building buildds AFAIK, although
there is the rebootstrap stuff.

https://wiki.debian.org/HelmutGrohne/rebootstrap

Obviously, it would be great if we could build arch:all packages on
any arch, native build on any arch and cross-build from any arch to
any other arch, but the world isn't an ideal place and neither is
Debian.

IIRC there are mechanisms on the buildds to deal with arch:any builds
that don't work on some architectures.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Building architecture:all packages

[Paul Wise]

On Sat, Nov 12, 2016 at 6:32 AM, Christoph Biedl wrote:

> How would this affect your assessment of the situation?

The details matter, without them I don't think any assessment is useful.

> In my feeling, revealing the packages' names would give the story some kind of
> blaming. That's not my intention.

I don't think mentioning package names is blaming, but I understand
not everyone takes it that way. When mentioning the details you could
be more explicit that your intention is not to blame anyone.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Building architecture:all packages

[Christoph Biedl]

Paul Wise wrote...

> On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:
> 
> > Other suggestions?
> 
> Include information about which packages/issues you are talking about.

How would this affect your assesment of the situation?

In my feeling, revealing the pakages' names would give the story some kind of
blaming. That's not my intention.

Christoph


signature.asc
Description: Digital signature

Re: Building architecture:all packages

[Christoph Biedl]

Nikolaus Rath wrote...

> Just fix it in "bar", and don't bother worrying about the right
> severity?

If it was that simple ... The maintainers of "bar" haven't reacted to
the bug report for a few months although it contains a clear statement
the current state breaks the build of other packages. And in general I
include patches into my bug reports, but the "bar" package is rather
big, some 400 kLOC. I have a vague idea of what precisely is supposed
to happen. Also I already spent some time to find the change. The last
hours I've been playing with gcov to find differing code paths taken,
so far no avail. 

Still, I might get this sorted out. However, this incident raised a
second, more generic question: Is this an acceptable state? If John
wants to rebuild packages like "foo", he cannot simply use his
preferred architecture. The build may fail, then he has to start
trying other ones until success. I don't consider this a satisfying
situation. On the other hand I can understand Debian maintainers
wern't very happy to learn a bug in the toolchain of a doorstopper
architecture causes FTBFS there for one of their packages, which might
even result in a removal from testing.

So I was looking whether there is a consensus about this. If not, I
wouldn't mind if this ends in a guideline (seems a bit to much in
detail for Debian policy) about packages that solely build arch:all
binary packages. Like: They must be buildable at least on certain
architectures, I called them "mostly used architectures" in my first
mail. I would strongly suggest that list should not solely consist of
amd64.

Christoph


signature.asc
Description: Digital signature

Re: Building architecture:all packages

[Nikolaus Rath]

On Nov 11 2016, Christoph Biedl  wrote:
> b) This is a serious issue as John D. Rebuilder should be free to choose
>on which architecture to build "src:foo".
>
> Personally, I tend to b) since
>
> * there is no sane way for the maintainer to tell the world which
>   architecture should be used to rebuild this package. The .buildinfo
>   file will solve this, still
> * it is certainly rather unfriendly to expect John to have a box for
>   that particular architecture just to be able to do the rebuilding.

That's a good theoretical argument. But in practice, I think the subset
of architectures for which bar works correctly will always include
amd64, and John D. Rebuilder will have access to such a box for sure.

> In my opinion "src:foo" should see a "serious" bug report FTFBS,
> although it's just a victim of "bar". What about "bar"?
>
> Other suggestions?

Just fix it in "bar", and don't bother worrying about the right
severity?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Building architecture:all packages

[Paul Wise]

On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote:

> Other suggestions?

Include information about which packages/issues you are talking about.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise