1 |
On Thu, Apr 11, 2013 at 04:34:12PM -0400, W. Trevor King wrote: |
2 |
> On Thu, Apr 11, 2013 at 01:24:19PM -0700, Matt Turner wrote: |
3 |
> > So, to make sure that I'm on the same page: is the the problem that |
4 |
> > we're using stale packages in stage1 and if so, where did they come |
5 |
> > from? A previous stage1 build that didn't do update-seed? |
6 |
> |
7 |
> That's where mine (and presumably iamben's) came from. However, they |
8 |
> could also (I think) come from a stage1 build that used an older |
9 |
> snapshot. I'm testing now with a build from: |
10 |
> |
11 |
> subarch: i686 |
12 |
> version_stamp: 2013.1 |
13 |
> target: stage1 |
14 |
> rel_type: default |
15 |
> profile: default/linux/x86/13.0/desktop |
16 |
> portage_confdir: /var/tmp/catalyst/portage-conf/default/ |
17 |
> snapshot: 20130208 |
18 |
> source_subpath: default/stage3-i686-20121213 |
19 |
> update_seed: yes |
20 |
> |
21 |
> Followed by another build with the same version_stamp but using: |
22 |
> |
23 |
> snapshot: 20130308 |
24 |
> |
25 |
> The idea is that the first build might produce packages linking |
26 |
> libmpc.so.2, and the second build might reuse those packages, despite |
27 |
> the stabilization of mpc-1.0.1 in the tree. |
28 |
|
29 |
So I finished the build and I have a broken stage1 after the tree |
30 |
update (as I expected). Here's how it goes: |
31 |
|
32 |
Clear the caches: |
33 |
|
34 |
# rm -rf --one-file-system /tmp/*.log /var/tmp/catalyst/{kerncache,packages,tmp} |
35 |
|
36 |
Confirm the first spec (using the older tree) |
37 |
|
38 |
# cat /var/tmp/catalyst/spec/default-stage1-i686-test.1.spec |
39 |
subarch: i686 |
40 |
version_stamp: 2013.1 |
41 |
target: stage1 |
42 |
rel_type: default |
43 |
profile: default/linux/x86/13.0/desktop |
44 |
portage_confdir: /var/tmp/catalyst/portage-conf/default/ |
45 |
snapshot: 20130208 |
46 |
source_subpath: default/stage3-i686-20121213 |
47 |
update_seed: yes |
48 |
|
49 |
Build it: |
50 |
|
51 |
# python2.7 catalyst -c catalyst.conf -f /var/tmp/catalyst/spec/default-stage1-i686-test.1.spec 2>&1 | tee /tmp/stage1-i686-test.1.log |
52 |
… |
53 |
>>> Emerging (30 of 38) sys-devel/gcc-4.6.3 for /tmp/stage1root/ |
54 |
>>> Installing (30 of 38) sys-devel/gcc-4.6.3 to /tmp/stage1root/ |
55 |
… |
56 |
|
57 |
As expected, with a tree where mpc-0.8.2 is the latest stable version, |
58 |
we get dependencies on libmpc.so.2: |
59 |
|
60 |
# less /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 | grep libmpc |
61 |
0x00000001 (NEEDED) Shared library: [libmpc.so.2] |
62 |
# ls -l /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 |
63 |
-rwxr-xr-x 1 root root 10557140 Apr 11 21:24 /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 |
64 |
# less /var/tmp/catalyst/packages/default/stage1-i686-2013.1/sys-devel/gcc-4.6.3.tbz2 | grep '/cc1$' |
65 |
-rwxr-xr-x root/root 10557140 2013-04-11 21:24 ./usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 |
66 |
|
67 |
Let's shift that stage out of the way for safe keeping and build |
68 |
another with a new snapshot: |
69 |
|
70 |
# mv /var/tmp/catalyst/tmp/default/stage1-i686-{2013.1,test.1}/ |
71 |
# diff /var/tmp/catalyst/spec/default-stage1-i686-test.{1,2}.spec |
72 |
7c7 |
73 |
< snapshot: 20130208 |
74 |
--- |
75 |
> snapshot: 20130308 |
76 |
# python2.7 catalyst -c catalyst.conf -f /var/tmp/catalyst/spec/default-stage1-i686-test.2.spec 2>&1 | tee /tmp/stage1-i686-test.2.log |
77 |
… |
78 |
>>> Emerging binary (10 of 75) sys-devel/gcc-config-1.7.3 for /tmp/stage1root/ |
79 |
>>> Installing (10 of 75) sys-devel/gcc-config-1.7.3 to /tmp/stage1root/ |
80 |
… |
81 |
|
82 |
Looks like were using the out-of-date binary package. Let's check to |
83 |
see we're still linking against the old libmpc: |
84 |
|
85 |
# less /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 | grep libmpc |
86 |
0x00000001 (NEEDED) Shared library: [libmpc.so.2] |
87 |
# ls -l /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 |
88 |
-rwxr-xr-x 1 root root 10557140 Apr 11 21:24 /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1 |
89 |
|
90 |
Yup. And that mpc version isn't in the new stage1: |
91 |
|
92 |
# ls /var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/lib/libmpc.so* |
93 |
/var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/lib/libmpc.so |
94 |
/var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/lib/libmpc.so.3 |
95 |
/var/tmp/catalyst/tmp/default/stage1-i686-2013.1/tmp/stage1root/usr/lib/libmpc.so.3.0.0 |
96 |
|
97 |
So, while iamben (I think) and I (definitely) ran into this problem |
98 |
because we had just turned on update_seed (with out-of-date packeages |
99 |
from a non-update_seed run), this problem can also crop up due to |
100 |
snapshot updates (even if you always have update_seed on). That means |
101 |
that the only reasonable fixes are: |
102 |
|
103 |
a. Clear the package cache whenever you update a spec (without bumping |
104 |
version_stamp). |
105 |
b. Migrate the toolchain packages to EAPI5 and use ABI sub-slotting. |
106 |
|
107 |
Since (b), even if it does happen, is likely to take a while, I think |
108 |
we should be pushing (a) for now. |
109 |
|
110 |
Cheers, |
111 |
Trevor |
112 |
|
113 |
-- |
114 |
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). |
115 |
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |