Your message dated Wed, 19 Apr 2017 15:27:13 -0400
with message-id <tsl37d4jizy....@suchdamage.org>
and subject line MIPS binutils for stretch
has caused the Debian Bug report #850887,
regarding Decide proper solution for binutils' mips* bug
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
850887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850887
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
Severity: normal
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].
[comment12] <https://sourceware.org/bugzilla/show_bug.cgi?id=20828#c12>
I proposed a patch that exclusively works on mips* to leave aside possible
bugs for other archs, see [patch].
[patch] <https://bugs.debian.org/cgi-bin/bugreport.cgi?
att=1;bug=844227;filename=844227_workaround_v2.patch;msg=144>
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
update
plan was announced last June [1], and I plan to stick to it. At least one
of
the mips toolchain maintainers (out of the five who committed to in the
architecture qualification process) seems to address RC issues, and
according to
the upstream issue, there's work in progress.
[m149] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844227#149>
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
because
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
maintainer
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,
'experimental-debug')
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)
--- End Message ---
--- Begin Message ---
The committee would like to thank everyone who was involved in this
discussion for helping us get to a mips binutils that is working for
stretch.
It sounded like Matthias wanted to add some extra thoughts going
forward. In closing the bug we're not closing off any future discussion
simply noting that this is no longer an issue before the committee.
As an individual, I note that this is the second significant issue
brought before the TC in the stretch time frame with regard to the
toolchain.
Communication was somewhat challenging on both issues.
The project as a whole might want to consider how we can better balance
these issues and get folks working on the toolchain the resources they
need both to produce an effective toolchain and to communicate with the
rest of the project.
The committee is of course available for a resource if useful in such a
discussion.
--- End Message ---
