Re: Which packages will hold up the release?
On Wed, Oct 08, 2003 at 10:04:38PM -0500, Steve Langasek wrote: Note that the testing scripts themselves do not examine Build-Depends today; such problems are only identified through manually filed RC bug reports. Which is not to say that we shouldn't be tracking such problems -- just that they don't actually hold a package out of testing by default. I would really like to know who I need to bribe in order to get this to happen. I do not have a useful development environment at this time due to my living situation, so unfortunately I cannot apply myself to thisk task directly. It is critical that we be able to at least satisfy build-dependencies within a release, as a step toward guaranteeing buildability of packages within a release. This is important for prompt security updates, license compliance and other good things. -- - mdz
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: /* You might ignore this comment... Looking at the list of RC bugs the packages seems to fall in two categories. Packages I don't use and packages I don't feel comfortable in touching (glibc being an example of the latter). Have you tried popbugs, in the debian-goodies package? It aims to show you RC bugs in packages that you use. And then depencies and build-depancies for these packages is needed too. Has anyone tried to make such list of packages we can't release without and made a list of RC-bugs in excatly those packages? An approach like the above would produce an individualized list for each developer, and the intersection of these lists would end up being something like what you envision here. So if everyone fixes bugs in packages they use, the packages that they use don't get removed. -- - mdz
Re: Which packages will hold up the release?
Colin Watson wrote: In the first example, the fact that foo depends on bar while simultaneously conflicting with the version of bar in the suite you're looking at is the thing that's bad, because it means foo can't be installed. The second example is OK, even though foo and bar can't be installed simultaneously; in an ideal world we might check that one of them is Priority: extra, but there's a bit too much other stuff going on for this to be feasible right now. Thank you. These examples are a bit contrived, but there are certainly real cases in the archive. My script currently only finds one: - jpilot-backup depends on jpilot = 0.99.4-1 but testing has 0.99.2-2 - jpilot-backup conflicts with jpilot 0.99.4-1 but testing has 0.99.2-2 If you know of other cases, I'd appreciate a note so I can examine why my script doesn't find them. -- Björn
Re: Which packages will hold up the release?
On Sun, Oct 12, 2003 at 12:01:11AM +0200, Bj?rn Stenberg wrote: Steve Langasek wrote: Ok. BTW, are you taking into account the possibility of a package being uninstallable due to versioned Conflicts, and Conflicts between packages which otherwise satisfy a package's dependencies? I have now added versioned conflict scanning and also checking for packages which depend on versions older than the ones about to be installed. To make packages with these problems easier to find, there are two new lists: http://bjorn.haxx.se/debian/conflicts.html http://bjorn.haxx.se/debian/olddeps.html It is not obvious to me how (or if) I can recognize a bad versioned conflict from a good. For instance, lvm10 conflicts with lvm2 1.95.15-3 while the lvm2 version in testing is 1.95.15-1. Is this simply a case of lvm10 superseding lvm2, and nothing I should warn about? If so, how can I tell? What's bad is if a package, taken on its own, is uninstallable. It's not bad (from britney's point of view) if combinations of packages without direct dependency relationships between them are uninstallable. So, bad: Package: foo Version: 1.1 Depends: bar Conflicts: bar ( 2.0) Package: bar Version: 1.1 Not bad: Package: foo Version: 1.1 Conflicts: bar ( 2.0) Package: bar Version: 1.1 In the first example, the fact that foo depends on bar while simultaneously conflicting with the version of bar in the suite you're looking at is the thing that's bad, because it means foo can't be installed. The second example is OK, even though foo and bar can't be installed simultaneously; in an ideal world we might check that one of them is Priority: extra, but there's a bit too much other stuff going on for this to be feasible right now. These examples are a bit contrived, but there are certainly real cases in the archive. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Which packages will hold up the release?
There are some mathematical tools that might be useful in working with some of these issues (I know them from models of social networks). One can represent relations between packages as a matrix D. The rows and columns refer to packages, and the cell is 1 if a relation exists, otherwise 0. For example, D[i, j] is 1 if package i depends on package j. One can define a funny form of matrix multiplication, in which the result can only be 0 or 1. Let D2 = D^2 = D*D Ordinary matrix multiplication says D2[i, j] = sum_k D[i, k] * D[k, j] (using pseudo-TeX notation) The modified form is D2[i, j] = or_k D[i, k] * D[k, j] (in other words: 1 if any of the combinations is 1) equivalently this = max(1, sum_k D[i, k]* D[k, j]) So D captures all direct dependencies, and D^2 has all direct dependencies and indirect dependencies of length 2 (usually D2 includes all of D, i.e., all direct relations, but if D[i, i] is not 1 that may not be so). D^infinity will have a stable limit, and expresses *all* direct and indirect dependencies. Since Björn already has a list of all indirect dependencies, I'm not sure this contributes anything useful. However, one can map a variety of relations using this approach (depends on, conflicts with, is a substitute for are some obvious ones), and then there are various tools to look at all the relations together (they form an algebra), and there are tools for separating individual packages into similar clusters based on their patterns of relations. It's also easy to make statements using this notation. For example, if D represents depends on (directly or indirectly) and C conflicts with (direct or indirect), then we can say that if D or C 0 (or is element by element, 0 is a 0 matrix) a logically impossible set of relations has been specified (I think; even if it's substantively wrong I hope you get the flavor). I still have only a partial handle on all the substantive issues involved in releasing packages, but throw this out on the chance it might be useful. More generally, it may be that taking the perspective of the overall pattern of relations provides some value beyond looking at things strictly from the perspective of a single package. P.S. I'm not a Debian developer or a subscriber to this list, but followed it on the web. I've tried to fake my headers so it appears properly in the thread. I'm curious if there's a good way to do that.
Re: Which packages will hold up the release?
On Thu, Oct 09, 2003 at 11:37:22PM -0700, Ross Boylan wrote: There are some mathematical tools that might be useful in working with some of these issues (I know them from models of social networks). When you have a hammer everything looks like a nail. Since I do SQL for a living I'd put all the data in a SQL database and use a technique called a parts-explosion table (see SQL For Smarties by Joe Celko). It helps you express recursive relationships in SQL. It helps when parts contain parts contain parts contain parts... and you need to know all possible parts affected by a part. For datasets the size of the package database it'd be a piece of cake with PostGres.
Re: Which packages will hold up the release?
Steve Langasek wrote: Ok. BTW, are you taking into account the possibility of a package being uninstallable due to versioned Conflicts, and Conflicts between packages which otherwise satisfy a package's dependencies? No, not yet. I will look into it. -- Björn
Re: Which packages will hold up the release?
Steve Langasek wrote: The term metapackage is a gratuitous label, here. There is a real binary package (as opposed to a virtual package) in the archive named gcc, which comes from the gcc-defaults source package; and its versions are handled just like those of any other packages. Ah, silly me. I was only looking in the Sources files, completely forgetting the Packages files. Now there's a first test implementation in place. It reads the Depends and Build-Depends* fields and reports potential problems with those packages. I currently don't handle the arch-specific component of dependencies properly - those are simply stripped. Alternative packages are all checked, but there's a prefix alternative x/y: on each line to indicate this. Also, I only use the i386 Packages files so far. Does anyone have a policy-compliant version comparator in Perl that I can reuse? I'm slightly confused as to the exact meaning of 5.6.11. This means some version compares (such as xaw3dg's 1.5+E-1 vs 1.5-25) currently return wrong result in my script. Speaking of xaw3d, I found a discrepancy in versions that I don't understand. testing/main/source/Sources says xaw3d in testing is version 1.5+E-1, while testing/main/binary-i386/Packages says xaw3d in testing is version 1.5-25. How come the source and binary packages have different versions in testing? I would appreciate if some of you tested this and reported cases where you know there is a problem but my script doesn't report it. The results are suspiciously clean, but I haven't yet been able to pinpoint a case which is clearly wrong. The script will not say anything if it finds no problem, but you can use the show all dependencies link to see the checks done. The page for openoffice.org shows an example of the output: http://bjorn.haxx.se/debian/testing.pl?package=openoffice.org I intend to inhibit printout if one of alternative dependencies match, but currently all broken dependencies are displayed. -- Björn
Re: Which packages will hold up the release?
On Wed, Oct 08, 2003 at 01:54:13PM +0200, Björn Stenberg wrote: Does anyone have a policy-compliant version comparator in Perl that I can reuse? I'm slightly confused as to the exact meaning of 5.6.11. This means some version compares (such as xaw3dg's 1.5+E-1 vs 1.5-25) currently return wrong result in my script. Presumably you mean other than `dpkg --compare-versions`? -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp1ppn8XTIOH.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Wed, Oct 08, 2003 at 01:54:13PM +0200, Bj?rn Stenberg wrote: Does anyone have a policy-compliant version comparator in Perl that I can reuse? There's one in debbugs CVS, module source, Debbugs/Versions/Dpkg.pm, translated from dpkg's algorithm as of a couple of years ago. It doesn't do ~ yet (but then I don't think policy does either). Alternatively, you could use libapt-pkg-perl, but that's quite hard to get going on stable. Speaking of xaw3d, I found a discrepancy in versions that I don't understand. testing/main/source/Sources says xaw3d in testing is version 1.5+E-1, while testing/main/binary-i386/Packages says xaw3d in testing is version 1.5-25. How come the source and binary packages have different versions in testing? They don't - I think your mirror is out of date. Both source and binary are 1.5+E-4 in testing. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Which packages will hold up the release?
On Wed, Oct 08, 2003 at 01:54:13PM +0200, Björn Stenberg wrote: Steve Langasek wrote: The term metapackage is a gratuitous label, here. There is a real binary package (as opposed to a virtual package) in the archive named gcc, which comes from the gcc-defaults source package; and its versions are handled just like those of any other packages. Ah, silly me. I was only looking in the Sources files, completely forgetting the Packages files. Now there's a first test implementation in place. It reads the Depends and Build-Depends* fields and reports potential problems with those packages. Note that the testing scripts themselves do not examine Build-Depends today; such problems are only identified through manually filed RC bug reports. Which is not to say that we shouldn't be tracking such problems -- just that they don't actually hold a package out of testing by default. I currently don't handle the arch-specific component of dependencies properly - those are simply stripped. Alternative packages are all checked, but there's a prefix alternative x/y: on each line to indicate this. Also, I only use the i386 Packages files so far. Ok. BTW, are you taking into account the possibility of a package being uninstallable due to versioned Conflicts, and Conflicts between packages which otherwise satisfy a package's dependencies? I would appreciate if some of you tested this and reported cases where you know there is a problem but my script doesn't report it. Will start looking... Thanks for working on this. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Which packages will hold up the release?
Steve Langasek wrote: Hypothetical example: 29 packages wait on (151 packages are stalled by) libxml2. This package is too young, and should be a valid candidate in 8 days. Suppose that the libxml2 source package provided not only the libxml2-python2.3 binary package, but also a libxml2-python package that depended on python ( 2.3). If that were the case, then even after libxml2 became a valid candidate in its own right, it would still be held up by the python2.3 transition. Thank you. Some followup questions: 1) How are meta packages handled, such as libz-dev that libxml2 depends on. There is no package or binary with that name listed in Sources. 2) How is meta package versioning handled? The gcc-defaults package, version 1.9, is the only package providing the gcc binary (without -version suffix) of which many packages require version = 2.95. -- Björn
Re: Which packages will hold up the release?
On Tue, Oct 07, 2003 at 05:23:32PM +0200, Björn Stenberg wrote: Steve Langasek wrote: Hypothetical example: 29 packages wait on (151 packages are stalled by) libxml2. This package is too young, and should be a valid candidate in 8 days. Suppose that the libxml2 source package provided not only the libxml2-python2.3 binary package, but also a libxml2-python package that depended on python ( 2.3). If that were the case, then even after libxml2 became a valid candidate in its own right, it would still be held up by the python2.3 transition. Thank you. Some followup questions: 1) How are meta packages handled, such as libz-dev that libxml2 depends on. There is no package or binary with that name listed in Sources. The testing scripts (barring any bugs) check to make sure that a given candidate package would be *installable* on a system composed only of testing packages. This means that it treats virtual packages the same way that dpkg does on install: by looking for available packages that Provide: the needed virtual package. 2) How is meta package versioning handled? The gcc-defaults package, version 1.9, is the only package providing the gcc binary (without -version suffix) of which many packages require version = 2.95. The term metapackage is a gratuitous label, here. There is a real binary package (as opposed to a virtual package) in the archive named gcc, which comes from the gcc-defaults source package; and its versions are handled just like those of any other packages. -- Steve Langasek postmodern programmer pgpT0ooAD1hMH.pgp Description: PGP signature
Re: Which packages will hold up the release?
Björn Stenberg writes: 2) How is meta package versioning handled? The gcc-defaults package, version 1.9, is the only package providing the gcc binary (without -version suffix) of which many packages require version = 2.95. gcc-defaults implements it's own version handling. see the source.
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 08:41:07PM -0500, Steve Langasek wrote: On Thu, Oct 02, 2003 at 10:43:24PM +0200, Björn Stenberg wrote: The first sorts packages according to which package has the highest number of other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free. The second sorts packages according to which package stalls the greatest number of other packages, via dependencies in more than one level. Top-3: python2.3, libxml2 and libxslt. Yep, and libxml2 is also a dependency of libxslt. But of course, neither of these are packages that need direct attention; the one is held up waiting for the other, which is only waiting because it's too young. And, when libxml2 isn't too young, installing it into testing will break libxslt1-python2.2 in testing, so we'll need to upgrade to libxslt1-python2.3, which needs - you guessed it - python2.3. :) It's the related packages that need to be examined and put in order (by removals or NMUs), and there's no good way to figure out right now which packages those are, short of digging through the dependency tree (or running simulations). What he said. Top stalls are useful but they often really only point you at areas of work. -- Colin Watson [EMAIL PROTECTED]
Re: Which packages will hold up the release?
Hi *, Chris Halls wrote: On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote: We didn't have OpenOffice at last release and it doesn't seem to be in unstable yet. 'apt-cache search openoffice' only find myspell dictionaries. It's in contrib, package openoffice.org. It is scheduled to move into main around version 1.0.1-2. 1.1.0-2 of course :) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
Re: Which packages will hold up the release?
Steve Langasek wrote: Yes, I refer to these lists frequently. :) Thanks for putting these together! Thanks for using them. ;) Yep, and libxml2 is also a dependency of libxslt. But of course, neither of these are packages that need direct attention; the one is held up waiting for the other, which is only waiting because it's too young. It's the related packages that need to be examined and put in order (by removals or NMUs), and there's no good way to figure out right now which packages those are, short of digging through the dependency tree (or running simulations). I don't quite follow you here. What exactly would you like to see? Which packages are waiting for the libxslt/libxml2 knot to be untied? That's available here: http://bjorn.haxx.se/debian/testing.pl?waiting=libxml2 http://bjorn.haxx.se/debian/testing.pl?staller=libxml2 Well, if you want to write a script that can trawl the dependency graphs and identify work-needed packages within a cluster... :) Could you tell me in more detail what you mean? I'm not very experienced with the Debian release process, so I am not familiar with the nuances. I already trawl the dependency tree, what information would you like to distill from it? (I.e. define work-needed packages and cluster.) A hypothetical example would be good, to get me on the right track. (I'll be away for the weekend, so I can't respond until sunday.) -- Björn
Re: Which packages will hold up the release?
On Fri, Oct 03, 2003 at 02:59:21PM +0200, Björn Stenberg wrote: Yep, and libxml2 is also a dependency of libxslt. But of course, neither of these are packages that need direct attention; the one is held up waiting for the other, which is only waiting because it's too young. It's the related packages that need to be examined and put in order (by removals or NMUs), and there's no good way to figure out right now which packages those are, short of digging through the dependency tree (or running simulations). I don't quite follow you here. What exactly would you like to see? Which packages are waiting for the libxslt/libxml2 knot to be untied? That's available here: Not which ones are waiting, though that's useful information. What we need is to be able to find out what packages depend on things like python2.3, but are *not* in the list because they themselves are not valid candidates. Usually when you have a lot of packages waiting on a single package before they can move into testing, there's a hard (as opposed to soft) transition involved which requires lots of packages to all be ready for testing at once. Your pages don't really identify those other packages which will need to be worked on. Currently, that information is available in raw form from http://ftp-master.debian.org/testing/update_output.txt.gz if the package at the base of the dependency tree is a valid candidate, and there's no place to easily get that information if that package is *not* yet a valid candidate. What would be nice is for developers to easily find out what else *will be* a blocker, so that we don't have to repeat a 10+ day cycle for every package in the group that's buggy. And I say it would be nice. This would be a difficult script to write, and probably even more difficult to run due to the amount of information that has to be processed. Right now the best system we have for getting this information is human traversal of dependency graphs, plus some simulation scripts which (AIUI) let us examine clusters of interest on a case-by-case basis. This isn't great, but it's not horrible either. Well, if you want to write a script that can trawl the dependency graphs and identify work-needed packages within a cluster... :) Could you tell me in more detail what you mean? I'm not very experienced with the Debian release process, so I am not familiar with the nuances. I already trawl the dependency tree, what information would you like to distill from it? (I.e. define work-needed packages and cluster.) work-needed packages refers here to those packages which are not valid candidates for testing because they are themselves buggy (either they have open RC bugs against them, or they are uninstallable/unbuildable/out-of-date, which is typically an unfiled RC bug). cluster refers to a group of packages which are so tightly interrelated (due to versioned depends, library soname changes, etc.) that they must all move into testing at the same time. A hypothetical example would be good, to get me on the right track. Hypothetical example: 29 packages wait on (151 packages are stalled by) libxml2. This package is too young, and should be a valid candidate in 8 days. Suppose that the libxml2 source package provided not only the libxml2-python2.3 binary package, but also a libxml2-python package that depended on python ( 2.3). If that were the case, then even after libxml2 became a valid candidate in its own right, it would still be held up by the python2.3 transition. Cheers, -- Steve Langasek postmodern programmer pgpIg3Jv5N8q0.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: A script that reads packages I'm interested in and prints out the RC-bugs I should try to fix would be usable. Does anyone have such script? Yup. It's been posted before (it's called rc-alert). I've got a copy here; if you can't find it in the archives (recently, like 6 months) e-mail me and I'll send it to you. - Matt
Re: Which packages will hold up the release?
Hi! Am 2003-10-02 12:38 +0200 schrieb Peter Makholm: I don't know the reason for some packages being marked [REMOVE] but it seems to me that it is not just an 'This package is not essential for a releas an useful distribution'. OTOH, php4 is marked for removal. I assume that I'm not the only one that would classify it as important. In addition, it is odd that there are still packages depending on php4 which are not marked for removal. I did not dig into the reasons why php4 should be removed (BTS says see -release, but that doesn't tell me anything), so I don't object against it loudly. But I would certainly call it a pity if it disappears. It would make Debian much less useful for the average LAMP server. Maybe someone can enlighten me here? Thanks and have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Which packages will hold up the release?
Matthew Palmer [EMAIL PROTECTED] writes: On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: A script that reads packages I'm interested in and prints out the RC-bugs I should try to fix would be usable. Does anyone have such script? Yup. It's been posted before (it's called rc-alert). I've got a copy here; if you can't find it in the archives (recently, like 6 months) e-mail me and I'll send it to you. Found it. http://people.debian.org/~tbm/rc-alert http://people.debian.org/~tbm/wnpp-alert Of course it assumes that the packages I'm interested in are the same as the pacakges I have installed which isn't always true. But it is usable. -- Peter Makholm | Sit back and watch the messages. This is actually [EMAIL PROTECTED] | more important than one might think as there is a http://hacking.dk | bug in GNU Mach whereby hitting a key during the | boot process causes the kernel to panic |-- GNU Hurd Installation Guide
Re: Which packages will hold up the release?
Martin Pitt [EMAIL PROTECTED] writes:
I did not dig into the reasons why php4 should be removed (BTS says
see -release, but that doesn't tell me anything), so I don't object
against it loudly. But I would certainly call it a pity if it
disappears. It would make Debian much less useful for the average LAMP
server.
Maybe someone can enlighten me here?
Read
http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html
and
http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html
Marc
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,u(kcapnu ,nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa{gwmclBHIbus}gwmclBHI{yVGa09mbbus}yVGa09mb{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # mailto:[EMAIL PROTECTED]
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote: Am 2003-10-02 12:38 +0200 schrieb Peter Makholm: I don't know the reason for some packages being marked [REMOVE] but it seems to me that it is not just an 'This package is not essential for a releas an useful distribution'. OTOH, php4 is marked for removal. I assume that I'm not the only one that would classify it as important. In addition, it is odd that there are still packages depending on php4 which are not marked for removal. I did not dig into the reasons why php4 should be removed (BTS says see -release, but that doesn't tell me anything), Expand that to see the archives of the debian-release mailing list and you'll find useful information. (It was a temporary attempt at pulling php4 out of testing to unblock other stuff, which is due to be reverted.) so I don't object against it loudly. Good; in general you probably shouldn't interpret removals from testing as policy decisions at this point, although of course if there's something broken in a package being removed from testing then fixing it is always a good thing. -- Colin Watson [EMAIL PROTECTED]
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 02:06:27PM +0200, Martin Pitt wrote: Hi! Am 2003-10-02 12:38 +0200 schrieb Peter Makholm: I don't know the reason for some packages being marked [REMOVE] but it seems to me that it is not just an 'This package is not essential for a releas an useful distribution'. OTOH, php4 is marked for removal. I assume that I'm not the only one that would classify it as important. In addition, it is odd that there are still packages depending on php4 which are not marked for removal. I did not dig into the reasons why php4 should be removed (BTS says see -release, but that doesn't tell me anything), so I don't object against it loudly. But I would certainly call it a pity if it disappears. It would make Debian much less useful for the average LAMP server. Maybe someone can enlighten me here? The removal of php4 was proposed as temporary measure to help sorting the unstable - testing progression. The plan is that it gets back into testing before release. A quite usual trick. If a package A in testing blocks the entry of a package B from unstable to testing, and in turn the lack of B prevents the new version of A from unstable to testing, A is removed from testing for a moment. But it is welcomed to get into testing again afterward. That's at least what I understood from -release. The removal of php4 from testing (and not removal from unstable, which is the death penalty for the package you were afraid of) was discussed in http://lists.debian.org/debian-release/2003/debian-release-200308/msg00024.html (which explains the reference to -release in the bug repport) Now, glibc which were blocking the regular progression of php4 into testing is solved, IIRC. The current status is discussed in: http://lists.debian.org/debian-release/2003/debian-release-200309/msg00030.html http://lists.debian.org/cgi-bin/searchlists is your friend for more details. Thanks, Mt. -- I'm not griping, I'm just observing what a miserable experience this is. --- Calvin pgpIVg9vhQx3f.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 02:10:21PM +0200, Peter Makholm wrote: Matthew Palmer [EMAIL PROTECTED] writes: On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: A script that reads packages I'm interested in and prints out the RC-bugs I should try to fix would be usable. Does anyone have such script? Yup. It's been posted before (it's called rc-alert). I've got a copy here; if you can't find it in the archives (recently, like 6 months) e-mail me and I'll send it to you. Found it. http://people.debian.org/~tbm/rc-alert http://people.debian.org/~tbm/wnpp-alert Of course it assumes that the packages I'm interested in are the same as the pacakges I have installed which isn't always true. But it is usable. To make this assumption more accurate, you may play a bit with deborphan and debfoster. Bye, Mt. -- Le capitalisme, c'est l'exploitation de l'homme par l'homme. Le communisme, c'est le contraire. -- Coluche pgpbmnUAGZKxq.pgp Description: PGP signature
Re: Which packages will hold up the release?
[Matthew Palmer] Yup. It's been posted before (it's called rc-alert). I've got a copy here; if you can't find it in the archives (recently, like 6 months) e-mail me and I'll send it to you. And if you want to figure out why a valid package still fail to enter testing, you can use URL:http://bjorn.haxx.se/debian/testing.pl. I make a summary of the update_excuses file with links and annotations available from URL:http://developer.skolelinux.no/info/cdbygging/distdiff.html.gz and URL:http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz. You might find it interesting.
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: Looking at the list of RC bugs the packages seems to fall in two categories. Packages I don't use and packages I don't feel comfortable in touching (glibc being an example of the latter). Personally, I recommend getting over your fears. glibc's not actually all that tricky mostly, and even in the parts where it is, the maintainers will generally block any major stupidities from hitting the tree. Certainly I wouldn't recommend trying to NMU glibc, but diving into the source and working out how to fix bugs is certainly worthwhile. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgpUkUkG0d1Cn.pgp Description: PGP signature
Re: Which packages will hold up the release?
Hi, Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38: - Gnome - KDE I just wondered how far your understanding of these goes? Only the base environment, or also those applications that don't really belong to - for example - the official Gnome distribution, but are needed to make the computer useful. I am thinking here of evolution, one of the browsers (galeon or (better and) epiphany) and gnucash (which has a RC bug. help. help. :-)). Don't know much about KDE, but I guess there are also applications not belonging to the KDE, but still should go with it. Also, please include openoffice in this list. Your list certainly is right, but it seems to overlook the normal office application user (or the system administrator, that has to set up large quantities of boxes for the normal office application user), so I tried to be his advocate here. Of course, my additions still don't make the list complete. Maybe the right way to do this is not to look at all the packages that come to one's mind and think if they are very important, but to look at the different use cases that come to ones mind, and have a look at what they need. Some that I think if are the office worker, the web developer/master, the software developer (including the debian developer, a very important user group to debian :-)), the one with the responsibility for security, the designer, and so on. This might be the best way to check how good we are in our aim to be the universal OS. nomeata -- Joachim nomeata Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Which packages will hold up the release?
Am Do, den 02.10.2003 schrieb Joachim Breitner um 16:55: I just wondered how far your understanding of these goes? Uh. Please don't get it wrong, and consider the .de in my mail address. I am not at all saying that you don't understand something. Merely, I wonder what you _meant_ by this. The excuse is hidden somewhere in the German language, where you can ask how someone understands something and actually mean what do you mean by or how do you interpret. nomeata -- Joachim nomeata Breitner e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189 Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?+ V? PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+* h! z? Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Which packages will hold up the release?
Joachim Breitner [EMAIL PROTECTED] writes: Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38: - Gnome - KDE I just wondered how far your understanding of these goes? Only the base environment, or also those applications that don't really belong to - for example - the official Gnome distribution, but are needed to make I'm neither a Gnome nor a KDE user so I don't really know what it takes for us to have Gnome or KDE. I use some of the Gnome applications but not Gnome as such. The main point is that I don't think we can just drop anything outside base. People expect something of a general purpose distribution. Also, please include openoffice in this list. Your list certainly is I think you 'use cases' are right for where do we want to be but I'm not sure if they are appropriate for where can we expect to be at the upcomming release. We didn't have OpenOffice at last release and it doesn't seem to be in unstable yet. 'apt-cache search openoffice' only find myspell dictionaries. It would be nice to have but I don't count is as something people would expect from an general purpose distribution yet. -- Peter Makholm |We constantly have to keep in mind why natural [EMAIL PROTECTED] |languages are good at what they're good at. And to http://hacking.dk | never forget that Perl is a human language first, |and a computer language second
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote: We didn't have OpenOffice at last release and it doesn't seem to be in unstable yet. 'apt-cache search openoffice' only find myspell dictionaries. It's in contrib, package openoffice.org. It is scheduled to move into main around version 1.0.1-2. Chris pgpz19JGQzfCQ.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: There are some packages we should have if we want Debian to be a general purpose distribution. I guess we can have a long flamewar about which packages this includes and in the end it is the release manager's decission but it is probally something like: - whatever in the Base Utils-section - Gnome - KDE - nethack - apache - XFree - ssh - Mozilla (some sort of) - Emacs (some sort of) - VI (some sort of) - Perl - LaTeX - ... And then some pacakges I've forgot... And then depencies and build-depancies for these packages is needed too. Has anyone tried to make such list of packages we can't release without and made a list of RC-bugs in excatly those packages? Colin Watson recently posted an excellent analysis of the python2.3 transition to d-release and d-python, identifying areas requiring attention. I'm hoping to follow his lead soon with similar posts regarding other package groups requiring concerted attention to get into testing. Is this sort of thing of sufficient interest that it should be cross-posted to d-d? I believe this is the bugs it would be most effective to actack when the packages I'm personally directly interested in. It can be hard to look at the RC-list and decide if the time is better spend fixing libtse3, libvorbisfile3, or fam. A script that reads packages I'm interested in and prints out the RC-bugs I should try to fix would be usable. Does anyone have such script? What's hard to see at a glance is how large collections of packages are interrelated in their dependencies. Many packages that you *don't* use may be having a direct effect on the packages you *do* use as a result of their bugginess. I'd like to be able to make as much of this information as possible available to developers, so they can dig into some of the larger package knots according to their interests rather than it being exclusively the domain of the RM assistants. -- Steve Langasek postmodern programmer pgpdw6xHmRZJ1.pgp Description: PGP signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: I believe this is the bugs it would be most effective to actack when the packages I'm personally directly interested in. It can be hard to look at the RC-list and decide if the time is better spend fixing libtse3, libvorbisfile3, or fam. Ogg Vorbis is close to a release which is why almost all bugs related to it are marked pending. If they don't actually release soon I will be uploading cvs snapshots of all the related packages. The only thing holding them up at the moment is getting it to build properly on win32. Thanks, Chris signature.asc Description: Digital signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 07:12:52PM +0200, Peter Makholm wrote: Joachim Breitner [EMAIL PROTECTED] writes: Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38: - Gnome - KDE I just wondered how far your understanding of these goes? Only the base environment, or also those applications that don't really belong to - for example - the official Gnome distribution, but are needed to make I'm neither a Gnome nor a KDE user so I don't really know what it takes for us to have Gnome or KDE. I use some of the Gnome applications but not Gnome as such. The main point is that I don't think we can just drop anything outside base. People expect something of a general purpose distribution. Also, please include openoffice in this list. Your list certainly is I think you 'use cases' are right for where do we want to be but I'm not sure if they are appropriate for where can we expect to be at the upcomming release. Ultimately, the only real requirement for a package's inclusion in the release is that it be free of RC bugs. So we can expect to be exactly where people are willing to put in the work to get us. :) There will almost certainly be more packages dropped from testing (and not making it back in) between now and release, but such decisions are made rather dispassionately by the release team -- if someone cares enough to fix it, it stays in; if no one cares enough to fix it, it doesn't. -- Steve Langasek postmodern programmer pgpk77tOpzAHQ.pgp Description: PGP signature
Re: Which packages will hold up the release?
Steve Langasek wrote: What's hard to see at a glance is how large collections of packages are interrelated in their dependencies. Many packages that you *don't* use may be having a direct effect on the packages you *do* use as a result of their bugginess. I'd like to be able to make as much of this information as possible available to developers, so they can dig into some of the larger package knots according to their interests rather than it being exclusively the domain of the RM assistants. I'm interested in helping with this. My why is X not in testing yet script attempts to identify some hot spots, in the form of a few crude toplists: http://bjorn.haxx.se/debian/toplist.html http://bjorn.haxx.se/debian/stalls.html The first sorts packages according to which package has the highest number of other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free. The second sorts packages according to which package stalls the greatest number of other packages, via dependencies in more than one level. Top-3: python2.3, libxml2 and libxslt. I'd appreciate ideas and suggestions how to improve this and create other information digests that can help developers find and choose areas to work on. -- Björn
Re: Which packages will hold up the release?
Joachim Breitner wrote: - Gnome - KDE I just wondered how far your understanding of these goes? Only the base environment, or also those applications that don't really belong to - I think that the equivilant metapackages are a good first step. Pity that one of them has still not made it into testing, and this means that the desktop taks currently contains *only* kde. To look at it in another way, we had some complaints about it including both, but the last way I would have guessed those would be resolved was by the gnome developers recusing themselves from release as they seem to have done. [EMAIL PROTECTED]:~madison gnome gnome | 31 | unstable | all Also, please include openoffice in this list. Openoffice is still in the ghetto of contrib. As such it will not appear in either any tasks, or even in the default package lists for sarge, unless something changes RSN. -- see shy jo signature.asc Description: Digital signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 07:23:36PM -0400, Joey Hess wrote: Joachim Breitner wrote: - Gnome - KDE I just wondered how far your understanding of these goes? Only the base environment, or also those applications that don't really belong to - I think that the equivilant metapackages are a good first step. Pity that one of them has still not made it into testing, and this means that the desktop taks currently contains *only* kde. To look at it in another way, we had some complaints about it including both, but the last way I would have guessed those would be resolved was by the gnome developers recusing themselves from release as they seem to have done. Despite the fact that meta-gnome2 hasn't yet made it into testing, I think GNOME is so far in a *much* better state than KDE, actually. The guts of gnome-core, with one or two exceptions, are there; there are only a few more dependencies left for gnome. Once nautilus makes it, which I hope should be RSN, all it would take is somebody quickly deciding at some point that we can drop a few less-important dependencies from meta-gnome2 and that'll be it. By contrast, KDE is still KDE 2 in testing, which in good conscience I don't think we can release with. I'm hoping this can change soon, and my impression is that the situation is beginning to improve. -- Colin Watson [EMAIL PROTECTED]
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 10:43:24PM +0200, Björn Stenberg wrote: Steve Langasek wrote: What's hard to see at a glance is how large collections of packages are interrelated in their dependencies. Many packages that you *don't* use may be having a direct effect on the packages you *do* use as a result of their bugginess. I'd like to be able to make as much of this information as possible available to developers, so they can dig into some of the larger package knots according to their interests rather than it being exclusively the domain of the RM assistants. I'm interested in helping with this. My why is X not in testing yet script attempts to identify some hot spots, in the form of a few crude toplists: http://bjorn.haxx.se/debian/toplist.html http://bjorn.haxx.se/debian/stalls.html Yes, I refer to these lists frequently. :) Thanks for putting these together! The first sorts packages according to which package has the highest number of other packages directly depend on it. Top-3: python2.3, kdelibs, qt-x11-free. The second sorts packages according to which package stalls the greatest number of other packages, via dependencies in more than one level. Top-3: python2.3, libxml2 and libxslt. Yep, and libxml2 is also a dependency of libxslt. But of course, neither of these are packages that need direct attention; the one is held up waiting for the other, which is only waiting because it's too young. It's the related packages that need to be examined and put in order (by removals or NMUs), and there's no good way to figure out right now which packages those are, short of digging through the dependency tree (or running simulations). I'd appreciate ideas and suggestions how to improve this and create other information digests that can help developers find and choose areas to work on. Well, if you want to write a script that can trawl the dependency graphs and identify work-needed packages within a cluster... :) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
