Very odd portage behaviour: arm = missing keyword?? [SOLVED]

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

I am currently trying to port gentoo to gumstix computers (check out www.gumstix.com to see why... very cool bit of kit).

I have been trying to put together my own baselayout based on baselayout-lite, however when it came to moving on to udev, I just gave up. Instead I've switched to a full blown baselayout for maximum compatibility with other Gentoo packages.

Here's my setup:

arm-softfloat-linux-uclibc toolchain based on gcc 3.4.6 build with crossdev (tried 4.1.1 but uclibc fails to link against libgcc as it claims libgcc is using VFP instructions... I think this is an eabi related issue but it was easier to switch to 3.4.6 than delve any deeper)

I have setup 2 directories: config-root and root.

I emerge using the following command:
$ ROOT="./root" PORTAGE_CONFIGROOT="./config-root" emerge ...

I've setup a profile, a make.conf, and some etc/portage config files. I'm using busybox, which causes dependency issues. I've overcome these by setting all the virtuals provided by busybox to busybox. However, not everything has virtuals (there's no virtual/coreutils for example) so for these packages, I've been listing them in package.provided. This has worked very well (thank you to whoever introduced this!).

Now my problem. There is a circular dependency between module-init-tools and baselayout. I'm able to overcome this for baselayout by setting the "bootstrap" use flag. So, I now have the following packages installed: baselayout-1.12.9, busybox-1.3.1, hotplug-base-20040401, udev-104 & dropbear-0.48.1

However, when I come to emerge module-init-tools, I get the following:

Genone · Posted: Mon Jan 22, 2007 12:04 pm Post subject:

output of emerge --info (when using ROOT and CONFIGROOT) might be of use here.

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

I've tried it with CTARGET set to arm-softfloat-linux-uclibc and with CTARGET unset. Both result in the same problem. Anyway, here's the output of emerge --info:

Genone · Posted: Mon Jan 22, 2007 11:22 pm Post subject:

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

Thanks for the tip, but sadly it's still producing the error. If I do an emerge --info now, I get the following output:

Genone · Posted: Tue Jan 23, 2007 7:53 pm Post subject:

Exactly the same (with "masked by ~amd64 keyword")?

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

Yup... This does seem to only happen when emerging module-init-tools. I've emerged udev successfully, which also depends on baselayout.

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

aryaniae · Posted: Wed Jan 24, 2007 6:42 pm Post subject:

Not entirely sure on this, but usually when portage gives me a "masked by: missing keyword" error, it means that package doesn't support the arch I'm building for.

Just to be sure, emerge --info *does* say ACCEPT_KEYWORS="arm" now, yes?

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

Genone · Posted: Thu Jan 25, 2007 6:04 pm Post subject:

Ok, just to make sure I'm understanding this right:
This error just happens with module-init-tools, a `emerge -p baselayout` works fine?

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

That's correct, baselayout (with the bootstrap use flag enabled) emerges fine, as does hotplug-base-20040401, udev-104 & dropbear-0.48.1. If I look in the root dir I see a full directory tree with everything I'd expect. It's only when I try to emerge module-init-tools that it falls over. I've tried it with and without bootstrap for baselayout in package.use.

I've also tried editing package.keywords and playing around with the baselayout line (including putting in amd64 and ~amd64... just to see what would happen). Reguardless of what I do, it still gives the same "masked by: ~amd64 keyword" style errors.

I can put together a tarball of the profile & config-root I'm using if you would like?

Thanks!

Genone · Posted: Thu Jan 25, 2007 10:48 pm Post subject:

Very odd, such behavior is impossible in theory, unless there is some very strange bash foo involved. For debugging I'd probably need the following:
- contents of your PORTAGE_CONFIGROOT
- contents of your profile
- output of `declare -f`
- output of `alias`
- output of the failing command with FEATURES=python-trace enabled and --debug in options
Though before you could try if this happens with an empty ROOT and CONFIGROOT (with just the bare minimum) as well and/or if it's persistent with portage-2.1.2.

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

I've spend a while working on this and it isn't just arm this applies to. I think this is due to a bug in the module-init-tools-3.2.2-r2 ebuild, or at least how it's being processed.

You don't need a very complicated setup to recreate this, in fact just the following directory tree and a single file:

Directory tree:

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

After a bit more thinking and digging, I actually don't think it's module-init-tools as all. The only major difference between -r1 and -r2 were the versions of baselayout they depend on. I now think it's something to do with base layout.

If you edit module-init-tools-3.2.2-r2 (after making sure it's unmasked) and change the the verson of baselayout in the DEPEND variable to ">=sys-apps/baselayout-1.12.6" it works. switching it for the next lastest version in the portage tree (sys-apps/baselayout-1.12.8-r1) then breaks it again.

So, when portage parses the baselayout-1.12.8-r1 and later ebuilds, something goes wrong. :-)

Genone · Posted: Sat Jan 27, 2007 7:22 pm Post subject:

Sorry, can't confirm your problem here:

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

I guess it must be something in my config somewhere then as I still get the error, even after upgrading to portage 2.1.2-r4. Where have all those use flags come from in your emerge --info? Mine only shows USE="arm".

First, the output with --debug (adding FEATURES="python-trace" adds too much debug to post here):

Genone · Posted: Sat Jan 27, 2007 11:26 pm Post subject:

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

Would you mind if I e-mailed you the output with python-trace turned on?

Genone · Posted: Sun Jan 28, 2007 9:46 am Post subject:

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

the output from emerge with FEATURES="python-debug" ran up to 95MB!!! This has gzip'd down to 4.7MB, but still too big to e-mail, so I've put it up at: http://www.tomcooksey.me.uk/emerge-debug.gz

I've also put up the output from declare -f: http://www.tomcooksey.me.uk/declare-f.gz

I hope you can decipher that 97MB of debug!

Thanks again!

Genone · Posted: Sun Jan 28, 2007 11:47 pm Post subject:

Ok, after checking with Zac I think I have an idea what's happening (though not 100% sure):
- module-init-tools has a DEPEND on baselayout
- portage has to merge the DEPEND to / (instead of $ROOT)
- packages merged to / use the configuration of / (instead of $CONFIGROOT)
- your / configuration has ARCH=amd64, so getmaskingstatus() reports the package as "masked by ~amd64"

So unmasking it in /etc/portage/package.keywords should help.

Hagra · n00b Joined: 24 Jun 2004 Posts: 74

Why does "portage has to merge the DEPEND to / (instead of $ROOT) "? Surely everything should run from $ROOT if it's set?

Why did this not show up when you tried it?

When you say I should unmask it in /etc/portage/package.keywords, do you mean /etc/portage/package.keywords? Or do you mean $PORTAGE_CONFIGROOT/etc/portage/package.keywords? What do I unmask? Both module-init-tools and baselayout? I've tried unmasking them both in packages.keywords (in my config-root) and the error still occurs.

The thing I don't understand is that there's an unmasked version of both module-init-tools (3.2.2-r2) and baselayout (1.12.8-r5) which satisfy the dependencies. I don't see how completely unmasking these packages will change anything? In fact, for both baselayout and module-init-tools, the latest unmasked version is higher for arm than it is for amd64.

Please don't think me ungrateful, I fully appreciate the time you've gone to trying to fix my problem. I just don't understand properly. :oops:

I'm going to try this on my PC at work tomorrow to see if I can recreate it on a different install.

Genone · Posted: Mon Jan 29, 2007 6:21 am Post subject: