1 |
On Monday 06 Jan 2014 21:35:41 Alan McKinnon wrote: |
2 |
> On 06/01/2014 19:58, »Q« wrote: |
3 |
|
4 |
> > I had exactly the same weirdness after 1.6.8 was stabilized. I waited |
5 |
> > a few hours, re-synced the tree, and then updated without any warnings |
6 |
> > about blocks; the old libpng was unmerged and 1.6.8 was merged |
7 |
> > automagically as one would expect. I don't know what caused the problem |
8 |
> > or what fixed it. |
9 |
> |
10 |
> Ah, that explains it. I last synced 3 days ago |
11 |
> |
12 |
> Obviously, updating libpng in the tree was a two stage process, with a |
13 |
> longer than expected delay between them. Or maybe a bug the dev didn't |
14 |
> anticipate showed up right away and needed fixing. You and fortitude |
15 |
> both sync'ed in this middle period and got hit by the bug. |
16 |
|
17 |
I'm having a similar problem on my local LAN server, an Atom box. I sync |
18 |
daily, and I've just synced again to make sure (31000 files, yet again, nearly |
19 |
all in metadata). |
20 |
|
21 |
The Atom's packages directory is NFS-mounted in a 32-bit chroot on my |
22 |
workstation, which does all the compiling work and then the Atom installs from |
23 |
packages. |
24 |
|
25 |
For several days I've been finding that the Atom box throws up the libpng error |
26 |
whereas the chroot doesn't want to upgrade anything. I've checked that |
27 |
/etc/portage/* is identical except for make.conf, which has to differ in proxy |
28 |
names, rsync hosts and a couple of other details. There's no ACCEPT_KEYWORDS |
29 |
entry in either make.conf. |
30 |
|
31 |
The packages that portage complains of are all at the same versions on the two |
32 |
boxes. |
33 |
|
34 |
I can't see a way out of this, other than forcing a libpng update on the atom. |
35 |
Any further thoughts anyone? I'm almost sure I'm overlooking something but in |
36 |
my present befuddled state I can't see what. |
37 |
|
38 |
-- |
39 |
Regards |
40 |
Peter |