| View previous topic :: View next topic |
| Author |
Message |
redblade7
Tux's lil' helper
Joined: 11 Jan 2018
Posts: 106
|
 Posted: Tue Feb 11, 2020 6:17 am Post subject: Permissions issue with www-client/firefox-73.0 ? |
 |
|
Hi,
I wasn't able to compile Firefox 73 because of a strange permissions issue. Portage kept trying to write into /tmp/root/.cache and failing. I changed the permissions of /tmp/root to portage:portage and it seems to be compiling now. Hopefully nothing really weird will happen between then and now.
I'll let you know what happens and attach build logs once Firefox finishes compiling, but before I file a bug, is anyone else having this permissions issue with v73.0?
Thank you! |
|
| Back to top |
|
 |
redblade7
Tux's lil' helper
Joined: 11 Jan 2018
Posts: 106
|
| Posted: Tue Feb 11, 2020 6:44 am Post subject: |
|
|
Nope, towards the end the build failed with a long parade of bizarre error messages, among which are:
| Code: | [2020-02-11T06:33:19Z ERROR audio_thread_priority::rt_linux] setrlimit64: 1
###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost |
I can post both build logs tomorrow since I have to get to bed now. But I want to hear other people's stories first before filing bugs.
EDIT: With root:root permissions for /tmp/root and unsetting XDG_CACHE_HOME (why is portage inheriting this from root?) Firefox had the proper permissions on its own, but the build still failed with these weird audio errors. |
|
| Back to top |
|
|
redblade7
Tux's lil' helper
Joined: 11 Jan 2018
Posts: 106
|
| Posted: Tue Feb 11, 2020 1:10 pm Post subject: |
|
|
Per bug 709272 I was able to get Firefox 73 to build with USE="-pgo -lto" and XDG_CACHE_HOME still unset.
Searching for that audio error online brings up stuff about kernel resource limits, so perhaps getting some sleep cleared those limits 
Maybe I'll file a bug about =www-client/firefox-73.0 inheriting XDG_CACHE_HOME from root.
That is a bad idea and I'm wondering if it's true for anyone else. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2751
|
| Posted: Tue Feb 11, 2020 1:16 pm Post subject: |
|
|
Limits shouldn't be a concern, it's not like it needs RT for dummy audio tests during profiling, but something probably tries to set that by default since it's commonly used for audio.
Edit: I'm in middle of building it myself with clang+lto+pgo, will see if anything strange happen. |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3712
|
| Posted: Tue Feb 11, 2020 1:47 pm Post subject: |
|
|
Thks for replies.Indeed here's | Code: | rc-update
rtirq | default |
|
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2751
|
| Posted: Tue Feb 11, 2020 2:03 pm Post subject: |
|
|
| Ionen wrote: | | Edit: I'm in middle of building it myself with clang+lto+pgo, will see if anything strange happen. |
Well making this post with LTO+PGO firefox 73.0 right now so Worked On My Machine™ with: | Code: | | USE="clang gmp-autoupdate lto pgo pulseaudio screenshot system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-sqlite system-webp -bindist -custom-cflags -custom-optimization -debug -eme-free -geckodriver -hardened -hwaccel -jack (-selinux) -startup-notification -test -wayland -wifi" |
Imagine issues may be more system/flags specific.
Are you using non-pulseaudio that may be confusing the profiling (knowing your USE flags would help)? While I use JACK myself I don't trust firefox's barely supported jack driver so I have minimalist pulseaudio as a dumb sink to jack instead along for a few other things like Wine. Both are setup to use RT priority but did not see issues during profiling (not like it should be _actually_ using them during dummy tests).
Edit: I never had XDG_* stuff set for root so I can't confirm for that one but the ebuild should be made to handle it if it gets used during profiling too. The ebuild does cleanup some variables already but not everything. |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3712
|
| Posted: Tue Feb 11, 2020 2:39 pm Post subject: |
|
|
gcc here.
current rebuild, uninterrupted: | Code: | Configure complete!
Be sure to run |mach build| to pick up any changes
>>> Source configured.
>>> Compiling source in /var/no-tmpfs/portage/www-client/firefox-73.0/work/firefox-73.0 ...
[32;01m*[0m Scanning for an open DISPLAY to start Xvfb ...
[32;01m*[0m Starting Xvfb on $DISPLAY=1 ...
/var/no-tmpfs/portage/www-client/firefox-73.0/work/firefox-73.0/testing/mozbase/mozsystemmonitor/mozsystemmonitor/resourcemonitor.py:266: UserWarning: psutil failed to run: not sure how to interpret line ' 8 0 sda 39781 49194 2808397 674849 28362 370146 6393896 1629650 0 113210 2212887 0 0 0 0 514 41928\n'
warnings.warn('psutil failed to run: %s' % e)
Config object not found by mach. |
No idea if related, though.
Edit:currently: | Code: | eix psutil
[I] dev-python/psutil
Available versions: ~5.4.8^t 5.5.0^t 5.6.0^t (~)5.6.5^t [m]5.6.7^t {test PYTHON_TARGETS="pypy3 python2_7 python3_6 python3_7 python3_8"}
Installed versions: 5.6.5^t(05:27:52 22/01/2020)(-test PYTHON_TARGETS="python3_6 -pypy3 -python2_7 -python3_7 -python3_8") |
Didn't keep track why 5.6.7 masked here.
Thks 4 ur attention.
Last edited by CaptainBlood on Tue Feb 11, 2020 2:53 pm; edited 1 time in total |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2751
|
| Posted: Tue Feb 11, 2020 2:43 pm Post subject: |
|
|
I had a similar psutil warning, didn't seem to cause any issues and is just a warning
Edit: I don't even have dev-python/psutil installed, firefox has a in-tree version at third_party/python/psutil that appears to be v5.6.3
Edit2: it's apparently a bug when used with kernel 5.5.x, will be fixed in the yet unreleased version 5.7.0, but again, it doesn't prevent compilation (at least for me with clang+lto+pgo, didn't try gcc) and should have nothing to do with current issues |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3712
|
| Posted: Tue Feb 11, 2020 5:38 pm Post subject: |
|
|
| Ionen wrote: | I had a similar psutil warning, didn't seem to cause any issues and is just a warning
Edit: I don't even have dev-python/psutil installed, firefox has a in-tree version at third_party/python/psutil that appears to be v5.6.3
Edit2: it's apparently a bug when used with kernel 5.5.x, will be fixed in the yet unreleased version 5.7.0, but again, it doesn't prevent compilation (at least for me with clang+lto+pgo, didn't try gcc) and should have nothing to do with current issues |
Was initially building with kernel < 5.5, thus no psutil issue reported in bugzilla attachment.
Making me laugh when u talk about what to expect from 5.7 when we have no 5.6 yet.
Thks 4 all your investigations, attention, interest & support. |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3712
|
| Posted: Tue Feb 11, 2020 5:58 pm Post subject: |
|
|
When updating from 72.0 to 73.0 as in: | Code: | emerge -p firefox
These are the packages that would be merged, in reverse order:
Calculating dependencies .......... ... ... done!
[ebuild U ~] www-client/firefox-73.0 [72.0.2] USE="system-harfbuzz%*" |
I was puzzled by the | Code: | | USE="system-harfbuzz%* |
with right operand printed in yellow.
Please note this flag was activated in 72.0. As I have a binpkg backup in 72.0 I will double check this fact ASAP.
Thks 4 ur attention. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2751
|
| Posted: Tue Feb 11, 2020 6:03 pm Post subject: |
|
|
system-harfbuzz flag didn't exist in 72.0.x, it was temporarily removed and its use also commented out in the ebuild due to being broken | Code: | - #mozconfig_use_with system-harfbuzz
- #mozconfig_use_with system-harfbuzz system-graphite2
+ mozconfig_use_with system-harfbuzz
+ mozconfig_use_with system-harfbuzz system-graphite2 |
So now it's being seen as a new flag that's enabled by default. |
|
| Back to top |
|
|
redblade7
Tux's lil' helper
Joined: 11 Jan 2018
Posts: 106
|
| Posted: Tue Feb 11, 2020 7:42 pm Post subject: |
|
|
| redblade7 wrote: | Maybe I'll file a bug about =www-client/firefox-73.0 inheriting XDG_CACHE_HOME from root.
That is a bad idea and I'm wondering if it's true for anyone else. |
I've filed a bug regarding this: bug 709318
Per the most recent edit (September 2019) to https://wiki.gentoo.org/wiki/SSD#XDG_cache_on_tmpfs, creating /tmp/root/.cache is not a good idea. So while this shouldn't be happening at all, it won't happen to me anymore. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2751
|
| Posted: Tue Feb 11, 2020 7:59 pm Post subject: |
|
|
XDG cache is usually better long lived anyway, it can be cleared but there's typically no reason to clear it. Firefox even store its web cache there by default now (used not to), so every time you reboot you have to redownload everything on common sites for nothing (unless you restore a snapshot or something). The paranoia around SSDs write cycles is really not needed anyway (unless you're a company doing constant real abuse of the drive, it's tiny (8-16GB), or very ancient).
That aside, it doesn't change that the ebuild should expect the possibility it's set, so yeah  |
|
| Back to top |
|
|
CaptainBlood
Advocate
Joined: 24 Jan 2010
Posts: 3712
|
| Posted: Wed Feb 12, 2020 6:58 am Post subject: |
|
|
clang fine here too.
Thks 4 ur attention. |
|
| Back to top |
|
|
redblade7
Tux's lil' helper
Joined: 11 Jan 2018
Posts: 106
|
| Posted: Mon Feb 17, 2020 12:33 am Post subject: |
|
|
| redblade7 wrote: | | redblade7 wrote: | Maybe I'll file a bug about =www-client/firefox-73.0 inheriting XDG_CACHE_HOME from root.
That is a bad idea and I'm wondering if it's true for anyone else. |
I've filed a bug regarding this: bug 709318
Per the most recent edit (September 2019) to https://wiki.gentoo.org/wiki/SSD#XDG_cache_on_tmpfs, creating /tmp/root/.cache is not a good idea. So while this shouldn't be happening at all, it won't happen to me anymore. |
The shell script on the Wiki is incorrect as $USER still exists under USER=root and XDG_CACHE_HOME is set to /tmp/root/.cache anyway. |
|
| Back to top |
|
|
|
Portage & Programming
