FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Catalyst

 
 
LinkBack Thread Tools
 
Old 11-23-2008, 06:07 PM
"Dio, James"
 
Default blocked packages com_err ss e2fsprogs during stage3

I had initially set out to create a new livecd, but ran into problems
with blocks involving com_err ss e2fsprogs. I then realized that
creating a livecd with a recent snapshot (Nov 20 2008) and the 2008.0
stage 3 wasn't the best way to go.

I set out to create new stage 1, 2 and 3 tarballs. I was able to create
the stage 1 and 2 (using the new snapshot) and am running into problems
attempting stage3.

Stage3 fails and below are the last few lines:

[ebuild N ] sys-libs/e2fsprogs-libs-1.41.2
[blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking
sys-libs/e2fsprogs-libs-1.41
.2)
[blocks B ] sys-libs/com_err (is blocking
sys-libs/e2fsprogs-libs-1.41.2)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
!!! catalyst: run script failed.

Traceback (most recent call last):
File "modules/generic_stage_target.py", line 1250, in run_local
"run script failed.",env=self.env)
File "/usr/lib/catalyst/modules/catalyst_support.py", line 539, in cmd
raise CatalystError,myexc
CatalystError
None
!!! catalyst: Stage build aborting due to error.
!!! catalyst: Error encountered during run of target stage3
Catalyst aborting....

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

I would appreciate any guidance as to how I can resolve these blocks
(which issues for this appear to be tracked in 234907 but make no
mention to catalyst.) I had thought that creating new stage 1 and 2 with
new snapshot may resolve this, but apparently I am off on that
assumption.

Thanks,
Jim
 
Old 11-23-2008, 10:38 PM
Andrew Gaffney
 
Default blocked packages com_err ss e2fsprogs during stage3

Dio, James wrote:

I had initially set out to create a new livecd, but ran into problems
with blocks involving com_err ss e2fsprogs. I then realized that
creating a livecd with a recent snapshot (Nov 20 2008) and the 2008.0
stage 3 wasn't the best way to go.

I set out to create new stage 1, 2 and 3 tarballs. I was able to create
the stage 1 and 2 (using the new snapshot) and am running into problems
attempting stage3.

Stage3 fails and below are the last few lines:

[ebuild N ] sys-libs/e2fsprogs-libs-1.41.2
[blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2)
[blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking
sys-libs/e2fsprogs-libs-1.41
.2)
[blocks B ] sys-libs/com_err (is blocking
sys-libs/e2fsprogs-libs-1.41.2)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.


If you're encountering blockers, then you did not build your seed stage2 (or
stage1) correctly. The initial stage1 you built should have already had
e2fsprogs-libs and the new e2fsprogs from the start. The fact that you're
hitting the blocker tells me that your stage 1 or 2 was still using the 2008.0
snapshot instead of the one you're trying to build the stage3 with.


You need to make sure you build *everything* with the same snapshot to prevent
issues like this.


--
Andrew Gaffney http://dev.gentoo.org/~agaffney/
Gentoo Linux Developer Catalyst/Genkernel + Release Engineering Lead
 
Old 11-24-2008, 12:15 AM
"Dio, James"
 
Default blocked packages com_err ss e2fsprogs during stage3

>> [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2
>> [blocks B ] sys-libs/ss (is blocking
sys-libs/e2fsprogs-libs-1.41.2)
>> [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking
>> sys-libs/e2fsprogs-libs-1.41
>> .2)
>> [blocks B ] sys-libs/com_err (is blocking
>> sys-libs/e2fsprogs-libs-1.41.2)
>> * Error: The above package list contains packages which cannot be
>> * installed at the same time on the same system..
>
>If you're encountering blockers, then you did not build your seed
stage2 (or
>stage1) correctly. The initial stage1 you built should have already had

>e2fsprogs-libs and the new e2fsprogs from the start. The fact that
you're
>hitting the blocker tells me that your stage 1 or 2 was still using the
2008.0
>snapshot instead of the one you're trying to build the stage3 with.
>
>You need to make sure you build *everything* with the same snapshot to
prevent
>issues like this.

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?

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
 
Old 11-24-2008, 12:29 AM
Andrew Gaffney
 
Default blocked packages com_err ss e2fsprogs during stage3

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
 
Old 11-24-2008, 12:08 PM
"Erick Michau"
 
Default blocked packages com_err ss e2fsprogs during stage3

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
 
Old 11-24-2008, 12:42 PM
"Dio, James"
 
Default blocked packages com_err ss e2fsprogs during stage3

> 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.


I see! I have done all of this over again using the -p flag and it has
built successfully this time... I guess something stuck around in the
cache causing these blocks to remain...

catalyst -p -f rwmc-stage1.spec && catalyst -p -f rwmc-stage2.spec &&
catalyst -p -f rwmc-stage3.spec


> 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.
 

Thread Tools




All times are GMT. The time now is 04:18 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org