[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: >2000 packages still waiting to enter testing, > 1500 over age



On Tue, Apr 15, 2003 at 08:42:40AM +0200, Sven Luther wrote:
> On Tue, Apr 15, 2003 at 12:31:44PM +1000, Paul Hampson wrote:
> 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.

This isn't a problem. When they're rebuilt for libvorbis0a, and then
become Valid Candidates, they get passed through to the main testing
script (which produces testing_output). Once everything that depends on
libvorbis0a is a Valid Candidate, then the Release Manager (I think...)
can add the hint to the testing script that it should try recur'ing
libvorbis. Until libvorbis is recur'd, it _can't_ go into testing
because it will always break things that depend on libvorbis0a, which
can't go in because they depend on libvorbis0a which isn't in the
archive.

The testing script is supposed to spot packages that need recurring
automatically, but from a brief code glance I think a hint needs to
be added (down the bottom) as to what should be considered.

> > 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).

You'd be surprised at the variances between architectures...

Just had a look, and libvorbis _is_ being recurred... Here's it's
output:
(Only i386, it's the worst affected... 80 packages broken)
* adonthell, adonthell-data, alsaplayer, alsaplayer-alsa,
* alsaplayer-common, alsaplayer-esd, alsaplayer-gtk, alsaplayer-nas,
* alsaplayer-oss, alsaplayer-text, amoeba, artsbuilder, audacity,
* bitcollider-plugins, brahms, cantus, chromium, chromium-data,
* clanlib-dev, clanlib-vorbis, crystalspace, crystalspace-data,
* crystalspace-demos, crystalspace-dev, easytag, fags, gcompris, gjay,
* gqmpeg, jack, jumpnbump, jumpnbump-levels, junior-sound, kde,
* kde-devel, kde-extras, kdebase-audiolibs, kdebase-dev,
* kdemultimedia-dev, kreatecd, libarts-mpeglib, libopenal-dev,
* libopenal0, libxine-dev, libxine0, mc-foo, mp32ogg, mp3blaster,
* mp3burn, mp3c, mp3kult, mpeglib, noatun, noatun-plugins, pingus,
* pingus-data, python-pyvorbis, race, ripperx, simplecdrx, sinek,
* soundgrab, sweep, sweep-dev, terminatorx, timidity, tuxpuck,
* vegastrike, vegastrike-data, vegastrike-music, vorbis-tools, vux,
* xine-ui, zinf, zinf-extras, zinf-plugin-alsa, zinf-plugin-esound

I expect what you did above was the list of source packages for
this list of broken packages...

apt-cache show `cat libv|sed 's/\*//g' | sed 's/,//g'` |grep Filename |sed 's!Filename: pool/[^/]*/[^/]/\(.*\)/[^/]*!\1!' | uniq

adonthell adonthell-data alsaplayer amoeba kdemultimedia audacity bitcollider
brahms cantus chromium chromium-data crystalspace crystalspace-data crystalspace
easytag fags gcompris gjay gqmpeg jack jumpnbump jumpnbump-levels junior-sound
meta-kde kdebase kdemultimedia kreatecd openal xine-lib mc-foo mp32ogg mp3blaster
mp3burn mp3c mp3kult kdemultimedia kdeaddons pingus pyvorbis race ripperx
simplecdrx sinek soundgrab sweep terminatorx timidity tuxpuck vegastrike
vegastrike-data vegastrike-music vorbis-tools vux xine-ui zinf

Hmm, on inspection, this is wrong. jumpnbump and jumpbnump-levels were
accepted under the recursion of libvorbis. So was jack... and mc-foo,
pyvorbis, simplecdrx, soundgrab, sweep, terminatorx, timidity, tuxpuck, 
vorbiss-tools... Weird.

Well, I guess it's possible, if libvorbis going in breaks those
packages, and the unstable version is also broken on a different
dependancy, then the installation doesn't make things worse and
it's acceptable, but the package ends up broken hence being on
the list. A second level of recursion would be needed to fix that,
if a library was found that was common enough to enough packages
that it could fall in cleanly.

I need to find out how recursion is chosen.... Naievely, I'd suggest
it recur any package that breaks more than 50 valid candidates on an
arch.

Anyway, now that I've done that... back to your actual interest:
ocaml is also being recurred:
i386: libpgsql-ocaml-dev, libsdl-ocaml, libsdl-ocaml-dev, ocaml-libs

From sources:
libpgsql-ocaml	<== Unstable version breaks with postgresql-dev
ocamlsdl		<== broken on m68k?
meta-ocaml		<== Unstable version breaks with something or
	breaks a single package when it fixes itself.

A problem here is that when a package hits that spot where it's
being installed in a recur'd loop, and it is accepted but still
not installable, the script doesn't tell you _what_ is still
breaking it. And the script can't tell the difference (at least
in the output) between this and a package that breaks a single
dependancy in all archs where it becomes installable.

Maybe it should handle broken packages staying broken in some
other way? Or at least report it differently? Give the data of
both an accept and a reject (Breakage counts and the list of
packages which make up the difference in the pre and post counts...
and some indicator why (if it's the case) this package stays
broken on being sarged.

-- 
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
6th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Anu.edu.au

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
-----------------------------------------------------------

Attachment: pgpzLtE5zowfK.pgp
Description: PGP signature


Reply to: