Created attachment 783953 [details] emerge --info of host I set up a Gentoo host with repo in /var/db/repos/gentoo. Intention is to keep varying files on /var. This is configured in /etc/portage/repos.conf/gentoo.conf. On the same host I set up an addition chroot with mainly default settings (after installation). Thus repo resides in /usr/portage. Emerge has been working for months and has no issues. Now I tried to track dependency issues inside the chroot with q applets like quse. Sadly it reports: qsearch: tree_open(): could not open repository at /var/db/repos/gentoo (under root /) Other q-applets work flawlessly and report the correct results - inside the chroot and outside of it. I also double checked and re-executed env-update && . /etc/profile inside the chroot to no avail. Somehow quse remembers the repo configuration from outside the chroot. Using app-portage/portage-utils-0.93.3
Created attachment 783956 [details] emerge --info of chroot
it's a bit "weird" if not "impossible" for quse to "see" outside of the chroot, so do you use ROOT or something from the host to look inside the chroot?
(In reply to Fabian Groffen from comment #2) > it's a bit "weird" if not "impossible" for quse to "see" outside of the > chroot, … Therefore I opened the bug. > so do you use ROOT or something from the host to look inside the > chroot? 1. Login via SSH to the (remote) host as regular user 2. su (and not sudo!) 3. chroot (plain, no --login, no additional commands like - su <other>) 4. quse <query> inside the chroot I also mount proc, sys and dev from the host into the chroot. And all the other q applets work correctly and also relate to the correct portage database/ portage tree.
I also checked the binaries by calculating checksums for the same path. On the host I get sha1sum A inside the chroot another B. I also grep-ped recursively through /etc, /var/portage and /usr/portage with 'repos/gentoo' inside the chroot. In addition I checked env and output on host differs from chroot as expected. But none contains any portage related path changing. Still inside the chroot quse assumes repository in /var/db/repos/gentoo. Could it be because of two additional crossdev environments? Crossdev (/etc/portage/repos.conf/crossdev.conf) has [crossdev] location = /var/db/repos/crossdev masters = gentoo auto-sync = no But such a constellation works on a second machine flawlessly (crossdev under /var/… and gentoo under /usr/portage). As soon as I create a symlink of /usr/portage to gentoo in /var/db/repos it works and shows the correct packages and their USE flags (as configured in the chroot differing from those on the host). Finally I also checked the permissions under /etc/portage/repos.conf: all owned by root and all 644. I thought maybe it appears only as it would remember but instead it is a hard coded default because the repos.conf is not readable/ accessible.
Please provide /etc/portage/repos.conf/* and /usr/share/portage/config/repos.conf from the chroot.
(In reply to Mike Gilbert from comment #5) > Please provide /etc/portage/repos.conf/* and > /usr/share/portage/config/repos.conf from the chroot. The file /usr/share/portage/config/repos.conf contains [gentoo] location = /var/db/repos/gentoo /etc/portage/repos.conf/gentoo looks like this (with the comment lines): [gentoo] #location = /var/db/repos/gentoo location=/usr/portage sync-type = rsync #sync-uri = rsync://rsync.gentoo.org/gentoo-portage sync-uri = rsync://rsync1.de.gentoo.org/gentoo-portage/ Also changing location in /usr/share/portage/config/repos.conf to the value of /etc/portage/repos.conf/gentoo and quse behaves correctly.
On the system I bootstrapped the chroot from both configs point to the same location (/usr/portage). Where bootstrapping means taking a Stage 3 archive and copying a subset of files and directories of /etc from a running host/ installation. I assume the Stage 3 provides /usr/…/repos.conf with /var while the running host has /usr/portage set.
(In reply to onkobu from comment #6) > /etc/portage/repos.conf/gentoo looks like this (with the comment lines): > > [gentoo] > #location = /var/db/repos/gentoo > location=/usr/portage It seems that portage-utils does not parse this location setting correctly. It expects to see a space between "location" and the equals sign.
`q -o` should list which overlays/repos q found. It indeed seems that a lack of whitespace between 'location' and '=' makes the repo to be ignored.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=2100df5c171029d6c347650fdaf098b67df0f059 commit 2100df5c171029d6c347650fdaf098b67df0f059 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2022-06-14 06:35:35 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2022-06-14 06:35:35 +0000 main: ensure correct parsing of key-value pairs in ini-files Ensure the key is terminated when the '=' is adjacent to it (without whitespace). Bug: https://bugs.gentoo.org/851138 Signed-off-by: Fabian Groffen <grobian@gentoo.org> main.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec3307e507ccfc092371f8e16ea40ff50557ca9f commit ec3307e507ccfc092371f8e16ea40ff50557ca9f Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2022-06-14 07:12:19 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2022-06-14 07:15:51 +0000 app-portage/portage-utils-0.94: version bump Closes: https://bugs.gentoo.org/851138 Closes: https://bugs.gentoo.org/837188 Closes: https://bugs.gentoo.org/836590 Closes: https://bugs.gentoo.org/833942 Closes: https://bugs.gentoo.org/807975 Signed-off-by: Fabian Groffen <grobian@gentoo.org> app-portage/portage-utils/Manifest | 1 + .../portage-utils/portage-utils-0.94.ebuild | 67 ++++++++++++++++++++++ 2 files changed, 68 insertions(+)
Updated to 0.94 and works as expected now. (Also checked that /usr/share/portage/config/repos.conf contains a location that does not exist.) THX for fixing.
