From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 50D2C138247 for ; Wed, 8 Jan 2014 12:32:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8031CE0C51; Wed, 8 Jan 2014 12:31:55 +0000 (UTC) Received: from smarthost01c.mail.zen.net.uk (smarthost01c.mail.zen.net.uk [212.23.1.5]) by pigeon.gentoo.org (Postfix) with ESMTP id 5CF71E0BEA for ; Wed, 8 Jan 2014 12:31:54 +0000 (UTC) Received: from [82.69.80.10] (helo=wstn.localnet) by smarthost01c.mail.zen.net.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1W0sIb-0009Mn-J6 for gentoo-user@lists.gentoo.org; Wed, 08 Jan 2014 12:31:53 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Confusion about slot conflict Date: Wed, 08 Jan 2014 12:31:52 +0000 Message-ID: <1431205.NJSxqFsAsX@wstn> Organization: at home User-Agent: KMail/4.11.2 (Linux/3.10.25-gentoo; KDE/4.11.2; x86_64; ; ) In-Reply-To: <52CB058D.2040301@gmail.com> References: <20140106115846.09d61679@fuchsia> <52CB058D.2040301@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Originating-smarthost01c-IP: [82.69.80.10] X-Archives-Salt: 5a372967-5d23-435a-9a65-17387e60cf58 X-Archives-Hash: 36520c7c749c8baff84e8b640ef3864e On Monday 06 Jan 2014 21:35:41 Alan McKinnon wrote: > On 06/01/2014 19:58, =BBQ=AB wrote: > > I had exactly the same weirdness after 1.6.8 was stabilized. I wai= ted > > a few hours, re-synced the tree, and then updated without any warni= ngs > > 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 pr= oblem > > or what fixed it. >=20 > Ah, that explains it. I last synced 3 days ago >=20 > 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 syn= c=20 daily, and I've just synced again to make sure (31000 files, yet again,= nearly=20 all in metadata). The Atom's packages directory is NFS-mounted in a 32-bit chroot on my=20= workstation, which does all the compiling work and then the Atom instal= ls from=20 packages. For several days I've been finding that the Atom box throws up the libp= ng error=20 whereas the chroot doesn't want to upgrade anything. I've checked that=20= /etc/portage/* is identical except for make.conf, which has to differ i= n proxy=20 names, rsync hosts and a couple of other details. There's no ACCEPT_KEY= WORDS=20 entry in either make.conf. The packages that portage complains of are all at the same versions on = the two=20 boxes. I can't see a way out of this, other than forcing a libpng update on th= e atom.=20 Any further thoughts anyone? I'm almost sure I'm overlooking something = but in=20 my present befuddled state I can't see what. --=20 Regards Peter