bug#57873: Build plan reports inaccurate download size in the presence of grafts
Hi, I just encountered the following: --8<---cut here---start->8--- $ guix shell turbovnc hint: Consider passing the `--check' option once to make sure your shell does not clobber environment variables. substitute: updating substitutes from 'http://127.0.0.1:8181'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% 486.5 MB will be downloaded turbovnc-3.0.1 1.9MiB 2.0MiB/s 00:01 [##] 100.0% The following derivation will be built: /gnu/store/l8bhv0zn1lxygfcbj1w6gdpyihqyzjyk-profile.drv applying 2 grafts for openjdk-17.0.3 ... applying 13 grafts for turbovnc-3.0.1 ... building CA certificate bundle... listing Emacs sub-directories... building fonts directory... building directory of Info manuals... The following builds are still in progress: /gnu/store/a03jyjkf6h8rkdyia734qxk8vlxx8n43-info-dir.drv /gnu/store/ri0ihsy1njd451fk56xq7l45jfsf1dh2-fonts-dir.drv /gnu/store/aazg9g3wn767x7hjwdh58g2mjlxv40x2-emacs-subdirs.drv The following builds are still in progress: /gnu/store/a03jyjkf6h8rkdyia734qxk8vlxx8n43-info-dir.drv /gnu/store/ri0ihsy1njd451fk56xq7l45jfsf1dh2-fonts-dir.drv The following build is still in progress: /gnu/store/a03jyjkf6h8rkdyia734qxk8vlxx8n43-info-dir.drv building profile with 1 package... --8<---cut here---end--->8--- It printed that nearly 500 MiB would be downloaded, then proceeded with only 1.9 MiB. I'm happy about the turnaround, but that's vastly inaccurate :-). Thanks, Maxim
bug#57868: GStreamer gst_gstsystemclock test fails on CI for i686
Hi, On i686-linux, the gstreamer gst_gstsystemclock test is failing: --8<---cut here---start->8--- 41/108 gst_gstsystemclockFAIL1.26s exit status 2 >>> GST_PLUGIN_SYSTEM_PATH_1_0='' CK_DEFAULT_TIMEOUT=600 >>> GST_STATE_IGNORE_ELEMENTS='' MALLOC_PERTURB_=230 >>> GST_PLUGIN_SCANNER_1_0=/tmp/guix-build-gstreamer-1.20.3.drv-0/build/libs/gst/helpers/gst-plugin-scanner >>> GST_PLUGIN_LOADING_WHITELIST=gstreamer >>> GST_REGISTRY=/tmp/guix-build-gstreamer-1.20.3.drv-0/build/tests/check/gst_gstsystemclock.registry >>> GST_PLUGIN_PATH_1_0=/tmp/guix-build-gstreamer-1.20.3.drv-0/build >>> /tmp/guix-build-gstreamer-1.20.3.drv-0/build/tests/check/gst_gstsystemclock ? ? ? stdout: Running suite(s): GstSystemClock 75%: Checks: 8, Failures: 0, Errors: 2 ../gstreamer-1.20.3/tests/check/gst/gstsystemclock.c:263:E:waiting:test_stress_cleanup_unschedule:0: (after this point) Received signal 5 (Trace/breakpoint trap) ../gstreamer-1.20.3/tests/check/gst/gstsystemclock.c:263:E:waiting:test_stress_reschedule:0: (after this point) Received signal 5 (Trace/breakpoint trap) Check suite gst_systemclock ran in 1.236s (tests failed: 2) stderr: (gst_gstsystemclock:5546): GLib-ERROR **: 22:57:16.217: creating thread 'wait': Error creating thread: Resource temporarily unavailable (gst_gstsystemclock:6027): GLib-ERROR **: 22:57:16.340: creating thread 'wait': Error creating thread: Resource temporarily unavailable ?? --8<---cut here---end--->8--- Full log output here: https://ci.guix.gnu.org/build/1305526/log/raw I'm not able to reproduce this locally. Any idea what might be going on here? Parallelism issue? Note: we have disabled these tests on i686 for a long time, but they were recently enabled again on 'staging'. I'll re-apply that hunk to disable the test, but wanted to have an issue to link to.
bug#44944: Unable to log into X session via gdm
Hi, Maxim Cournoyer writes: [...] > /var/lib/gdm/.local/share/xorg: > total 132 > drwxr-xr-x 1 nixbld04 opendht96 Dec 8 2021 . > drwxr-xr-x 1 nixbld04 opendht72 Dec 7 2021 .. > -rw-r--r-- 1 nixbld04 opendht 52932 Dec 8 2021 Xorg.0.log > -rw-r--r-- 1 nixbld04 opendht 53878 Dec 8 2021 Xorg.0.log.old > -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log > -rw-r--r-- 1 nixbld04 opendht 10481 Dec 8 2021 Xorg.1.log.old > > We have some logic in %gdm-activation that was supposed to fix that, but > it doesn't kick in, because it has some optimization to not recurse if > the top dir has the correct permissions, and since d429878daf3 the top > directory permissions are always controlled at system activation time > (and this must happen before the gdm activation script runs). > > I'll follow-up with a patch that puts /var/lib/gdm on a tmpfs. This > should avoid many pitfalls people have had. Pushed as d7e56aebec. This should fix the issue for good! Closing. Maxim
bug#57867: Tealdeer build fails
The builds have been unsuccessful since about the start of this month on both my machine and ci.guix.gnu.org. I tried to fix the issue, but I'm unfamiliar with Rust, so I just ended up fumbling around. Thanks to anyone who can get this working again! :D signature.asc Description: OpenPGP digital signature
bug#57838: (No Subject)
i have fixed it by running a reconfigure in a chroot. surprisingly, this has also fixed the old, previously broken system generations, not only the newly created one. maybe some boot related references are not traversed while GC'ing? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- If you expect the world to be fair with you because you are fair, you're fooling yourself. Stop bitching about the lion, and get busy learning how not to get eaten.
bug#44944: Unable to log into X session via gdm
Hi, Danny Milosavljevic writes: > The latest guix system reconfigure (of yesterday) left me unable to login into > my X session. guix system rollback DID NOT fix it. > > I would enter my password and it would "try" to login and return right back to > the gdm login screen. > > I've since removed gdm from my OS configuration (because I have to do actual > *work* on this computer), but I think it would have been enough to just > chown /var/lib/gdm and rm ~/.xsession-errors (!) in order to make it work > again. > > Does that mean that user ids are non-reproducible? > > Why not have user_id = hash(user_name) ? Then they *are* reproducible. That'd be cool, but how would you implement such a hash, that returns something fixed between 0 and 1024? That doesn't sound feasible, although I'm no hash function expert. > (I've tried finding the spot where those user accounts are generated/updated > but so far have been unable to) > > Anyway, this is just to record the problem and workaround. I won't do > further research on this problem on it on this computer. > > The "gdm" system account is gone by now because I've removed gdm from the > OS configuration--and I don't plan on adding it ever again. I experienced the exact same problem as you. My topmost /var/lib/gdm directory has the correct permissions, but it contains stale entries that were created in the past by a different GDM user whose ID is no longer the same: --8<---cut here---start->8--- /var/lib/gdm: total 616 drwx-- 1 gdm gdm 46 Sep 16 09:09 . drwxr-xr-x 1 root root222 May 7 20:40 .. drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .cache drwx-- 1 nixbld04 opendht 44 Dec 7 2021 .config -rw--- 1 955 gdm 1146880 Sep 16 09:09 core drwxr-xr-x 1 nixbld04 opendht 10 Dec 7 2021 .local /var/lib/gdm/.cache: total 0 drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 . drwx-- 1 gdm gdm 46 Sep 16 09:09 .. drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 fontconfig drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 ibus drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 mesa_shader_cache /var/lib/gdm/.cache/fontconfig: total 84 drwxr-xr-x 1 nixbld04 opendht 384 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht62 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 18496 Dec 7 2021 23ef510a04af7dd5ac1a2dbd06c4afd1-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 272 Dec 7 2021 269249ae71e4e445ff7f16f21dcb6de5-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 256 Dec 7 2021 50fa4f3b9c91fead50cbfcdae3296c45-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 50584 Dec 7 2021 a927202dec7f348d7a0569dcad9f19a8-le64.cache-7 -rw-r--r-- 1 nixbld04 opendht 200 Dec 7 2021 CACHEDIR.TAG /var/lib/gdm/.cache/ibus: total 0 drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 bus /var/lib/gdm/.cache/ibus/bus: total 172 drwxr-xr-x 1 nixbld04 opendht 16 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 6 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 173300 Dec 7 2021 registry /var/lib/gdm/.cache/mesa_shader_cache: total 36 drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 62 Dec 7 2021 .. drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 02 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 72 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 88 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 a3 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 c4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 f9 -rw-r--r-- 1 nixbld04 opendht 1310728 Dec 7 2021 index /var/lib/gdm/.cache/mesa_shader_cache/02: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 868 Dec 7 2021 f0edfe0ef96096640b39ff4d2786b503a60a43 /var/lib/gdm/.cache/mesa_shader_cache/72: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 989 Dec 7 2021 7cd650943c7a3136f424df6a67c7897f922307 /var/lib/gdm/.cache/mesa_shader_cache/88: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 755 Dec 7 2021 d03ceaeebc55f4b3c972e855775b2c21381b60 /var/lib/gdm/.cache/mesa_shader_cache/a3: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 1187 Dec 7 2021 2d688084f93805f8921dab8d7a8de5e0f1bc66 /var/lib/gdm/.cache/mesa_shader_cache/c4: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04 opendht 34 Dec 7 2021 .. -rw-r--r-- 1 nixbld04 opendht 523 Dec 7 2021 93ffa46c262472c8d01161a581304a790b71ff /var/lib/gdm/.cache/mesa_shader_cache/f9: total 4 drwxr-xr-x 1 nixbld04 opendht 76 Dec 7 2021 . drwxr-xr-x 1 nixbld04
bug#51813: gdm: Unknown failure to launch after installation from guix installer
Hi, Jacob Hrbek writes: > Steps to reproduce: > 0. Get GIGABYTE M1022 > 1. Get the installer for i686-linux from > https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.i686-linux.iso e.g. > using `wget wget > https://ftp.gnu.org/gnu/guix/guix-system-install-1.3.0.i686-linux.iso` > 2. Plug in the USB flash disk that will be used for the installation > 3. Invoke `dd if=path/to/guix-system-install-1.3.0.i686-linux.iso of=/dev/sdX > conv=sync progress=status && sync` wait for it to finish and > then boot the device with it > 4. Finish the installation and reboot > 5. On startup the gdm fails with "Oh no! Something has gone wrong" telling > you to contact yourself for help > 6. Check log in `/var/log/gdm/greeter.log` and fail to find anything useful > (see attachement) > > FWIW: it seems like an issue with gdm on 32-bit system Could you try using the latest CI-baked images such as https://ci.guix.gnu.org/build/1450071/details? And let me know if it still reproduces. Thanks, Maxim
bug#51804: Manual: Add verification of storage drive sanity for the installation
Hi Jacob, Jacob Hrbek writes: > My Guix installation(s) are keep failing, because people keep giving me free > USB drivers that are faulty. > > Proposing to add some method to verify that the USB drive is sane in the > manual for the installation to avoid weird, confusing and infuriating > errors. I honestly think this is outside the scope of the Guix reference manual. There is a wide range of storage devices out there, and checking for their health is not trivial, especially for SMART-less devices like flash thumb drives. Closing. Thanks, Maxim
bug#57864: rust-zstd-sys bundles zstd
Solved as follows in antioxidant (i.e., enable the 'pkg-config' feature
and remove the local copy in a snippet).
diff --git a/antioxidant-packages.scm b/antioxidant-packages.scm
index e851bc9..b0296e7 100644
--- a/antioxidant-packages.scm
+++ b/antioxidant-packages.scm
@@ -4708,6 +4708,7 @@ RFC-compliant `EmailAddress` newtype. ")
;; rust-num-bigint-dig's zeroize feature requires the "derive"
;; feature of rust-zeroize
("rust-zeroize" ,#~'("default" "derive"))
+("rust-zstd-sys" ,#~'("default" "pkg-config" "non-cargo"))
("rust-zip" ,#~'("bzip2" "deflate" "time" "zstd" ; avoid
default "aes-crypto" feature, which requiers an ol
(define %replacements
@@ -5748,6 +5749,8 @@ RFC-compliant `EmailAddress` newtype. ")
(("rust-parking-lot" ,(p rust-parking-lot-0.11 ; test input
("rust-zip" ; new inputs for new version
(("rust-zstd" ,(p rust-zstd-0.9
+("rust-zstd-sys"
+ (("zstd:lib" ,(@ (gnu packages compression) zstd) "lib")))
("sniffglue" (("rust-bstr" ,(@ (gnu packages crates-io)
rust-bstr-0.2))
(define %no-parallel-tests?
@@ -6628,6 +6631,14 @@ RFC-compliant `EmailAddress` newtype. ")
(inherit (package-source pack))
(modules '((guix build utils)))
(snippet #~(delete-file-recursively "source"
+("rust-zstd-sys"
+ ;; Unbundle zstd
+ (origin
+ (inherit (package-source pack))
+ (modules '((guix build utils)))
+ (snippet #~(begin
+ (delete-file-recursively "zstd")
+ (delete-file "zstd.h")
("rust-itoa"
(origin
(inherit (package-source pack))
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
bug#57864: rust-zstd-sys bundles zstd
X-Debbugs-CC: Arun Isaac ^ author of the commit adding the rust-zstd-sys I noticed that the package 'rust-zstd-sys' bundles a copy of zstd. This is against policy for the reasons documented in the manual. This package was added in commit 4402eb48cdd18aed8072696496362f2e774e973f. I'll try unbundling it in antioxidant. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#57840: rust-sqlite3-src bundles sqlite3
Solved locally in antioxidant by adding 'sqlite' to the inputs of rust-sqlite3-src and removing the 'source' directory in a snippet. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#57853: “inappropriate ioctl for device” when running in RStudio Server
When running “guix” in RStudio Server the “terminal-window-size”
procedure triggers an error. (You can ignore the cause of the error,
because I’m running this in a container where
/var/guix/profiles/per-user/rekado doesn’t exist.)
--8<---cut here---start->8---
> system("/bin/guix pull")
guix pull: error: while creating directory
`/var/guix/profiles/per-user/rekado': Permission denied
hint: Backtrace:
18 (primitive-load "/bin/guix")
In guix/ui.scm:
2263:7 17 (run-guix . _)
2226:10 16 (run-guix-command _ . _)
In ice-9/boot-9.scm:
1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
1747:15 14 (with-exception-handler # …)
1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
656:37 12 (thunk)
In guix/status.scm:
815:4 11 (call-with-status-report _ _)
In guix/store.scm:
1318:3 10 (_)
1295:8 9 (call-with-build-handler # …)
In guix/scripts/pull.scm:
526:3 8 (_)
In guix/profiles.scm:
2300:6 7 (ensure-profile-directory)
In ice-9/boot-9.scm:
1685:16 6 (raise-exception _ #:continuable? _)
1685:16 5 (raise-exception _ #:continuable? _)
In guix/ui.scm:
827:16 4 (_ _)
311:42 3 (display-hint "Please create the @file{/var/guix/profi…" …)
In ice-9/boot-9.scm:
1747:15 2 (with-exception-handler # …)
In guix/build/syscalls.scm:
2287:35 1 (_)
2276:8 0 (terminal-window-size _)
guix/build/syscalls.scm:2276:8: In procedure terminal-window-size:
In procedure terminal-window-size: Inappropriate ioctl for device
--8<---cut here---end--->8---
Here yousee that the call to terminal-window-size fails because the
RStudio Server IDE in the web browser is not a true TTY.
“terminal-window-size” should fail gracefully.
--
Ricardo
bug#57827: Shepherd 0.9.2 possible regressions
Hey Chris, > Since empty files is a possibility with wait-for-file, I've sent a patch > to [1] which prevents the eof issue, plus another change to make it > easier to debug. Nice! I wonder if we should maybe block in wait-for-file until the file has some content. In the cgit/gitile tests, we will keep going while the pid file is empty so the nginx server is not maybe completely up yet. > This could be related to the Shepherd upgrade, but only indirectly, as I > think the failure at least for cgit was also timing dependent. Yes looks like so. Thanks, Mathieu
bug#57827: Shepherd 0.9.2 possible regressions
Mathieu Othacehe writes: > Since Shepherd 0.9.2 the following tests are failing: > > * cgit: https://ci.guix.gnu.org/build/1427375/details > * gitile https://ci.guix.gnu.org/build/1427377/details > > It seems that an unexpected # object is received on the marionette > socket. I had a look at the cgit system test, and it seems like this # is coming from the NGinx pid file being empty. Since empty files is a possibility with wait-for-file, I've sent a patch to [1] which prevents the eof issue, plus another change to make it easier to debug. 1: https://issues.guix.gnu.org/57850 With that change, both of the above tests seem to pass for me. This could be related to the Shepherd upgrade, but only indirectly, as I think the failure at least for cgit was also timing dependent. Chris signature.asc Description: PGP signature
bug#57844: Shepherd fails to start in user session ~50% of the time
Hi Guix! I've been using Guix on Archlinux for a little while now, and ever since I've started using Guix Home on my laptop to start up user-level services I've been having the issue that about 50% of the time when I boot my laptop shepherd fails to start. My .xsession-errors says: > shepherd: while opening socket '/run/user/1000/shepherd/socket': bind: > Address already in use and looking at my shepherd log: > 2022-09-15 11:47:18 Service root has been started. > 2022-09-15 11:47:18 Service root has been started. > 2022-09-15 11:47:19 Starting services... > 2022-09-15 11:47:19 Starting services... > 2022-09-15 11:47:19 Exiting shepherd... > 2022-09-15 11:47:19 Service dunst has been started. > 2022-09-15 11:47:19 Service unclutter has been started. > 2022-09-15 11:47:19 Service syncthing has been started. > 2022-09-15 11:47:19 Service polybar has been started. > 2022-09-15 11:47:19 Service cmst has been started. > 2022-09-15 11:47:19 Service kdeconnect has been started. > 2022-09-15 11:47:20 Service xbindkeys has been started. > 2022-09-15 11:47:20 Service picom has been started. > 2022-09-15 11:47:20 Service xmodmap has been started. > 2022-09-15 11:47:20 Service redshift has been started. > 2022-09-15 11:47:20 Exiting shepherd... > 2022-09-15 11:47:20 Service syncthing has been stopped. > 2022-09-15 11:47:20 Service xbindkeys has been stopped. > 2022-09-15 11:47:20 Service redshift has been stopped. > 2022-09-15 11:47:20 Service cmst has been stopped. > 2022-09-15 11:47:20 Service kdeconnect has been stopped. > 2022-09-15 11:47:20 Service polybar has been stopped. > 2022-09-15 11:47:20 Service dunst has been stopped. > 2022-09-15 11:47:20 Service picom has been stopped. > 2022-09-15 11:47:20 Service unclutter has been stopped. > 2022-09-15 11:47:20 Exiting. It looks like it starts twice and then exits both, but I'm not sure why. I'm guessing it's the ~/.guix-home/activate and ~/.guix-home/on-first-login that are trying to start it. I'm not sure what other information I can provide you that will help, so please let me know! Cheers, Tom
