Debian Bug report logs - #694525
nmu: 14 packages, for GStaticMutex

Package: release.debian.org; Maintainer for release.debian.org is Debian Release Team <debian-release@lists.debian.org>;

Reported by: Simon McVittie <smcv@debian.org>

Date: Tue, 27 Nov 2012 09:09:02 UTC

Severity: normal

Done: Julien Cristau <jcristau@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

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


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Tue, 27 Nov 2012 09:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Tue, 27 Nov 2012 09:09:05 GMT) Full text and rfc822 format available.

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

From: Simon McVittie <smcv@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: nmu: 227 source packages, for GStaticMutex
Date: Tue, 27 Nov 2012 09:05:49 +0000
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: binnmu

The upgrade from GLib 2.30 to 2.32 breaks ABI on most non-x86 32-bit
architectures (#674156). Specifically, the deprecated struct GStaticMutex,
and the deprecated structs GStaticRecMutex and GStaticRWLock (each of which
contains a GStaticMutex), change in size on each architecture where the
alignment of a double is greater than the size of a pointer: for us, that's
armel, armhf, mips, mipsel, powerpc, s390 and sparc, plus probably some -ports
architectures.

Mitigations:

* it's in a deprecated struct
* the part of GStaticMutex after the initial pointer is no longer used for
  anything, so it only really matters when a larger struct contains a
  GStaticMutex followed by other members

Upstream consensus appears to be that since their stable branches 2.32 and
2.34 have the "new" ABI, we are way past the point where reverting it or
bumping the SONAME would be useful, so we should just consider the new ABI
to be the canonical one. I'm inclined to agree: any package in Debian that
gets regular uploads will have been built against the new GLib by now,
so we'd have to rebuild even more packages to go back.

Here is a lengthy list of binNMUs. I would like these to be done on all
architectures: our slower architectures are the ones that really need the
rebuild anyway, and if we also rebuild on the fast architectures, then those
packages from this list that are multiarch remain co-installable.

nmu \
    4store_1.1.4-2 \
    aisleriot_1:3.4.1-1 \
    alarm-clock-applet_0.3.3-1 \
    alarm-clock_1.2.5-1.2 \
    allegro5_5.0.7-2 \
    alsaplayer_0.99.80-5.1 \
    amanda_3.3.1-4 \
    ardour_2.8.14-1 \
    at-spi2-atk_2.5.3-2 \
    ats-lang-anairiats_0.2.3-1 \
    ats-lang-anairiats_0.2.6-1 \
    audacious-plugins_3.2.3-1 \
    audiopreview_0.6-2 \
    aweather_0.7-1 \
    ayttm_0.6.3-3 \
    balsa_2.4.12-1 \
    banshee-community-extensions_2.4.0-1 \
    betaradio_1.4-1 \
    bibledit-gtk_4.6-1 \
    bluefish_2.2.3-4 \
    bluez_4.99-2 \
    bognor-regis_0.6.12+git20101007.02c25268-7 \
    brasero_3.4.1-4 \
    bsl_0.5.0-2.1 \
    buzztard_0.5.0-4 \
    byzanz_0.2.2+git22.10.2011-1.3 \
    cheese_3.4.2-2 \
    cinnamon_1.6.2-1 \
    clementine_1.0.1+dfsg-2 \
    connman_1.0-1 \
    crystalhd_1:0.0~git20110715.fdd2f19-7 \
    cutter-testing-framework_1.1.7-1.2 \
    darktable_1.0.5-1 \
    dbus-glib_0.100-1 \
    dsyslog_0.6.0 \
    dvdisaster_0.72.4-1 \
    efax-gtk_3.2.8-1 \
    eiskaltdcpp_2.2.6-4 \
    entangle_0.4.1-1 \
    farstream_0.1.2-1 \
    ffgtk_0.8.1-2 \
    fluidsynth_1.1.5-2 \
    folks_0.6.9-1 \
    foxtrotgps_1.1.1-2 \
    fso-deviced_0.11.4-1 \
    g2ipmsg_0.9.6+dfsg-1.1 \
    gamine_1.1-2 \
    garcon_0.1.12-1 \
    gbemol_0.3.2-2 \
    gcompris_12.01-1 \
    gegl_0.2.0-2 \
    gentoo_0.19.13-2 \
    gfal2_2.0.0-1 \
    gftp_2.0.19-4 \
    gigedit_0.2.0-1 \
    gmerlin_1.2.0~dfsg-2 \
    gnac_0.2.4-1 \
    gnet_2.0.8-2.2 \
    gnome-applets_3.4.1-3  \
    gnome-dvb-daemon_1:0.2.8-1 \
    gnome-games_1:3.4.2-3 \
    gnome-keyring_3.4.1-5 \
    gnome-media_3.4.0-1 \
    gnome-mud_0.11.2-1 \
    gnome-settings-daemon_3.4.2+git20120925.a4c817-2 \
    gnome-shell_3.4.2-3 \
    gnome-subtitles_1.2-4 \
    gnome-sushi_0.4.1-3 \
    gnome-vfs_1:2.24.4-1 \
    gnomeradio_1.8-2 \
    gnomint_1.2.1-4 \
    gnonlin_0.10.17-2 \
    gnubiff_2.2.15-1 \
    gobject-introspection_1.32.1-1 \
    goobox_3.0.1-5 \
    google-gadgets_0.11.2-6 \
    gpe-announce_0.14-2 \
    gpe-bluetooth_0.56-3 \
    gpredict_1.3-2 \
    gsmartcontrol_0.8.6-1.2 \
    gst-buzztard_0.5.0-2+deb7u1 \
    gst-buzztard_0.6.0-1 \
    gst-fluendo-mp3_0.10.15.debian-1 \
    gst-plugins-base0.10_0.10.36-1 \
    gst0.10-python_0.10.22-3 \
    gst123_0.3.1-1 \
    gstreamer-hplugins_0.2.0-2 \
    gstreamer-sharp_0.9.2-4 \
    gstreamer0.10-editing-services_0.10.1-2 \
    gstreamer0.10-rtsp_0.10.8-3 \
    gstreamer0.10_0.10.36-1 \
    gthumb_3:3.0.1-2 \
    gtkpod_2.1.2-1 \
    guayadeque_0.3.5~ds0-4 \
    guile-gnome-platform_2.16.2-1 \
    gupnp-dlna_0.6.6-1 \
    gupnp-igd_0.2.1-2 \
    gxine_0.5.907-2 \
    haskell-gstreamer_0.12.1-1 \
    haskell-gtk_0.12.3-1 \
    heartbeat_3.0.5-3 \
    iptux_0.5.3-1 \
    istanbul_0.2.2-9 \
    jabber-muc_0.8-3 \
    jd_2.8.5~beta120206-3 \
    jnettop_0.13.0-1 \
    kamoso_2.0.2-1 \
    lensfun_0.2.5-2 \
    libbonobo_2.24.3-1 \
    libcanberra_0.28-5 \
    libdmapsharing_2.9.15-1 \
    libepc_0.4.4-1 \
    libgda5_5.0.3-1 \
    libgdata_0.12.0-1 \
    libgdiplus_2.10-3 \
    libglib-perl_3:1.260-1 \
    libgnome-keyring_3.4.1-1 \
    libgnome-media-profiles_3.0.0-1 \
    libgnome_2.32.1-2 \
    libgnomecups_0.2.3-5 \
    libgsecuredelete_0.2-1 \
    libgstreamer-interfaces-perl_0.06-2 \
    libgstreamer-perl_0.17-1 \
    libgusb_0.1.3-5 \
    libinstpatch_1.0.0-3 \
    libnice_0.1.2-1 \
    libplayer_2.0.1-2.1 \
    libvisual-plugins_0.4.0.dfsg.1-7 \
    libvisual_0.4.0-5 \
    libxr_1.0-2.1 \
    libzorpll_3.9.1.3-1 \
    lightspark_0.6.0.1-2 \
    linphone_3.5.2-10 \
    linuxdcpp_1.1.0-1 \
    longomatch_0.16.8+git20110626-1 \
    lua-lgi_0.6.2-1 \
    me-tv_1.3.7-0.2 \
    medit_1.0.93-1 \
    minbar_0.2.1-7 \
    mistelix_0.33-3 \
    moodbar_0.1.2-3 \
    moodbar_0.1.2-4 \
    morla_0.16.1-1.1 \
    mp3splt-gtk_0.7.2-2 \
    mpd_0.17.1-1 \
    mtpfs_1.1-2 \
    mysql-proxy_0.8.1-1.1 \
    mysql-workbench_5.2.40+dfsg-1 \
    netbeans_7.0.1+dfsg1-5 \
    network-manager_0.9.4.0-6 \
    nufw_2.4.3-2.1 \
    obex-data-server_0.4.5-1 \
    ocaml-gstreamer_0.1.0-3 \
    open-vm-tools_8.8.0+2012.05.21-724730-4 \
    openfetion_2.2.1-3.2 \
    openhpi_2.14.1-1.2 \
    orbit2_2.14.19-0.1 \
    packagekit_0.7.6-1 \
    pango1.0_1.30.0-1 \
    parole_0.2.0.6-1 \
    passepartout_0.7.1-1 \
    performous_0.6.1-6 \
    phonon-backend-gstreamer_4:4.6.0.0-2 \
    pidgin-sipe_1.13.1-2 \
    pidgin_2.10.6-1 \
    pidgin_2.10.6-2 \
    pigment-python_0.3.12-2 \
    pigment_0.3.17-1 \
    projectm_2.1.0+dfsg-1 \
    psimedia_1.0.3-git20120506-fb54b6e-1 \
    purple-plugin-pack_2.6.3-2 \
    qemu-kvm_1.1.2+dfsg-2 \
    qemu_1.1.2+dfsg-2 \
    qt-gstreamer_0.10.2-2 \
    rawstudio_2.0-1 \
    rhythmbox_2.97-2.1 \
    root-system_5.34.00-1 \
    ruby-gnome2_1.1.3-2 \
    rygel_0.14.3-2 \
    scli_0.4.0-2 \
    searchmonkey_0.8.1-8 \
    sflphone_1.1.0-2 \
    shotwell_0.12.3-2 \
    sigx_2.0.2-1 \
    slurm-llnl_2.3.4-2 \
    snappy-player_0.2-1 \
    sofia-sip_1.12.11+20110422-1 \
    sound-juicer_3.4.0-3 \
    spice-gtk_0.12-4 \
    sqlheavy_0.1.1-1 \
    squeak-vm_1:4.4.7.2357-1.1 \
    stardict_3.0.1-9.1 \
    subtitleeditor_0.33.0-1 \
    swac-explore_0.2-1.2 \
    swami_2.0.0+svn389-1 \
    sylpheed_3.2.0-1 \
    syncevolution_1.2.99.1-1 \
    syslog-ng_3.3.5-2 \
    telepathy-farstream_0.4.0-3 \
    telepathy-qt_0.9.1-4 \
    telepathy-ring_2.1.0-1 \
    thoggen_0.7.1-1 \
    tilda_0.09.6-2 \
    toonloop_2.2.0-1 \
    totem_3.0.1-8 \
    tumbler_0.1.25-1 \
    tuxcmd_0.6.70+dfsg-1 \
    uget_1.8.2-1 \
    vagalume_0.8.5-4 \
    vte3_0.32.2-1 \
    vte_0.28.2-5 \
    wireshark_1.8.2-1 \
    workrave_1.9.909+abc941eb70-1 \
    xbmc_11.0~git20120510.82388d5-1 \
    xfburn_0.4.3-4 \
    xfce4-mailwatch-plugin_1.1.0-5 \
    xfce4-volumed_0.1.13-3 \
    xfconf_4.8.1-1 \
    xmms2_0.8+dfsg-4 \
    xmp_3.4.0-1.1 \
    xneur_0.15.0-1.1 \
    xxxterm_1:1.11.3-1 \
    yelp_3.4.2-1 \
    zathura_0.1.2-4 \
    zorp_3.9.5-4 \
    . ALL . -m "Ensure package is built against GLib >= 2.32 (see #674156)"

Once all those have been binNMU'd, we can try again with gnome-dvb-daemon:

    gb gnome-dvb-daemon_1:0.2.9-1 . armel armhf mips mipsel powerpc s390 sparc

and it will probably build this time.

For some packages that I know to be big or significant, I checked the build
logs, confirmed that they were built with GLib 2.32 on all affected
architectures and excluded them from the list above. For instance, qt4-x11,
qtwebkit, webkit and the Mozilla suite don't need rebuilding, thankfully,
because their versions in both testing and unstable were built against
GLib 2.32 everywhere. There is scope for doing more of that, but at this
stage it's probably quicker to just queue the binNMUs...

To get that list I searched codesearch.debian.net for:

GStaticMutex, GStaticRecMutex, GStaticRWLock (for GLib)
\bStaticMutex, \bStaticRecMutex, \bStaticRWLock (for glibmm)
libvisual/libvisual.h (for libvisual)

and also included every package with a build-dependency on
src:gstreamer0.10, by asking dak (there were too many search results for
GstElement to look at them individually).

Of the affected packages, these headers mention GStaticMutex, GStaticRecMutex
or GStaticRWLock:

/usr/include/glibmm-2.4/glibmm/thread.h
/usr/include/gstreamer-0.10/gst/audio/gstaudiodecoder.h
/usr/include/gstreamer-0.10/gst/audio/gstaudioencoder.h
/usr/include/gstreamer-0.10/gst/base/gstcollectpads2.h
/usr/include/gstreamer-0.10/gst/check/gstcheck.h           (false positive)
/usr/include/gstreamer-0.10/gst/gstelement.h
/usr/include/gstreamer-0.10/gst/gstobject.h
/usr/include/gstreamer-0.10/gst/gstpad.h
/usr/include/gstreamer-0.10/gst/gsttask.h
/usr/include/gstreamer-0.10/gst/gsttrace.h
/usr/include/gstreamer-0.10/gst/rtp/gstbasertpdepayload.h
/usr/include/gstreamer-0.10/gst/video/gstbasevideocodec.h
/usr/include/libinstpatch-1.0/libinstpatch/IpatchItem.h
/usr/include/libvisual-0.4/libvisual/lv_thread.h
/usr/include/swami/libswami/SwamiLock.h
/usr/include/zorp/connect.h
/usr/include/zorp/listen.h
/usr/include/zorp/proxy.h

glibmm was already built against 2.32 on all architectures, because it
has a versioned dependency. So we don't have to binNMU glibmm, only
things that depend on it (because those might have been built with the
old GLib installed).

swami and zorp have a -dev but are in fact leaf packages, so we can stop
there.

I approximated the Gst stuff by the set of packages build-depending on
a package from src:gstreamer0.10. I'm open to suggestions for how to
improve on this - in theory, things could indirectly subclass one of the
Gst objects that contains a static mutex without directly depending on
libgstreamer0.10-dev, but in practice I don't think that really happens.

Regards,
    S



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Tue, 27 Nov 2012 09:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Cyril Brulebois <kibi@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Tue, 27 Nov 2012 09:33:03 GMT) Full text and rfc822 format available.

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

From: Cyril Brulebois <kibi@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Tue, 27 Nov 2012 10:28:38 +0100
[Message part 1 (text/plain, inline)]
Simon McVittie <smcv@debian.org> (27/11/2012):
> Here is a lengthy list of binNMUs. I would like these to be done on
> all architectures: our slower architectures are the ones that really
> need the rebuild anyway, and if we also rebuild on the fast
> architectures, then those packages from this list that are multiarch
> remain co-installable.

Except dpkg can't co-install binNMU'd packages since the “oops, those
changelogs are different” issue isn't fixed.

Mraw,
KiBi.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Tue, 27 Nov 2012 09:33:04 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 Release Team <debian-release@lists.debian.org>. (Tue, 27 Nov 2012 09:33:04 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Tue, 27 Nov 2012 10:28:54 +0100
On Tue, Nov 27, 2012 at 09:05:49 +0000, Simon McVittie wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: binnmu
> 
> The upgrade from GLib 2.30 to 2.32 breaks ABI on most non-x86 32-bit
> architectures (#674156). Specifically, the deprecated struct GStaticMutex,
> and the deprecated structs GStaticRecMutex and GStaticRWLock (each of which
> contains a GStaticMutex), change in size on each architecture where the
> alignment of a double is greater than the size of a pointer: for us, that's
> armel, armhf, mips, mipsel, powerpc, s390 and sparc, plus probably some -ports
> architectures.
> 
*sigh*

> Mitigations:
> 
> * it's in a deprecated struct
> * the part of GStaticMutex after the initial pointer is no longer used for
>   anything, so it only really matters when a larger struct contains a
>   GStaticMutex followed by other members
> 
> Upstream consensus appears to be that since their stable branches 2.32 and
> 2.34 have the "new" ABI, we are way past the point where reverting it or
> bumping the SONAME would be useful, so we should just consider the new ABI
> to be the canonical one. I'm inclined to agree: any package in Debian that
> gets regular uploads will have been built against the new GLib by now,
> so we'd have to rebuild even more packages to go back.
> 
> Here is a lengthy list of binNMUs. I would like these to be done on all
> architectures: our slower architectures are the ones that really need the
> rebuild anyway, and if we also rebuild on the fast architectures, then those
> packages from this list that are multiarch remain co-installable.
> 
Actually, they won't.  They'll have different changelogs.

Cheers,
Julien



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Tue, 27 Nov 2012 09:39: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 Release Team <debian-release@lists.debian.org>. (Tue, 27 Nov 2012 09:39:03 GMT) Full text and rfc822 format available.

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

From: Simon McVittie <smcv@debian.org>
To: 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Tue, 27 Nov 2012 09:36:56 +0000
On 27/11/12 09:28, Julien Cristau wrote:
> *sigh*

Yeah, I know. I don't think there is a good solution to this, and
mass-binNMUing seems like the least awful.

>> Here is a lengthy list of binNMUs. I would like these to be done on all
>> architectures [...] those
>> packages from this list that are multiarch remain co-installable.
>>
> Actually, they won't.  They'll have different changelogs.

I'd hoped that binNMUing for all architectures with the same "commit
message" avoided that, but I suppose the timestamp in debian/changelog
is what causes the problem?

In that case, please hold off on this for now, and I'll spend some more
time trying to reduce the list.

    S



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Tue, 27 Nov 2012 13:03:04 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 Release Team <debian-release@lists.debian.org>. (Tue, 27 Nov 2012 13:03:05 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Tue, 27 Nov 2012 13:59:29 +0100
[Message part 1 (text/plain, inline)]
On Tue, Nov 27, 2012 at 09:36:56 +0000, Simon McVittie wrote:

> I'd hoped that binNMUing for all architectures with the same "commit
> message" avoided that, but I suppose the timestamp in debian/changelog
> is what causes the problem?
> 
Timestamp, name/address, and "Binary-only non-maintainer upload for
$arch; no source changes".

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Fri, 30 Nov 2012 12:54:04 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 Release Team <debian-release@lists.debian.org>. (Fri, 30 Nov 2012 12:54:04 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Fri, 30 Nov 2012 13:51:26 +0100
[Message part 1 (text/plain, inline)]
On Tue, Nov 27, 2012 at 09:05:49 +0000, Simon McVittie wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: binnmu
> 
> The upgrade from GLib 2.30 to 2.32 breaks ABI on most non-x86 32-bit
> architectures (#674156). Specifically, the deprecated struct GStaticMutex,
> and the deprecated structs GStaticRecMutex and GStaticRWLock (each of which
> contains a GStaticMutex), change in size on each architecture where the
> alignment of a double is greater than the size of a pointer: for us, that's
> armel, armhf, mips, mipsel, powerpc, s390 and sparc, plus probably some -ports
> architectures.
> 
Before rebuilding the world, I'd like to avoid breaking partial
upgrades.  Which, as far as I can tell, means:
- if possible, get a list of packages in squeeze that expose an affected
  struct (gstreamer, glibmm, others?)
- once we have that, add appropriate Breaks on affected reverse
  dependencies in e.g. libgstreamer0.10-0 (and others, if step 1 found
  any), and make sure its shlibs/symbols ensure that newly rebuilt
  reverse deps get a dependency on a libgstreamer using the new glib ABI
- only then rebuild whatever gstreamer plugins (and possibly other
  packages) are affected.

Does that sound ok?

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Fri, 30 Nov 2012 13:06: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 Release Team <debian-release@lists.debian.org>. (Fri, 30 Nov 2012 13:06:03 GMT) Full text and rfc822 format available.

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

From: Simon McVittie <smcv@debian.org>
To: debian-devel@lists.debian.org
Cc: 694525@bugs.debian.org
Subject: Re: Candidates for removal from testing (2012-11-30)
Date: Fri, 30 Nov 2012 13:03:46 +0000
On 30/11/12 11:55, Niels Thykier wrote:
> The packages have been selected based on the following criteria: *
> The package had at least one RC bug without activity for the past 
> 14 days.
...
> Debian GNOME Maintainers
> <pkg-gnome-maintainers@lists.alioth.debian.org> gnome-dvb-daemon
> (U)

I have no particular interest in gnome-dvb-daemon, but if it works
correctly on those architectures that can build it, I think it
deserves to remain in testing.

Its RC bugs are duplicate FTBFSs, which aren't really a
gnome-dvb-daemon bug: it's a victim of #674156, a long-standing[1] ABI
break in glib2.0 on 32-bit non-x86 architectures, and will probably
build successfully once that has been resolved.

Discussion of how best to resolve that bug (#694525, and further
discussion in #debian-gnome) was inconclusive: none of the options are
actually good, so it's a matter of choosing the least bad.

Suggested options include:

A) Consider the new ABI to be "right". Recompile every package that
   mentions the affected structs (including everything that
   subclasses GstElement), unless it has already been compiled
   against GLib 2.32 on every architecture.

   +: Every frequently-uploaded package, including large ones like
      Webkit, Qt and the Mozilla suite, have already been compiled
      against GLib 2.32 in practice anyway. The most significant
      exception that I noticed is GStreamer 0.10, which is where we
      noticed this ABI break: the problem is that "core" GStreamer has
      not been recompiled since, but some packages that subclass its
      objects have.

   -: Binaries built against squeeze's GLib on the affected
      architectures will break, in relatively rare circumstances[2].
      We have to recompile up to 227 source packages.

B) Consider the old ABI to be "right". Recompile every package that
   mentions the affected structs, unless it has never been compiled
   against GLib 2.32 on any architecture.

   +: Binaries built against squeeze's GLib will not break.

   -: Binaries built against anyone else's GLib (most notably the
      increasingly popular ARM ports of other distributions, e.g.
      Fedora, Ubuntu, Raspbian) will break on Debian in
      relatively rare circumstances[2]. We have to carry the patch
      for the lifetime of libglib2.0.so.0, otherwise we might
      as well have done (A). We have to recompile an unknown
      number of source packages, including Webkit, Qt and the
      Mozilla suite; the longer we think about it for, the larger this
      number gets.

C) Change GLib's package name and/or SONAME. Recompile literally every
   package that depends on GLib.

   +: Parallel-installable with squeeze's GLib. Existing binaries
      built by stable users continue to work. Existing binaries built
      by testing/unstable users are no more broken than they already
      are.

   -: Our ABI diverges from upstream for every GLib user (not just
      those that use the affected structs, or are on the affected
      architectures) for the lifetime of libglib2.0.so.0. Binaries
      built against anyone else's GLib will not have their
      dependencies met in Debian and vice versa. We have to
      recompile 903 source packages, if my count is correct.

When I say "recompile", what I mean is:

* If the source does not build Multi-Arch:same packages, binNMU it.
  In strategies A and B, in most cases it's probably not worth taking
  the time to audit whether it is actually affected, or whether it has
  already been built with the right GLib on every architecture: buildd
  time is less limited than developer time.

* If following strategy A or B, check whether it's actually affected
  and whether it's already been built with the right GLib on every
  architecture; if following strategy C, it needs rebuilding anyway.
  If an upload is needed, make a sourceful upload.

I personally think the order of desirability is (A) > (B) >> (C), but
I have tried to give an unbiased summary of each option.

----

[1] By "long-standing" I mean: upstream master since September 2011,
upstream stable releases since March 2012, Debian unstable also since
March 2012, Debian testing since at least April 2012.

[2] The "rare circumstances" under which breakage occurs are:

* the architecture ABI gives doubles greater alignment than the size
of a pointer. In practice this means 32-bit RISC: arm*, mips*,
powerpc, s390, sparc.

* a package (typically gstreamer0.10) defines a struct in its public
header which contains a GStaticMutex, GStaticRecMutex or GStaticRWLock
(the most prominent example is GstElement)

* package P1 (typically an implementor of GStreamer plugins) embeds
that struct in a larger struct (typically a GstElement subclass)

* package P2, which might be gstreamer0.10 or a third package, looks
at members of the larger struct that appear after the GStaticWhatever.
GObject has a built-in check for this: it issues a warning if
subclasses think they're smaller than their parent class.

* of packages P1 and P2, one was compiled with GLib < 2.32 and the
other was compiled with GLib >= 2.32



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Fri, 30 Nov 2012 16:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Adam D. Barratt" <adam@adam-barratt.org.uk>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 30 Nov 2012 16:27:03 GMT) Full text and rfc822 format available.

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

From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
To: <debian-devel@lists.debian.org>
Cc: <694525@bugs.debian.org>
Subject: Re: Candidates for removal from testing (2012-11-30)
Date: Fri, 30 Nov 2012 16:22:59 +0000
On 30.11.2012 13:03, Simon McVittie wrote:
> Suggested options include:
>
> A) Consider the new ABI to be "right". Recompile every package that
>    mentions the affected structs (including everything that
>    subclasses GstElement), unless it has already been compiled
>    against GLib 2.32 on every architecture.
>
>    +: Every frequently-uploaded package, including large ones like
>       Webkit, Qt and the Mozilla suite, have already been compiled
>       against GLib 2.32 in practice anyway. The most significant
>       exception that I noticed is GStreamer 0.10, which is where we
>       noticed this ABI break: the problem is that "core" GStreamer 
> has
>       not been recompiled since, but some packages that subclass its
>       objects have.
>
>    -: Binaries built against squeeze's GLib on the affected
>       architectures will break, in relatively rare circumstances[2].
>       We have to recompile up to 227 source packages.

I think this is basically what was suggested in 
<20121130125125.GS5634@radis.cristau.org>, with the negative point being 
addressed by adding Breaks: for those cases we can identify.

Regards,

Adam



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sat, 29 Dec 2012 17:57:03 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 Release Team <debian-release@lists.debian.org>. (Sat, 29 Dec 2012 17:57:03 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Cc: glib2.0@packages.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Sat, 29 Dec 2012 18:55:27 +0100
[Message part 1 (text/plain, inline)]
On Fri, Nov 30, 2012 at 13:51:26 +0100, Julien Cristau wrote:

> Before rebuilding the world, I'd like to avoid breaking partial
> upgrades.  Which, as far as I can tell, means:
> - if possible, get a list of packages in squeeze that expose an affected
>   struct (gstreamer, glibmm, others?)
> - once we have that, add appropriate Breaks on affected reverse
>   dependencies in e.g. libgstreamer0.10-0 (and others, if step 1 found
>   any), and make sure its shlibs/symbols ensure that newly rebuilt
>   reverse deps get a dependency on a libgstreamer using the new glib ABI
> - only then rebuild whatever gstreamer plugins (and possibly other
>   packages) are affected.
> 
> Does that sound ok?
> 
Ping.  We need to make some progress here...

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sun, 30 Dec 2012 19:03:04 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 Release Team <debian-release@lists.debian.org>. (Sun, 30 Dec 2012 19:03:04 GMT) Full text and rfc822 format available.

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

From: Simon McVittie <smcv@debian.org>
To: Julien Cristau <jcristau@debian.org>
Cc: 694525@bugs.debian.org, glib2.0@packages.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Sun, 30 Dec 2012 19:00:35 +0000
On 29/12/12 17:55, Julien Cristau wrote:
>> - if possible, get a list of packages in squeeze that expose an
>> affected struct (gstreamer, glibmm, others?)

> Ping.  We need to make some progress here...

I'm still trying to construct this list. It's going to take a while.

On the positive side, it looks as though many of the 227 that I
mentioned can be ignored, because they're actually not the problematic
cases. (For instance, the usage in GstElement is safe, as it turns out.)

    S



Added blocking bug(s) of 694525: 697025 Request was from Simon McVittie <smcv@debian.org> to submit@bugs.debian.org. (Sun, 30 Dec 2012 21:57:04 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 694525: 697026 Request was from Simon McVittie <smcv@debian.org> to submit@bugs.debian.org. (Sun, 30 Dec 2012 22:03:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sun, 30 Dec 2012 23:00: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 Release Team <debian-release@lists.debian.org>. (Sun, 30 Dec 2012 23:00:03 GMT) Full text and rfc822 format available.

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

From: Simon McVittie <smcv@debian.org>
To: 694525@bugs.debian.org
Cc: Julien Cristau <jcristau@debian.org>
Subject: Re: Bug#694525: nmu: 14 packages, for GStaticMutex
Date: Sun, 30 Dec 2012 22:56:52 +0000
On 30/11/12 12:51, Julien Cristau wrote:
> Before rebuilding the world, I'd like to avoid breaking partial 
> upgrades.

Here is an attempt at a better list of packages via better choice of
regexps, with notes on methodology.

Sourceful uploads (multi-arch):

gstreamer0.10 (sourceful upload request: #697025)
swami (sourceful upload request: #697026)

binNMUs:

# some of these might be false positives, but buildds don't get bored
nmu \
    4store_1.1.4-2 \
    ats-lang-anairiats_0.2.6-1 \
    gnome-vfs_1:2.24.4-1 \
    gnubiff_2.2.15-1 \
    gpredict_1.3-2 \
    libzorpll_3.9.1.3-1 \
    mysql-proxy_0.8.1-1.1 \
    passepartout_0.7.1-1 \
    purple-plugin-pack_2.6.3-2 \
    scli_0.4.0-2 \
    . armel armhf mips mipsel powerpc s390 sparc . \
    -m 'Rebuild against GLib 2.32, see #694525'

# this one might FTBFS again like it did when first tried, but it seems
# worth a go...
nmu \
    sigx_2.0.2-1
    . armel . \
    -m 'Rebuild against GLib 2.32, see #694525'

Are you able to make binNMUs of versions from testing that have a
newer version in unstable? If so, these also need doing:

nmu \
    ats-lang-anairiats_0.2.3-1 \
    mpd_0.16.7-2 \
    mtpfs_0.9-3 \
    . armel armhf mips mipsel powerpc s390 sparc . \
    -m 'Rebuild against GLib 2.32, see #694525'

and if not ... something else will need to be done about them. (Check
whether the upload is really needed, add a sourceful upload to t-p-u
if necessary?)

There are two lists of affected source packages, 61 in all, suitable
for the Breaks: you requested, at the end of this mail. I can't say
I'm looking forward to trying to map those to binary packages... (Some
of them are probably false-positives and don't actually need a Breaks.)

I'm not really convinced those 61(ish) Breaks are particularly
valuable. We don't formally support partial upgrades, the affected
architectures are not mainstream desktop systems (powerpc is the
closest), none of the broken packages are particularly "core"
(GStreamer and Java are the closest), and anyone tracking testing is
going to have encountered this breakage with the current
glib2.0/wheezy already.

In any case, if we're going to add the Breaks, I'd prefer to get the
binNMUs and the two sourceful uploads done first, so we can add them
all in one go?

Regards,
    S

----

Step 0. Restating the problem:

 In src:glib2.0, the GStaticMutex, GStaticRecMutex and GStaticRWLock
structs broke ABI by changing their sizes. These structs are
semi-opaque: they contain a set amount of padding, but only the
GThread part of GLib is allowed to dereference them (which it does by
casting to a pointer to a struct of equal size with more useful members).

In the new version of GLib, only the first sizeof(void *) bytes are
actually ever used, and the rest remain uninitialized. The old and new
sizes are both more than sizeof(void *), so the only problematic
binaries are those where the size change causes two modules to
disagree on the position of members (or the end-of-struct) appearing
after a GStaticMutex, etc. in a larger struct.

In particular, if a .c file contains a static GStaticMutex, etc. at
file scope, a private header contains an extern GStaticMutex whose
declaration is only visible within that source package, or a .c file
or private header embeds a GStaticMutex in a larger struct, then
that's fine: the whole source package is guaranteed to have been
compiled with a consistent idea of how large a GStaticMutex is.

----

Step 1. Who uses those structs, other than as a pointer or a static
(file-scope) variable?

I searched codesearch.d.n for
"(GStaticMutex|GStaticRecMutex|GStaticRWLock)\s+(\w|/|$)". I ignored
glib2.0 itself.

I also ignored occurrences in a .c file or an obviously-private header
(something-internal.h, something-private.h). Justification: these can
never be a problem because they are only visible to the package that
contains them, and any given compilation of that package was against one
particular consistent version of GLib.

I also ignored anything wrapped in #if !GLIB_CHECK_VERSION(...).
Justification: those are obviously going to break ABI with older/newer
GLib anyway, and the authors are surely aware of that. (Seen in at least
gstreamer0.10 and gst-plugins-base0.10, in what are hopefully private
headers...)

I also ignored anything that's obviously only for Windows or Mac OS -
not our problem. (A few packages have an embedded code copy of GLib in a
directory called macosx or win32gdi or something, presumably to simplify
compilation on platforms without proper package management.)

So far the list is (source packages):

4store
alsaplayer
ats-lang-anairiats
audacious-plugins
connman
efax-gtk
eiskaltdcpp
evolution-data-server
farstream
fluidsynth
gfal2
gftp
gimp-plugin-registry
glibmm2.4
gnome-vfs
gnubiff
gpredict
gsmartcontrol
gst-plugins-bad0.10
gst-plugins-bad1.0
gst-plugins-base0.10
gst-plugins-good0.10
gstreamer0.10
gxine
libinstpatch
libsyncml
libvisual
libzorpll
linuxdcpp
mpd
mtpaint
mtpfs
mysql-proxy
mysql-workbench
network-manager
nufw
openhpi
purple-plugin-pack
root-system
scli
slurm-llnl
swami
syslog-ng
workrave
zathura
zorp

Next ignore anything that does not install any headers.

xargs -n1 grep-aptavail --exact-match -S -n -s Package --pattern \
    < sources | LC_ALL=C sort -u > binaries-wheezy
zgrep '^usr/include' \
    ftp.uk.debian.org_debian_dists_wheezy_main_Contents-amd64.gz \
    | awk '{print $2}' \
    | LC_ALL=C sort -u \
    | sed -e 's@[a-z]\+/@@' \
    | grep -f binaries-wheezy > dev-wheezy

That gives a long list of potentially affected binary packages. I
edited the list to fix lines containing a comma (libivykis-dev
shares a file with libsyslog-ng-dev but is not built by an affected
source package).

Next check those binary packages for false positives: the installed
headers might not actually contain any affected structs in a problematic
form.

Potential problems:

In src:glibmm2.4, Glib::StaticMutex, Glib::StaticRWLock and
Glib::StaticRecMutex each embeds a struct of the corresponding C type
as its only data member.

In the GStreamer packages, GstCollectPads2, GstBaseVideoCodec,
GstAudioDecoder, GstAudioEncoder, GstBaseRTPDepayload each contains a
GStaticRecMutex.

In src:swami, SwamiLock contains a GStaticRecMutex.

In src:zorp, ZConnector, ZListener, ZProxy, ZStackedProxy each contain
a GStatic(Rec)Mutex.

In src:syslog-ng, LogQueue, LogTemplate each contain a GStaticMutex.

This leaves us with only these source packages in wheezy from step 1:

glibmm2.4
gst-plugins-bad0.10
gst-plugins-base0.10
gstreamer0.10
swami
syslog-ng

False positives:

/usr/include/gstreamer-0.10/gst/gsttrace.h contains a global, "extern
GStaticMutex _gst_trace_mutex" used by macros in that file. I believe
this is not a problem because each extern symbol in a library has its
own relocation, so nothing will be relying on the offset of whatever
symbol follows it?

/usr/include/gstreamer-0.10/gst/check/gstcheck.h has a GStaticRecMutex
but it's a static variable in a static inline function. Never a problem.

In src:libvisual, VisMutex contains a GStaticMutex under certain
compile-time configurations, but Debian's is configured to use
pthreads directly instead. (Libraries that change ABI depending on
compile-time configuration are usually a bug, but, whatever. Not our
problem right now.)

In src:syslog-ng, stats.h has an extern GStaticMutex with the same
reasoning for it not being a problem as gsttrace.h.

----

Step 2: who uses the structs from step 1? I searched for
\bGstCollectPads2\b, etc.

I didn't ignore uses as a pointer this time, since the module could
conceivably be dereferencing p->member where p is a GstCollectPads2
(etc.) and member comes after the affected struct.

StaticMutex, StaticRecMutex, StaticRWLock:

ardour
lightspark
passepartout
jd
me-tv
sigx

GstCollectPads2, GstBaseVideoCodec, GstAudioDecoder, GstAudioEncoder,
GstBaseRTPDepayload:

gst-plugins-bad0.10 (embedded in GstBaseVideoDecoder, GstBaseVideoEncoder)
gst-plugins-base0.10
gst-plugins-good0.10
gst-plugins-ugly0.10
gst-plugins-bad1.0
gst-plugins-base1.0
gst-plugins-good1.0
gst-plugins-ugly1.0

SwamiLock:

swami (embedded in SwamiWavetbl, SwamiRoot, SwamiPropTree,
SwamiMidiDevice, SwamiLoopFinder, SwamiControl, SwamiControlQueue)

ZConnector, ZListener, ZProxy, ZStackedProxy:

zorp

LogQueue, LogTemplate:

syslog-ng

----

Step 3: fan out again...

Swami*: nothing outside src:swami matches \b_?Swami[A-Z] so I think
we're safe.

GstBaseVideoDecoder, GstBaseVideoEncoder:
gst-plugins-bad0.10 (not embedded in any public struct)
gst-plugins-bad1.0 (not embedded in any public struct)

so I think we're done.

----

Step 4: of the step 1-3 packages, which ones are multiarched, and thus
will need sourceful uploads, if they have not already been compiled
against GLib 2.32 on every architecture?

cat sources sources-step2 \
    | sort -u \
    | xargs -n1 grep-aptavail --exact-match -n -s Source:Package \
        '(' -F Multi-arch --pattern same ')' --and -S --pattern \
    | LC_ALL=C sort -u > ma

For each of those, check the build logs for armel armhf mips mipsel
powerpc s390 sparc and see whether the version in sid, and the version
in wheezy if different, was built against 2.32 on all affected
architectures.

(These are from a less filtered list so some of them don't actually
install headers. Sorry, I've done enough on this already that I don't
want to spend yet more time filtering them... I did check that the
ones requiring a sourceful upload have public headers without false
positives, since those are going to require additional work to be done.)

                           OK version (not necessarily minimal)
audacious-plugins            3.2.4-1
farstream                    0.1.2-1
farstream-0.2                0.2.2-1
fluidsynth                   1.1.6-1
glibmm2.4                    2.32.1-1
gst-plugins-bad0.10          0.10.23-7
gst-plugins-bad1.0           1.0.4-1
gst-plugins-base0.10         0.10.36-1.1
gst-plugins-base1.0          1.0.4-1
gst-plugins-good0.10         0.10.31-3+nmu1
gst-plugins-good1.0          1.0.4-1
gst-plugins-ugly0.10         0.10.19-2+b2
gst-plugins-ugly1.0          1.0.4-1
gstreamer0.10                NONE (bug filed)
gstreamer0.10-ffmpeg         0.10.13-5
libvisual                    0.4.0-5
openjdk-6                    6b24-1.11.5-1
openjdk-7                    7u3-2.1.3-1
root-system                  5.34.00-1
swami                        NONE (bug filed)
syslog-ng                    3.3.6-1
telepathy-farstream          0.4.0-3

And the rest:

cat sources sources-step2 | LC_ALL=C sort -u | grep -v -F --file ma \
    > not-ma

                                              (assuming binNMU is done)
4store                       NONE             1.1.4-2+b1
alsaplayer                   0.99.80-5.1
ardour                       1:2.8.14-2
ats-lang-anairiats           NONE             0.2.3-1+b1, 0.2.6-1+b1
connman                      1.0-1
efax-gtk                     3.2.8-1+b1
eiskaltdcpp                  2.2.6-4
evolution-data-server        3.4.4-1
gfal2                        2.0.0-1
gftp                         2.0.19-4
gimp-plugin-registry         5.20120621
gnome-vfs                    NONE             1:2.24.4-1+b1
gnubiff                      NONE             2.2.15-1+b1
gpredict                     NONE             1.3-2+b1
gsmartcontrol                0.8.6-1.2
gxine                        0.5.907-2
jd                           1:2.8.5~beta120206-3
libsyncml                    0.5.4-2.1
libzorpll                    NONE             3.9.1.3-1+b1
lightspark                   0.6.0.1-2
linuxdcpp                    1.1.0-1+b2 (+b1 on armhf)
me-tv                        1.3.7-0.2
mpd                          0.17.1-1 (not in wheezy)
mtpaint                      3.40-1+b1
mtpfs                        1.1-2 (not in wheezy)
mysql-proxy                  NONE             0.8.1-1.1+b2 (b1 on armhf)
mysql-workbench              5.2.40+dfsg-2
network-manager              0.9.4.0-6
nufw                         2.4.3-2.2
openhpi                      2.14.1-1.2
passepartout                 NONE             0.7.1-1+b1
purple-plugin-pack           NONE             2.6.3-2+b1
scli                         NONE             0.4.0-2+b1
sigx                         2.0.2-1+b1 (not on armel)
slurm-llnl                   2.3.4-2+b1
workrave                     1.9.909+abc941eb70-1
zathura                      0.1.2-4
zorp                         3.9.5-4

That looks like a lot of Breaks, but it's better than the 227 packages
I thought it'd be.



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

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

Added indication that bug 694525 blocks 674156 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.

Changed Bug title to 'nmu: 14 packages, for GStaticMutex' from 'nmu: 227 source packages, for GStaticMutex' Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Sun, 30 Dec 2012 23:18:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Tue, 01 Jan 2013 13:15:03 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 Release Team <debian-release@lists.debian.org>. (Tue, 01 Jan 2013 13:15:03 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>
Cc: 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 14 packages, for GStaticMutex
Date: Tue, 1 Jan 2013 14:10:53 +0100
[Message part 1 (text/plain, inline)]
On Sun, Dec 30, 2012 at 22:56:52 +0000, Simon McVittie wrote:

> On 30/11/12 12:51, Julien Cristau wrote:
> > Before rebuilding the world, I'd like to avoid breaking partial 
> > upgrades.
> 
> Here is an attempt at a better list of packages via better choice of
> regexps, with notes on methodology.
> 
Thanks.

> Are you able to make binNMUs of versions from testing that have a
> newer version in unstable? If so, these also need doing:
> 
Yes, that's possible.

> There are two lists of affected source packages, 61 in all, suitable
> for the Breaks: you requested, at the end of this mail. I can't say
> I'm looking forward to trying to map those to binary packages... (Some
> of them are probably false-positives and don't actually need a Breaks.)
> 
> I'm not really convinced those 61(ish) Breaks are particularly
> valuable. We don't formally support partial upgrades, the affected

Yes we do...

> architectures are not mainstream desktop systems (powerpc is the
> closest), none of the broken packages are particularly "core"
> (GStreamer and Java are the closest), and anyone tracking testing is
> going to have encountered this breakage with the current
> glib2.0/wheezy already.
> 
> In any case, if we're going to add the Breaks, I'd prefer to get the
> binNMUs and the two sourceful uploads done first, so we can add them
> all in one go?
> 
OK.

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sat, 26 Jan 2013 12:18:03 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 Release Team <debian-release@lists.debian.org>. (Sat, 26 Jan 2013 12:18:03 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 14 packages, for GStaticMutex
Date: Sat, 26 Jan 2013 12:16:09 +0000
[Message part 1 (text/plain, inline)]
On Sun, Dec 30, 2012 at 22:56:52 +0000, Simon McVittie wrote:

> # this one might FTBFS again like it did when first tried, but it seems
> # worth a go...
> nmu \
>     sigx_2.0.2-1
>     . armel . \
>     -m 'Rebuild against GLib 2.32, see #694525'
> 
FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=sigx&arch=armel&ver=2.0.2-1%2Bb2&stamp=1359200243

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sat, 26 Jan 2013 12:21:05 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 Release Team <debian-release@lists.debian.org>. (Sat, 26 Jan 2013 12:21:05 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 14 packages, for GStaticMutex
Date: Sat, 26 Jan 2013 12:19:40 +0000
[Message part 1 (text/plain, inline)]
On Sun, Dec 30, 2012 at 22:56:52 +0000, Simon McVittie wrote:

> # some of these might be false positives, but buildds don't get bored
> nmu \
>     4store_1.1.4-2 \

scheduled.

>     ats-lang-anairiats_0.2.6-1 \

version mismatch (sid has 0.2.9-1, wheezy 0.2.3-1)

>     gnome-vfs_1:2.24.4-1 \
>     gnubiff_2.2.15-1 \
>     gpredict_1.3-2 \
>     libzorpll_3.9.1.3-1 \
>     mysql-proxy_0.8.1-1.1 \
>     passepartout_0.7.1-1 \
>     purple-plugin-pack_2.6.3-2 \
>     scli_0.4.0-2 \
>     . armel armhf mips mipsel powerpc s390 sparc . \
>     -m 'Rebuild against GLib 2.32, see #694525'
> 
scheduled.

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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sat, 26 Jan 2013 13:06:19 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 Release Team <debian-release@lists.debian.org>. (Sat, 26 Jan 2013 13:06:19 GMT) Full text and rfc822 format available.

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

From: Simon McVittie <smcv@debian.org>
To: Julien Cristau <jcristau@debian.org>
Cc: 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 14 packages, for GStaticMutex
Date: Sat, 26 Jan 2013 13:05:31 +0000
On 26/01/13 12:19, Julien Cristau wrote:
> On Sun, Dec 30, 2012 at 22:56:52 +0000, Simon McVittie wrote:
>> ats-lang-anairiats_0.2.6-1 \
> 
> version mismatch (sid has 0.2.9-1, wheezy 0.2.3-1)

0.2.9-1 is OK, it was uploaded pretty recently.

0.2.3-1 needs a binNMU in wheezy, I think I asked for that in a
separate list in the same mail.

>> nmu \ sigx_2.0.2-1 . armel . \ -m 'Rebuild against GLib 2.32, see
>> #694525'
>> 
> FTBFS:
> 
https://buildd.debian.org/status/fetch.php?pkg=sigx&arch=armel&ver=2.0.2-1%2Bb2&stamp=1359200243

I did wonder whether that would happen. I'm opening a FTBFS bug
against sigx; it looks as though it might be fixable by throwing cast
operators at the problem.

Failing that, sigx is a library with no reverse dependencies (and no
new upstream release since 2009), so removal from testing seems a
reasonable fallback option.

    S



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#694525; Package release.debian.org. (Sat, 26 Jan 2013 13:18:03 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 Release Team <debian-release@lists.debian.org>. (Sat, 26 Jan 2013 13:18:03 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525@bugs.debian.org
Subject: Re: Bug#694525: nmu: 14 packages, for GStaticMutex
Date: Sat, 26 Jan 2013 13:15:49 +0000
[Message part 1 (text/plain, inline)]
On Sun, Dec 30, 2012 at 22:56:52 +0000, Simon McVittie wrote:

> nmu \
>     ats-lang-anairiats_0.2.3-1 \
>     mpd_0.16.7-2 \
>     mtpfs_0.9-3 \
>     . armel armhf mips mipsel powerpc s390 sparc . \
>     -m 'Rebuild against GLib 2.32, see #694525'
> 
Scheduled ats-lang-anairiats and mpd.  I've added a rm hint for mtpfs,
due to 696552.

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

Reply sent to Julien Cristau <jcristau@debian.org>:
You have taken responsibility. (Thu, 25 Apr 2013 10:18:05 GMT) Full text and rfc822 format available.

Notification sent to Simon McVittie <smcv@debian.org>:
Bug acknowledged by developer. (Thu, 25 Apr 2013 10:18:06 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Simon McVittie <smcv@debian.org>, 694525-done@bugs.debian.org
Subject: Re: Bug#694525: nmu: 227 source packages, for GStaticMutex
Date: Thu, 25 Apr 2013 12:15:02 +0200
[Message part 1 (text/plain, inline)]
On Tue, Nov 27, 2012 at 09:05:49 +0000, Simon McVittie wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: binnmu
> 
> The upgrade from GLib 2.30 to 2.32 breaks ABI on most non-x86 32-bit
> architectures (#674156). Specifically, the deprecated struct GStaticMutex,
> and the deprecated structs GStaticRecMutex and GStaticRWLock (each of which
> contains a GStaticMutex), change in size on each architecture where the
> alignment of a double is greater than the size of a pointer: for us, that's
> armel, armhf, mips, mipsel, powerpc, s390 and sparc, plus probably some -ports
> architectures.
> 
Let's call this one done.

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, 24 May 2013 07:27:03 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: Wed Apr 16 16:29:54 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.