Hi there, and thanks for the official binpkg support! If I run 'emerge -puvDUg @world' as my local non-root user, I see: "Local copy of remote index is up-to-date and will be used." despite the index being out of date: $ ls -l /var/cache/edb/binhost/gentoo.osuosl.org/releases/amd64/binpackages/17.1/x86-64 total 15632 -rw-r--r-- 1 root root 16004944 Dec 31 11:35 Packages Looking at https://gentoo.osuosl.org/releases/amd64/binpackages/17.1/x86-64/ shows that the remote Packages file currently has a timestamp of 2024-01-05 02:45. When I immediately repeat the emerge call as root, the local file does get updated: -rw-r--r-- 1 root root 16374518 Jan 5 22:41 Packages Am I misunderstanding what that message should mean? If Portage isn't able to check the remote server or isn't able to write the file, it might be helpful to display e.g. "index last updated N days ago" instead, if N > (some number). My user's in the portage group, but of course it still can't update the root-owned file. Having that file be writable by the portage group could be helpful too.
Created attachment 881527 [details] emerge --info
I forgot to mention, this does affect the pretend emerge results. Only three binaries were available in the first, non-root emerge: [binary U ] kde-frameworks/khtml-5.113.0-1:5/5.113::gentoo [binary U ] sys-apps/xdg-desktop-portal-1.18.2-5::gentoo [binary U ] kde-frameworks/baloo-5.113.0-1:5/5.113::gentoo Three more and an updated xdg-desktop-portal were available in the second, root emerge: [binary U ] x11-misc/xkeyboard-config-2.40-r1-1::gentoo [binary U ] dev-python/pillow-10.1.0-r1-1::gentoo [binary U ] kde-frameworks/khtml-5.113.0-1:5/5.113::gentoo [binary N ] media-video/wireplumber-0.4.17-r1-2:0/0.4::gentoo [binary U ] sys-apps/xdg-desktop-portal-1.18.2-7::gentoo [binary U ] kde-frameworks/baloo-5.113.0-1:5/5.113::gentoo
Might have some relationship to the getbinpkg_refresh=False default from bug 864259 comment #2.
(In reply to Khumba from comment #0) > Hi there, and thanks for the official binpkg support! > > If I run 'emerge -puvDUg @world' as my local non-root user, I see: > > "Local copy of remote index is up-to-date and will be used." > > despite the index being out of date: > > $ ls -l > /var/cache/edb/binhost/gentoo.osuosl.org/releases/amd64/binpackages/17.1/x86- > 64 > total 15632 > -rw-r--r-- 1 root root 16004944 Dec 31 11:35 Packages > > Looking at https://gentoo.osuosl.org/releases/amd64/binpackages/17.1/x86-64/ > shows that the remote Packages file currently has a timestamp of 2024-01-05 > 02:45. When I immediately repeat the emerge call as root, the local file > does get updated: > > -rw-r--r-- 1 root root 16374518 Jan 5 22:41 Packages > > Am I misunderstanding what that message should mean? If Portage isn't able > to check the remote server or isn't able to write the file, it might be > helpful to display e.g. "index last updated N days ago" instead, if N > > (some number). > Khumba, I totally agree: the message is misleading. I think that's the minimum thing to fix. > My user's in the portage group, but of course it still can't update the > root-owned file. Having that file be writable by the portage group could be > helpful too. That might be the actual problem. After fetching the remote package index portage tries to write it. If your user is not allowed, this step is skipped. See this clarifying comment: https://github.com/palao/portage/blob/da5b18a418233e289229d3d124f6352e531c9ffb/lib/portage/dbapi/bintree.py#L1609
(In reply to Zac Medico from comment #3) > Might have some relationship to the getbinpkg_refresh=False default from bug > 864259 comment #2. I don't think that's the case because with emerge -puvDUg @world the remote package index is populated first in the "run_action" function (https://github.com/palao/portage/blob/da5b18a418233e289229d3d124f6352e531c9ffb/lib/_emerge/actions.py#L3494 ). Later, in the "action_build" function is called again with (the default) "getbinpkg_refresh=False" (https://github.com/palao/portage/blob/da5b18a418233e289229d3d124f6352e531c9ffb/lib/_emerge/actions.py#L178 ). In this case, that is correct since the package index has been already populated. The problem is, as I wrote before: 1) the message is misleading, and 2) the package index is silently not updated in the first call to populate (in the "run_action" function).
I can think of several ways to fix this, but I'm not sure what's the more consistent solution. The solutions that I find more reasonable are: 1) portage writes the local copy of the remote package index such that any user in the portage group can write it. 2) portage writes more accurate messages: "Local copy of remote index is up-to-date and will be used." is a false statement in this case. It could print out also some message when the package index could not be written. Plus the index should not be marked as populated if the file could not be written. But the package index is only writable by its owner. 3) a combination of 1) and 2): the indices can be written by any member of the portage group and more accurate messages are printed out? Opinions?
(In reply to Khumba from comment #2) > I forgot to mention, this does affect the pretend emerge results. Only > three binaries were available in the first, non-root emerge: > > [binary U ] kde-frameworks/khtml-5.113.0-1:5/5.113::gentoo > [binary U ] sys-apps/xdg-desktop-portal-1.18.2-5::gentoo > [binary U ] kde-frameworks/baloo-5.113.0-1:5/5.113::gentoo > > Three more and an updated xdg-desktop-portal were available in the second, > root emerge: > > [binary U ] x11-misc/xkeyboard-config-2.40-r1-1::gentoo > [binary U ] dev-python/pillow-10.1.0-r1-1::gentoo > [binary U ] kde-frameworks/khtml-5.113.0-1:5/5.113::gentoo > [binary N ] media-video/wireplumber-0.4.17-r1-2:0/0.4::gentoo > [binary U ] sys-apps/xdg-desktop-portal-1.18.2-7::gentoo > [binary U ] kde-frameworks/baloo-5.113.0-1:5/5.113::gentoo The reason for that is what I explained above.
I like 3) with the "n days old". We also need to fix the annoying thing where it gets shown twice.
(In reply to Sam James from comment #8) > I like 3) with the "n days old". > > We also need to fix the annoying thing where it gets shown twice. Thanks a lot for the comment. That helps me a lot! One question: what do you mean by "the annoying thing where it gets shown twice"?
(In reply to David Palao from comment #9) > (In reply to Sam James from comment #8) > > I like 3) with the "n days old". > > > > We also need to fix the annoying thing where it gets shown twice. > > Thanks a lot for the comment. That helps me a lot! > No, thank you! > One question: what do you mean by "the annoying thing where it gets shown > twice"? Check out bug 510296 and bug 920937.
