From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PBS4U-0000EK-TI for garchives@archives.gentoo.org; Thu, 28 Oct 2010 12:59:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B78AE07BA; Thu, 28 Oct 2010 12:59:01 +0000 (UTC) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 47623E07BA for ; Thu, 28 Oct 2010 12:59:01 +0000 (UTC) Received: by ywa6 with SMTP id 6so1794902ywa.40 for ; Thu, 28 Oct 2010 05:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=qw/Bcitgzfb6cWqYOMpILv5omwGnYLkeMRWGVUmqJ/Y=; b=Op2nhjqMQkHpQz/3AmeyxsiXYdGuukCuxKZFClRUN2LtyYWxvgacCwrUNwyxXCO/A+ xmLdZXxXBb2A4IuoTorONF5gOSDLYpUbj34UHrHmMXN/Vpw7G2kL28eGn7XQQsmFqfEU wcHfr3LSelYdKLQalYNKG2nP6egs7eXKI6MP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=ih90BIh3njzncnzaf4U59jYYXl/k2x0t8KCA31BJfgGCN4nkhz7ZKZ5H056R0sdROU h48HC3OFSAkct1jA/995JKvLwzvWnqm9cr0TVN9KrBCMf4ySskHjxGU8lU6Fmr3NY2rV QoRRCmkKHDYGcW0h2obdR7PtZGMSMPgN+PQTA= Received: by 10.42.192.193 with SMTP id dr1mr8533845icb.254.1288270740198; Thu, 28 Oct 2010 05:59:00 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 Received: by 10.231.199.70 with HTTP; Thu, 28 Oct 2010 05:58:39 -0700 (PDT) In-Reply-To: <20101026161127.16496.qmail@stuge.se> References: <20101026161127.16496.qmail@stuge.se> From: Daniel van Ham Colchete Date: Thu, 28 Oct 2010 10:58:39 -0200 Message-ID: Subject: Re: [gentoo-catalyst] Little help building stage3 (Can't locate Tie/Hash.pm building autoconf-2.65-r1) To: gentoo-catalyst@lists.gentoo.org Content-Type: multipart/alternative; boundary=20cf301d41ead816990493ace727 X-Archives-Salt: 4713adde-51ac-4a9f-a934-363973a5041f X-Archives-Hash: f07621466c79cb1e6607e6a2f7af75e1 --20cf301d41ead816990493ace727 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Oct 26, 2010 at 2:11 PM, Peter Stuge wrote: > Daniel van Ham Colchete wrote: > > And this is the build log: http://pastebin.com/Em8fyRyT > > This is my stage 1, 2 and 3 files: http://pastebin.com/bkcuGaP7 > > Which version of perl is in the 20101019 stage3? > > 5.8.8 > > > Tie/Hash.pm is available on my old Perl 5.8.8 installation but it > > doesn't appear to be on Perl 5.12.2. > > I've done similar as you, but I tried to take a shortcut and build > stage4 directly from today's stage3. > > For the most psrt it works fine, but especially with perl modules > there's a twist. > > Portage doesn't know which version of perl that the installed modules > were built against, and even if a module was built against an older > perl, the dependency on that module is still satisfied, even if perl > has been upgraded so that the module cannot be found. > > This happened to me when today's stage3 had one version of perl, and > a newer one was in my stage4. > > Rather than doing the correct thing and build my own stage3 like you, > I just hacked around it by calling perl-cleaner --allmodules in > /usr/lib64/catalyst/targets/stage4/stage4-chroot.sh which is kinda > ugly but does work. > The problem is that Tie/Hash.pm is a built in module. When the stage1 installs Perl 5.12.2 the Tie/Hash.pm is not going to /usr/lib/perl/5.12.2 even though Perl 5.8.8 is not installed on /tmp/stage1root. I`m pretty much sure this is a bug with the recently stabilized new Perl 5.12.2 ebuild. > > > > So, when building a new stage3 Perl 5.8.8 is not getting there and > > I think this is the cause of the problem. > > Again, which version is in your stage3? > > > > The stage1 build failed as well, but when I did a > > catalyst -a -f stage1.spec after the failure, the build finished > > correctly, so I didn`t want to search for the root cause. > > Leaving unexplained errors is always risky, and can definately come > back to bite you later. Do you at least recall how it failed? If it > was related to perl then this might still be the same problem, but I > don't know if perl is at all involved in stage1. > > > //Peter > > I solved the problem using the 20101019 portage snapshot. The guys at releng still didn`t release Tuesday`s stage3 for this week and I think it was because of the same problem. I think the weekly builds are a very good way to improve system packages stability on Portage, but I`m also getting some other problems with non-system packages. Examples: * ipvsadm doesn`t build with the stable gentoo-source because the directory include/asm changed to include/asm-generic on the kernel`s source. Solution one: create a link. Solution two: patch. I went with #1. * sys-cluster/heartbeat-2.0.7-r2 doesn`t compile using the latest GCC/Glib pair. I`m not sure witch one is the root cause. Quick solution: go for sys-cluster/heartbeat-2.0.8 (~x86). So, my suggestion is that the QA guys build a few stage4 stages (KDE, Gnome, mail server, web server, file server, db server) weekly internally to monitor for inconsistencies on the non-system part of Portage and file the bugs everytime there is one. This way the probability of a user getting into problems before QA is reduced. Another sugestion: have any stabilizing package a 48 hour delay so that the stage4 could be tested in advance. Or give a 48 hour delay for the entire official portage tree, make QA tests daily on the live one and minimize the risks this way also. Thanks for the help. Best, Daniel van Ham Colchete --20cf301d41ead816990493ace727 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 26, 2010 at 2:11 PM, Peter S= tuge <peter@stuge.se> wrote:
Daniel van Ham Colchete wrote:
> And this is the build log: http://pastebin.com/Em8fyRyT
> This is my stage 1, 2 and 3 files: http://pastebin.com/bkcuGaP7

Which version of perl is in the 20101019 stage3?

5.8.8
=A0

> Tie/Hash.pm is available on my old Perl 5.8.8 installation but it
> doesn't appear to be on Perl 5.12.2.

I've done similar as you, but I tried to take a shortcut and buil= d
stage4 directly from today's stage3.

For the most psrt it works fine, but especially with perl modules
there's a twist.

Portage doesn't know which version of perl that the installed modules were built against, and even if a module was built against an older
perl, the dependency on that module is still satisfied, even if perl
has been upgraded so that the module cannot be found.

This happened to me when today's stage3 had one version of perl, and a newer one was in my stage4.

Rather than doing the correct thing and build my own stage3 like you,
I just hacked around it by calling perl-cleaner --allmodules in
/usr/lib64/catalyst/targets/stage4/stage4-chroot.sh which is kinda
ugly but does work.

The problem is that Tie/Hash.p= m is a built in module. When the stage1 installs Perl 5.12.2 the Tie/Hash.p= m is not going to /usr/lib/perl/5.12.2 even though Perl 5.8.8 is not instal= led on /tmp/stage1root. I`m pretty much sure this is a bug with the recentl= y stabilized new Perl 5.12.2 ebuild.

=A0


> So, when building a new stage3 Perl 5.8.8 is not getting there and
> I think this is the cause of the problem.

Again, which version is in your stage3?


> The stage1 build failed as well, but when I did a
> catalyst -a -f stage1.spec after the failure, the build finished
> correctly, so I didn`t want to search for the root cause.

Leaving unexplained errors is always risky, and can definately come back to bite you later. Do you at least recall how it failed? If it
was related to perl then this might still be the same problem, but I
don't know if perl is at all involved in stage1.


//Peter


I solved the problem using the 20101019 porta= ge snapshot. The guys at releng still didn`t release Tuesday`s stage3 for t= his week and I think it was because of the same problem.

I think the= weekly builds are a very good way to improve system packages stability on = Portage, but I`m also getting some other problems with non-system packages.= Examples:

=A0* ipvsadm doesn`t build with the stable gentoo-source because the di= rectory include/asm changed to include/asm-generic on the kernel`s source. = Solution one: create a link. Solution two: patch. I went with #1.
=A0* s= ys-cluster/heartbeat-2.0.7-r2 doesn`t compile using the latest GCC/Glib pai= r. I`m not sure witch one is the root cause. Quick solution: go for sys-clu= ster/heartbeat-2.0.8 (~x86).

So, my suggestion is that the QA guys build a few stage4 stages (KDE, G= nome, mail server, web server, file server, db server) weekly internally to= monitor for inconsistencies on the non-system part of Portage and file the= bugs everytime there is one. This way the probability of a user getting in= to problems before QA is reduced.

Another sugestion: have any stabilizing package a 48 hour delay so that= the stage4 could be tested in advance. Or give a 48 hour delay for the ent= ire official portage tree, make QA tests daily on the live one and minimize= the risks this way also.

Thanks for the help.

Best,
Daniel van Ham Colchete
--20cf301d41ead816990493ace727--