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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
