From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L4bAn-0004c5-Ra for garchives@archives.gentoo.org; Mon, 24 Nov 2008 13:08:18 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D0B89E0350; Mon, 24 Nov 2008 13:08:16 +0000 (UTC) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.190]) by pigeon.gentoo.org (Postfix) with ESMTP id 95357E0350 for ; Mon, 24 Nov 2008 13:08:16 +0000 (UTC) Received: by rn-out-0910.google.com with SMTP id m36so1795490rnd.14 for ; Mon, 24 Nov 2008 05:08:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=EiPgcl/TaS4HRNh6+0WIVaFLhpF/4J/6yHoV7LfIMVw=; b=lIooSmssvsO+RwOxTDZ2HMOqlbZzkEFwmrmj4Iz0F0z5VX8CpuzpYpzxPpWnTSBdOZ Vn0L7Bri7Sa+gO16sgXfKR3x29mm6OJUxJSoTYe2NRtvHyPOR3jvLgeZELm3F40z3osE tynmZuCityfNEfjDA9WV4cgXQloYruD0Kbq3M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=p98vgzjOy9WvKjlQdLxnKxXfhwaq8qqnsKOOi75VKglX/4f0PnJ1lWVdiPcF6Xfaud H6F2LiqXehFYzwXUcYrp5s4EqGYVjfjRCnlksYDPm2pnaLPyqGzGYAofnLyZRFNPtQaX qRmf7AGPBFaRRZNaXMO8LoXDM0fD+7aII+Kh4= Received: by 10.151.142.16 with SMTP id u16mr7082899ybn.34.1227532094468; Mon, 24 Nov 2008 05:08:14 -0800 (PST) Received: by 10.151.125.11 with HTTP; Mon, 24 Nov 2008 05:08:14 -0800 (PST) Message-ID: Date: Mon, 24 Nov 2008 14:08:14 +0100 From: "Erick Michau" To: gentoo-catalyst@lists.gentoo.org Subject: Re: [gentoo-catalyst] blocked packages com_err ss e2fsprogs during stage3 In-Reply-To: <492A038F.2060508@gentoo.org> 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 Content-Type: multipart/alternative; boundary="----=_Part_126635_12614050.1227532094454" References: <1C41B58A4BFDF94D89711390731555AB01B53809@RWMC-MAIL-C.RWMC.ORG> <4929E960.6070709@gentoo.org> <1C41B58A4BFDF94D89711390731555AB01B53814@RWMC-MAIL-C.RWMC.ORG> <492A038F.2060508@gentoo.org> X-Archives-Salt: ff158a09-cfa7-4091-995f-6b8dbd6951b8 X-Archives-Hash: 27eb0184a78ad3178600c2e94689cfaa ------=_Part_126635_12614050.1227532094454 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello James, I do not know if it is useful for what you're trying to achieve, but using catalyst for few years now, I encountered this problem a dozen times already. I never found a proper/elegant way to solve this issue (blocking packages on an aging stage3 tarball). Actually there is (start from a stage1 but then you can end up struggling with cpp preprocessor missing). I'm too lazy and scripting a chroot is way faster for me. So what I do (and I'm currently having the same issue as you do), I copy a portage snapshot inside the temp dir (/var/tmp/catalyst/tmp/default/whatever/usr/portage/) chroot into it and correct whatever was blocking my build. I then rerun catalyst and here it goes. Before you pack the whole as an iso, don't forget to remove the portage snapshot or your livecd will be oversized. I know it is ugly, but it does the trick. To give an idea, here is my routine to build/patch a stage1. #!/bin/bash set -e set -x vs=0.1.10 pv="20081124" CHROOT="/var/tmp/catalyst/tmp/default/livecd-stage1-x86-genluks-$vs" catalyst -a -f genluks-stage1.spec || { rsync -av /var/tmp/catalyst/snapshot_cache/$pv/portage $CHROOT/usr #echo "emerge autounmask;autounmask app-misc/livecd-tools-1.0.40_pre3;autounmask sys-apps/hwsetup-1.2;emerge livecd-tools hwsetup udev" > $CHROOT/lo echo "emerge -f e2fsprogs e2fsprogs-libs && emerge --unmerge ss com_err e2fsprogs && emerge e2fsprogs e2fsprogs-libs" > $CHROOT/lo chroot $CHROOT bash /lo rm -rf $CHROOT/usr/portage/* rm $CHROOT/lo catalyst -f genluks-stage1.spec } I'm currently running it and it works like a charm. Hope it helps in some way. Erick On Mon, Nov 24, 2008 at 2:29 AM, Andrew Gaffney wrote: > Dio, James wrote: > >> Thank you for your response, in an effort to make sure that everything >> is using the same snapshot, I have done everything over again and have >> the same issue, and included the spec files I used. >> I had wanted to purge everything catalyst has produced so far, however >> when I ran catalyst --purge, I get the following error: >> !!! catalyst: please specify one of either -f or -C >> When I specify both --purge and -f (some spec file) it attempts to build >> the stage instead of purge. Should I open a bug for this? >> > > No, that's how it's supposed to work. The purge isn't an operation all by > itself. It's just an additional step that's performed before a build. > > > Here's what I did: >> emerge --sync >> catalyst -s rwmc.001 >> catalyst -f rwmc-stage1.spec >> catalyst -f rwmc-stage2.spec >> catalyst -f rwmc-stage3.spec >> >> rwmc-stage1.spec contains: >> subarch: x86 >> target: stage1 >> version_stamp: rwmc.001 >> rel_type: default >> profile: default/linux/x86/2008.0 >> snapshot: rwmc.001 >> source_subpath: default/stage3-i686-2008.0 >> chost: i686-pc-linux-gnu >> >> rwmc-stage2.spec contains: >> subarch: i686 >> target: stage2 >> version_stamp: rwmc.001 >> rel_type: default >> profile: default/linux/x86/2008.0 >> snapshot: rwmc.001 >> source_subpath: default/stage1-x86-rwmc.001 >> chost: i686-pc-linux-gnu >> >> rwmc-stage3.spec contains: >> subarch: i686 >> target: stage3 >> version_stamp: rwmc.001 >> rel_type: default >> profile: default/linux/x86/2008.0 >> snapshot: rwmc.001 >> source_subpath: default/stage2-i686-rwmc.001 >> > > At first glance, everything here looks fine. I'm not sure what to tell you. > > > -- > Andrew Gaffney > http://dev.gentoo.org/~agaffney/ > Gentoo Linux Developer Catalyst/Genkernel + Release Engineering > Lead > > ------=_Part_126635_12614050.1227532094454 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello James,

I do not know if it is useful for what you're trying to achieve, but using catalyst for few years now, I encountered this problem a dozen times already.

I never found a proper/elegant way to solve this issue (blocking packages on an aging stage3 tarball). Actually there is (start from a stage1 but then you can end up struggling with cpp preprocessor missing). I'm too lazy and scripting a chroot is way faster for me.
So what I do (and I'm currently having the same issue as you do), I copy a portage snapshot inside the temp dir (/var/tmp/catalyst/tmp/default/whatever/usr/portage/) chroot into it and correct whatever was blocking my build. I then rerun catalyst and here it goes. Before you pack the whole as an iso, don't forget to remove the portage snapshot or your livecd will be oversized.

I know it is ugly, but it does the trick.

To give an idea, here is my routine to build/patch a stage1.
#!/bin/bash
set -e
set -x
vs=0.1.10
pv="20081124"
CHROOT="/var/tmp/catalyst/tmp/default/livecd-stage1-x86-genluks-$vs"
catalyst -a -f genluks-stage1.spec || {
  
        rsync -av /var/tmp/catalyst/snapshot_cache/$pv/portage $CHROOT/usr
        #echo "emerge autounmask;autounmask app-misc/livecd-tools-1.0.40_pre3;autounmask sys-apps/hwsetup-1.2;emerge livecd-tools hwsetup udev" > $CHROOT/lo
        echo "emerge -f e2fsprogs e2fsprogs-libs && emerge --unmerge ss com_err e2fsprogs && emerge e2fsprogs e2fsprogs-libs" > $CHROOT/lo
        chroot $CHROOT  bash /lo
        rm -rf $CHROOT/usr/portage/*
        rm $CHROOT/lo
        catalyst -f genluks-stage1.spec
}

I'm currently running it and it works like a charm.

Hope it helps in some way.

Erick

On Mon, Nov 24, 2008 at 2:29 AM, Andrew Gaffney <agaffney@gentoo.org> wrote:
Dio, James wrote:
Thank you for your response, in an effort to make sure that everything
is using the same snapshot, I have done everything over again and have
the same issue, and included the spec files I used.
I had wanted to purge everything catalyst has produced so far, however
when  I ran catalyst --purge, I get the following error:
!!! catalyst: please specify one of either -f or -C
When I specify both --purge and -f (some spec file) it attempts to build
the stage instead of purge. Should I open a bug for this?

No, that's how it's supposed to work. The purge isn't an operation all by itself. It's just an additional step that's performed before a build.


Here's what I did:
emerge --sync
catalyst -s rwmc.001
catalyst -f rwmc-stage1.spec
catalyst -f rwmc-stage2.spec
catalyst -f rwmc-stage3.spec

rwmc-stage1.spec contains:
subarch: x86
target: stage1
version_stamp: rwmc.001
rel_type: default
profile: default/linux/x86/2008.0
snapshot: rwmc.001
source_subpath: default/stage3-i686-2008.0
chost: i686-pc-linux-gnu

rwmc-stage2.spec contains:
subarch: i686
target: stage2
version_stamp: rwmc.001
rel_type: default
profile: default/linux/x86/2008.0
snapshot: rwmc.001
source_subpath: default/stage1-x86-rwmc.001
chost: i686-pc-linux-gnu

rwmc-stage3.spec contains:
subarch: i686
target: stage3
version_stamp: rwmc.001
rel_type: default
profile: default/linux/x86/2008.0
snapshot: rwmc.001
source_subpath: default/stage2-i686-rwmc.001

At first glance, everything here looks fine. I'm not sure what to tell you.


--
Andrew Gaffney                                 http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer            Catalyst/Genkernel + Release Engineering Lead


------=_Part_126635_12614050.1227532094454--