www-client/firefox-61.0-r1 fails with Permission denied :'/etc' while firefox-60.1.0 works fine. Reproducible by # ebuild `equery w firefox-61.0-r1` clean configure The build is done on a dedicated btrfs subvolume, but also fails on a 13GB tmpfs. Investigating the sources it tries to read the gentoo-release which is readable: # ls -ald / /etc /etc/gentoo-release drwxr-xr-x 1 root root 368 Jun 27 12:13 / drwxr-x--x 1 root root 5248 Jul 27 10:52 /etc -rw-rw-r-- 1 root root 31 Jul 26 08:18 /etc/gentoo-release ccache is active here, but it fails also with FEATURES="-ccache"
Created attachment 541198 [details] emerge --info
Created attachment 541200 [details] emerge -pvq firefox::gentoo
Created attachment 541202 [details] /var/log/portage/www-client:firefox-61.0-r1:20180724-084437.log.gz
(In reply to Massimo Burcheri from comment #0) > Investigating the sources it tries to read the gentoo-release which is > readable: > > # ls -ald / /etc /etc/gentoo-release > drwxr-xr-x 1 root root 368 Jun 27 12:13 / > drwxr-x--x 1 root root 5248 Jul 27 10:52 /etc /etc is not readable by non-root users, that's why the following code in distro.py fails: basenames = os.listdir(_UNIXCONFDIR)
What is the correct permission for /etc? Why does the older Firefox ebuild work?
I see, my drwxr-x--x on /etc is breaking the listdir. This is the first ebuild since years failing with that. In my eyes drwxr-x--x is the better permission for /etc. Firefox doesn't need to do the listdir, it could also just check for any file it expects there. Could the ebuild patch that in any way? The behaviour seems to be new in 61.0-r1.
BTW, this is fixed in newer pip: https://github.com/pypa/pip/commit/270ea3af207273b4815d73b10e83b580387adeaf The problem is that the pip is shipped as .whl package in the firefox tarball, so it would be hard to patch.
Thanks. So I revert the permission to my previous setting and wait for the next ebuild including the newer pip. Please keep this open until solved by the next ebuild.
I requested a bump of bundled PIP upstream, https://bugzilla.mozilla.org/show_bug.cgi?id=1494779
Fixed in firefox-72+