Re: Bug#519006: breaks dump builds, too
Matthias Klose writes: > On 09.06.2010 12:02, Arnaud Patard (Rtp) wrote: >> Matthias Klose writes: >> >> Hi, >> >>> On 08.06.2010 20:02, Bdale Garbee wrote: >>>> This prevents dump from building on mips/mipsel, which means the version >>>> of dump in testing is now months out of date. >>>> >>>> Is there an estimate for when this bug will be fixed? >>> >>> this is up to the debian-mips maintainers to answer. >>> >>> is there different behaviour when all objects involved in the link are >>> rebuilt with binutils from experimental? >> >> hmm... Why are you talking about binutils ? From what I remember, the >> patch fixing the issue is in gcc 4.5 > > reference? http://sourceware.org/bugzilla/show_bug.cgi?id=10144#c6 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519006#97 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519006#111 > >> and someone said it won't be easy to backport it. > > so what do you propose? > > - drop mips as a release architecture? > - do you volunteer to make gcc-4.5 ready for inclusion >in mips and fix any resulting RC-critical issue? I'm no gcc or binutils hacker. I've reported what I understood on the issue in order to help seeing it fixed. My mail was not intended to offense you at all. Unfortunately, it looks like it was not well perceived so I will stop replying to this bug. I'm not using Debian on my mips boxes after all... Arnaud -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aar2wvwf@lechat.rtp-net.org
Bug#680699: unblock: flash-kernel/3.1
Philipp Kern writes: > Hi, > > On Sun, Jul 08, 2012 at 03:16:41AM +0200, Hector Oron wrote: >> Please unblock package flash-kernel >> >> Hello, >> >> flash-kernel/3.1 adds device tree support for Dreamplug device (used by >> freedombox). >> >> Dreamplug support has been backported into linux/3.2.21-1, which we expect >> it to get into wheezy sometime. >> >> Therefore, it would be really nice if we can get flash-kernel/3.1 in >> wheezy. >> >> unblock flash-kernel/3.1 > > my only concern is that /proc/device-tree/model takes precedence over > /proc/cpuinfo in any case with no fallback to the latter. So if any ARM SoC > gets device-tree enabled by a backport it might potentially need a change to > flash-kernel, if the "Hardware" string does not match up with what the model > file delivers. no. With DT, the Hardware string doesn't change with the model but with the SoC. For instance, all kirkwood systems booting with DT have : Hardware: Marvell Kirkwood (Flattened Device Tree) [ defined in arch/arm/mach-kirkwood/board-dt.c ] Then, the model is found in /proc/device-tree/model and I don't think that things in /proc are changing a lot. Arnaud -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bojqiqv4@lebrac.rtp-net.org
Re: Bug#519006: mips/ld: non-dynamic relocations refer to dynamic symbol
Aurelien Jarno writes: > Hi all, Hi, > > I have made some progress on this bug, though it has not progress in the > expected direction. In other words I got some surprises. > > First of all it the bug has been introduced in binutils when introducing > the MIPS PLT support [1] (commits around 2008-08-08). I am still > convinced it is actually a binutils bug. Secondly, if the problem is > actually not present in gcc-snapshot in gcc 4.5 we have *in Debian*, it > is not due to the fix linked in the bugzilla entry. It is due to the > fact we default to -mplt on these compilers. It is possible to > workaround the bug on gcc 4.4 using -mplt (like it is possible to > workaround it by dropping the -g). To sum up, there's no fix upstream for the bug but the solution/workaround for now is -mplt, right ? > > Given all of that, the only forseen solution for this fix is to also > default to -mplt on gcc 4.4. It also brings speed improvements, as > well as some more "standard" binaries with regard to other > architectures. On the other hand, I understand it is something quite > risky so close to a release. If we go for this solution, we may want If the bug is "fixed" by this change and as a side effect, there are improvements, there's no reason to not include it. I don't think it can be worse than the current situation. Moreover (iirc) this bug is a release blocker for mips so seeing it closed would be really nice. > to trigger a rebuild of part of the archive as it is currently done > on sparc. There's a bunch of packages known to be bitten by this bug but there may be others we're not aware of. imho a rebuild is mandatory. This would also give us a good up-to-date status of the mips/mipsel ports for the release. My 2 cents, Arnaud -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aao1eu8r@lechat.rtp-net.org
Re: DSA concerns for jessie architectures
Martin Zobel-Helas writes: > [please consider replacing debian-ports@ldo with the appropriate port > specific list when replying.] > > Comrades! > > At our recent Essen sprint, DSA went through the release qualification > matrix (for wheezy, as there isn't one for jessie, yet) and defined a > set of requirements that we consider necessary for us to support a port > for the next stable release. > > We have limited these requirements to whether DSA can support a port > well or not, and we wanted to establish these requirements early in the > release cycle so that our concerns can be addressed. > > Our requirements for machines are not new; they are: > > * reliability - The stable release manager requires that we operate > three machines for each port: two buildd machines in different > locations and one porter machine. These machines must be reliable > (see mips for counterexample). > * out of band management - We require the ability to manage the machines > independently of their primary network interface: serial console or > better, remotely-controllable power. > * supportability - We require that the machines be commercialy available > (within financial constraints) and that they be supportable through a > warranty or post-warranty support or are otherwise easy to replace. > * stability - We require that the machine's architecture have an > actively-maintained stable kernel in the archive. > * environment - We require that packages critical for DSA operations be > available: puppet, samhain, syslog-ng, ferm/pf, etc. > > Historically, we have not been enforcing these requirements strictly > and this has caused / continues to cause us significant operational > challenges resulting in our inability to render the service levels that > should reasonably be expected of us. Therefore, we believe it is > important that all debian.org machines meet these requirements. > > Based on the list of requirements enumerated above, we currentlty are > concerned about the following architectures from the perspective of > using them as debian.org machines: > > * armel: no remote management (being worked on); no archive kernel for > the machines we use. afair buildd are: marvell DB-78x00 -> should be supported by armel kernel flavour mx78xx0 thecus n2100 -> should be supported by armel kernel flavour iop32x Please, can you explain what's exactily missing on kernel support side ? thanks, Arnaud -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo6yar46@lebrac.rtp-net.org
Re: DSA concerns for jessie architectures
Kurt Roeckx writes: > On Sat, Jun 22, 2013 at 09:21:29PM +0200, Arnaud Patard wrote: >> Martin Zobel-Helas writes: >> >> > * armel: no remote management (being worked on); no archive kernel for >> > the machines we use. >> >> >> afair buildd are: >> marvell DB-78x00 -> should be supported by armel kernel flavour mx78xx0 >> thecus n2100 -> should be supported by armel kernel flavour iop32x >> >> Please, can you explain what's exactily missing on kernel support >> side ? > > There is no mx78xx0 kernel in the Debian archive as far as I can > see. There is a linux-image-3.2.0-4-iop32x however. > Sorry, I made a typo. It's mv78xx0: http://packages.debian.org/wheezy/linux-image-3.2.0-4-mv78xx0 Arnaud -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877ghmaq0i@lebrac.rtp-net.org
