[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#850887: marked as done (Decide proper solution for binutils' mips* bug)

Your message dated Wed, 19 Apr 2017 15:27:13 -0400
with message-id <tsl37d4jizy.fsf@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 owner@bugs.debian.org

850887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850887
Debian Bug Tracking System
Contact owner@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?

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 [1], 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 
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 
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)

--- 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

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
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

--- End Message ---

Reply to: