Re: [gentoo-user] Re: Confusion about slot conflict
On Wednesday 08 Jan 2014 12:31:52 I wrote: > I'm having a similar problem on my local LAN server, an Atom box. I sync > daily, and I've just synced again to make sure (31000 files, yet again, > nearly all in metadata). > > The Atom's packages directory is NFS-mounted in a 32-bit chroot on my > workstation, which does all the compiling work and then the Atom installs > from packages. > > For several days I've been finding that the Atom box throws up the libpng > error whereas the chroot doesn't want to upgrade anything. I've checked > that /etc/portage/* is identical except for make.conf, which has to differ > in proxy names, rsync hosts and a couple of other details. There's no > ACCEPT_KEYWORDS entry in either make.conf. > > The packages that portage complains of are all at the same versions on the > two boxes. > > I can't see a way out of this, other than forcing a libpng update on the > atom. Any further thoughts anyone? I'm almost sure I'm overlooking > something but in my present befuddled state I can't see what. Having tried many times to emerge -uaDvNK world on the Atom box and then separately emerging all the packages complained about, I finally got portage to come up with a set of packages to update - 637 of the total 645! While it's doing that (may be gone some time) I find that the /etc/portage directory on the Atom box had permissions root:root 0700. How that happened I've not the foggiest idea, but portage will have been unable to read any of the files in there. So, a word to the wise: beware rogues setting bad permissions. -- Regards Peter
Re: [gentoo-user] Re: Confusion about slot conflict
On Monday 06 Jan 2014 21:35:41 Alan McKinnon wrote: > On 06/01/2014 19:58, »Q« wrote: > > I had exactly the same weirdness after 1.6.8 was stabilized. I waited > > a few hours, re-synced the tree, and then updated without any warnings > > about blocks; the old libpng was unmerged and 1.6.8 was merged > > automagically as one would expect. I don't know what caused the problem > > or what fixed it. > > Ah, that explains it. I last synced 3 days ago > > Obviously, updating libpng in the tree was a two stage process, with a > longer than expected delay between them. Or maybe a bug the dev didn't > anticipate showed up right away and needed fixing. You and fortitude > both sync'ed in this middle period and got hit by the bug. I'm having a similar problem on my local LAN server, an Atom box. I sync daily, and I've just synced again to make sure (31000 files, yet again, nearly all in metadata). The Atom's packages directory is NFS-mounted in a 32-bit chroot on my workstation, which does all the compiling work and then the Atom installs from packages. For several days I've been finding that the Atom box throws up the libpng error whereas the chroot doesn't want to upgrade anything. I've checked that /etc/portage/* is identical except for make.conf, which has to differ in proxy names, rsync hosts and a couple of other details. There's no ACCEPT_KEYWORDS entry in either make.conf. The packages that portage complains of are all at the same versions on the two boxes. I can't see a way out of this, other than forcing a libpng update on the atom. Any further thoughts anyone? I'm almost sure I'm overlooking something but in my present befuddled state I can't see what. -- Regards Peter
Re: [gentoo-user] Re: Confusion about slot conflict
On 06/01/2014 19:58, »Q« wrote: > On Sun, 5 Jan 2014 15:57:10 + > 张东亚 wrote: > >> Hi list, >> >> When I do a world upgrade, I have encountered the following slot >> conflict: >> >> >> media-libs/libpng:0 >> >> (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by >> media-libs/libpng:0/0= required by >> (dev-python/wxpython-2.8.12.1-r1::gentoo, installed) >> >=media-libs/libpng-1.4:0/0= required by >> (net-libs/webkit-gtk-1.8.3-r201::gentoo, installed) >> media-libs/libpng:0/0= required by >> (app-text/poppler-0.22.5::gentoo, installed) >> media-libs/libpng:0/0= required by >> (media-libs/libwebp-0.3.1::gentoo, installed) >> media-libs/libpng:0/0= required by >> (net-print/cups-filters-1.0.36-r1::gentoo, installed) >> media-libs/libpng:0/0= required by >> (kde-base/kdelibs-4.11.4::gentoo, installed) >> >> (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) >> pulled in by (no parents that aren't satisfied by other packages in >> this slot) >> >> >> My question is, seems upgrade to libpng-1.6.8 will solve the >> conflict, why emerge cannot proceed this automatically? or there are >> some switches to controller this? >> >> Thanks a lot. > > I had exactly the same weirdness after 1.6.8 was stabilized. I waited > a few hours, re-synced the tree, and then updated without any warnings > about blocks; the old libpng was unmerged and 1.6.8 was merged > automagically as one would expect. I don't know what caused the problem > or what fixed it. Ah, that explains it. I last synced 3 days ago Obviously, updating libpng in the tree was a two stage process, with a longer than expected delay between them. Or maybe a bug the dev didn't anticipate showed up right away and needed fixing. You and fortitude both sync'ed in this middle period and got hit by the bug. It happens a lot actually :-) -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: Confusion about slot conflict
On Sun, 5 Jan 2014 15:57:10 + 张东亚 wrote: > Hi list, > > When I do a world upgrade, I have encountered the following slot > conflict: > > > media-libs/libpng:0 > > (media-libs/libpng-1.5.17-r1::gentoo, installed) pulled in by > media-libs/libpng:0/0= required by > (dev-python/wxpython-2.8.12.1-r1::gentoo, installed) > >=media-libs/libpng-1.4:0/0= required by > (net-libs/webkit-gtk-1.8.3-r201::gentoo, installed) > media-libs/libpng:0/0= required by > (app-text/poppler-0.22.5::gentoo, installed) > media-libs/libpng:0/0= required by > (media-libs/libwebp-0.3.1::gentoo, installed) > media-libs/libpng:0/0= required by > (net-print/cups-filters-1.0.36-r1::gentoo, installed) > media-libs/libpng:0/0= required by > (kde-base/kdelibs-4.11.4::gentoo, installed) > > (media-libs/libpng-1.6.8::gentoo, ebuild scheduled for merge) > pulled in by (no parents that aren't satisfied by other packages in > this slot) > > > My question is, seems upgrade to libpng-1.6.8 will solve the > conflict, why emerge cannot proceed this automatically? or there are > some switches to controller this? > > Thanks a lot. I had exactly the same weirdness after 1.6.8 was stabilized. I waited a few hours, re-synced the tree, and then updated without any warnings about blocks; the old libpng was unmerged and 1.6.8 was merged automagically as one would expect. I don't know what caused the problem or what fixed it.
