Re: mass bug filing for libjack dependant packages
* Robert Jordens [Mon, 27 Jun 2005 16:10:42 +0200]:
Hi Robert, there a few things I'd like to comment about the handling
of this transition. It is my intention to be constructive.
> The following source packages have been built against libjack0.80.0-dev
At the end of this mail there is the same list processed with Lars
Wirzenius' dd-list script [1] (which we will hopefully see some day
integrated into devscripts). I think it's good to provide lists of
packages in this format, since it's much more suitable for human
consumption and people can easily find their packages; looking at the
mail you sent to @packages.debian.org addresses [2], it's really
difficult to find one's own packages...
[1] http://liw.iki.fi/liw/download/dd-list
[2] http://lists.debian.org/debian-qt-kde/2005/06/msg00297.html
In this list, there are two separate sets of packages: those
build-depending on libjack0.80.0-dev or libjack-dev (e.g., arts and
ams, respectively), and those who get an indirect binary dependency on
libjack0.80.0-0 via some other package (e.g., xmms-jackasyn via
libjackasyn-dev). It is normally a good idea to file these bugs / send
these mails in two stages, in order to have all the build-dependencies
fixed first, and then go for the binary dependencies.
About the list itself, gst-plugins is no longer in the archive, and my
apt sources know nothing about bio2jack. But there are some missing
packages as well: wine (build-depends on libjack0.80.0-dev,
libwine-jack depends on libjack0.80.0-0), soundtracker, and swami.
These two build-depend on libjack0.80.0-dev but their binary packages
don't depend on libjack0.80.0-0 -- there may be a bug there, or the
build-dependency is obsolete. In either case, they should be notified,
since they'll FTBFS automatically when libjack0.80.0-dev gets removed
from the archive.
Also, and though we maintainers are supposed to do the right thing,
experience shows this is not always the case, so it's really best to
have library maintainers provide detailed explanations as of how to
proceed. From your mail [2], maintainers build-depending on
libjack0.80.0-0 will know that they have to change such B-D to
libjack0.100.0-dev, but there are not crystal clear instructions for
those build-depending on libjack-dev (honest!): though anybody reading
the mail would say, "s/libjack-dev/libjack0.100.0-dev/ in
debian/control", I'd bet money that some maintainer will upload with
debian/control unchanged "because libjack-dev is now provided by
libjack0.100.0-dev and buildds will install it". And then get the
package compiled against different -dev packages depending on the
architecture (more on architectures later). And as per the two stages
mentioned above, packages not directly build-depending on libjack*-dev
should get special handling as well, such as asking for rebuilds only
when build-depencencies are fixed in _all_ architectures, or providing
info about what versioned build-dependencies to use.
Ah, architectures... I think it's been a really bad idea to start this
transition without waiting for the package to have built successfully
in all our arches. At the time being, ia64 and s390 have already
failed to build jack-audio-connection-kit 0.100.0-2 (not the fault of
your package, though), which means that each upload of depending
packages will fail on those arches and buildd admins have to requeue
by hand.
And finally, this is IMHO a sufficiently big transition that
debian-release should have been contacted in advance, for guidance and
advice too. Perhaps the answer would have been "Sure, go ahead right
now", but it could also have been "We're sorting out the bits for the
C++ transition, let's hold this a few weeks, ok? Sorry for the
inconvenience." Or even (this is not your case, and I'm only
mentioning as a worst-case scenario): "Dude, you just f*cked up our
timeline for the C++ transition".
* * *
LIST OF PACKAGES
Guenter Geiger (Debian/GNU) <geiger@debian.org>
hydrogen
jack-rack
ladcca
libjackasyn
meterbridge
puredata
qjackctl
rezound
seq24
snd
sooperlooper
stk
swami
Enrique Robledo Arnuncio <era@debian.org>
freqtweak
rosegarden4
tapiir
Paul Brossier <piem@altern.org>
supercollider
xmms-jackasyn
Eric Van Buggenhaut <ericvb@debian.org>
fluidsynth
Ben Burton <bab@debian.org>
kdeaddons
koffice
Chris Butler <chrisb@debian.org>
spiralsynthmodular
Hubert Chan <hubert@uhoreg.ca>
alsaplayer
Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
arts
kdeartwork
kdebase
kdelibs
kdemultimedia
kdenetwork
Free Ekanayaka <free@agnula.org>
ams
brutefir
creox
horgand
jackeq
Free Ekanayaka <free@centrotemporeale.it>
amsynth
Mike Furr <mfurr@debian.org>
terminatorx
xmms-jack
Henrique de Moraes Holschuh <hmh@debian.org>
timidity
Robert Jordens <jordens@debian.org>
ardour
bitscope
jack-audio-connection-kit
jack-tools
jamin
timemachine
Jean-Michel Kelbert <kelbert@debian.org>
k3b
Daniel Kobras <kobras@debian.org>
muse
Joshua Kwan <joshk@triplehelix.org>
thinksynth
Wesley J. Landaker <wjl@icecavern.net>
cheesetracker
David I. Lehn <dlehn@debian.org>
gst-plugins0.8
Eduardo Marcel Macan <macan@debian.org>
specimen
zynaddsubfx
Debian ALSA Maintainers <pkg-alsa-devel@lists.alioth.debian.org>
alsa-lib
alsa-plugins
Samuel Mimram <smimram@debian.org>
linphone
Tommaso Moroni <moronito@debian.org>
knights
Sam Hocevar (Debian packages) <sam+deb@zoy.org>
allegro4.1
Nick Rusnov <nickrusnov@debian.org>
galan
Jose Luis Tallon <jltallon@adv-solutions.net>
basket
Junichi Uekawa <dancer@debian.org>
ecamegapedal
ecasound
ecasound2.2
ecawave
soundtracker
Ove Kaaven <ovek@arcticnet.no>
wine
* * *
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Let us not be ashamed to speak what we shame not to think.
-- Michel de Montaigne
Reply to: