Processing control commands:
> severity -1 normal
Bug #932287 [src:glib2.0] glib2.0: FTBFS on mips64el: linking 32-bit code with
64-bit code
Severity set to 'normal' from 'serious'
--
932287: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932287
Debian Bug Tracking System
Contact ow...@bugs.
Control: severity -1 normal
On Thu, 18 Jul 2019 at 16:04:36 +0800, YunQiang Su wrote:
> Simon McVittie 于2019年7月18日周四 上午2:03写道:
> > Looks like plain objcopy produces MIPS-I objects, whereas invoking it
> > in the normal way via the compiler frontend produces MIPS64r2 objects:
> >
> > (sid_mips64el
Simon McVittie 于2019年7月18日周四 上午2:03写道:
>
> On Wed, 17 Jul 2019 at 12:18:14 +0100, Simon McVittie wrote:
> > It looks like the culprit might be commit
> > d04b9c371d277fa45ba20ad83642e57af50381e7:
> > https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7
> > Is that o
On Wed, 17 Jul 2019 at 12:18:14 +0100, Simon McVittie wrote:
> It looks like the culprit might be commit
> d04b9c371d277fa45ba20ad83642e57af50381e7:
> https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7
> Is that objcopy invocation wrong for mips64el? Does mips64el
Source: glib2.0
Version: 2.59.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-m...@lists.debian.org
Something involving GResource appears to have regressed between 2.58.x in
buster/bullseye and the more current G
5 matches
Mail list logo