Re: Package xxx has broken dep on yyy: normal?
On Fri, 25 Feb 2005 17:16:57 -0800, Steve Langasek [EMAIL PROTECTED] wrote: That said, any package that is uninstallable in testing for such a long period of time almost certainly has an RC bug that should be filed. In the case of gpe-contacts, this is definitely so; the package currently in unstable cannot be built using sources in the archive (it depends on a library that currently awaits ftp-master NEW processing), so should not have been uploaded to main. Chances are that it was uploaded together with the library it depends on, relying on ftpmasters doing their work, as in processing new packages in reasonable time. Please note also, that currently there is no official statement that the NEW queue is frozen, and queries regarding the obviously stalled NEW queue are - as usual - ignored. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Package xxx has broken dep on yyy: normal?
On Sat, Feb 26, 2005 at 04:28:36PM +0100, Marc Haber wrote: On Fri, 25 Feb 2005 17:16:57 -0800, Steve Langasek [EMAIL PROTECTED] wrote: That said, any package that is uninstallable in testing for such a long period of time almost certainly has an RC bug that should be filed. In the case of gpe-contacts, this is definitely so; the package currently in unstable cannot be built using sources in the archive (it depends on a library that currently awaits ftp-master NEW processing), so should not have been uploaded to main. Chances are that it was uploaded together with the library it depends on, relying on ftpmasters doing their work, as in processing new packages in reasonable time. And if the new library package is rejected instead of being accepted? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Package xxx has broken dep on yyy: normal?
On Sat, 26 Feb 2005 11:15:30 -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Sat, Feb 26, 2005 at 04:28:36PM +0100, Marc Haber wrote: Chances are that it was uploaded together with the library it depends on, relying on ftpmasters doing their work, as in processing new packages in reasonable time. And if the new library package is rejected instead of being accepted? How often does that happen? For some reasons, I do still have hope and tend to take the optimistic approach. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Package xxx has broken dep on yyy: normal?
M Dan Jacobson [12]wondered about the broken dependencies he notices M every now and then. Colin Watson [13]answered that this is the M problem that the testing distribution is intended to solve. Goswin M Brederlow [14]explained that this is caused by strictly versioned M dependencies to binary-all packages. Well I like sid, but am not used to Package gpe-contacts has broken dep on libgpevtype0 Try to Re-Instate gpe-contacts lasting for days into weeks. Goswin's post implied that such problems should only last a day or two. How is it that such problems are allowed to persist for days into weeks? Isn't there a feedback mechanism to prevent developers making the archive unstable permanently unknowingly? A couple of days isn't so bad, but apparently users often have to remind developers what mess apt-get shows they have turned their dependencies into otherwise they are oblivious? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
On Sat, Feb 26, 2005 at 07:39:17AM +0800, Dan Jacobson wrote: M Dan Jacobson [12]wondered about the broken dependencies he notices M every now and then. Colin Watson [13]answered that this is the M problem that the testing distribution is intended to solve. Goswin M Brederlow [14]explained that this is caused by strictly versioned M dependencies to binary-all packages. Well I like sid, but am not used to Package gpe-contacts has broken dep on libgpevtype0 Try to Re-Instate gpe-contacts lasting for days into weeks. Get used to it, it happens. This is unstable, not testing; there are no safeguards to ensure that *any* given package in unstable is installable at all, and at any given moment there are lots of packages that are not installable. If you aren't willing to cope with this, then you do not like sid, you just refuse to understand that the issues you have a problem with are fundamental to unstable and are fundamentally *avoided* by using testing instead. That said, any package that is uninstallable in testing for such a long period of time almost certainly has an RC bug that should be filed. In the case of gpe-contacts, this is definitely so; the package currently in unstable cannot be built using sources in the archive (it depends on a library that currently awaits ftp-master NEW processing), so should not have been uploaded to main. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Package xxx has broken dep on yyy: normal?
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Dan Jacobson [EMAIL PROTECTED] writes: Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. So what? Then they don't have the bleading edge version of the package but their old non upgrade one. Big deal. I think the point is that dist-upgrade can sometimes do the Wrong Thing in cases like this. As sid user you are supposed to look what apt-get will do before letting it remove like 500 packages. No pitty for anyone doing that before leaving town. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
Dan Jacobson [EMAIL PROTECTED] writes: Upon apt-get, is it normal to every so often see Package xxx has broken dep on yyy? However the next day the problem is gone. Yes. If normal, then can't whatever intermediate stage not be split across the mirror push? Somehow can consistent versions of xxx and yyy either be made sure to go out this mirror run together, or both wait for the next run? No and yes. There are some packages with a strict version depend (=) between a arch:any and arch:all package. The maintainers upload will update the arch:all package to the new version while leaving most archs without the arch:any package. Some time after the upload the buildd will fill in the missing arch:any debs but not necessarily before the daily dinstall run. Those cases can't be avoided with the current DAK implementation but they should be. Patches are surely welcome. Other things are strict versioned depends between different source packages. Even with a coordinated upload of both source packages the buildds can (and will often) build them out of order so you see only one of them for a short while. But those cases should be uncommon and nothing can be done there. Thats just how unstable works. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
On Wed, 16 Feb 2005, Dan Jacobson wrote: Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. Unstable is definitely not for people who can't try again. Try this if you don't understand: awk 'NR = 258 NR = 278' /usr/share/common-licenses/GPL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
Dan Jacobson [EMAIL PROTECTED] writes: Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. I'm inclined to think that people should not do apt-get dist-upgrade on unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
Dan Jacobson [EMAIL PROTECTED] writes: Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. So what? Then they don't have the bleading edge version of the package but their old non upgrade one. Big deal. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
Goswin von Brederlow [EMAIL PROTECTED] writes: Dan Jacobson [EMAIL PROTECTED] writes: Well OK, but please be aware of the cases where a kid leaves his village for a trip to the big city and his single chance to do an apt-get dist-upgrade. He can't just try again tomorrow if things don't work out. So what? Then they don't have the bleading edge version of the package but their old non upgrade one. Big deal. I think the point is that dist-upgrade can sometimes do the Wrong Thing in cases like this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package xxx has broken dep on yyy: normal?
Upon apt-get, is it normal to every so often see Package xxx has broken dep on yyy? However the next day the problem is gone. If normal, then can't whatever intermediate stage not be split across the mirror push? Somehow can consistent versions of xxx and yyy either be made sure to go out this mirror run together, or both wait for the next run? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package xxx has broken dep on yyy: normal?
On Sun, Feb 13, 2005 at 02:54:26AM +0800, Dan Jacobson wrote: Upon apt-get, is it normal to every so often see Package xxx has broken dep on yyy? However the next day the problem is gone. If normal, then can't whatever intermediate stage not be split across the mirror push? Somehow can consistent versions of xxx and yyy either be made sure to go out this mirror run together, or both wait for the next run? That's the problem that the testing distribution is intended to solve. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
