Bugs to target for 2.0.54
Not to target.. Bugs that are fixed.
I suggest the following bugs for this release: Bug 100478, Bug 109961, Bug 110443. Those should be easily doable. This one could prove a little trickier: Bug 1343
(In reply to comment #2) > I suggest the following bugs for this release: > Bug 100478, Bug 109961, Bug 110443. None of these bugs have fixes in ~arch (2.1_preX) yet. > Those should be easily doable. This one could prove a little trickier: > Bug 1343 This one will never make it into a 2.0 release because it requires way too many changes. It may or may not make it into 2.1 either. Whichever series it does get into, it won't be backported due to its complexity. I've put 2.0.54 into CVS with ~arch keywords. There's only two changes beyond what's in 2.0.53. The first is that repoman virtuals-related errors have been dropped down to warnings as they are no longer strictly applicable. The second is that world atoms that have matching installed packages are considered valid regardless of whether it can be fulfilled by an unmasked package from PORTDIR or not. This is due to many complaints after 2.0.53 was stabled. (Why don't ~arch people have these issues?)
I would bet because people uses 'ACCEPT_KEYWORDS="~arch" emerge crap' ...
That's the main problem causer, yes. However, there has been at least one case of a valid usage. Install some-package-1.0 after which some-package-1.1 comes out and 1.0 is removed. However, some-package-1.0 is required for some-dev-machine and so the admin masks >=some-package-1.1.
[ebuild U ] sys-apps/portage-2.0.54 [2.0.53] -build +doc (-selinux) 229 kB *** Portage will stop merging at this point and reload itself, recalculate dependencies, and complete the merge. [ebuild N ] app-portage/portage-manpages-1.2 17 kB And when it's finished doing 2.0.54... --- !targe sym /usr/bin/emerge --- !targe sym /usr/bin/ebuild >>> Regenerating /etc/ld.so.cache... emerge: please tell me what to do. Usage: emerge [ options ] [ action ] [ ebuildfile | tbz2file | dependency ] [ ... ] emerge [ options ] [ action ] < system | world > emerge < --sync | --metadata | --info > emerge --resume [ --pretend | --ask | --skipfirst ] emerge --help [ system | config | sync ] Options: -[abcCdDefhikKlnNoOpPsSuUvV] [--oneshot] [--newuse] [--noconfmem] [--columns] [--nospinner] Actions: [ --clean | --depclean | --prune | --regen | --search | --unmerge ] Doesn't look happy to me...
Need more information than that. As I said, there are only two changes - neither of which could cause what you're describing. It looks like `emerge =portage-2.0.54; emerge` to me...
No, it's just a plain "emerge -u portage" that causes it, from 2.0.53 -> 2.0.54, on my sparc dev box and my mostly stable (new gnome) athlon box (via package.keywords). Everything else was up to date except the portage-manpages PDEP that was recently introduced. Oh, and i just reproduced it on my home amd64 box too. My best guess is something is working funky with upgrading and doing the PDEP, but then again you're supposed to be the experts. I can give you emerge --info from every box but i doubt that will help in any way.
(In reply to comment #8) > No, it's just a plain "emerge -u portage" that causes it, from 2.0.53 -> > 2.0.54 This bug exists in both 2.0.53 and 2.0.54. It was inadvertantly caused by the fix for bug 107865 which translates "emerge -u portage" to "emerge -u".
I'm getting the same as Gustavo. Cheers, Ferdy
(In reply to comment #6) > [ebuild U ] sys-apps/portage-2.0.54 [2.0.53] -build +doc (-selinux) 229 kB > *** Portage will stop merging at this point and reload itself, > recalculate dependencies, and complete the merge. > [ebuild N ] app-portage/portage-manpages-1.2 17 kB > > And when it's finished doing 2.0.54... > > --- !targe sym /usr/bin/emerge > --- !targe sym /usr/bin/ebuild > >>> Regenerating /etc/ld.so.cache... > emerge: please tell me what to do. bug 117988 filed
Neither of the two bugs I just removed are regressions in any way for this release and neither of them have been fixed in subversion nor released into ~arch at all meaning they are not candidates for a stable release. As for the issue with USE="doc" emerge -u portage, I've moved the portage-manpages dependency from PDEPEND to RDEPEND (where it should have been to begin with) which is what was triggering the bug. The bug, by the way, has existed since at least 2.0.50 and probably since portage started restarting itself after upgrading. I'm not very comfortable with a fix for it being pushed quickly into a stable release either...
And in case I wasn't clear (I'm generally not when I'm requesting something) this should mean that all issues are cleared up and stabling can happen if no other possible regressions have been picked up.
sparc stable, we're happy now.
x86 is done...
stable on ppc64
stable on amd64
Stable on ppc.
Stable on alpha.
Stable on hppa.
mips stable.
should be all set now
