Created attachment 897105 [details] /var/tmp/portage/sys-power/upower-1.90.4/work/upower-1.90.4-build/meson-logs/testlog.txt PermissionError: [Errno 13] Permission denied: '/root/.local/share/flatpak/exports/share/python-dbusmock/templates/logind.py'
Created attachment 897106 [details] build.log:
Created attachment 897107 [details] environment // profile default/linux/amd64/23.0/split-usr/desktop/plasma gcc-13.2.1_p20240210 O3 pipe march=native(verbose) lto graphite ggdb3
Created attachment 897108 [details] emerge --info
Created attachment 897109 [details] /etc/portage/* in `zip -9`
Reproducible with sys-power/upower-1.90.4-r1
Seems like you probably have some flatpak stuff stuff polluting your environment. I don't see anything obvious in your environment file, but I don't really know how flatpak works. Also, please do NOT update the bug for every version/revision for which you encounter the issue.
Oh, I see it's in XDG_DATA_DIRS.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1899cf52d63af9a6213be707536e0f3ffdda41ab commit 1899cf52d63af9a6213be707536e0f3ffdda41ab Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2024-07-16 15:13:17 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2024-07-16 15:15:11 +0000 sys-power/upower: unset XDG_CONFIG_DIRS and XDG_DATA_DIRS Closes: https://bugs.gentoo.org/935575 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-power/upower/upower-1.90.4-r1.ebuild | 2 ++ 1 file changed, 2 insertions(+)
That makes me wonder about why there is this note at profiles/base/make.defaults: # XDG_* since the values coming from user environment can collide with # ebuild-set ${HOME} (e.g. by referring to user's home directory). # We exclude XDG_DATA_DIRS & XDG_CONFIG_DIRS as those are set in env.d. It looks more logical to also unset them instead of relying on random values from env.d, but I don't know the reasons for explicitly excluding them from the list of ENV_UNSET
(In reply to Pacho Ramos from comment #9) > It looks more logical to also unset them instead of relying on random values > from env.d, but I don't know the reasons for explicitly excluding them from > the list of ENV_UNSET Yeah, I was wondering about that myself. Probably worth looking into.
I found that they are excluded from the beginning: https://gitweb.gentoo.org/repo/gentoo.git/commit/profiles/base/make.defaults?id=c54e5e702dbf2ade6cba311101fcc08f2cc4c6eb But I am still unsure about the real reasons: https://bugs.gentoo.org/499288 I have grepped in the tree and it seems that packages interact with those variables only to set them to their needed values or unsetting them to avoid issues like this one.
I think it is because of this bug: https://bugs.gentoo.org/635040 as explained at: https://archives.gentoo.org/gentoo-dev/message/bf36c4c50f9c15db222faa6a66b0c6c9 But, I think, that packages needing the variable to be set should simply set it at build time to the desired values
(In reply to Pacho Ramos from comment #12) > But, I think, that packages needing the variable to be set should simply set > it at build time to the desired values That seems reasonable to me.
