Debian Bug report logs - #674156
glib2.0: GStaticMutex ABI change on armel, armhf, mipsel, powerpc, s390, sparc and probably mips

Package: glib2.0; Maintainer for glib2.0 is Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>;

Reported by: Sebastian Reichel <sre@debian.org>

Date: Wed, 23 May 2012 13:06:02 UTC

Severity: serious

Done: Julien Cristau <jcristau@debian.org>

Bug is archived. No further changes may be made.

Forwarded to https://bugzilla.gnome.org/show_bug.cgi?id=688406

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, sre@debian.org, Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>:
Bug#674156; Package gstreamer0.10-plugins-good. (Wed, 23 May 2012 13:06:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sebastian Reichel <sre@debian.org>:
New Bug report received and forwarded. Copy sent to sre@debian.org, Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>. (Wed, 23 May 2012 13:06:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Sebastian Reichel <sre@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: gstreamer0.10-plugins-good: rtpmp2tpay not working on some architectures
Date: Wed, 23 May 2012 15:04:08 +0200
Package: gstreamer0.10-plugins-good
Version: 0.10.31-2
Severity: important

Hi,

Currently ther are detection problems of gstreamer0.10-plugins-good's
rtpmp2tpay (which is provided by libgstrtp.so according to
gst-inspect-0.10) on most architectures. This breaks the build of
gnome-dvb-daemon:

https://buildd.debian.org/status/package.php?p=gnome-dvb-daemon

-- Sebastian




Added indication that bug 674156 blocks 683012,683013 Request was from Sebastian Reichel <sre@ring0.de> to control@bugs.debian.org. (Fri, 27 Jul 2012 22:36:05 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'important' Request was from Adam D. Barratt <adam@adam-barratt.org.uk> to control@bugs.debian.org. (Sun, 14 Oct 2012 12:09:12 GMT) Full text and rfc822 format available.

Added indication that 674156 affects gstreamer0.10-plugins-base Request was from Koichi Akabe <vbkaisetsu@gmail.com> to control@bugs.debian.org. (Fri, 19 Oct 2012 13:06:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>:
Bug#674156; Package gstreamer0.10-plugins-good. (Fri, 19 Oct 2012 13:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Koichi Akabe <vbkaisetsu@gmail.com>:
Extra info received and forwarded to list. Copy sent to Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>. (Fri, 19 Oct 2012 13:33:05 GMT) Full text and rfc822 format available.

Message #16 received at 674156@bugs.debian.org (full text, mbox):

From: Koichi Akabe <vbkaisetsu@gmail.com>
To: 674156@bugs.debian.org
Subject: alignment issue
Date: Fri, 19 Oct 2012 22:32:46 +0900
According to the build log on armel:

> 0%: Checks: 1, Failures: 1, Errors: 0
> elements/rtpbin_buffer_list.c:198:F:general:test_bufferlist:0: '*(guint64 *) data' (939538581729009792) is not equal to '*(guint64 *) rtp_header[index]' (16815518223612020252)
>

It casts from *guint8 to *guint64. armel doesn't return expected result
if the first address is not suited for guint64. In this case, the data
is shifted 2 bytes.

939538581729009792   = 0x0D09E95CB8BB6080
16815518223612020252 =     0xE95CB8BB6080861C

> 
> (gst-plugin-scanner:961): GLib-GObject-WARNING **: specified instance
> size for type `GstRtpAC3Depay' is smaller than the parent type's
> `GstBaseRTPDepayload' instance size
> 
> (gst-plugin-scanner:961): GLib-CRITICAL **: g_once_init_leave:
> assertion `result != 0' failed
> 
> (gst-plugin-scanner:961): GStreamer-CRITICAL **: gst_element_register:
> assertion `g_type_is_a (type, GST_TYPE_ELEMENT)' failed W: Could not
> load
> 'debian/gstreamer0.10-plugins-good/usr/lib/arm-linux-gnueabi/gstreamer-0.10/libgstrtp.so':
> File
> "debian/gstreamer0.10-plugins-good/usr/lib/arm-linux-gnueabi/gstreamer-0.10/libgstrtp.so"
> appears to be a GStreamer plugin, but it failed to initialize
> 

I tried getting the size of these structures using sizeof(). Both
structures are 320 bytes, but
gst-plugins-base-0.10.36/tests/check/libs/struct_arm.h says 328 bytes.

I think it also alignment issue.

-- 
Koichi Akabe
  vbkaisetsu at {gmail.com, debian.or.jp}



Information forwarded to debian-bugs-dist@lists.debian.org, Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>:
Bug#674156; Package gstreamer0.10-plugins-good. (Tue, 06 Nov 2012 08:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sjoerd Simons <sjoerd@luon.net>:
Extra info received and forwarded to list. Copy sent to Maintainers of GStreamer packages <pkg-gstreamer-maintainers@lists.alioth.debian.org>. (Tue, 06 Nov 2012 08:45:04 GMT) Full text and rfc822 format available.

Message #21 received at 674156@bugs.debian.org (full text, mbox):

From: Sjoerd Simons <sjoerd@luon.net>
To: Koichi Akabe <vbkaisetsu@gmail.com>, 674156@bugs.debian.org
Subject: Re: Bug#674156: alignment issue
Date: Tue, 6 Nov 2012 09:42:48 +0100
reassign 674156 glib-2.0
thanks,

On Fri, Oct 19, 2012 at 10:32:46PM +0900, Koichi Akabe wrote:
> > (gst-plugin-scanner:961): GLib-GObject-WARNING **: specified instance
> > size for type `GstRtpAC3Depay' is smaller than the parent type's
> > `GstBaseRTPDepayload' instance size

Digging through this it turned out that GStaticMutex changed size since
squeeze... When running the following test program:

#include <stdio.h>
#include <glib.h>

#define SIZE(x) printf (#x ": %"G_GSIZE_FORMAT"\n", sizeof (x))

int
main (int argc, char **argv)
{
  SIZE (GMutex *);
  SIZE (double);
  SIZE (pthread_mutex_t);
  SIZE (GStaticMutex);
  SIZE (GStaticRecMutex);

  SIZE (struct { GMutex *a;  union { char pad[24] ; char d; }; });
  return 0;
}

On squeeze (armel):

GMutex *: 4
double: 8
pthread_mutex_t: 24
GStaticMutex: 32
GStaticRecMutex: 48
struct { GMutex *a; union { char pad[24] ; double d; }; }: 32

On wheezy (armel):

GMutex *: 4
double: 8
pthread_mutex_t: 24
GStaticMutex: 28
GStaticRecMutex: 40
struct { GMutex *a; union { char pad[24] ; double d; }; }: 32


Digging futher and futher on squeese GStaticMutex was defined as:

struct _GStaticMutex
{
  struct _GMutex *runtime_mutex;
  union {
    char   pad[24];
    double dummy_double;
    void  *dummy_pointer;
    long   dummy_long;
  } static_mutex;
};

While on wheezy:

typedef struct
{
    GMutex *mutex;
#ifndef G_OS_WIN32
      /* only for ABI compatibility reasons */
        pthread_mutex_t unused;
#endif
} GStaticMutex;

Even though both pthread_mutex_t and the earlier union are 24 bytes themselves,
because of the double in the union it gets aligned to a multiple of 8 on ARM,
causing 4 bytes of extra padding to be added. Which in turns makes the old
GStaticMutex struct 4 bytes bigger then the current one...

This obviously breaks ABI on these platforms, not only of glib but also of
libraries which have a GStaticMutex embedded in their public structs in some
way.

I'm not sure what to do at this point... One option would be to patch
glib-2.0 so it's at least ABI compatible again with squeeze again, but it's
unlikely other distributions would follow (so we would be incompatible with
others). On the other hand this might not matter so much for arm.

Whatever we do, we do need to ensure that all affected software gets compiled
against whatever final solution we pick.

-- 
The light of a hundred stars does not equal the light of the moon.



Bug reassigned from package 'gstreamer0.10-plugins-good' to 'glib-2.0'. Request was from Sjoerd Simons <sjoerd@debian.org> to control@bugs.debian.org. (Tue, 06 Nov 2012 08:54:03 GMT) Full text and rfc822 format available.

No longer marked as found in versions gst-plugins-good0.10/0.10.31-2. Request was from Sjoerd Simons <sjoerd@debian.org> to control@bugs.debian.org. (Tue, 06 Nov 2012 08:54:04 GMT) Full text and rfc822 format available.

Bug reassigned from package 'glib-2.0' to 'glib2.0'. Request was from Sjoerd Simons <sjoerd@debian.org> to control@bugs.debian.org. (Fri, 09 Nov 2012 22:36:07 GMT) Full text and rfc822 format available.

Changed Bug title to 'glib2.0: GStaticMutex ABI change on armel (maybe other archs)' from 'gstreamer0.10-plugins-good: rtpmp2tpay not working on some architectures' Request was from Michael Gilbert <michael.s.gilbert@gmail.com> to control@bugs.debian.org. (Tue, 13 Nov 2012 01:27:03 GMT) Full text and rfc822 format available.

Set Bug forwarded-to-address to 'https://bugzilla.gnome.org/show_bug.cgi?id=688406'. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Thu, 15 Nov 2012 16:18:08 GMT) Full text and rfc822 format available.

Changed Bug title to 'glib2.0: GStaticMutex ABI change on armel, armhf, mipsel, powerpc, s390, sparc and probably mips' from 'glib2.0: GStaticMutex ABI change on armel (maybe other archs)' Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Mon, 19 Nov 2012 14:27:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>:
Bug#674156; Package glib2.0. (Mon, 19 Nov 2012 14:57:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>. (Mon, 19 Nov 2012 14:57:08 GMT) Full text and rfc822 format available.

Message #38 received at 674156@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Sjoerd Simons <sjoerd@luon.net>, 674156@bugs.debian.org
Subject: Re: Bug#674156: alignment issue
Date: Mon, 19 Nov 2012 14:55:35 +0000
On Tue, 06 Nov 2012 at 09:42:48 +0100, Sjoerd Simons wrote:
> This obviously breaks ABI on these platforms, not only of glib but also of
> libraries which have a GStaticMutex embedded in their public structs in some
> way.

I sent this upstream, GNOME #688406. The new ABI has already been in two
upstream stable branches, so reverting it would be just as painful from
their point of view (and, I suspect, ours - testing is in an inconsistent
state where some things have been recompiled, but not everything).

In general, 32-bit RISC architectures are affected. i386 is unaffected
because its ABI only aligns doubles on 32-bit boundaries, and
64-bit architectures are unaffected because the pointer at the beginning
of GStaticMutex aligns the next struct member at a 64-bit boundary without
needing padding.

Confirmed affected: armel, armhf, mipsel, powerpc, s390, sparc
(see https://bugzilla.gnome.org/show_bug.cgi?id=688406 for a standalone test)

Suspected to be affected, but I couldn't log into a porterbox: armeb, mips,
powerpcspe (of which mips is the only release architecture)

Confirmed unaffected: amd64, i386, ia64, sh4, s390x

Suspected to be unaffected, but I couldn't log into a porterbox: alpha,
ppc64, sparc64 (all 64-bit, none are release architectures?)

Untested: kfreebsd-i386, kfreebsd-amd64, hurd-i386 (assumed to have the same
struct member alignment requirements as Linux, in which case all are
unaffected)

No idea: hppa, m68k (not release architectures anyway)

One mitigating factor is that since GLib 2.32, only the first sizeof(void *)
bytes of a GStaticMutex are actually used - so in global static mutexes, the
most common use, it doesn't actually matter. The problem cases are structs
that contain a GStaticMutex, and either are a GObject, or have members after
the GStaticMutex.

In GLib, GStaticRWLock and GStaticRecMutex are also affected (they contain
a GStaticMutex). I haven't done the trawl through codesearch.debian.net to
find out whether they're in anything else's public headers.

> Whatever we do, we do need to ensure that all affected software gets compiled
> against whatever final solution we pick.

My vote would be to use codesearch.debian.net to find all affected software,
and binNMU it on all release architectures, plus all affected unofficial
architectures that have the infrastucture for binNMUs.

The slower official architectures need the binNMU anyway, because they're
precisely the 32-bit non-x86 architectures that are affected. If we binNMU
on the unaffected official architectures - any-i386, any-amd64 and ia64 - as
well, it shouldn't take any longer (they're "fast" architectures), and keeping
the binNMU version in sync between architectures will make more multiarch
packages co-installable.

    S



Added blocking bug(s) of 674156: 697026 Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Sun, 30 Dec 2012 23:18:05 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 674156: 697025 Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Sun, 30 Dec 2012 23:18:06 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 674156: 694525 Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Sun, 30 Dec 2012 23:18:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>:
Bug#674156; Package glib2.0. (Wed, 09 Jan 2013 21:30:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>. (Wed, 09 Jan 2013 21:30:16 GMT) Full text and rfc822 format available.

Message #49 received at 674156@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: 697025@bugs.debian.org
Cc: 674156@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#697025: gstreamer0.10: please re-upload built against GLib 2.32
Date: Wed, 09 Jan 2013 21:29:11 +0000
On 01/01/13 13:26, Julien Cristau wrote:
> On Sun, Dec 30, 2012 at 23:28:13 +0000, Simon McVittie wrote:
>> I've only tested this fairly trivially (totem still plays
>> videos); I'll do some more testing before uploading if it becomes
>> necessary, but it'd be better if a maintainer could do proper
>> testing and a MU.

Any maintainer opinions on this?

> This seems to be missing a way to ensure plugins get a dependency
> on the rebuilt libgstreamer0.10-0 (or whatever else is needed to
> prevent the combination of a gstreamer and plugin that disagree on
> the size of structs)?

As far as I can work out, bumping libgstreamer0.10-0's shlibs would only
help to achieve this if we additionally NMU a bunch of packages to
rebuild them against the new libgstreamer0.10-0 so they get a
dependency. Some of them are multiarch and would thus need a sourceful
upload (gst-plugins-*0.10, *farstream*, etc.) so that doesn't seem
ideal; most of the affected packages have the new ABI already.

One alternative would be for libgstreamer0.10-0 to have versioned Breaks
on those packages, which would reduce the number of uploads considerably.

Another alternative would be to add Breaks to libglib2.0-0 and rely on
the fact that a newly-built libgstreamer0.10-0 already picks up
Depends: libglib2.0-0 (>> squeeze's), and so squeeze-to-wheezy partial
upgrades that pull in the new libgstreamer0.10-0 also pull in the new
libglib2.0-0, which forces the other affected packages to be upgraded
or removed.

The broken situation is in this dependency chain:

libglib2.0-0 <- libgstreamer0.10-0 <- third-package

with this embedding:

    struct ThirdPackageThing {
        ...
        struct GstThing {
            ...
            struct GStaticMutex;
            ...
        }
        ...
    }

Let's call anything that encodes the old (glib2.0 << 2.32) size of
GStaticMutex "old", and anything that encodes the new (glib2.0 >= 2.32)
size of GStaticMutex "new".

The binaries in libgstreamer0.10-0 are either "old" or "new" depending
on their interpretation of their own headers. That interpretation
depends on the version of libglib2.0-dev, "old" or "new", that was
installed when they were compiled.

The binaries in third-package are either "old" or "new", depending on
their interpretation of GStreamer's headers. That interpretation depends
only on the version of libglib2.0-dev that was installed at the time
they were compiled; it does not depend on the version of
libgstreamer0.10-dev that was installed at the time they were compiled.
This is because, in the usual C way, the Gst headers don't explicitly
say what the size of GstThing is: they only define it in terms of the
size of GStaticMutex, and the compiler does the arithmetic anew while
building each translation unit.

(This is how we can have third-level packages appearing in the "new"
set, even though no "new" version of gstreamer0.10 exists yet.)

The broken situation is that at runtime, you have a "new" libglib2.0-0,
an "old" libgstreamer0.10-0, and a "new" third-package.

AFAICS, a big pile of versioned Breaks from libglib2.0-0 to packages
that are known to be affected and built with "old" GLib would resolve
this. I'm somewhat concerned that that many versioned Breaks are going
to make the apt resolver work harder, and might themselves break the
full-upgrade process (like #676485).

I believe that can be mitigated by making the versioned Breaks specific
to the affected architectures, which would result in no additional
upgrade problems for users of unaffected architectures - but in practice
I don't think anyone ever runs piuparts on the affected architectures,
making it harder for any upgrade problems to be discovered.

Regards,
    S



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>:
Bug#674156; Package glib2.0. (Wed, 09 Jan 2013 21:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>. (Wed, 09 Jan 2013 21:39:09 GMT) Full text and rfc822 format available.

Message #54 received at 674156@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>
Cc: 697025@bugs.debian.org, 674156@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#697025: gstreamer0.10: please re-upload built against GLib 2.32
Date: Wed, 9 Jan 2013 22:38:18 +0100
[Message part 1 (text/plain, inline)]
On Wed, Jan  9, 2013 at 21:29:11 +0000, Simon McVittie wrote:

> The broken situation is that at runtime, you have a "new" libglib2.0-0,
> an "old" libgstreamer0.10-0, and a "new" third-package.
> 
That situation can be prevented by making sure every "new" third-package
has versioned depends on "new" libgstreamer0.10-0, which is why I asked
for the shlibs bump.  And yes, this does mean rebuilding those
third-packages after the shlibs bump, but I think that's better than
adding more Breaks than necessary.

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>:
Bug#674156; Package glib2.0. (Wed, 09 Jan 2013 21:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>. (Wed, 09 Jan 2013 21:57:03 GMT) Full text and rfc822 format available.

Message #59 received at 674156@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Simon McVittie <smcv@debian.org>
Cc: 697025@bugs.debian.org, 674156@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#697025: gstreamer0.10: please re-upload built against GLib 2.32
Date: Wed, 09 Jan 2013 22:54:27 +0100
[Message part 1 (text/plain, inline)]
On 09.01.2013 22:29, Simon McVittie wrote:
> On 01/01/13 13:26, Julien Cristau wrote:
>> On Sun, Dec 30, 2012 at 23:28:13 +0000, Simon McVittie wrote:
>>> I've only tested this fairly trivially (totem still plays
>>> videos); I'll do some more testing before uploading if it becomes
>>> necessary, but it'd be better if a maintainer could do proper
>>> testing and a MU.
> 
> Any maintainer opinions on this?
> 
>> This seems to be missing a way to ensure plugins get a dependency
>> on the rebuilt libgstreamer0.10-0 (or whatever else is needed to
>> prevent the combination of a gstreamer and plugin that disagree on
>> the size of structs)?
> 
> As far as I can work out, bumping libgstreamer0.10-0's shlibs would only
> help to achieve this if we additionally NMU a bunch of packages to
> rebuild them against the new libgstreamer0.10-0 so they get a
> dependency. Some of them are multiarch and would thus need a sourceful
> upload (gst-plugins-*0.10, *farstream*, etc.) so that doesn't seem
> ideal; most of the affected packages have the new ABI already.

How many would need a sourceful upload?

> One alternative would be for libgstreamer0.10-0 to have versioned Breaks
> on those packages, which would reduce the number of uploads considerably.
> 
> Another alternative would be to add Breaks to libglib2.0-0 and rely on
> the fact that a newly-built libgstreamer0.10-0 already picks up
> Depends: libglib2.0-0 (>> squeeze's), and so squeeze-to-wheezy partial
> upgrades that pull in the new libgstreamer0.10-0 also pull in the new
> libglib2.0-0, which forces the other affected packages to be upgraded
> or removed.

I've just dropped a bunch of Breaks from libglib2.0-0 since that broke
the dist-upgrade of a default GNOME installation. [1]

I'm worried that adding new Breaks to libglib2.0-0 might bring back
those problems.

Michael


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676485
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>:
Bug#674156; Package glib2.0. (Fri, 11 Jan 2013 18:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>. (Fri, 11 Jan 2013 18:42:02 GMT) Full text and rfc822 format available.

Message #64 received at 674156@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Michael Biebl <biebl@debian.org>
Cc: 697025@bugs.debian.org, 674156@bugs.debian.org, debian-release@lists.debian.org
Subject: Re: Bug#697025: gstreamer0.10: please re-upload built against GLib 2.32
Date: Fri, 11 Jan 2013 18:39:24 +0000
On 09/01/13 21:54, Michael Biebl wrote:
> On 09.01.2013 22:29, Simon McVittie wrote:
>> As far as I can work out, bumping libgstreamer0.10-0's shlibs
>> would only help to achieve this if we additionally NMU a bunch of
>> packages to rebuild them against the new libgstreamer0.10-0 so
>> they get a dependency.
> 
> How many would need a sourceful upload?

See <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694525#59>.
tl;dr: up to 22 sourceful and 38 binNMU, although not all of those
depend on GStreamer (some depend directly on GLib).

Having said that, if Julien's reasoning from
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674156#54> is valid
for Gst, then it's presumably valid for GLib as well? If so, then the
thing to do would be to bump GLib's shlibs instead of adding the
Breaks, and sourceful-upload or binNMU those 60 packages (as appropriate).

> I'm worried that adding new Breaks to libglib2.0-0 might bring
> back those problems.

Yeah, I was getting worried about that too.

The way I see this is that there are some sets of packages in wheezy
that are already in a broken situation. By making a sourceful upload
of gstreamer0.10, together with the sourceful upload of swami that has
already happened and a pile of 14 binNMUs (see 694525#59), we can get
full upgrades into a consistent state. I agree that "full upgrades
work" is less desirable than "every partial upgrade allowed by apt
works" - but it's also better than the situation we're in right now!
In particular, I believe that after those uploads, gnome-dvb-daemon,
the package that started all this, would be able to build on the
affected architectures again.

I've spent some time trying to gather and provide useful information,
but I do not maintain the packages in question, and I am unlikely to
be able to do 22 sourceful uploads of unfamiliar packages any time
soon. Better plans gratefully received. If you (for broad plural
values of "you") would like me to leave this discussion and let the
maintainers of the affected packages sort it out among themselves,
please say.

    S



Information forwarded to debian-bugs-dist@lists.debian.org, Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>:
Bug#674156; Package glib2.0. (Mon, 28 Jan 2013 09:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian GNOME Maintainers <pkg-gnome-maintainers@lists.alioth.debian.org>. (Mon, 28 Jan 2013 09:42:03 GMT) Full text and rfc822 format available.

Message #69 received at 674156@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: 674156@bugs.debian.org
Cc: Sebastian Reichel <sre@debian.org>
Subject: Re: Bug#674156: glib2.0: GStaticMutex ABI change on armel, armhf, mipsel, powerpc, s390, sparc and probably mips
Date: Mon, 28 Jan 2013 09:38:47 +0000
On Fri, 11 Jan 2013 at 18:39:24 +0000, Simon McVittie wrote:
> By making a sourceful upload
> of gstreamer0.10, together with the sourceful upload of swami that has
> already happened and a pile of 14 binNMUs (see 694525#59), we can get
> full upgrades into a consistent state.

Julien has NMU'd gstreamer0.10 and scheduled some binNMUs, and swami has
migrated, so all we're waiting for to achieve this is for gstreamer0.10
to migrate. (This can be tracked by waiting for #697025, which is also RC,
to migrate.)

So, assuming no serious problems with the NMU, it's only a matter of time
before full upgrades are OK.

Regarding the original bug, gnome-dvb-daemon was recently built on the
affected architectures; it is now built on all Linux architectures.
So, from that point of view, job done.

As for partial upgrades: Julien's NMU of gstreamer0.10 bumped the shlibs,
so if dependent packages are rebuilt (up to 22 source NMUs of Multi-arch: same
packages, and up to 38 binNMUs of other packages,
see http://bugs.debian.org/694525#59), certain broken combinations
(namely: new dependent package, old gstreamer0.10) will be prevented.
There hasn't been any systematic upload of these; it's an open question
whether it's worthwhile to do all of these, or just the binNMUs, or neither.

The other broken combination (new gstreamer0.10, old dependent package)
can only be addressed via Breaks relations. I think Julien's conclusion
was that this has an unacceptable risk of introducing weird upgrade bugs
where apt fails to find a solution, similar to
<http://bugs.debian.org/676485>?

Regards,
    S



Reply sent to Julien Cristau <jcristau@debian.org>:
You have taken responsibility. (Thu, 28 Feb 2013 20:21:03 GMT) Full text and rfc822 format available.

Notification sent to Sebastian Reichel <sre@debian.org>:
Bug acknowledged by developer. (Thu, 28 Feb 2013 20:21:03 GMT) Full text and rfc822 format available.

Message #74 received at 674156-done@bugs.debian.org (full text, mbox):

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 674156-done@bugs.debian.org
Cc: Sebastian Reichel <sre@debian.org>
Subject: Re: Bug#674156: glib2.0: GStaticMutex ABI change on armel, armhf, mipsel, powerpc, s390, sparc and probably mips
Date: Thu, 28 Feb 2013 21:16:36 +0100
[Message part 1 (text/plain, inline)]
On Mon, Jan 28, 2013 at 09:38:47 +0000, Simon McVittie wrote:

> On Fri, 11 Jan 2013 at 18:39:24 +0000, Simon McVittie wrote:
> > By making a sourceful upload
> > of gstreamer0.10, together with the sourceful upload of swami that has
> > already happened and a pile of 14 binNMUs (see 694525#59), we can get
> > full upgrades into a consistent state.
> 
> Julien has NMU'd gstreamer0.10 and scheduled some binNMUs, and swami has
> migrated, so all we're waiting for to achieve this is for gstreamer0.10
> to migrate. (This can be tracked by waiting for #697025, which is also RC,
> to migrate.)
> 
> So, assuming no serious problems with the NMU, it's only a matter of time
> before full upgrades are OK.
> 
> Regarding the original bug, gnome-dvb-daemon was recently built on the
> affected architectures; it is now built on all Linux architectures.
> So, from that point of view, job done.
> 
> As for partial upgrades: Julien's NMU of gstreamer0.10 bumped the shlibs,
> so if dependent packages are rebuilt (up to 22 source NMUs of Multi-arch: same
> packages, and up to 38 binNMUs of other packages,
> see http://bugs.debian.org/694525#59), certain broken combinations
> (namely: new dependent package, old gstreamer0.10) will be prevented.
> There hasn't been any systematic upload of these; it's an open question
> whether it's worthwhile to do all of these, or just the binNMUs, or neither.
> 
> The other broken combination (new gstreamer0.10, old dependent package)
> can only be addressed via Breaks relations. I think Julien's conclusion
> was that this has an unacceptable risk of introducing weird upgrade bugs
> where apt fails to find a solution, similar to
> <http://bugs.debian.org/676485>?
> 
Right.  I think we can close the bug against glib now, as the ABI change
is not going to be reverted and we've (hopefully) done what we could to
minimize the damage it causes.

Cheers,
Julien
[signature.asc (application/pgp-signature, inline)]

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 29 Mar 2013 07:28:55 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 04:26:36 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.