Re: Why doesn't libsidplay enter testing?
On Fri, Jul 04, 2003 at 10:05:59AM +0200, Gerfried Fuchs wrote: * Colin Watson [EMAIL PROTECTED] [2003-07-04 00:03]: Please stop saying rude things like Please check foo to the people who are trying to explain the state of play to you, because they are right: it has been like this for a long time. Sorry, I don't get it why you call it rude. It might be just me but I would have considered it rude if I told Anthony to RTF update_excuses. If you take what I wrote as rude then sorry, I didn't mean it that way. I even haven't thought that anyone would take a please check as rude anyway, and I still don't understand it why you might think so Dismissing people's concerns with a one-sentence reference to inapposite information is inherently rude. Know whereof you speak, or remain quiet. (Or, alternatively, crack wise. :) ) -- G. Branden Robinson| Debian GNU/Linux | // // // / / [EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ | pgp9gGcnESjbp.pgp Description: PGP signature
Re: Why doesn't libsidplay enter testing?
* Colin Watson [EMAIL PROTECTED] [2003-07-04 00:03]: On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote: Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. That doesn't happen for circular dependencies (i.e. cycles of packages that each depend on newer versions of each other than are in testing), the reason being that if they weren't considered valid candidates then such cycles could never get into testing at all. (Invalid candidates are completely ignored - they aren't eligible for hinting, even.) Oh, didn't know that part yet, thanks for the enlightenment. Please stop saying rude things like Please check foo to the people who are trying to explain the state of play to you, because they are right: it has been like this for a long time. Sorry, I don't get it why you call it rude. It might be just me but I would have considered it rude if I told Anthony to RTF update_excuses. If you take what I wrote as rude then sorry, I didn't mean it that way. I even haven't thought that anyone would take a please check as rude anyway, and I still don't understand it why you might think so And like Anthony's answer showed he hasn't taken it as rude neither, and even he thought it would happen to be written out in update_excuses. Upgrading either the foo source package alone or the libfoo source package alone renders foo uninstallable. Upgrading both simultaneously works. The latter requires manual action (or the occasional bit of guesswork by the testing scripts). It has always been this way. Yes, it has always been this way. Or rather not, for I don't see the need for manual action, it is documented that these cases are cought by the testing script since ages, and it worked without manual action for quite some time already (from what I can tell). I just like to know if there is really the need for manual action for such things every now and then (then this should be noted in the documentation and I consider it rather as a bug, for there is not much magic in this case, IMHO) or if there is something else behind this very case, which I don't grok yet. So long, Alfie [no, not meant rude; don't understand it as rude]
Re: Why doesn't libsidplay enter testing?
Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. I've written a little script that tries to answer precisely this type of question. You can run it here: http://bjorn.haxx.se/debian/ For libsidplay, it says: - Updating libsidplay makes 3 packages uninstallable on alpha: sidplay-base, xmms-sid, xsidplay - sidplay-base is waiting for libsidplay - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base - xmms-sid is waiting for libsidplay - Updating xmms-sid makes 1 packages uninstallable on alpha: xmms-sid - xsidplay is waiting for libsidplay - Updating xsidplay makes 1 packages uninstallable on alpha: xsidplay The packages are waiting for each other, so none of them can go in. It looks like a nudge by a maintainer is required. From the update_output it seems that alpha seems to have problems with the package Platforms are tested in alphabetical order, and only the first that breaks is displayed. That's why many packages are reported as uninstallable on alpha. Actually they are most likely uninstallable on many other platforms too, but only the result for alpha is displayed. -- Björn
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 11:37:06AM +0200, Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. It can (or at least it could a few days ago), it just needs a manual hint in update_out.py. I mentioned this to aj on 23 June. -- Colin Watson [EMAIL PROTECTED]
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 12:50:50PM +0200, Björn Stenberg wrote: Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. I've written a little script that tries to answer precisely this type of question. You can run it here: http://bjorn.haxx.se/debian/ Thanks for the great script. It shows me that the testing script seems to be buggy, because: - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? - Updating xmms-sid makes 1 packages uninstallable on alpha: xmms-sid - Updating xsidplay makes 1 packages uninstallable on alpha: xsidplay The packages are waiting for each other, so none of them can go in. It looks like a nudge by a maintainer is required. From the texting I would interpret this as they are waiting for _themselfes_, not for the others. What nudge by a maintainer are you talking about? Especially, which maintainer (testing-maintainer?) Platforms are tested in alphabetical order, and only the first that breaks is displayed. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? From what I understand the testing script should be able to see such circular dependencies -- but a dependency that breaks itself seems to be weird. Have fun, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Why doesn't libsidplay enter testing?
Gerfried Fuchs wrote: Thanks for the great script. It shows me that the testing script seems to be buggy, because: - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Because it breaks testing rule #5: The operation of installing the package into testing must not break any packages currently in testing. Updating sidplay-base alone breaks the current versions of xmms-sid and xsidplay. This is not allowed, and thus sidplay-base is uninstallable. The solution is to update all of the packages at once, which requires manual intervention. As Colin Watson said, this has already been mentioned to the maintainer so the packages should be going in soon. -- Björn
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 01:21:53PM +0200, Gerfried Fuchs wrote: On Thu, Jul 03, 2003 at 12:50:50PM +0200, Bj?rn Stenberg wrote: Gerfried Fuchs wrote: Yes, I've read the testing page with the FAQ and both the testing_excuses and testing_output, but I can't see the reason why libsidplay doesn't enter testing. I've written a little script that tries to answer precisely this type of question. You can run it here: http://bjorn.haxx.se/debian/ Thanks for the great script. It shows me that the testing script seems to be buggy, because: Not really. See my earlier mail. - Updating sidplay-base makes 1 packages uninstallable on alpha: sidplay-base Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? That should be obvious: if sidplay-base is upgraded *by itself* in testing, then it will itself be uninstallable in testing. (libsidplay needs to go in at the same time, and doing such simultaneous source package upgrades generally requires action by the RM or somebody else who can mess with update_out.py directly. This sort of thing happens when library package names change.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 06:03:38PM +0200, Björn Stenberg wrote: Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Because it breaks testing rule #5: The operation of installing the package into testing must not break any packages currently in testing. Please read the output again. It claims that the install of sidplay-base would render sidplay-base (e.g. _itself_) broken -- that is what I call nonsense for the broken rendered sidplay-base would be replaced, that's what it's all about. A package should never be able to render _itself_ broken. Updating sidplay-base alone breaks the current versions of xmms-sid and xsidplay. This is not allowed, and thus sidplay-base is uninstallable. Please read the documentation for the testing script again -- that should already be triggered by the script. Read the part in the FAQ about the real, non-trivial example. This is exactly that the example describes and what it claims to be able to do already. The solution is to update all of the packages at once, which requires manual intervention. I don't see why it would need manual intervention. Either the documentation is ahead of the script or it is wrong. It is claimed in the documentation for quite some time that this is handled automagically already and this is the whole purpose for why the packages are repeatedly mentioned in the update_output. So simply put: You don't know neither why they don't move to testing automatically like they should (and I'm quite sure that it already worked that way...). I still think that there must be a different problem here, or rather someone b0rked the script. I don't want to accuse anyone to have done it, I don't need anyone responsible for the brokeness, but I'm not sure if it's really b0rked or if there is something that I misunderstood So long, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Why doesn't libsidplay enter testing?
On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Easily. Example: Package: foo Version: 1.0.6-4 Depends: libc6 = 2.2.0 vs. Package: foo Version: 1.0.7-1 Depends: libc6 = 2.4.0 Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) What nudge by a maintainer are you talking about? Especially, which maintainer (testing-maintainer?) ftp master would be a better term. Probably Anthony Towns. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? No. From what I understand the testing script should be able to see such circular dependencies -- but a dependency that breaks itself seems to be weird. Circular dependencies are not handled well. I suppose the feel free to submit patches thing applies here.
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote: On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Easily. Example: Package: foo Version: 1.0.6-4 Depends: libc6 = 2.2.0 vs. Package: foo Version: 1.0.7-1 Depends: libc6 = 2.4.0 Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. Thanks, that explains a lot. But it still doesn't explain why the package holds back itself... Is this a bug in the testing script? No. What makes you so sure? If it is just a circular dependency problem like Björn said it should be caught already, like documented (and worked before). I never noticed before that a package seems to hold back itself though. So long, Alfie -- SILVER SERVER \\ \\ \ [EMAIL PROTECTED]www.sil.at keep your backbone tidy
Re: Why doesn't libsidplay enter testing?
On Thursday, Jul 3, 2003, at 13:58 US/Eastern, Gerfried Fuchs wrote: Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. Hmmm, you have a good point there. I think you can still pull the stunt off with some Conflicts: lines, though...
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 07:47:07PM +0200, Gerfried Fuchs wrote: On Thu, Jul 03, 2003 at 06:03:38PM +0200, Björn Stenberg wrote: Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Because it breaks testing rule #5: The operation of installing the package into testing must not break any packages currently in testing. Please read the output again. It claims that the install of sidplay-base would render sidplay-base (e.g. _itself_) broken -- that is what I call nonsense for the broken rendered sidplay-base would be replaced, that's what it's all about. A package should never be able to render _itself_ broken. This is precisely what would happen if this package was installed *into testing*. Trying to move sidplay-base into testing means that its dependencies would not be satisfied, and would therefore be broken. There are packages here that need to be moved together into testing, and that requires manual hinting. Updating sidplay-base alone breaks the current versions of xmms-sid and xsidplay. This is not allowed, and thus sidplay-base is uninstallable. Please read the documentation for the testing script again -- that should already be triggered by the script. Read the part in the FAQ about the real, non-trivial example. This is exactly that the example describes and what it claims to be able to do already. Well, if we trust the documentation... :) The fact is, testing is currently in such sorry shape that the daily job *cannot* test all combinations of packages that are waiting, without either OOM'ing the machine or wrapping past the 24-hour mark. This functionality is administratively disabled until such time as testing no longer looks like a holy mess. -- Steve Langasek postmodern programmer pgpPrHCSZyO1T.pgp Description: PGP signature
Re: Why doesn't libsidplay enter testing?
On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote: On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote: On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote: Uhm, that is somehow nonsense. How can an update of a package make itself uninstallable? What's the reasoning behind it? Easily. Example: Package: foo Version: 1.0.6-4 Depends: libc6 = 2.2.0 vs. Package: foo Version: 1.0.7-1 Depends: libc6 = 2.4.0 Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable (becasue there is no glibc-2.4.0 in testing) Please check the update_excuses, it would make package foo _not_ a valid candidate, if that happens. That doesn't happen for circular dependencies (i.e. cycles of packages that each depend on newer versions of each other than are in testing), the reason being that if they weren't considered valid candidates then such cycles could never get into testing at all. (Invalid candidates are completely ignored - they aren't eligible for hinting, even.) Please stop saying rude things like Please check foo to the people who are trying to explain the state of play to you, because they are right: it has been like this for a long time. Example: testing: foo source package = binary foo (1.0) Depends: libfoo0 (= 1.0) libfoo source package = binary libfoo0 (1.0) unstable: foo source package = foo (1.1) Depends: libfoo1 (= 1.1) libfoo source package = libfoo1 (1.1) Upgrading either the foo source package alone or the libfoo source package alone renders foo uninstallable. Upgrading both simultaneously works. The latter requires manual action (or the occasional bit of guesswork by the testing scripts). It has always been this way. Cheers, -- Colin Watson [EMAIL PROTECTED]
