[ Matthias, please always Cc me on the bugs I report if you talk to me
in your replies ]
[ Trimming Cc list to just gcc-14-cross for simplicity. Still Cc to
ADA people, I'd love to hear from them ].
building sequentially is nice to have, but not a must
What do you mean by "sequentially"? Whether the build happens
"sequentially" or not will depend on what you do in debian/rules.
For example, in gcc-8-cross version 27 you already did something
like this:
ifeq ($(JOBS),1)
JOBS := 2
endif
so that the build is never "sequential", and it allowed everybody
to build the package (unfortunately, I think the package was
removed from unstable before the fix became part of a stable release).
In either case, Debian Policy 4.2 says that packages *must*
build from source when build-dependencies are installed,
so yes, this is a must, not just a "nice thing to have".
We have seen calls to the TC for a lot less than this,
and we have seen NMUs from reproducible-builds people
to make packages reproducible, which is just a "should".
And as you write, your fix just papers over a dependency issue.
I'm not reporting that the package has makefile bugs in
a "general sense". There are hundreds of such bugs:
https://people.debian.org/~sanvila/make-shuffle/
but that's not the issue here.
I'm reporting that the package fails in a very specific way,
and the proposed patch makes such specific mode of failure not to
happen at all.
It was you who said "patches welcome" a long time ago
regarding this bug. Now I expect you to honor your word.
Please could you address this upstream,
if it's really important for you?
I could report this upstream, but there are several problems
with that:
A) This is a complex package and I don't really know if
you are using those makefiles to create cross compilers
in the way they were designed to be used. Only you know that.
B) Reporting a GCC bug upstream requires a minimal case.
I don't have a minimal case for this. It's the whole package
what's wrong. This is a Debian bug.
C) I report many FTBFS bugs, each of them has a different
upstream bug tracker. If I had to report them upstream,
I would have to open an account in each of those bug tracking
systems. This definitely does not scale.
D) I wonder how you would feel if anybody suggested that
you had to be the one to forward *any* of these bugs upstream:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org;tag=ftbfs-gcc-15
You can make the failure not to happen in several different ways.
Just choose the one which makes you more happy. I think it would be
acceptable if you implement the workaround in gcc-8-cross at the same
time you ask upstream for a better fix. I don't mind that the fix is not
the better fix, but I do mind if you deliberately choose to ignore a must
directive in Policy when there is a patch on the table.
Thanks.
