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
