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:
pgpfNdIJal__a.pgp
Description: PGP signature