Mailing List Archive

On 12/16/05, Brian Harring <ferringb@gentoo.org> wrote:
> On Thu, Dec 15, 2005 at 04:35:36PM -0800, m h wrote:
> > Got around (hacked around) python issue (I have no portage user
> > currently, only the group). So in portage_data.py, I override
> > portage_uid to my userid
> > portage_uid=os.getuid()
> > and I'm rolling again.
> ./configure --help | less # instead
> there's configurable's for defining uid/gid. Down the line (repeating
> myself), if this is mainlined, proper implementation will be created
> where config can define/adjust uid/gid's to use instead of current
> hardcoding at install time.
> ~harring
>

it looks like Haubi's toolbox is doing the right thing here (setting
the right configure flags):
src_build() {
echo "ENV:"
env
echo "MATT"
configureflags=
case "${PLATFORM}" in
SunOS)
XCU_ID=/usr/xpg4/bin/id
;;
*)
XCU_ID=/usr/bin/id
;;
esac
if [ -x "${DESTDIR}/bin/bash" ]
then
CU_BASH="${DESTDIR}/bin/bash" export CU_BASH
fi
configureflags="${configureflags} --with-offset-prefix=${DESTROOT}"
configureflags="${configureflags} --prefix=${DESTROOT}/usr"
configureflags="${configureflags} --with-user=`${XCU_ID} -un`"
configureflags="${configureflags} --with-rootuser=`${XCU_ID} -un`"
configureflags="${configureflags} --with-group=`${XCU_ID} -gn`"
configureflags="${configureflags} --with-wheelgroup=`${XCU_ID} -gn`"
gnu_build || die
}


Even if these are set, there is some hardcoded values in portage....
No biggie. Just need to edit them...

>
>

--
gentoo-osx@gentoo.org mailing list

The easiest way around this is to add
secpass=2
to the bottom of portage_data.py
Note that the comment in portage_data.py reading:
#Secpass will be set to 1 if the user is root or in the portage group.
is erroneous. It should say set to 2...

On 12/16/05, m h <sesquile@gmail.com> wrote:
> On 12/16/05, Brian Harring <ferringb@gentoo.org> wrote:
> > On Thu, Dec 15, 2005 at 04:35:36PM -0800, m h wrote:
> > > Got around (hacked around) python issue (I have no portage user
> > > currently, only the group). So in portage_data.py, I override
> > > portage_uid to my userid
> > > portage_uid=os.getuid()
> > > and I'm rolling again.
> > ./configure --help | less # instead
> > there's configurable's for defining uid/gid. Down the line (repeating
> > myself), if this is mainlined, proper implementation will be created
> > where config can define/adjust uid/gid's to use instead of current
> > hardcoding at install time.
> > ~harring
> >
>
> it looks like Haubi's toolbox is doing the right thing here (setting
> the right configure flags):
> src_build() {
> echo "ENV:"
> env
> echo "MATT"
> configureflags=
> case "${PLATFORM}" in
> SunOS)
> XCU_ID=/usr/xpg4/bin/id
> ;;
> *)
> XCU_ID=/usr/bin/id
> ;;
> esac
> if [ -x "${DESTDIR}/bin/bash" ]
> then
> CU_BASH="${DESTDIR}/bin/bash" export CU_BASH
> fi
> configureflags="${configureflags} --with-offset-prefix=${DESTROOT}"
> configureflags="${configureflags} --prefix=${DESTROOT}/usr"
> configureflags="${configureflags} --with-user=`${XCU_ID} -un`"
> configureflags="${configureflags} --with-rootuser=`${XCU_ID} -un`"
> configureflags="${configureflags} --with-group=`${XCU_ID} -gn`"
> configureflags="${configureflags} --with-wheelgroup=`${XCU_ID} -gn`"
> gnu_build || die
> }
>
>
> Even if these are set, there is some hardcoded values in portage....
> No biggie. Just need to edit them...
>
> >
> >
>

--
gentoo-osx@gentoo.org mailing list

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.

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

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

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.

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.

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.

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

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


--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list

On 17-12-2005 14:49:40 +0100, Grobian wrote:
> > (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.

Update:
I 'fixed' this by changing portage_data.py. Instead of the hardcoded
wheel user and group, I just substituted them with my own names. So far
so good. Now what's left is to start adding packages to the overlay
tree with EAPI="prefix", I suppose.
--
gentoo-osx@gentoo.org mailing list

Doesn't Kito's ebuild's already have EAPI? Or do you want different packages?

On 12/17/05, Grobian <grobian@gentoo.org> wrote:
> On 17-12-2005 14:49:40 +0100, Grobian wrote:
> > > (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.
>
> Update:
> I 'fixed' this by changing portage_data.py. Instead of the hardcoded
> wheel user and group, I just substituted them with my own names. So far
> so good. Now what's left is to start adding packages to the overlay
> tree with EAPI="prefix", I suppose.
> --
> gentoo-osx@gentoo.org mailing list
>
>

--
gentoo-osx@gentoo.org mailing list

This is great thanks!

On 12/17/05, Grobian <grobian@gentoo.org> 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@gentoo.org mailing list

On 17-12-2005 08:48:49 -0800, m h wrote:
> So when you try "emerge -av system" what happens?
> Do dependencies get worked out? Do they build?

Ehm, no. I lost quite some hair by now. It keeps on bugging me. I
spoke to kito, to get some understanding on the process. Appeared I did
some things wrong, so I'm going to restart it. For short if I recall
correctly, Kito said this:

1. create directory where the prefix should live
2. populate the directory with stuff from profile packages file
3. configure/install portage with prefix=prefix dir
4. emerge -ev system from it


--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx@gentoo.org mailing list