Bug#907829: p4est: FTBFS on single CPU machines

Santiago Vila sanvila at unex.es
Sun Sep 30 14:10:23 BST 2018


On Fri, 7 Sep 2018, Adrian Bunk wrote:

> On Fri, Sep 07, 2018 at 02:45:31PM +0200, Santiago Vila wrote:
> >...
> > And I put a very simple example: Imagine that all our amd64
> > autobuilders are Intel and there is a package which FTBFS on AMD.
> > 
> > Are you really trying to tell me that the FTBFS bug would not be
> > serious "because it does not happen on buildd.debian.org"?
> 
> That's pretty exactly how things are handled.

No, we would not do that, because it would mean users of Debian on
Intel would be better supported than users of Debian on AMD.

And that would be completely absurd, not to say ridiculous. Users of
Intel and AMD should be equally supported, because they are both users
of "Debian on amd64", a release architecture.

Similarly, users of amd64 on single-cpu and users of amd64 on
multi-core are both users of "Debian on amd64", a release architecture,
and therefore they should be equally supported.

We are the universal operating system and do *not* discriminate among
users of the different release architectures, much less among the
users of the *same* (release) architecture.

Your reply, however, clarifies what I think is the root cause of this
disagreement:

In my opinion, you are so much fixated on the idea that "does not fail
on the buildds" is the "same" as "the bug is not RC" that you would
end up applying such (wrong) rule when it makes absolutely no sense
to apply it (for example, the Intel/AMD case).

It is even more interesting that you decided not to reply to some key
questions I asked, so I'll try again:

Do you want to deprecate using Debian on single-core, or only building
Debian on single-core?

I say please show me the standard or official statement saying "Debian
on amd64 has to be multi-core", or "Debian on single-core is deprecated
or less supported" and you basically reply that "we don't need any
official statement, considering the number of affected users is
enough".

However, I see you have absolutely no problem applying standards in
cases like this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908384
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909817

In those bugs, the package blindly assumes CPU features that may or
may not be present on any Debian system of the same architecture.

In this bug (p4est), the package blindly assumes CPU features (being
multi-core) that may or may not be present on any Debian system of the
same architecture.

Why some of those bugs have to be serious and this one only important
is still an unexplained mystery, but to me it seems a clear case of
double-standards.

If we were to consider the "number of people affected", there are
probably more users of amd64 on single-core (remember that we have to
count everybody who uses Debian on virtual machines) than users of
i386 on very old CPUs.

AFAIK you are not a release manager. What authority do you have to
decide that this bug is not RC, or not serious?

I don't mind you moving severities up and down based on "common
sense", and in fact I really appreciate all the tidy up work you do
with FTBFS bugs.

But there does not seem to be a "common sense" here. Instead, we have
a case of double-standards. Can I move the priorities of bugs reported
by you up and down based on my own criteria as well?

Thanks.



More information about the debian-science-maintainers mailing list