When I do "equery l -p" I get that it is searching for package in portage tree (/usr/portage) but it doesn't find any. If I use "equery l -o" I get that it is searching in the overlay tree (with empty braces) but it find's the packages from the portage tree. Here's an example: weser ~ # equery l -p baselayout [ Searching for package 'baselayout' in all categories among: ] * installed packages [I--] [ ] sys-apps/baselayout-1.12.4-r6 (0) * Portage tree (/usr/portage/) weser ~ # equery l -o baselayout [ Searching for package 'baselayout' in all categories among: ] * installed packages [I--] [ ] sys-apps/baselayout-1.12.4-r6 (0) * overlay tree () [--O] [M~] sys-apps/baselayout-1.11.13-r2 (0) [--O] [ ] sys-apps/baselayout-1.11.14-r8 (0) [--O] [ ] sys-apps/baselayout-1.11.15-r3 (0) [--O] [ ] sys-apps/baselayout-1.12.1 (0) [--O] [M~] sys-apps/baselayout-1.12.4 (0) [--O] [M~] sys-apps/baselayout-1.12.4-r1 (0) [--O] [ ] sys-apps/baselayout-1.12.4-r2 (0) [--O] [ ] sys-apps/baselayout-1.12.4-r3 (0) [--O] [ ] sys-apps/baselayout-1.12.4-r4 (0) [--O] [ ] sys-apps/baselayout-1.12.4-r5 (0) [--O] [ ] sys-apps/baselayout-1.12.4-r6 (0) [--O] [M ] sys-apps/baselayout-darwin-1.11.11 (0) [--O] [M ] sys-apps/baselayout-darwin-1.11.11-r1 (0) [--O] [M-] sys-apps/baselayout-lite-1.0_pre1 (0) [--O] [ ] sys-apps/baselayout-vserver-1.11.14-r4 (0) [--O] [M~] sys-apps/baselayout-vserver-1.11.15 (0) [--O] [M~] sys-apps/baselayout-vserver-1.12.1 (0) [--O] [M ] sys-freebsd/freebsd-baselayout-20060624 (0) I have no overlay installed. Strange enough that with -p it tells me my correct portage dir and with -o it tells me an empty path but find's the portage stuff. My emerge --info follows as attachment.
Created attachment 94766 [details] emerge --info
What version of gentoolkit do you have installed? It is working for me with gentoolkit-0.2.2: # equery l -p baselayout [ Searching for package 'baselayout' in all categories among: ] * installed packages [I--] [ ] sys-apps/baselayout-1.12.4-r6 (0) * Portage tree (/usr/portage) [-P-] [M~] sys-apps/baselayout-1.11.13-r2 (0) [-P-] [ ] sys-apps/baselayout-1.11.14-r8 (0) [-P-] [ ] sys-apps/baselayout-1.11.15-r3 (0) [-P-] [ ] sys-apps/baselayout-1.12.1 (0) [-P-] [M~] sys-apps/baselayout-1.12.4 (0) [-P-] [M~] sys-apps/baselayout-1.12.4-r1 (0) [-P-] [ ] sys-apps/baselayout-1.12.4-r2 (0) [-P-] [ ] sys-apps/baselayout-1.12.4-r3 (0) [-P-] [ ] sys-apps/baselayout-1.12.4-r4 (0) [-P-] [ ] sys-apps/baselayout-1.12.4-r5 (0) [-P-] [M ] sys-apps/baselayout-darwin-1.11.11 (0) [-P-] [M ] sys-apps/baselayout-darwin-1.11.11-r1 (0) [-P-] [M-] sys-apps/baselayout-lite-1.0_pre1 (0) [-P-] [ ] sys-apps/baselayout-vserver-1.11.14-r4 (0) [-P-] [M~] sys-apps/baselayout-vserver-1.11.15 (0) [-P-] [M~] sys-apps/baselayout-vserver-1.12.1 (0) [-P-] [M ] sys-freebsd/freebsd-baselayout-20060624 (0) # equery l -o baselayout [ Searching for package 'baselayout' in all categories among: ] * installed packages [I--] [ ] sys-apps/baselayout-1.12.4-r6 (0) * overlay tree ()
Checking gentoolkit shows this: weser ~ # equery k gentoolkit [ Checking app-portage/gentoolkit-0.2.2 ] * 78 out of 78 files good So same version as you and package files are in good shape.
Is $PORTDIR a symlink or a real directory?
(In reply to comment #4) > Is $PORTDIR a symlink or a real directory? No, $PORTDIR (/usr/portage) is no symlink. /usr/portage is a real directory. The only difference to /usr is, that /usr/portage resides on it's own parition: /dev/sda9 on / type reiserfs (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw) /dev/sda1 on /boot type reiserfs (ro,notail) /dev/sda5 on /tmp type reiserfs (rw,noexec,nosuid,nodev,usrquota,grpquota) /dev/sda7 on /var type reiserfs (rw,nodev,usrquota,grpquota) /dev/sda8 on /home type reiserfs (rw,nosuid,nodev,usrquota,grpquota,acl) /dev/sda11 on /mnt/sda11 type reiserfs (rw,nosuid,nodev,usrquota,grpquota,acl) /dev/sda10 on /usr/portage type reiserfs (rw) none on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,devmode=0664,devgid=85)
Created attachment 100461 [details] Duncan's emerge --info, same problem, different portage/gentoolkit versions This just started happening to me, too. After finding this bug, I verified that equery is indeed reversing the overlay and portage tree here too. $emerge -p portage gentoolkit These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild R ] sys-apps/portage-2.1.2_pre3-r8 [ebuild R ] app-portage/gentoolkit-0.2.3_pre2 I've been regularly updating portage, so immediately thought it was portage. However, the OR (original reporter) was on portage 2.1-r2 and gentoolkit-0.2.2, and I left them behind some time ago yet everything was working fine last I tried equery, until today. gentoolkit was last updated here on Oct. 11, according to its filesystem date, and while I'm not positive I've used equery list since then, I think I have, and anyway the previous versions the OR reported the problem in never gave me any. Possibly related, altho I'm not sure... earch (freshly downloaded 0.9.2 from robbat's devspace after 0.9 gave the issue) is acting strangely as well. Again, I've been regularly using earch for some time, no issues until now, but now it's failing with the following traceback, which seems to indicate an attempt in portage.py to set cpv with the configuration locked. $earch gcc Traceback (most recent call last): File "/l/bin/earch", line 342, in ? earch_main() File "/l/bin/earch", line 82, in earch_main (ebuildlist,ebuilddata,pkgkeywords) = earch_data_generate(args,slots=opt_slot,hide_masked=opt_hide_masked,include_category=opt_category,ignore_redundant=opt_ignore_redundant,one_slot=opt_one_slot) File "/l/bin/earch", line 206, in earch_data_generate masking = portage.getmaskingstatus(cpv) File "/usr/lib/portage/pym/portage.py", line 3960, in getmaskingstatus settings.setcpv(mycpv, mydb=portdb) File "/usr/lib/portage/pym/portage.py", line 1530, in setcpv self.modifying() File "/usr/lib/portage/pym/portage.py", line 1456, in modifying raise Exception, "Configuration is locked." Exception: Configuration is locked. Of note, I'm on amd64 the OR is i686, so it doesn't seem to be platform specific. My portage layout is a bit strange. The tree as configured in make.conf exists in /p (I got tired of typing long paths). My overlay is in /l/p (aka /usr/local/p). Just in case something tries to use the default tree location, however, I have a symlink at /usr/portage -> /p. Perhaps critically, both the OR and myself have the portage tree as a separate partition, type reiserfs. However, as I said, I had no problem with it, with his reported versions. It's only very recently that the issue appeared here. Full emerge --info attached.
Yipee, another one bites the dust... I've got several gentoo installations. All behave fine except the one with /usr/portage on its own partition. Does portage do any tricks with analysing the partition layout? Or does it other tricks which may fail like moving files between /usr/portage and other locations outside which obviously will fail in this case? We are only two reporters now with this problem with one similarity in common so it may not stick the bug to this point. But maybe it's worth investigating the source code regarding partition layouts...
This seems to be fixed since one of the last portage upgrades - so this can be closed if nobody else cares...
Same problem still exists here. equery list -p and -o are reversed. Updated yesterday. ~$emerge -p portage gentoolkit These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-apps/portage-2.1.2-r8 [ebuild R ] app-portage/gentoolkit-0.2.3_pre3 PORTDIR=/p PORTDIR_OVERLAY=/l/p /p -> /str/portage, where /str is the mountpoint for my striped/RAID-0 volume. /l is an actual dir and is the mountpoint for a (RAID-6/Lvm2) volume also symlinked as /usr/local (/usr/local -> /l), so the overlay is also (thru the symlink) logically /usr/local/p. OF INTEREST: equery list --help lists the CORRECT locations for the portage tree (/p) and overlay tree (/l/p). So at that point, it has it correct. Where does it get it wrong? I'm not a python coder (tho I have learning it on my todo list), but it appears there are verbosity debugging checks in there. How do I turn those on and will it help? If not, what about a patch I can run that prints out debugging var values at various points? (I'm used to doing that to track down bash/initscript errors, just don't know what I'm doing in python yet so can't easily figure out what to put where, myself.)
Then I reopen it...
Created attachment 132795 [details] emerge --info of heinrich.nirschl I see the same problem on my machine. In my case /usr/portage is a symlink to a different partition.
Duncan or anyone else with the problem, Would you please spell out explicitly your mount points and any symbolic links involved for your PORTDIR and PORTDIR_OVERLAY settings? I am still completely unable to reproduce this utilizing separate partitions and symlinks.
Paul, here are my mount points of the problematic machine: /dev/sda9 on / type reiserfs (rw,relatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec) devpts on /dev/pts type devpts (rw,nosuid,noexec) /dev/sda1 on /boot type reiserfs (ro,notail) /dev/sda5 on /tmp type reiserfs (rw,noexec,nosuid,nodev,relatime,usrquota,grpquota) /dev/sda7 on /var type reiserfs (rw,nodev,relatime,usrquota,grpquota) /dev/sda8 on /home type reiserfs (rw,nosuid,nodev,relatime,usrquota,grpquota,acl) /dev/sda11 on /mnt/sda11 type reiserfs (rw,nosuid,nodev,relatime,usrquota,grpquota,acl) /dev/sda12 on /var/lib/mysql type reiserfs (rw,nosuid,nodev,relatime,acl) /dev/sda10 on /usr/portage type reiserfs (rw,relatime) none on /dev/shm type tmpfs (rw) usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85) The problem switches behaviour only on updating portage as far as I could reproduce. Current portage installation doesn't show the bug for me: weser ~ # equery l portage [ Searching for package 'portage' in all categories among: ] * installed packages [I--] [ ] app-portage/portage-utils-0.1.29 (0) [I--] [ ] sys-apps/portage-2.1.4.4 (0) weser ~ # equery l gentoolkit [ Searching for package 'gentoolkit' in all categories among: ] * installed packages [I--] [ ] app-portage/gentoolkit-0.2.3-r1 (0) No symlinks are involved...
(In reply to comment #12) I have a partition mounted to /mnt/sda5 and a symlink from /usr/portage -> /mnt/sda5/portage Default settings for PORTDIR (/usr/portage). equery l -p gcc gives: # equery l -p gcc [ Searching for package 'gcc' in all categories among: ] * installed packages [I--] [ -] sys-devel/gcc-4.1.2 (4.1) [I--] [ ] sys-devel/gcc-config-1.4.0-r4 (0) [I--] [ ] x11-misc/gccmakedep-1.0.2 (0) * Portage tree (/usr/portage) but # equery l -o gcc [ Searching for package 'gcc' in all categories among: ] * installed packages [I--] [ -] sys-devel/gcc-4.1.2 (4.1) [I--] [ ] sys-devel/gcc-config-1.4.0-r4 (0) [I--] [ ] x11-misc/gccmakedep-1.0.2 (0) * overlay tree (/usr/local/portage) [--O] [ ] dev-ada/asis-gcc-3.4.6 (3.4) [--O] [M~] dev-ada/asis-gcc-4.1.1 (4.1) [--O] [M~] dev-ada/asis-gcc-4.1.2 (4.1) ...
OK, I got the problems I was having related to the upgrade to the portage-2.2 series (2.2-rc1 currently) sorted, hoping maybe that would solve the problem somehow, but it didn't. Here's what I'm currently seeing (no konqueror ebuilds in the overlays, all in the gentoo main tree, thus the bug). Note that with the addition of the layman/sunrise tree, what WAS being reported as in my personal overlay is now shown as being in sunrise, even tho it's in gentoo/main. equery l -o -p konqueror [ Searching for package 'konqueror' in all categories among: ] * installed packages [I--] [ ~] kde-base/konqueror-3.5.9 (3.5) [I--] [ ~] kde-base/konqueror-akregator-3.5.9 (3.5) * Portage tree (/p) * overlay tree (/p/layman/sunrise /l/p) [--O] [ ~] kde-base/konqueror-3.5.9 (3.5) [--O] [M~] kde-base/konqueror-4.0.4 (kde-4) [--O] [M~] kde-base/konqueror-4.0.5 (kde-4) [--O] [ ~] kde-base/konqueror-akregator-3.5.9 (3.5) My three repos: /p: main/gentoo/portage tree /p/layman/sunrise: layman's sunrise tree /l/p: my personal/local overlay As portage sees them: $emerge -v --info|grep PORTDIR PORTDIR="/p" PORTDIR_OVERLAY="/p/layman/sunrise /l/p" Related symlinks: ls -l /p /usr/local lrwxrwxrwx 1 root root 12 Sep 6 2007 /p -> /str/portage/ lrwxrwxrwx 1 root root 2 Sep 6 2007 /usr/local -> /l/ Related mounts: mount |egrep "root|local|str" rootfs on / type rootfs (rw) /dev/root on / type reiserfs (rw) /dev/md_d2p1 on /str type reiserfs (rw,noatime) /dev/mapper/vg-local on /l type reiserfs (rw,noatime) It's likely not relevant, but WTH, FWIW, maybe it'll help you duplicate it <shrug>: str=striper, my main partitioned RAID-0 array partition, no redundancy but fast, perfect place for local caches of trees downloaded off the net, particularly when they're accessed frequently as $PORTDIR can be. rootfs is on a partition of my partitioned RAID-6 for redundancy. (The kernel groks mdp/RAID directly, but not LVM, which requires userspace help. Thus, / is direct on partitioned RAID so as not to require an initramfs.) /l=local, /usr/local, on a logical volume on a physical volume residing on a different partition on that same RAID-6. (This can be on LVM since regular userspace is loaded by the time I need anything in local.) Also probably not relevant, but if it might help you duplicate... all my filesystems are reiserfs. As comment #12 asking for this was shortly after I left a comment referencing this bug on bug #228595 (portage-2.2_rc1 repo confusion), you may already be aware of it, but if not, I'm guessing this is related. The problem there turned out to be incorrectly tracing symlinks back to their canonical filesystem names. That would appear to be happening here as well, thus involving symlinks but not mountpoints. While I know not so much about python/portage/gentoolkit, perhaps this will help... or not. Anyway, taking a look at the patch on that bug and at the equery code, I'd suggest the solution may be in using os.path.realpath() in the code around lines 1465 and 1471 resolving PORTDIR and PORTDIR_OVERLAY, and/or similar resolutions on lines 1579 and 1581. (There are a few other hits for PORTDIR but they appear to be help related.) I'm guessing that without an exact match due to failure to resolve to a canonical filesystem path, equery defaults to matching up the repos and the packages in them more or less randomly (well, by local order, which will be locally predictable but is basically random globally, based on whatever the local order happens to be). Thanks for what is certainly a very useful toolkit! =8^) Duncan
Same isse, no symlink of /usr/portage nor a different partition. But (as Duncans) the rootfs is reiserfs.
Anyone still experiencing this problem, please see if the patch attached to bug 253968 makes a difference.
(In reply to comment #17) > Anyone still experiencing this problem, please see if the patch attached to bug > 253968 makes a difference. > Yes, its working for me with the patch applied (see Comment #11 for my configuration).
(In reply to comment #17) > please see if the patch attached to bug > 253968 makes a difference. Yes, with the patch, it's now working as documented here, too. I did guess correctly in comment 9 that os.path.realpath as in bug 228595 would help. As observed in bug 253968 (with the patch), nice, simple, clean patch! =:^) Duncan
This was fixed in gentoolkit-0.2.4.3
