Bug#850887: Decide proper solution for binutils' mips* bug
Hi! Before stating the issue at hand I would like to address the fact that
this issue needs a quick solution as many packages are not able to
enter testing and we are near the freeze.
I would like the TC to address a solution for bug #844227. It's a binutils
bug that makes lots of packages FTBFS on mips*.
There are currently two proposed patches upstream, but upstream would like
to find a generic solution before considering accepting them, and encouraged
us to use either of them in the meantime [comment12].
I proposed a patch that exclusively works on mips* to leave aside possible
bugs for other archs, see [patch].
Yes, I happened to miss Matthias' request to not upload the patch due to a bad
spam filter, and I would like to use this opportunity to present once again
my apologies for that.
Problem is that we still have the bug affecting us.
binutils maintainer states in [m149]:
[..] I'm fine to apply work arounds for port architectures, but not
for release architectures (I didn't decide on this status). The binutils
plan was announced last June , and I plan to stick to it. At least one
the mips toolchain maintainers (out of the five who committed to in the
architecture qualification process) seems to address RC issues, and
the upstream issue, there's work in progress.
While I do totally agree with Matthias that an upstream-approved fix is indeed
the best possible way out of this, in the meantime we have been dealing with
this bug almost two months now, and it's hindering the effort of many other
package maintainers not being able to get their packages into testing on
time for the release.
I would also like to note that I could not fully test my proposed patch
I can build the package on a porterbox but not use it later to build other
stuff. Of course I'll be more than happy to do this if there is a way for me
to do it.
So my question is: how can we fix this issue? Should we ask binutils
to apply the patch (or let someone else do it), should we leave this matter
as it is or should we take any other further way of action?
Kinds regards, Lisandro.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing-
debug'), (500, 'buildd-unstable'), (500, 'testing'), (500, 'stable'), (1,
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)