1 |
On Tue, Oct 26, 2010 at 2:11 PM, Peter Stuge <peter@×××××.se> wrote: |
2 |
|
3 |
> Daniel van Ham Colchete wrote: |
4 |
> > And this is the build log: http://pastebin.com/Em8fyRyT |
5 |
> > This is my stage 1, 2 and 3 files: http://pastebin.com/bkcuGaP7 |
6 |
> |
7 |
> Which version of perl is in the 20101019 stage3? |
8 |
> |
9 |
> 5.8.8 |
10 |
|
11 |
|
12 |
> |
13 |
> > Tie/Hash.pm is available on my old Perl 5.8.8 installation but it |
14 |
> > doesn't appear to be on Perl 5.12.2. |
15 |
> |
16 |
> I've done similar as you, but I tried to take a shortcut and build |
17 |
> stage4 directly from today's stage3. |
18 |
> |
19 |
> For the most psrt it works fine, but especially with perl modules |
20 |
> there's a twist. |
21 |
> |
22 |
> Portage doesn't know which version of perl that the installed modules |
23 |
> were built against, and even if a module was built against an older |
24 |
> perl, the dependency on that module is still satisfied, even if perl |
25 |
> has been upgraded so that the module cannot be found. |
26 |
> |
27 |
> This happened to me when today's stage3 had one version of perl, and |
28 |
> a newer one was in my stage4. |
29 |
> |
30 |
> Rather than doing the correct thing and build my own stage3 like you, |
31 |
> I just hacked around it by calling perl-cleaner --allmodules in |
32 |
> /usr/lib64/catalyst/targets/stage4/stage4-chroot.sh which is kinda |
33 |
> ugly but does work. |
34 |
> |
35 |
|
36 |
The problem is that Tie/Hash.pm is a built in module. When the stage1 |
37 |
installs Perl 5.12.2 the Tie/Hash.pm is not going to /usr/lib/perl/5.12.2 |
38 |
even though Perl 5.8.8 is not installed on /tmp/stage1root. I`m pretty much |
39 |
sure this is a bug with the recently stabilized new Perl 5.12.2 ebuild. |
40 |
|
41 |
|
42 |
|
43 |
> |
44 |
> |
45 |
> > So, when building a new stage3 Perl 5.8.8 is not getting there and |
46 |
> > I think this is the cause of the problem. |
47 |
> |
48 |
> Again, which version is in your stage3? |
49 |
> |
50 |
> |
51 |
> > The stage1 build failed as well, but when I did a |
52 |
> > catalyst -a -f stage1.spec after the failure, the build finished |
53 |
> > correctly, so I didn`t want to search for the root cause. |
54 |
> |
55 |
> Leaving unexplained errors is always risky, and can definately come |
56 |
> back to bite you later. Do you at least recall how it failed? If it |
57 |
> was related to perl then this might still be the same problem, but I |
58 |
> don't know if perl is at all involved in stage1. |
59 |
> |
60 |
> |
61 |
> //Peter |
62 |
> |
63 |
> |
64 |
I solved the problem using the 20101019 portage snapshot. The guys at releng |
65 |
still didn`t release Tuesday`s stage3 for this week and I think it was |
66 |
because of the same problem. |
67 |
|
68 |
I think the weekly builds are a very good way to improve system packages |
69 |
stability on Portage, but I`m also getting some other problems with |
70 |
non-system packages. Examples: |
71 |
|
72 |
* ipvsadm doesn`t build with the stable gentoo-source because the directory |
73 |
include/asm changed to include/asm-generic on the kernel`s source. Solution |
74 |
one: create a link. Solution two: patch. I went with #1. |
75 |
* sys-cluster/heartbeat-2.0.7-r2 doesn`t compile using the latest GCC/Glib |
76 |
pair. I`m not sure witch one is the root cause. Quick solution: go for |
77 |
sys-cluster/heartbeat-2.0.8 (~x86). |
78 |
|
79 |
So, my suggestion is that the QA guys build a few stage4 stages (KDE, Gnome, |
80 |
mail server, web server, file server, db server) weekly internally to |
81 |
monitor for inconsistencies on the non-system part of Portage and file the |
82 |
bugs everytime there is one. This way the probability of a user getting into |
83 |
problems before QA is reduced. |
84 |
|
85 |
Another sugestion: have any stabilizing package a 48 hour delay so that the |
86 |
stage4 could be tested in advance. Or give a 48 hour delay for the entire |
87 |
official portage tree, make QA tests daily on the live one and minimize the |
88 |
risks this way also. |
89 |
|
90 |
Thanks for the help. |
91 |
|
92 |
Best, |
93 |
Daniel van Ham Colchete |