Re: >2000 packages still waiting to enter testing, > 1500 over age
On Tue, Apr 15, 2003 at 12:31:44PM +1000, Paul Hampson wrote:
> On Wed, Apr 09, 2003 at 08:30:42PM +0200, Sven Luther wrote:
> > On Wed, Apr 09, 2003 at 05:59:26PM +0200, Michael Banck wrote:
> > > On Wed, Apr 09, 2003 at 04:40:31PM +0200, Sven Luther wrote:
> > > > depth, i cannot help all that much about it, and libvorbis is a valid
> > > > candidate, but his installation would break 107 or so packages in
> > > > testing, and i have not really the intention to check by hand all those
> > > > 107 packages. I believe it is just some packages that need to be rebuilt
> > > > due to the libvorbis0a thingy, not sure though. I already checked the
> > > > primary dependencies of all our packages (around 40) by hand, which
> > >
> > > apt-cache showpkg libvorbis0 prints out just a couple of packages. Is
> >
> > You have to look at the update_output.txt file, it shows :
> >
> > * alpha: adonthell, alsaplayer, alsaplayer-alsa, alsaplayer-common,
> > * alsaplayer-esd, alsaplayer-gtk, alsaplayer-nas, alsaplayer-oss,
> > * alsaplayer-text, amoeba, artsbuilder, audacity, bitcollider-plugins,
> > * black-box, brahms, bugsquish, bumprace, cantus, castle-combat, chromium,
> > * circuslinux, clanlib-dev, clanlib-vorbis, crimson, criticalmass, csmash,
> > * defendguin, easytag, enigma, fags, frozen-bubble, gcompris, gemdropx,
> > * gjay, gl-117, gltron, gqmpeg, gtoaster, heroes-sdl, icebreaker, jack,
> > * jumpnbump, kdebase-audiolibs, kdebase-dev, kdemultimedia-dev, kreatecd,
> > * langband-zterm, lbreakout2, lgeneral, libarts-mpeglib, libopenal-dev,
> > * libopenal0, libsdl-mixer1.2, libsdl-mixer1.2-dev, libsdl-ocaml,
> > * libsdl-ocaml-dev, libsdl-perl, libsdl-ruby, libxine-dev, libxine0,
> > * ltris, madbomber, mangoquest, mirrormagic, moon-lander, mp3blaster,
> > * mp3c, mp3kult, mpeglib, noatun, noatun-plugins, penguin-command, prboom,
> > * pygame, python-pyvorbis, race, ripperx, rockdodger, rocks-n-diamonds,
> > * saytime, simplecdrx, sinek, sox, sox-dev, sweep, terminatorx, timidity,
> > * toppler, tuxpaint, tuxpuck, tuxracer, tuxtype, vectoroids, vegastrike,
> > * vorbis-tools, vorbisgain, vsound, xine-ui, zinf, zinf-extras,
> > * zinf-plugin-alsa, zinf-plugin-esound
>
> Is this with libvorbis being 'recur'd by the testing script? If I read
> the documentation correctly, then:
> libvorbis will be rejected because it breaks everything that depends on
> libvorbis0.
> Everything that now depends on libvorbis0a will be rejected because
> their dependancies cannot be met...
Ok, i have a partialy more detailed list, all done by hand :
* adonthell : hppa
* alsaplayer : Valid Candidate.
* amoeba : arm, sparc built ok, but package disapeared.
* kdemultimedia : 4 RC bugs, out of date on s390.
* audacity : 1 RC bug, out of date on hppa and powerpc.
* bitcollider : OK.
* black-box : Valid Candidate.
* brahms : Only 3/10, alpha, arm, hppa, m68k, s390, kdemultimedia.
* bugsquish : OK.
* bumprace : OK.
* cantus : Calid Candidate.
* castle-combat : Only 0/10.
* chromium : 1 RC bug, out of date on arm.
* circuslinux : OK.
* clanlib : 3 RC bugs, need a rebuild, libdirectfb & libvorbis dependant.
* crimson : m68k.
* criticalmass : mips/mipsel.
* csmash : Valid Candidate.
* defendgui : OK.
* easytag : 1RC bug, ia64.
* enigma : Valid Candidate.
* fags : 3 of 10 days.
* frozen-bubble : alpha, arm, m68k.
* gcompris : 2 RC bugs.
* gemdropx : OK.
* gjay, gl-117, gltron, gqmpeg, gtoaster, heroes-sdl, icebreaker, jack,
* jumpnbump, kdebase-audiolibs, kdebase-dev, kdemultimedia-dev, kreatecd,
* langband-zterm, lbreakout2, lgeneral, libarts-mpeglib, libopenal-dev,
* libopenal0, libsdl-mixer1.2, libsdl-mixer1.2-dev, libsdl-ocaml,
* libsdl-ocaml-dev, libsdl-perl, libsdl-ruby, libxine-dev, libxine0,
* ltris, madbomber, mangoquest, mirrormagic, moon-lander, mp3blaster,
* mp3c, mp3kult, mpeglib, noatun, noatun-plugins, penguin-command, prboom,
* pygame, python-pyvorbis, race, ripperx, rockdodger, rocks-n-diamonds,
* saytime, simplecdrx, sinek, sox, sox-dev, sweep, terminatorx, timidity,
* toppler, tuxpaint, tuxpuck, tuxracer, tuxtype, vectoroids, vegastrike,
* vorbit-tools : Valid Candidate.
* vorbisgain : Valid Candidate.
* vsound : OK.
* xine-ui : 4 RC bugs, arm, m68k, mips, mipsel, s390
* zinf : 1 RC bug, alpha and hppa.
The problem is that the version of let's say xine-ui in testing is
dependent on libvorbis0, which is not available in the unstable package,
and thus you need a new version of xine-ui to be able to enter testing
which depend on libvorbis0a. In turn the xine-ui could be dependant on
other package, which in turn are not able to enter testing, and thus
holding up the packages.
As an example, we have around 40 or so ocaml packages, which are all
ready to enter testing (because we were holding a mini-freeze these past
month, and actively hunting and working on bugs and build issues), but
this is all work for nothing, since we are hold up by postgresql and
libvorbis, which we don't really use apart from two small binding
libraries. The postgresql seem to be in good way of being solved, but
will in turn be hold back by python and perl, if i read the dependency
graph correctly.
I see only three ways that this can get handled :
1) We hold a real freeze, and actively hunt bug, rebuild problematic
packages and such.
2) We remove the packages holding up the testing migration. Not
automatically and in a huge way, but as a concerted and case by case
effort to balance the removed packages from the ones entering testing.
The removed packages will enter testing again once they are ready.
3) We do a bit of testing-update rebuilding. I don't know if this is
really easily feasible today, but it would be nice solution, a bit
similar with the two level unstable that some spoke of. The idea is to
have a small pool, which consist of libvorbis and all the packages in
testing that would get broken by it. Then you rebuild all these
packages with testing + libvorbis. Once everything is built, it will
enter testing, and the huge amount of packages will not be hold back
by one or the other libraries, possibly for long times, as wad the
case with libc6.
Well, maybe a separate pooling mechanish for library or more exactly
hugely depended upon packages would be a nice solution. Wasn't is
exactly that what was discussed back then when we spoke about pools ?
> I guess someone has to add a hint to the testing script to recur over
> libvorbis and see if upgrading it would mean less breakage than
> currently exists... Which is probably true if all the packages which
> depend on it are "valid candidates".
Hardly, there are many RC bugs or FTBFS bugs in those. I think the main
issue is that the PTS does not show the list of packages holding up. IT
is not as easy, since there may be more than one possible update path,
but still everything would be better than what we have now. I have been
trying to make a little program that would parse the update_output and
update_excuses as well as the testing/unstable package list and generate
more info, but i have been hold back by the fact that the update_output
is really not all that informative and easy to parse. I guess i could
modify the testing script, but i don't (yet) speak python, and it is not
even sure that my changes will be accepted. The idea is that since the
testing scripts have all the needed information, they would much
easilier be able to output this data in a usable format. But then, all
my attempts at communication about this have been meet by silence, as
usual.
Also, notice that most of the packages that are valid candidate are only
such because they were not rebuilt since the libvorbis0a change, any
modification of them will break them also.
> If libvorbis is 'recur'd unsuccessfully, then you'll get a complete list
> of the packages in testing which would be broken by libvorbis and which
> can't be updated to a version that depends on libvorbis0a. On _all_
> arches, not just one.
Well, that is not a problem, most of these packages list one arch, but
the result would be the same for all arches. The real problem is to be
able to identify those packages easily, with a link from the PTS to the
corresponding pts package, and maybe a hint at what is the reason/status
of the package (RC bugs, valid candidate, build problems, time delay,
dependencies).
Friendly,
Sven Luther
Reply to: