bug#59784: [version 1.4.0rc1] Retrying a failed install fails
Ludovic Courtès writes: > One finding: when hitting C-c, the dynamic-wind exit handler (the one > that restores the database and umounts the cow store) is *not* executed. Impressive findings. Now that you found the dynamic-wind’s out-guard does not even run: Uhh I had misdiagnosed when I thought your 'stop-service' patch had made a difference and caused a second resume to work. Second resume was already possible on rc2. Except eventually resume stops working and on some install attempts with rc2, resume stops working right away. After seeing that you opened a bug#60116 on setsid(), I tested removing the setsid call and it had no effect, but if the dynamic-wind’s out-guard does not even run, that is to be expected. > I did reproduce the issue in a VM by running “ifconfig ens3 down” in a > tty, or by killing the ‘guix substitute’ process, to cause failure of > ‘guix system init’. In that case the database is indeed restored, but I > occasionally get errors like “/gnu/store/….drv: No such file or > directory”. Yes, this is the error message that I get on failing resumes. Regards, Florian
bug#59784: [version 1.4.0rc1] Retrying a failed install fails
Maxime Devos writes: > So, I'm nominally 'on hiatus', but I noticed this mail, and noticed > you copied a file (and fsync'ed it), but forgot to fsync the directory > it was copied to -- from what I've read (but I don't recall the > source), fsyncing the contents of the file isn't enough, you also need > to fsync the directory such that the new file entry is in the > directory after crashing. Ohh indeed! The Linux manpage on fsync confirms it. That invalidates my fsync testing. Which was on a codepath that, as Ludo found out, did not even run. But I will remember to fsync the directory in the future. Thank you very much Maxime! Regards, Florian
bug#59784: [version 1.4.0rc1] Retrying a failed install fails
Hi, "pelzflorian (Florian Pelz)" skribis: > Desperately I tried also adding fsync, to no avail, both issues remain. > Non-working patch attached. > > Maybe dynamic-wind is an inappropriate pattern here? > > If I interrupt installation using Ctrl-C (which I normally don’t, > instead I unplug Ethernet), then I have to press Ctrl-C twice. Maybe > that could be related to why I need to resume twice? One finding: when hitting C-c, the dynamic-wind exit handler (the one that restores the database and umounts the cow store) is *not* executed. This is because ‘call-with-mnt-container’ sets a SIGINT handler that terminates that process with SIGKILL (I’m not entirely sure of the rationale, but said process cannot handle signals in Scheme while it’s in ‘waitpid’, called from ‘run-command’). I did reproduce the issue in a VM by running “ifconfig ens3 down” in a tty, or by killing the ‘guix substitute’ process, to cause failure of ‘guix system init’. In that case the database is indeed restored, but I occasionally get errors like “/gnu/store/….drv: No such file or directory”. Ludo’.
bug#59546: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites
On Fri Dec 16, 2022 at 7:31 AM CST, Maxim Cournoyer wrote: > Thanks for sharing. It looks like we have something to investigate. > It's perhaps related to the way we build qtwebengine; do these sites > work in ungoogled-chromium for you? Just tested in ungoogled-chromium, and yes it seems both gitlab and livechart worked fine, passing the brower checks quickly on my Guix System machine. Very interesting. I tried copying the user agent from ungoogled-chromium (similar but slightly different from the qutebrowser default) but it didn't seem to make a difference.
bug#59784: [version 1.4.0rc1] Retrying a failed install fails
On 14-12-2022 22:47, pelzflorian (Florian Pelz) wrote: fsyncing the database had no effect. (In addition to Ludo’s 'stop-service', I had done fsync.patch diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm index ef487805f0..13deffef85 100644 --- a/gnu/installer/final.scm +++ b/gnu/installer/final.scm @@ -217,8 +217,16 @@ (define (assert-exit x) ;; alive. (stop-service 'guix-daemon) - ;; Restore the database and restart it. + ;; Restore the database. (copy-file saved-database database-file) + + ;; Sync it to the filesystem. + (let* ((flags O_RDONLY) +(fd (open database-file flags))) + (fsync fd) + (close fd)) + So, I'm nominally 'on hiatus', but I noticed this mail, and noticed you copied a file (and fsync'ed it), but forgot to fsync the directory it was copied to -- from what I've read (but I don't recall the source), fsyncing the contents of the file isn't enough, you also need to fsync the directory such that the new file entry is in the directory after crashing. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#59546: qutebrowser and icecat stuck in infinite browser checks (cloudflare) on applicable sites
reopen 59546 quit Hello, "bdju" writes: > On Thu Dec 15, 2022 at 7:26 AM CST, Maxim Cournoyer wrote: >> That's a good lead; could you please test qutebrowser in Guix vs >> qutebrowser on another distribution yourself and confirm this hypothesis >> (that it works elsewhere?), and post your finings here? If you can do >> that and post your finding, I we can reopen the ticket, as we'll have >> something actionable to look at. >> > > I'm able to pass the browser check in a matter of seconds and log in to > GitLab from my PineBook Pro running postmarketOS (Alpine-based) using > qutebrowser. > > Here is the :version output from the working qutebrowser: > > qutebrowser v2.5.2 > Git commit: > Backend: QtWebEngine 5.15.3, based on Chromium 87.0.4280.144 > Qt: 5.15.6 > > CPython: 3.11.1 > PyQt: 5.15.7 > > sip: 6.6.2 > colorama: 0.4.6 > jinja2: 3.1.2 > pygments: 2.13.0 > yaml: 6.0 > adblock: 0.6.0 > PyQt5.QtWebEngineWidgets: yes > PyQt5.QtWebEngine: 5.15.6 > PyQt5.QtWebKitWidgets: no > pdf.js: no > sqlite: 3.40.0 > QtNetwork SSL: OpenSSL 3.0.7 1 Nov 2022 > > Style: QFusionStyle > Platform plugin: wayland > OpenGL: OpenGL ES > Platform: Linux-5.18.0-aarch64-with, 64bit > Linux distribution: postmarketOS edge (alpine) > Frozen: False > Imported from /usr/lib/python3.11/site-packages/qutebrowser > Using Python from /usr/bin/python3 > Qt library executable path: /usr/lib/qt5/libexec, data path: /usr/share/qt5 > > Paths: > cache: /home/bdju/.cache/qutebrowser > config: /home/bdju/.config/qutebrowser > data: /home/bdju/.local/share/qutebrowser > runtime: /run/user/10001/qutebrowser > system data: /usr/share/qutebrowser > > Autoconfig loaded: no > Config.py: /home/bdju/.config/qutebrowser/config.py has been loaded > Uptime: 0:02:55 > > > guix version info for comparison: > > qutebrowser v2.5.2 > Git commit: > Backend: QtWebEngine 5.15.5, based on Chromium 87.0.4280.144 > Qt: 5.15.5 > > CPython: 3.9.9 > PyQt: 5.15.5 > > sip: 6.6.1 > colorama: 0.4.4 > jinja2: 3.1.1 > pygments: 2.12.0 > yaml: 6.0 > adblock: no > PyQt5.QtWebEngineWidgets: yes > PyQt5.QtWebEngine: 5.15.5 > PyQt5.QtWebKitWidgets: no > pdf.js: no > sqlite: 3.36.0 > QtNetwork SSL: OpenSSL 1.1.1s 1 Nov 2022 > > Style: QFusionStyle > Platform plugin: xcb > OpenGL: Intel Open Source Technology Center, 3.0 Mesa 21.3.8 > Platform: Linux-6.0.8-gnu-x86_64-with-glibc2.33, 64bit > Linux distribution: Guix System (unknown) > Frozen: False > Imported from > /gnu/store/675pkhpvbvi0yai1bggkkaj3h1xy2xrb-qutebrowser-2.5.2/lib/python3.9/site-packages/qutebrowser > Using Python from > /gnu/store/avmnzy8djp42r5926cwznz6ls9gablf8-python-wrapper-3.9.9/bin/python > Qt library executable path: > /gnu/store/mgkd6lgihvqv9n1rlsqfv2rv0zq9whnh-qtbase-5.15.5/lib/qt5/libexec, > data path: > /gnu/store/mgkd6lgihvqv9n1rlsqfv2rv0zq9whnh-qtbase-5.15.5/share/qt5 > OS Version: > > --- /etc/os-release --- > NAME="Guix System" > ID=guix > PRETTY_NAME="Guix System" > LOGO=guix-icon > DOCUMENTATION_URL="https://guix.gnu.org/en/manual; > > Paths: > cache: /home/brad/.cache/qutebrowser > config: /home/brad/.config/qutebrowser > data: /home/brad/.local/share/qutebrowser > runtime: /run/user/1000/qutebrowser > > Autoconfig loaded: no > Config.py: /home/brad/.config/qutebrowser/config.py has been loaded > Uptime: 1 day, 3:11:30 > Thanks for sharing. It looks like we have something to investigate. It's perhaps related to the way we build qtwebengine; do these sites work in ungoogled-chromium for you? Re-opening! -- Thanks, Maxim
bug#60121: [armhf-linux] inkscape 1.1.1 test failures
Hi, When attempting to build inkscape 1.1.1 for armhf-linux, there are two test failures: The following tests FAILED: 231 - cli_export-png-color-mode-gray-8_png (Bus error) 233 - cli_export-png-color-mode-rgb-8_png (Bus error) --8<---cut here---start->8--- 231/300 Test #231: cli_export-png-color-mode-gray-8_png Bus error***Except Unable to init server: Could not connect: Connection refused Background RRGGBBAA: ff00 Area 0:0:453.543:396.85 exported to 454 x 397 pixels (96 dpi) Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at https://inkscape.org/report with a detailed description of the steps leading to the crash, so we can fix it. ** Message: 05:56:45.905: Error: Inkscape encountered an internal error and will close now. [...] Start 233: cli_export-png-color-mode-rgb-8_png 233/300 Test #233: cli_export-png-color-mode-rgb-8_png .Bus error***Except Unable to init server: Could not connect: Connection refused Background RRGGBBAA: ff00 Area 0:0:453.543:396.85 exported to 454 x 397 pixels (96 dpi) Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at https://inkscape.org/report with a detailed description of the steps leading to the crash, so we can fix it. ** Message: 05:56:46.879: Error: Inkscape encountered an internal error and will close now. --8<---cut here---end--->8--- The above failures were encountered when building natively on overdrive1. -- Thanks, Maxim
bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Ludovic Courtès writes: > I ended up with a minimal change, > pushed in commit b1aef25453067004279c4267cf25e8d6d365890d, that lets > modprobe load uvesafb for good (it was all about setting > ‘LINUX_MODULE_DIRECTORY’). Thank you Ludo for your excellent work. All is good now on AMD hardware (my laptop and PC). I’m still not sure why LINUX_MODULE_DIRECTORY is needed here and is not needed for kernel module loader service, but whatever. Regards, Florian
bug#60116: ‘herd stop guix-daemon’ doesn’t stop running sessions
Suppose you run a bunch of clients, ‘guix shell’, ‘guix build’, whatever. For each of these connections, guix-daemon creates a child process to handle it. (You can see them as “SessionPID” in the output of ‘guix processes’.) ‘herd stop guix-daemon’ won’t stop these guix-daemon child processes, only the parent process. This is because those sub-processes put themselves in a separate process group by calling ‘setsid’ (see ‘daemonLoop’ in ‘nix-daemon.cc’); shepherd terminates the whole process group, but that group contains nothing but the parent guix-daemon process. I traced back this ‘setsid’ call to 2006 in Nix (Nix commit 0130ef88ea280e67037fa76bcedc59db17d9a8ca), but there’s no justification. I would be tempted to just remove that ‘setsid’ call, but I wonder if there’s something subtle I’m overlooking. Thoughts? Ludo’.
