Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Migration between different CHOSTs during a stage 1/2 installation
when doing emerge -e system. This bug seems to affect mainly autoconf-2.59
and cronbase.
Autoconf fails because of Perl not being recompiled before it (Data::Dumper 
module is not found) and cronbase because there is no functional Shadow for 
adding the user/group.

To work around this bug, a change in dependencies should be done, so that the 
order of affected packages is :
perl -> shadow -> cronbase

The respective dependencies get pulled in in right order too.

Reproducible: Always
Steps to Reproduce:
1.decide to make a stage 1/2 installation
2.change CHOST value
3.emerge -e system (evtl. after successful bootstrap if stage1 install)

Actual Results:  
emerge -e system breaks at cronbase. even if this one gets injected externally 
with ROOT="..." set, autoconf-2.59 will fail because of not-found perl module

Expected Results:  
all steps from stage1 throughout the installation until a reboot should run 
flawlessly

*** Bug 113299 has been marked as a duplicate of this bug. ***

No need to CC me when I told you where to assign it.  Also, no need for a
blocker... well... pretty much ever.  The only time we consider something a
"blocker" is when it means "Oh dear God, we need to roll out a new release
because of this *NOW*" type of thing.

I'll get to this today.  I honestly didn't have much time to work on Gentoo last
night.

Sorry for this, won't happen again...

(In reply to comment #0)

Apparently, the problem is a missing dependency in the depgraph
concerning dependencies of cronbase, or more precisely eutils.

Reasons for NOT adding shadow to eutils dependencies is more or less elaborated 
in bug #94745, see comment 5 + 6...

I think cronbase maintainer should be bugged to add the dep, as this might solve
all problems regarding CHOST issue with stage1/2 installs, life of releng people 
would certainly get a little less stressful too.

I didn't CC no one this time, someone more appropriate should do it ;)

Created an attachment (id=73440) [details]
emerge info

This is emerge info from my main system, although it is
not built upon the stages i have tested the above behaviours on.

The interesting thing might be my catalyst version: 
dev-util/catalyst-2.0_pre20051122

I'm currently looking at implimenting a eusergroup eclass that includes
enewuser
and enewgroup (along with a couple helper functions).  What this would do is
allow us to make *that* eclass DEPEND on shadow (on Linux) and work around the
problems in bug #94745 by side-stepping it.

I've upgraded this to a blocker since some fix is required for our release to
build properly and we are nearing our snapshot date.

or you could simply add shadow to packages.build and be done with it

Except adding shadow breaks stage 1 and stage2 building, so isn't a viable
solution, as I stated last time you brought it up.  It also makes it impossible
to build a set of default-linux stages without USE=pam...

(In reply to comment #9)
> to build a set of default-linux stages without USE=pam...

I have pam set in the generic ppc-profile.  But it breaks as well.

Testing results:

Test #1 (shadow in packages.build and blockers removed)

# grep shadow profiles/default-linux/packages.build
# While shadow could be in here, it breaks stage 1 and stage 2 building for the
sys-apps/shadow
# grep pam-login sys-apps/shadow/shadow-4.0.7-r4.ebuild
        !pam? ( !build? ( !bootstrap? ( !sys-apps/pam-login ) ) )
# We moved /etc/pam.d/login to pam-login
PDEPEND="pam? ( >=sys-apps/pam-login-3.17 )"
                # These is now shipped with pam-login, and login
                                        # pam-login now.

>>> md5 files   ;-) files/README
>>> md5 files   ;-) files/run-crons-0.2.1
 * Adding group 'cron' to your system ...
 *  - Groupid: 16
/usr/portage/eclass/eutils.eclass: line 735: groupadd: command not found

!!! ERROR: sys-process/cronbase-0.3.2 failed.
!!! Function enewgroup, Line 735, Exitcode 127
!!! enewgroup failed
!!! If you need support, post the topmost build error, NOT this status message.


!!! catalyst: run script failed.

This is when it gets to building stage3.


Test #2 (shadow in packages.build)

# grep shadow profiles/default-linux/packages.build
# While shadow could be in here, it breaks stage 1 and stage 2 building for the
sys-apps/shadow
# grep pam-login sys-apps/shadow/shadow-4.0.7-r4.ebuild
        !pam? ( !sys-apps/pam-login )
# We moved /etc/pam.d/login to pam-login
PDEPEND="pam? ( >=sys-apps/pam-login-3.17 )"
                # These is now shipped with pam-login, and login
                                        # pam-login now.

Calculating dependencies ...done!

!!! Error: the sys-apps/pam-login package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers.


!!! catalyst: run script failed.

This is building a stage1.

Possible solution:

#1: Add pam to STAGE1_USE in *all* pam-enabled 2006.0 profiles
#2: Add sys-apps/shadow to default-linux/packages.build

This has been verified to work on x86.  Currently testing on amd64/ppc...

This also fixes amd64/ppc... I've added pam to STAGE1_USE on alpha, amd64, ppc,
ppc64, sparc, and x86 for the 2006.0 profiles.

The rest of you need to make yourself a 2006.0 profile and make this change.

mips done

I did s390 since there was already a 2006.0 profile...

Apparently adding PAM to stage1 is a bad thing, so I'm adding solar to CC since
he was working on a solution to this that doesn't involve PAM in stage1.

I am removing arches from CC since we might not need to do this.  I'll add them
back if it ends up being necessary in the end or if another solution requires
their assistance.

*** Bug 121807 has been marked as a duplicate of this bug. ***

OK.  I have resolved this in my snapshots with two changes.  First, I have
removed sys-process/cronbase from RDEPEND on man, since it wasn't necessary. 
Second, I have added a patch to baselayout-1.11.14-r3 in my snapshot that adds
back the man user and group.  After these two changes, stage3 builds
successfully (without pam in STAGE1_USE) on all arches.

Created an attachment (id=79772) [details]
baselayout-1.11.14-users.patch

This patch resolves this issue for me.

Chris should this bug be reassigned to spanky/baselayout/base-system now?

I would say so.  I'm keeping release on CC, though, since it'll affect anyone
trying to build from stage1, so I'm sure we'll get *lots* of bugs on this if it
isn't fixed in the tree by the time 2006.0 rolls out.

that's the point of the dupe

Anything new about this?
Stages can't be built with a current snapshot without tweaking it.

*** Bug 127157 has been marked as a duplicate of this bug. ***

*** Bug 129255 has been marked as a duplicate of this bug. ***

*** Bug 129951 has been marked as a duplicate of this bug. ***

*** Bug 128999 has been marked as a duplicate of this bug. ***

Is there still any issue with adding shadow dependency back to eutils.eclass 
(where is really belongs), once the new shadow with re-integrated pam-login is
marked stable? (Not that I'd notice any significant benefit wrt punting of
various pretty much essential groups/users like cron/sshd/man from baselayout
in the first place...)

shadow inherits eutils, so it can't be a dependency of eutils...

(In reply to comment #29)
> shadow inherits eutils, so it can't be a dependency of eutils...

It can with a little hack...

MY_PN="shadow"

DEPEND="!bootstrap? ( sys-devel/patch )"
RDEPEND=""

if [[ "${PN}" != "${MY_PN}" ]]; then
DEPEND="${DEPEND}
        sys-apps/shadow"
RDEPEND="${RDEPEND}"
fi

As soon as you can prove to me that it won't cause more trouble than it is
worth when trying to build stages via catalyst, I'll do it.  However, I can
guarantee you that this will cause circular dependencies and generally be more
trouble than it is worth.

Shrug. If the above produces circular dependencies, then portage is broken... 

If that's not an acceptable solution, then I'd suggest re-adding cron/sshd/man
back to baselayout and think twice before punting them again just for the sake
of saving a few "redundant" lines in /etc/{passwd,group}.

(In reply to comment #32)
> Shrug. If the above produces circular dependencies, then portage is broken... 

Circular dependencies are just that. portage broken or not..  
A circle is still round.

> If that's not an acceptable solution, then I'd suggest re-adding cron/sshd/man
> back to baselayout and think twice before punting them again just for the sake
> of saving a few "redundant" lines in /etc/{passwd,group}.

Right this is the only real solution to the problem.

The only thing that is required to be added back in man user/group.  That is
because shadow will come in after man, but before openssh/cronbase.  As I said,
the patch above worked perfectly for the 2006.0 release.

*** Bug 132947 has been marked as a duplicate of this bug. ***

*** Bug 133281 has been marked as a duplicate of this bug. ***

This is a formal vote for the solution presented by Chris in comment #34, me in 
#33 and others via IRC.
Add man back to user/group as needed and lose the dep so this bug wont hold up 
releng or others building feom the lowe levels of gentoo without adding any 
new deps. In addition I vote for making the change within the next few days.

Seconded.  This just halted my 2006.1-pre stage run for mips, so I wanna squish
it.

+1
i've been patching this for ages now to build QA stuff and it's quite
bothersome.

+1

I'm for it.

+1 from me as well (as the supposed SPARC basesystem guy).

formal vote ?  you just made that up

adding users back into baselayout ignores problems, it doesnt fix them

the only real fix is having portage create the users instead of relying on
packages such as shadow being installed

(In reply to comment #42)
> formal vote ?  you just made that up
> 
> adding users back into baselayout ignores problems, it doesnt fix them
> 
> the only real fix is having portage create the users instead of relying on
> packages such as shadow being installed
> 

while i agree with you on principal, this bug is holding people up.  We have a
SoC project for GLEP 27, perhaps we can provide a module for this situation. 
For now though, if you don't have a workable solution, I can't see a reason to
leave it 'broken'; ie it blocks legitimate work for a bunch of other projects.

(In reply to comment #42)
> formal vote ?  you just made that up
> 
> adding users back into baselayout ignores problems, it doesnt fix them
> 
> the only real fix is having portage create the users instead of relying on
> packages such as shadow being installed

man is a user on every system. There is no reason to not really have it 
there cept maybe on uclibc systems where noman might be set.

Problem is this is blocking building from stage1 (comment #9) 
correctly and forcing shadow where it was not forced before is a 
worse solution than a one liner returning old behavior.

If you have a creative way to add users which does not rely on shadow then 
I think all of us are all ears.

the man account serves no purpose when the system has no man functionality
installed

as i said, moving the logic to portage negates the need for any accounting
utilities to be preinstalled

Feel free to remove the 'man' user/group once that logic has been moved to
portage and is shown to be stable (and work with ${ROOT}!) :)

Portage-2.1 is in feature freeze right now, so even if someone cooked up that
kind of logic, it would be of no use because it would not be able to make the
snapshot, so the temp solution for now is the one-line addition.  Maybe said
logic can be drafted and put into portage before 2007.0 rolls around (it can't
be that hard -- anyone even drafted up pseudo-code or something for it?), and
we can get rid of this change.  But for 2006.1 to work well, we need this
change.

*** This bug has been marked as a duplicate of 53269 ***

When glep 27 is done, this is fixed, fix your shit now and we can fix it later
at the end of the summer.

Don't go creating problems when no solution exists.

instead of being a jackass why dont you read the backlog

baselayout isnt broken

people want to add users back in to baselayout to ignore the underlying issue

uberlord *already added the user back in to baselayout*

the problem reported here *no longer shows up because the hacks have been added
back into portage*

no go back to doing something useful instead of re-opening bugs you havent been
following

*** This bug has been marked as a duplicate of 53269 ***