Re: [gentoo-osx] Attempt to use prefix on linux as secondary...

[m h]

This is great thanks!

On 12/17/05, Grobian <grobian@g.o> wrote:
> Ok, I decided to to something completely different today, and went on
> trying to get this working.  First I tried to follow your steps:
>
> On 14-12-2005 15:21:41 -0800, m h wrote:
> > ===========Steps for prefix================
> >  * download toolsbox from http://dev.gentoo.org/~ferringb/portage/prefix/haubi/
> >  * download portage and prefixed overlay from
> > http://dev.gentoo.org/~kito/distfiles/
> >  * cd /data1/portage/dec14/toolsbox-4-20050927
> >  * export PREFIX=/data1/portage/dec14/prefix
> >  * gmake config PREFIX=$PREFIX
> > DISTURL=http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles
> > portage_BUILD
>
> What is this portage_BUILD?  gmake doesn't like it as target.

Sorry, you should have probably gone from my script, but portage_BUILD
is part of toolsbox... at least for me.

>
> >  *  mkdir buildroot/distfiles
> >  * cp ../../kito/portage-2.0.53.03.tar.gz buildroot/distfiles/
>
> I took kito's prefixed version instead.  Because it's not what the
> scripts expect, I did some fooling around:
>
> % tar -jxf portage-prefix-2.0.54.tar.bz2
> % mv portage-prefix-2.0.54 portage-2.0.54
> % tar -gcf portage-2.0.54.tar.gz portage-2.0.54

Yep, I also had to do this...

>
> >  * touch buildroot/portage/portage.fetched.done
> >  * change portage/portage.build
> >   * change line version to "VERSION=2.0.53.03"
>
> I set the version to 2.0.54, at least the unpack phase went fine in
> gmake portage.
>
> >   * toolsbox will still fail to install portage... FIXME!
> >  * gmake portage
> >  * wait for a while (3 hours...)
>
> hmmm...  Could have known, some of the packages don't compile out of the
> box, because my FC4 system uses gcc4.
> So I replaced binutils (which bugged) with a never version.  Easy, just
> change binutils/binutils.build and change to the never version.

When I was using using FC4 a month or two ago I also had to do this. 
This time I've been working on FC3....

>
> However, after that worked, python didn't want to install, because the
> linker could not find gcc_s or something.  Ok, so I gave up, wondering
> why I'd need all those tools anyway, and see how hard I would fall, if I
> would just configure and install kito's portage tar.

Sounds reasonable, I can try this route as well, though it seems like
I was a little more successful using toolsbox.  This certainly is
easier and since you should be able to get the deps for portage
installed easily on most machines maybe it is the way to go.  I know
that others have had success using toolsbox on AIX....

>
> So I unpacked it, ran configure like this: (where $(prefix) is here for
> making it generic, and killing lots of long paths)
> configure \
> --sysconfdir=$(prefix)/etc \
> --prefix=$(prefix)/usr \
> --with-offset-prefix=$(prefix) \
> --with-user=fabian \
> --with-group=ins \
> --with-wheelgroup=ins1 \
> --with-rootuser=fabian \
>
> configure, make, make install went all fine, so in my $(prefix), I added
> an /usr/portage (rsync tree), including distfiles (for fun, from another
> machine) and a usr/local/portage which contained the prefix overlay
> files from kito.
>
> portage is enormously picky, and creating the make.profile symlink gave
> me some problems.  Making it a relative link, e.g.
> ../usr/portage/profiles... portage assumed the .. was bogus, and thought
> that the profiles was at /usr/portage/profiles... where it of course
> wasn't.  Solution: use an absolute symlink there.

Hmmm, I don't think I ran into this....  but I wasn't using relative
paths.  Maybe python is doing something unexpected here.  That should
be pretty easy to fix.

>
> Next stop was emerge dying with some vague permission denied message.
> Iteratively executing emerge made it work in the end, because it
> appeared to be creating the /var/cache/... tree, and died each time when
> a directory didn't exist.  So after each run of emerge, my directory
> tree there was one level deeper, hence after a lot of runs, emerge
> finally exited cleanly, leaving me with some messages:
>
> > (pegasus:~/scratch/programs/gentoo) fabian% usr/bin/emerge info
> > portage: 'portage' user or group missing. Please update baselayout
> >          and merge portage user(250) and group(250) into your passwd
> >          and group files. Non-root compilation is disabled until then.
> >          Also note that non-root/wheel users will need to be added to
> >          the portage group to do portage commands.
> >
> >          For the defaults, line 1 goes into passwd, and 2 into group.
> >          portage:x:250:250:portage:/var/tmp/portage:/bin/false
> >          portage::250:portage
>
> Ok, I had hoped these numbers would have been set to my user and group
> IDs by the configure call.  Apparently not.  Or it is something else I
> did wrong here.  There's no way for me on this system to create or
> modify users.

Yeah, I'm pretty sure I passed the right configuration flags to change
the users too.  But I still have to do the secpass=2 hack.  I know
that Haubi's 2.1 portage code handled this correctly.  There are still
issues in the 2.0 backport.

>
> > *** You are not in the portage group. You may experience cache problems
> > *** due to permissions preventing the creation of the on-disk cache.
> > *** Please add this user to the portage group if you wish to use portage.
>
> Hmmm... ok.
>
> > !!! Problem with sandbox binary. Disabling...
>
> Right.  It probably doesn't exist.

This is just a friendly warning right?  I guess sandbox would be
useful to see that everything is going in the right place though...

>
> > !!! Relying on the shell to locate gcc, this may break
> > !!! DISTCC, installing gcc-config and setting your current gcc
> > !!! profile will fix this
> > Portage 2.0.54 (default-linux/amd64/2006.0, gcc-4.0.2, unavailable, 2.6.13-1.1526_FC4 x86_64)
> > =================================================================
> > System uname: 2.6.13-1.1526_FC4 x86_64 x86_64
> > Unknown Host Operating System
> > distcc 2.18.3 x86_64-redhat-linux-gnu (protocols 1 and 2) (default port 3632) [disabled]
> > ccache version 2.4 [disabled]
> > dev-lang/python:     [Not Present]
> > sys-apps/sandbox:    [Not Present]
> > sys-devel/autoconf:  [Not Present]
> > sys-devel/automake:  [Not Present]
> > sys-devel/binutils:  [Not Present]
> > sys-devel/libtool:   [Not Present]
> > sys-devel/odcctools: [Not Present]
> > virtual/os-headers:  [Not Present]
> > ACCEPT_KEYWORDS="amd64 x86"
> > CBUILD="i686-pc-linux-gnu"
> > CFLAGS="-O2 -pipe"
> > CHOST="i686-pc-linux-gnu"
> > CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
> [snip]
>
> I probably should go and look for some documentation on this...
>

So when you try "emerge -av system" what happens?
Do dependencies get worked out?  Do they build?

-- 
gentoo-osx@g.o mailing list