Hi!

Since a few days i keep getting this when trying to bootstrap on interix (and here it's not the lib dirs....):

>>> Compiling source in /opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.9583/work/prefix-portage-2.2.00.9583 ...
Traceback (most recent call last):
File "<string>", line 1, in ?
ImportError: No module named portage.const
./configure --prefix=/opt/gentoo/usr --host=i586-pc-interix3.5 --mandir=/opt/gentoo/usr/share/man --infodir=/opt/gentoo/usr/share/info --datadir=/opt/gentoo/usr/share --sysconfdir=/opt/gentoo/etc --localstatedir=/opt/gentoo/var/lib --with-portage-user=mduft --with-portage-group=Domõnen-Benutzer --with-root-user= --with-offset-prefix=/opt/gentoo --with-default-path=/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/usr/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/usr/sbin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/sbin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/bin:/usr/bin:/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/portage/bin: --build=i586-pc-interix3.5
...
...
configure: error: bad value for --with-root-user

!!! Please attach the following file when seeking support:
!!! /opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.9583/work/prefix-portage-2.2.00.9583/config.log
*
* ERROR: sys-apps/portage-2.2.00.9583 failed.

What can i do?

From the portage i use for bootstrap: /tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/portage/pym/portage/__init__.py:VERSION="2.2.00.8280-prefix"
If i change the ebuild and hardcode the root user, everything works fine. Is my bootstrap portage too old?

Cheers, Markus
--
gentoo-alt@lists.gentoo.org mailing list

On 02-04-2008 10:56:28 +0200, Duft Markus wrote:
> Hi!
>
> ImportError: No module named portage.const

^^^^

> configure: error: bad value for --with-root-user
>
> !!! Please attach the following file when seeking support:
> !!! /opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.9583/work/prefix-portage-2.2.00.9583/config.log
> *
> * ERROR: sys-apps/portage-2.2.00.9583 failed.
>
> What can i do?
>
> From the portage i use for bootstrap: /tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/portage/pym/portage/__init__.py:VERSION="2.2.00.8280-prefix"
> If i change the ebuild and hardcode the root user, everything works fine. Is my bootstrap portage too old?

Feels like quite ancient to me, yes, but IIRC, portage.const should
exist there too. Does 'import portage' work with your (bootstrapped)
python? I think it works for noone during bootstrapping actually,
unless python (from the tree) is emerged before reinstalling portage. I
think my bootstrap docs at least for Mac OS X and Solaris (the only two
that are possibly correct by the way) pull in python before portage
reemerges itself (step 1.10 in the Solaris bootstrap) hence it works
there. Maybe that's not an option for you, then we have to make a
workaround.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@lists.gentoo.org mailing list

Duft Markus wrote:

Traceback (most recent call last):
File "<string>", line 1, in ?
ImportError: No module named portage.const
./configure --prefix=/opt/gentoo/usr --host=i586-pc-interix3.5 --mandir=/opt/gentoo/usr/share/man --infodir=/opt/gentoo/usr/share/info --datadir=/opt/gentoo/usr/share --sysconfdir=/opt/gentoo/etc --localstatedir=/opt/gentoo/var/lib --with-portage-user=mduft --with-portage-group=Domõnen-Benutzer --with-root-user= --with-offset-prefix=/opt/gentoo --with-default-path=/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/usr/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/usr/sbin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/sbin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/bin:/usr/bin:/bin:/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/portage/bin: --build=i586-pc-interix3.5
...
...
configure: error: bad value for --with-root-user

!!! Please attach the following file when seeking support:
!!! /opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.9583/work/prefix-portage-2.2.00.9583/config.log
*
* ERROR: sys-apps/portage-2.2.00.9583 failed.

What can i do?

From the portage i use for bootstrap: /tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/portage/pym/portage/__init__.py:VERSION="2.2.00.8280-prefix"
If i change the ebuild and hardcode the root user, everything works fine. Is my bootstrap portage too old?

Cheers, Markus


I had the same problem and I *think* re-emerging coreutils fixed it.

Matt.

--
gentoo-alt@lists.gentoo.org mailing list

On 02-04-2008 20:23:36 +1100, Matt Michalowski wrote:
>> From the portage i use for bootstrap: /tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/portage/pym/portage/__init__.py:VERSION="2.2.00.8280-prefix"
>> If i change the ebuild and hardcode the root user, everything works fine. Is my bootstrap portage too old?
>>
>> Cheers, Markus
>>
> I had the same problem and I *think* re-emerging coreutils fixed it.

I doubt that.

For bug #212818 [1] I had to make sure that the "root user" which is
different from the normal "portage user" is retained over Portage
upgrades. By default, "root user" is set to the same value as "portage
user", hence older Portage ebuilds didn't set this value.

The problem with setting "root user" is that this user is not made
available in the environment somehow. Hence, I have to retrieve it
using python from the module where it is stored: (indirectly in)
portage.const.

My naive approach in the ebuild assumes that the portage modules are in
the PYTHONPATH, which is the case if a) your python is installed by
Portage, and b) your libdirs are correctly symlinked on a "multilib"
install (which I'd like to kill, but that put aside).

We can relax a) by modifying the PYTHONPATH within python itself for
that portage.const call. Won't be very easy, but I think it can be done
as there should be enough information in the ebuild available.


[1] http://bugs.gentoo.org/show_bug.cgi?id=212818


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@lists.gentoo.org mailing list

Fabian Groffen <mailto:grobian@gentoo.org> wrote:
> On 02-04-2008 10:56:28 +0200, Duft Markus wrote:
>> Hi!
>>
>> ImportError: No module named portage.const
>
> ^^^^
>
>> configure: error: bad value for --with-root-user
>>
>> !!! Please attach the following file when seeking support:
>> !!!
>>
/opt/gentoo/var/tmp/portage/sys-apps/portage-2.2.00.9583/work/prefix-por
tage-2.2.00.9583/config.log
>> * * ERROR: sys-apps/portage-2.2.00.9583 failed.
>>
>> What can i do?
>>
>> From the portage i use for bootstrap:
>>
/tools/snapshot/prefix-launcher-1pre.20080225/i586-pc-interix3.5/lib/por
tage/pym/portage/__init__.py:VERSION="2.2.00.8280-prefix"
>> If i change the ebuild and hardcode the root user, everything works
>> fine. Is my bootstrap portage too old?
>
> Feels like quite ancient to me, yes, but IIRC, portage.const should
> exist there too. Does 'import portage' work with your (bootstrapped)
> python? I think it works for noone during bootstrapping actually,
> unless python (from the tree) is emerged before reinstalling portage.
> I think my bootstrap docs at least for Mac OS X and Solaris (the only
> two that are possibly correct by the way) pull in python before
> portage reemerges itself (step 1.10 in the Solaris bootstrap) hence
> it works there. Maybe that's not an option for you, then we have to
> make a workaround.

I now tried to emerge python as first package, before portage. This
results in the same, since i have problems setting the PATH right. The
portage i use to bootstrap the prefix comes from prefix-launcher, and
(as all portage's do) insists on setting the PATH to some known value
(which doesn't include the dirs of the to-bootstrap prefix, and hence
misses the just installed python, but rather gets the python 2.4 from
prefix-launcher.

Cheers, Markus

>
>
> --
> Fabian Groffen
> Gentoo on a different level

--
gentoo-alt@lists.gentoo.org mailing list

On 02-04-2008 15:22:27 +0200, Duft Markus wrote:
> > Feels like quite ancient to me, yes, but IIRC, portage.const should
> > exist there too. Does 'import portage' work with your (bootstrapped)
> > python? I think it works for noone during bootstrapping actually,
> > unless python (from the tree) is emerged before reinstalling portage.
> > I think my bootstrap docs at least for Mac OS X and Solaris (the only
> > two that are possibly correct by the way) pull in python before
> > portage reemerges itself (step 1.10 in the Solaris bootstrap) hence
> > it works there. Maybe that's not an option for you, then we have to
> > make a workaround.
>
> I now tried to emerge python as first package, before portage. This
> results in the same, since i have problems setting the PATH right. The
> portage i use to bootstrap the prefix comes from prefix-launcher, and
> (as all portage's do) insists on setting the PATH to some known value
> (which doesn't include the dirs of the to-bootstrap prefix, and hence
> misses the just installed python, but rather gets the python 2.4 from
> prefix-launcher.

a) muck with DEFAULT_PATH
b) configure your bootstrap-portage differently (--default-path= or
something) to include the right path before your prefix-launcher path


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@lists.gentoo.org mailing list

Fabian Groffen <mailto:grobian@gentoo.org> wrote:
> On 02-04-2008 15:22:27 +0200, Duft Markus wrote:
>>> Feels like quite ancient to me, yes, but IIRC, portage.const should
>>> exist there too. Does 'import portage' work with your
>>> (bootstrapped) python? I think it works for noone during
>>> bootstrapping actually, unless python (from the tree) is emerged
>>> before reinstalling portage. I think my bootstrap docs at least for
>>> Mac OS X and Solaris (the only two that are possibly correct by the
>>> way) pull in python before portage reemerges itself (step 1.10 in
>>> the Solaris bootstrap) hence it works there. Maybe that's not an
>>> option for you, then we have to make a workaround.
>>
>> I now tried to emerge python as first package, before portage. This
>> results in the same, since i have problems setting the PATH right.
>> The portage i use to bootstrap the prefix comes from
>> prefix-launcher, and (as all portage's do) insists on setting the
>> PATH to some known value (which doesn't include the dirs of the
>> to-bootstrap prefix, and hence misses the just installed python, but
>> rather gets the python 2.4 from prefix-launcher.
>
> a) muck with DEFAULT_PATH
> b) configure your bootstrap-portage differently (--default-path= or
> something) to include the right path before your prefix-launcher path

Used a) since i'm messing with environment anyway in the bootstrap
script, and i don't know what eprefix i will bootstrap at compile time,
so b) isn't possible.
Now the right python is found, but i have another problem: there is no
rpath hardcoded in python, so it doesn't find python2.5.so...... Need to
mess a little more with the environment

Cheers, and thanks, Markus

>
>
> --
> Fabian Groffen
> Gentoo on a different level

--
gentoo-alt@lists.gentoo.org mailing list

On 02-04-2008 16:55:30 +0200, Duft Markus wrote:
> Fabian Groffen <mailto:grobian@gentoo.org> wrote:
> > a) muck with DEFAULT_PATH
> > b) configure your bootstrap-portage differently (--default-path= or
> > something) to include the right path before your prefix-launcher path
>
> Used a) since i'm messing with environment anyway in the bootstrap
> script, and i don't know what eprefix i will bootstrap at compile time,
> so b) isn't possible.
> Now the right python is found, but i have another problem: there is no
> rpath hardcoded in python, so it doesn't find python2.5.so...... Need to
> mess a little more with the environment

Then set your LDFLAGS to the appropriate values when you bootstrap
python.


--
Fabian Groffen
Gentoo on a different level
--
gentoo-alt@lists.gentoo.org mailing list