bug#70897: Guix system hangs on boot with LUKS root partition
Hi Ludo', I wanted to let you know that I have figured out what the failure is, and it turned out to be a customization buried within some shared operating-system configuration that I had forgotten about (and wasn't finding because it was due to a missing import, and simply grepping for "system*/tty" didn't match the file that was missing the import). Thank you for your time and help, and sorry about the red herring of a bug report! Cheers, Kaelyn
bug#70897: Guix system hangs on boot with LUKS root partition
Hi Ludo', On Monday, May 13th, 2024 at 3:14 AM, Ludovic Courtès wrote: > > > Hi Kaelyn, > > Kaelyn kaelyn.al...@protonmail.com skribis: > > > I recently updated my systems after finally finding > > https://issues.guix.gnu.org/70051 and seeing the issue I was having with > > booting with a non-root LUKS partition configured had been fixed. After > > updating to a commit past these two: > > > > 49f82fca41 mapped-devices: luks: Specify modules needed at the top-level. > > 6062339156 mapped-devices: can specify modules to > > import. > > > > I am now seeing a different error, which I am pretty sure is related > > to the module import changes in 49f82fca41. The error I get is about > > an unknown symbol "system*/tty" when the initramfs tries to prompt for > > a password to unlock the LUKS partition containing the root > > filesystem. > > > To be clear, you have both a LUKS-encrypted root and a non-root > LUKS-encrypted partition? > > (FWIW I tested (1) with a LUKS-encrypted root, and (2) with a cleartext > root and LUKS-encrypted /home. The bug you mention affected #2.) More accurately, I have one system that has a mirrored btrfs root with two LUKS-encrypted partitions (and a few quirks in the setup that make rebooting a bit tedious, such as grub slowly unlocking two drives, and a ZFS pool that has to be unlocked manually after boot), and one with a single LUKS-encrypted btrfs partition. I hit (2) on the first system about a month ago when I updated both, with the second system booting fine. I hit (1) on the second system when updating much more recently after seeing (2) was fixed, and hadn't tried rebooting the first system with the new generation. > Could you share your OS config or a relevant subset thereof? My full OS config is decidedly non-trivial, with parts (e.g. common services and user accounts) shared between host configurations. The mapped-devices and file-systems fragments for the two systems are below. For the first system, with the mirrored btrfs root: (mapped-devices (list (mapped-device (source (uuid "7bcca55e-8a41-44a8-beab-2047eed0af41")) (target "cryptroot1") (type luks-device-mapping)) (mapped-device (source (uuid "9472b8ae-c90c-4712-b90d-ca07602514d7")) (target "cryptroot2") (type luks-device-mapping)) )) (file-systems (let ((rootfs (file-system (mount-point "/") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@guix") (dependencies mapped-devices (cons* rootfs (file-system (mount-point "/boot/efi") (device (file-system-label "EFI")) (type "vfat") (mount-may-fail? #t) (dependencies mapped-devices)) (file-system (mount-point "/gnu") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@gnu_store") (dependencies (cons rootfs mapped-devices))) %base-file-systems The second system, with the single-drive encrypted btrfs root: (mapped-devices (list (mapped-device (source (uuid "e6aaafc5-49cb-477b-a665-daf065611195")) (target "cryptroot1") (type luks-device-mapping)) )) (file-systems (let ((rootfs (file-system (mount-point "/") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@guix") (dependencies mapped-devices (cons* rootfs (file-system (mount-point "/boot/efi") (device (file-system-label "EFI")) (type "vfat") (mount-may-fail? #t) (dependencies mapped-devices)) (file-system (mount-point "/gnu") (device "/dev/mapper/cryptroot1") (type "btrfs") (check? #f) (options "compress=zstd,subvol=@gnu_store") (dependencies (cons rootfs mapped-devices))) %common-file-systems (Note the %common-file-systems is simply %base-file-systems plus a couple of NFS mounts from the first system, which are shared with several computers.) For both computers, I make use of the 6.1 or 6.6 LTS kernels since I also use ZFS. When I hit (1), I eventually figured out where the hang during boot was happening by removing "quiet" from the kernel command line, which also caused shepherd to be more verbose (something I hadn't realized). When I hit (2), the boot process was still in the initrd due to failing to unlock and mount the root filesystem. If there is any further information I can provide, please let me know. Cheers, Kaelyn > > > I
bug#70897: Guix system hangs on boot with LUKS root partition
Hi Ludo' and others, I recently updated my systems after finally finding https://issues.guix.gnu.org/70051 and seeing the issue I was having with booting with a non-root LUKS partition configured had been fixed. After updating to a commit past these two: 49f82fca41 mapped-devices: luks: Specify modules needed at the top-level. 6062339156 mapped-devices: can specify modules to import. I am now seeing a different error, which I am pretty sure is related to the module import changes in 49f82fca41. The error I get is about an unknown symbol "system*/tty" when the initramfs tries to prompt for a password to unlock the LUKS partition containing the root filesystem. I don't know how the module plumbing of Shepherd and the generated initramfs work, but I suspect the fix for Shepherd opening LUKS partition broke the import of system*/tty in the initramfs (for example, at the early REPL that booting my latest system generation ends up at, system*/tty is undefined initially, but after evaluating "(use-modules (gnu build file-systems))" system*/tty resolves to a procedure as exected--so the module is at least present in the initramfs). I have encountered this error with two different systems, and I believe the reproduction is simply trying to open a LUKS device without a keyfile so that a password prompt is necessary. Cheers, Kaelyn
bug#58719: core-updates: Build failure for file on i686-linux
Hi Maxim, On Sunday, December 17th, 2023 at 2:15 PM, Maxim Cournoyer wrote: > > Hello, > > Kaelyn kaelyn.al...@protonmail.com writes: > > > As a bit of followup, this bug still exists with the latest > > core-updates commit. This not only affects i686 systems, but also some > > x86_64 packages like wine/wine64 which require a 32-bit build in > > addition to a 64-bit one. > > > Is this problem known upstream? If not, we should forward it to them. Thank you for the follow-up. I'm fairly certain this bug is outdated and can be closed now (it was from a previous iteration of core-updates). I don't remember what fixed it (possibly the update of file from 5.42 to 5.44), but the issue did get resolved by the time core-updates was merged and I haven't run into issues building wine since then. Cheers, Kaelyn > > -- > Thanks, > Maxim
bug#58251: Mesa missing patches for Vulkan shared libraries
The manifest files have been fixed in mesa to include the path to the vulkan layer shared objects in commit 02995444dbe9861c32b6e2cdbfb7a7b2affe2c2b.
bug#63267: gcc-toolchain is missing libstdc++.so
--- Original Message --- On Friday, May 5th, 2023 at 8:59 PM, John Kehayias wrote: > > > Hi Kaelyn, > > On Thu, May 04, 2023 at 11:45 PM, Kaelyn wrote: > > > --- Original Message --- > > I wasn't sure the best place to share it, so I've attached my "run" > > script for running the binary download of PolyMC in a container. It is > > both a shell script and a guix package manifest, and is the one place > > so far I've worked around the removal of gcc:lib. The main > > program-specific bits are what CMD defaults to and which packages need > > to be included (most of the various shares are to get things like > > hardware 3D, pulseaudio, and dbus working and aren't all always > > needed). It also contains the original manifest commented-out for > > comparison. Hope it can be of help to folks! > > > Thanks, that's a nice little hack! Just something very minor I > noticed, but you don't need to specify glibc directly for the -F (FHS) > option in guix shell, as it will automatically include the (modified) > glibc. Thanks! A small side note: I have glibc in there mainly so ldd is available for debugging problems or getting new binaries working (I think the comment with it is a remnant of an older version of the manifest from before "-F" was added to "guix shell"). Cheers, Kaelyn
bug#63267: gcc-toolchain is missing libstdc++.so
--- Original Message --- On Thursday, May 4th, 2023 at 9:50 PM, John Kehayias wrote: > > I have similar use cases of FHS containers to run binaries (primarily > > games). I recently ran into the issue of gcc:lib going away and no > > output from a visible package providing libstdc++. My current > > workaround was to implement a replacement for specifications->manifest > > that could handle packages and '(package "output") pairs in addition > > to strings, so that I could include `(,(@@ (gnu packages gcc) gcc) > > "lib") in place of "gcc:lib". Internally it resolves package strings > > to packages with specification->package, then passes the package and > > optional output specifier to package->manifest-entry. But I digress a > > little... > > > Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if > this should be something we should have more easily anyway. I wasn't sure the best place to share it, so I've attached my "run" script for running the binary download of PolyMC in a container. It is both a shell script and a guix package manifest, and is the one place so far I've worked around the removal of gcc:lib. The main program-specific bits are what CMD defaults to and which packages need to be included (most of the various shares are to get things like hardware 3D, pulseaudio, and dbus working and aren't all always needed). It also contains the original manifest commented-out for comparison. Hope it can be of help to folks! Cheers, Kaelyn run Description: Binary data
bug#63267: gcc-toolchain is missing libstdc++.so
Hi, --- Original Message --- On Thursday, May 4th, 2023 at 3:26 PM, John Kehayias wrote: > > Hi Christopher, > > On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote: > > > Sorry for the spam; Resending this without the bugs address, but with > > the issue's address. > > > > Christopher Rodriguez yewsc...@gmail.com writes: > > > > > Hello All, > > > > > > I noticed today that libstdc++.so.1 (and some others), which used to be > > > part of gcc:lib, are not included in any of the outputs of the > > > superceding `gcc-toolchain` package. > > > > > > Is there another method for getting these needed shared libraries in a > > > guix system at this point? It's entirely possible I'm missing something. > > > > > > I am CCing guix-de...@gnu.org per podiki[m]'s request. > > > > > > Thanks! > > > Thanks for opening this and cc'ing; this has come up with some > frequency on IRC, especially recently. In discussing there today, the > current reasoning is that usually one will just call g++ which knows > how to find libstdc++. So, gcc-toolchain does not include gcc:lib as > part of what it makes available. > > I think what we (and when this comes up, others) are getting at are > some edge cases or different use cases where one wants to directly get > at libstdc++. Previously it was more direct to use gcc:lib; of course > one still can in code and/or cli with the proper call. For example, > guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show > the lib output of the (hidden) gcc package. Though I'm not sure how to > select just the lib output here. > > My use case currently is in the FHS container where a binary wants to > find some libraries directly. Previously one would include the gcc:lib > package output in the guix shell call. Now some of those libraries can > be found elsewhere, like libgccjit, but libstdc++ seems to be the > trickier one. Open to other suggestions/workarounds, or thoughts on if > it is worthwhile to include gcc:lib in the gcc-toolchain package (or > make a gcc-toolchain:lib output?). I have similar use cases of FHS containers to run binaries (primarily games). I recently ran into the issue of gcc:lib going away and no output from a visible package providing libstdc++. My current workaround was to implement a replacement for specifications->manifest that could handle packages and '(package "output") pairs in addition to strings, so that I could include `(,(@@ (gnu packages gcc) gcc) "lib") in place of "gcc:lib". Internally it resolves package strings to packages with specification->package, then passes the package and optional output specifier to package->manifest-entry. But I digress a little... Regarding solutions, I would prefer to have libstdc++ in it's own package or output rather than bundled into gcc-toolchain:out; it feels messy and against the grain of isolating programs in containers if I have to make the gcc and g++ compilers available in the container in order to run a program that needs libstdc++. Cheers, Kaelyn
bug#58719: core-updates: Build failure for file on i686-linux
As a bit of followup, this bug still exists with the latest core-updates commit. This not only affects i686 systems, but also some x86_64 packages like wine/wine64 which require a 32-bit build in addition to a 64-bit one.
bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux
Here is a revised diff with comments added for the flags. diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm index 8343f8ffc6..ea7f0f19e9 100644 --- a/gnu/packages/libreoffice.scm +++ b/gnu/packages/libreoffice.scm @@ -1235,6 +1235,12 @@ (define (install-appdata app) ;; when our default compiler is >=GCC 6. "--disable-pdfium" "--without-doxygen" + ;; Enable building with LTO to avoid linker errors about + ;; non-virtual thunks on i686-linux. + "--enable-lto" + ;; Disable galleries to avoid errors rebuilding the Gtk icon + ;; cache, at least on i686-linux. + "--without-galleries" "--enable-build-opensymbol"))) (native-inputs (list bison
bug#58031: LibreOffice 7.3.5.2 is not reproducible
Hi, >From some local testing, it appears the timestamps in bpmn.otg can be >addressed by adding "otg" to the list of file extensions the existing >'reset-zip-timestamps phase looks for: diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm index 8343f8ffc6..69319177db 100644 --- a/gnu/packages/libreoffice.scm +++ b/gnu/packages/libreoffice.scm @@ -1159,7 +1159,7 @@ (define-public libreoffice (for-each (lambda (file) (invoke "ziptime" file)) ;; So many different extensions for .zip files. -(find-files #$output "\\.(bau|dat|otp|ott|zip)$" +(find-files #$output "\\.(bau|dat|otg|otp|ott|zip)$" (add-after 'install 'bin-and-desktop-install ;; Create 'soffice' and 'libreoffice' symlinks to the executable ;; script.
bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux
Sorry, I messed up the patch a little as I wanted to get the error message that prompted adding "--without-galleries". It should be: diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm index 8343f8ffc6..7fb3fe1327 100644 --- a/gnu/packages/libreoffice.scm +++ b/gnu/packages/libreoffice.scm @@ -1235,6 +1235,8 @@ (define (install-appdata app) ;; when our default compiler is >=GCC 6. "--disable-pdfium" "--without-doxygen" + "--enable-lto" + "--without-galleries" "--enable-build-opensymbol"))) (native-inputs (list bison
bug#59519: LibreOffice 7.3.5.2 fails to build on i686-linux
Hi,
I was able to build libreoffice for i686-linux by adding "--enable-lto" and
"--without-galleries" to the configure flags. The former seemed to resolve the
linking issue, and the latter was to deal with the build failing because of 0
themes being found.
That error was:
[build GAL] backgrounds
[build GAL] sounds
[build MOD] postprocess
Work on gallery
'file:///tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/Gallery/backgrounds'
Existing themes: 0
make[1]: ***
[/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/solenv/gbuild/Gallery.mk:57:
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/Gallery/backgrounds.done]
Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: ***
[/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/solenv/gbuild/Gallery.mk:57:
/tmp/guix-build-libreoffice-7.3.5.2.drv-0/libreoffice-7.3.5.2/workdir/Gallery/sounds.done]
Error 1
make: *** [Makefile:289: build] Error 2
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("-j" "24"
"gtk_update_icon_cache=true") exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 954.9 seconds
command "make" "-j" "24" "gtk_update_icon_cache=true" failed with status 2
And a basic patch to add the two flags:
diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm
index 8343f8ffc6..9ded4b5e5e 100644
--- a/gnu/packages/libreoffice.scm
+++ b/gnu/packages/libreoffice.scm
@@ -1235,6 +1235,8 @@ (define (install-appdata app)
;; when our default compiler is >=GCC 6.
"--disable-pdfium"
"--without-doxygen"
+ "--enable-lto"
+ ;; "--without-galleries"
"--enable-build-opensymbol")))
(native-inputs
(list bison
bug#58251: Mesa missing patches for Vulkan shared libraries
I've just created https://issues.guix.gnu.org/59453 with the patch to mesa on core-updates to fix the library paths in the Vulkan layer manifests. I split the change out from my previous mesa update patch (https://issues.guix.gnu.org/58566) as mesa on core-updates has since been updated to version 22.2.4.
bug#59279: MPV does not work on X11
Hi, I recently encountered the same error with mpv 0.35 on X11, and can confirm that the patch in https://issues.guix.gnu.org/59378 fixes the playback error. Cheers, Kaelyn
bug#58719: core-updates: Build failure for file on i686-linux
Hi, Trying to build 'wine-minimal for x86-64 on core-updates, the following error is hit while building 'file for i686-linux: /tmp/guix-build-file-5.42.drv-0/file-5.42/src/.libs/file: symbol lookup error: /gnu/store/wb8f0ydwl7458ixgsmx65x5ni54c7zgk-glibc-mesboot-2.16.0/lib/libpthread.so.0: undefined symbol: h_errno, version GLIBC_PRIVATE make[2]: *** [Makefile:857: magic.mgc] Error 127 make[2]: Leaving directory '/tmp/guix-build-file-5.42.drv-0/file-5.42/magic' make[1]: *** [Makefile:462: all-recursive] Error 1 make[1]: Leaving directory '/tmp/guix-build-file-5.42.drv-0/file-5.42' make: *** [Makefile:371: all] Error 2 The build failure can be easily reproduced with `./pre-inst-env guix build --system=i686-linux file`, and I have bisected the failure on core-updates to commit 25b30622b4a77cd4b2965b9d62fa310a22413d54 "gnu: glibc: Update to 2.35.". I suspect this may be causing many i686 failures on core-updates since `./pre-inst-env guix refresh -l file` reports 7732 packages that would have to be built to ensure 16065 dependent packages are rebuilt. Cheers, Kaelyn
bug#58251: Mesa missing patches for Vulkan shared libraries
I've just sent in https://issues.guix.gnu.org/58566 to update mesa on core-updates, and that patch includes a new phase to fix up the Vulkan layer manifests similar to how I'd done for vulkan-validationlayers in https://issues.guix.gnu.org/57297.
bug#55854: "guix refresh" doesn't handle older versions like gtk+@2
When attempting a mass "guix refresh -ru" of system and home profile packages, some bogus updates were encountered. One category of those is older/multiple versions of a package all being updated to the latest, as was seen with gtk+@2, libsigc++@2, and the gtkmm packages. For example: $ guix refresh gtk+@2 gnu/packages/gtk.scm:851:13: gtk+ would be upgraded from 2.24.33 to 3.94.0 Per the IRC discussion at https://logs.guix.gnu.org/guix/2022-06-08.log#185744, those packages should only be upgraded within the same major version. Maxime suggested adding a REQUIRED-MAJOR-VERSION field to such packages so they are updated correctly: https://logs.guix.gnu.org/guix/2022-06-08.log#185842 (Side note: I believe gtk+ uses a numbering scheme of x.9y.0 for pre-releases of the (x+1).0.0 release; i.e. gtk+ 3.94.0 is a pre-release of gtk 4.)
bug#55585: inetd-based bitlbee service terminating on new connections
On Wednesday, May 25th, 2022 at 3:04 AM, Ludovic Courtès wrote: > Hi Kaelyn, > > Kaelyn kaelyn.al...@protonmail.com skribis: > > > Recently I upgraded my server running bitlbee for the first time in a few > > weeks (from guix commit 3363f2c878 to 14384d9586), and after rebooting I > > was unable to connect to bitlbee because the child service spawned on > > connect terminates within a few seconds. I'm not certain, but I believe > > commit 211fe3f66e "services: bitlbee: Use 'make-inetd-constructor'." is the > > culprit. From /var/log/messages (with the IP address edited out) when I try > > to connect: > > > > May 21 21:24:31 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 > > from W.X.Y.Z:38014. > > May 21 21:25:21 localhost shepherd[1]: 0 connections still in use after > > bitlbee-3 termination. > > May 21 21:25:21 localhost shepherd[1]: Service bitlbee-3 has been disabled. > > May 21 21:25:21 localhost shepherd[1]: Transient service bitlbee-3 > > terminated, now unregistered. > > May 21 21:25:26 localhost shepherd[1]: Accepted connection on 0.0.0.0:6969 > > from W.X.Y.Z:46492. > > May 21 21:25:26 localhost shepherd[1]: Service bitlbee-4 has been started. > > May 21 21:25:26 localhost shepherd[1]: 0 connections still in use after > > bitlbee-4 termination. > > May 21 21:25:26 localhost shepherd[1]: Service bitlbee-4 has been disabled. > > May 21 21:25:26 localhost shepherd[1]: Transient service bitlbee-4 > > terminated, now unregistered. > > > What configuration of Bitlbee are you using? > > I have this: > > (service bitlbee-service-type > (bitlbee-configuration > (bitlbee bitlbee-purple) > (plugins (list purple-mattermost > > and it works well, modulo warnings from libpurple about locale > conversion errors it seems (I haven’t investigated, but it’s harmless). My bitlbee config (which I first added about 7 months ago) is simply: (service bitlbee-service-type (bitlbee-configuration (interface "0.0.0.0") (port 6969))) and I use it as a bridge between znc and a local/private prosody server. > > What do you see in your IRC client when connecting? I've since rolled back the system config of the server to the previously running version, but basically znc kept connecting and getting disconnected. >From the znc status log (~/.znc/moddata/log///status/2022-05-21.log) around the same time as the syslog messages: [21:25:26] Disconnected from IRC (jibber +6969) [21:25:56] Connected to IRC (jibber 6969) [21:27:57] Disconnected from IRC (jibber 6969) [21:27:57] Disconnected from IRC (jibber +6969) [21:28:56] Disconnected from IRC (jibber +6969) [21:29:26] Connected to IRC (jibber 6969) [21:53:52] Disconnected from IRC (jibber +6969) > > Can you reproduce the problem in a VM with ‘guix system vm’? I'm uncertain if I can; I haven't really used 'guix system vm' before, so I'll have to play around with it a bit. I think the most notable difference between your config and mine is that I use the default `bitlbee` package instead of overriding it to use `bitlbee-purple` (since I didn't need any protocol support other than XMPP, which is one of the two non-purple protocol plugins). Thank you for your assistance! Cheers, Kaelyn > > Thanks in advance, > Ludo’.
bug#55585: inetd-based bitlbee service terminating on new connections
Hi, Recently I upgraded my server running bitlbee for the first time in a few weeks (from guix commit 3363f2c878 to 14384d9586), and after rebooting I was unable to connect to bitlbee because the child service spawned on connect terminates within a few seconds. I'm not certain, but I believe commit 211fe3f66e "services: bitlbee: Use 'make-inetd-constructor'." is the culprit. From /var/log/messages (with the IP address edited out) when I try to connect: May 21 21:24:31 localhost shepherd[1]: Accepted connection on 0.0.0.0:22 from W.X.Y.Z:38014. May 21 21:25:21 localhost shepherd[1]: 0 connections still in use after bitlbee-3 termination. May 21 21:25:21 localhost shepherd[1]: Service bitlbee-3 has been disabled. May 21 21:25:21 localhost shepherd[1]: Transient service bitlbee-3 terminated, now unregistered. May 21 21:25:26 localhost shepherd[1]: Accepted connection on 0.0.0.0:6969 from W.X.Y.Z:46492. May 21 21:25:26 localhost shepherd[1]: Service bitlbee-4 has been started. May 21 21:25:26 localhost shepherd[1]: 0 connections still in use after bitlbee-4 termination. May 21 21:25:26 localhost shepherd[1]: Service bitlbee-4 has been disabled. May 21 21:25:26 localhost shepherd[1]: Transient service bitlbee-4 terminated, now unregistered. May 21 21:25:56 localhost shepherd[1]: Accepted connection on 0.0.0.0:6969 from W.X.Y.Z:46494. May 21 21:25:56 localhost shepherd[1]: Service bitlbee-5 has been started. May 21 21:27:57 localhost shepherd[1]: Service bitlbee-5 has been stopped. May 21 21:27:57 localhost shepherd[1]: Transient service bitlbee-5 unregistered. May 21 21:27:57 localhost shepherd[1]: Accepted connection on 0.0.0.0:6969 from W.X.Y.Z:46496. May 21 21:27:57 localhost shepherd[1]: Service bitlbee-6 has been started. May 21 21:27:57 localhost shepherd[1]: 1 connection still in use after bitlbee-6 termination. May 21 21:27:57 localhost shepherd[1]: Service bitlbee-6 has been disabled. May 21 21:27:57 localhost shepherd[1]: Transient service bitlbee-6 terminated, now unregistered. May 21 21:28:02 localhost shepherd[1]: Service bitlbee has been stopped. May 21 21:28:28 localhost shepherd[1]: Service bitlbee has been started. May 21 21:28:56 localhost shepherd[1]: Accepted connection on 0.0.0.0:6969 from W.X.Y.Z:46500. May 21 21:28:56 localhost shepherd[1]: Service bitlbee-7 has been started. May 21 21:28:56 localhost shepherd[1]: 1 connection still in use after bitlbee-7 termination. May 21 21:28:56 localhost shepherd[1]: Service bitlbee-7 has been disabled. May 21 21:28:56 localhost shepherd[1]: Transient service bitlbee-7 terminated, now unregistered. May 21 21:29:26 localhost shepherd[1]: Accepted connection on 0.0.0.0:6969 from W.X.Y.Z:46502. May 21 21:29:26 localhost shepherd[1]: Service bitlbee-8 has been started. May 21 21:29:45 localhost shepherd[1]: Service bitlbee has been stopped. May 21 21:29:51 localhost shepherd[1]: 1 connection still in use after bitlbee-8 termination. May 21 21:29:51 localhost shepherd[1]: Service bitlbee-8 has been disabled. May 21 21:29:51 localhost shepherd[1]: Transient service bitlbee-8 terminated, now unregistered. Cheers, Kaelyn Sent with ProtonMail secure email.
bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
Hi, ‐‐‐ Original Message ‐‐‐ On Wednesday, July 21st, 2021 at 1:08 AM, Chris Marusich wrote: > Hi, > > I need a little help figuring out how to use gdb in Guix for bug 48941: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48941 > > Here's the situation. A libfaketime test hangs forever. Upstream > > suggested I debug it. I'm trying to, but gdb errors out. What am I > > doing wrong? It's probably something simple, but I can't see what. > > I'll describe what I've done. First, I started a build like so: > > ./pre-inst-env guix build --keep-failed libfaketime > > While the problematic test hung, I found the PID of the test and killed > > it. This caused the build to fail, leaving the build environment for me > > to play around in. > > I entered a pure environment that contains all the things I need to > > debug the test (gcc 10.3.0 is currently the default gcc on > > core-updates): > > ./pre-inst-env guix environment --pure libfaketime --ad-hoc > gcc-toolchain@10.3.0 gcc-toolchain@10.3.0:debug gdb > > In the pure environment, I confirmed I can build and run the hanging > > test via the following commands (I added -g in order to get debug > > symbols): > > make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc > PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix > > make FAKETIME_COMPILE_CFLAGS='-DFORCE_MONOTONIC_FIX -g' CC=gcc > PREFIX=/tmp/guix-build-libfaketime-0.9.9.drv-0/myprefix test > > OK, so I can trigger the hang. Great! Next step, fire up GDB: > > --8<---cut here---start->8--- > > [0] [env] marusich@suzaku:/tmp/guix-build-libfaketime-0.9.9.drv-0/source/test > > $ gdb ./timetest > > GNU gdb (GDB) 10.2 > > Copyright (C) 2021 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "powerpc64le-unknown-linux-gnu". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > https://www.gnu.org/software/gdb/bugs/. > > Find the GDB manual and other documentation resources online at: > > http://www.gnu.org/software/gdb/documentation/. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from ./timetest... > > (gdb) > > --8<---cut here---end--->8--- > > The debug symbols provided by gcc-toolchain@10.3.0:debug are under > > $GUIX_ENVIRONMENT/lib/debug. This is the value of GUIX_ENVIRONMENT: > > --8<---cut here---start->8--- > > $ echo $GUIX_ENVIRONMENT > > /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile > > --8<---cut here---end--->8--- > > By the way, this directory corresponds to glibc 2.33: > > --8<---cut here---start->8--- > > $ realpath /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug > > /gnu/store/8akrlhc25d7xvi85gzvginw0vdi4zyg4-glibc-2.33-debug/lib/debug > > --8<---cut here---end--->8--- > > Let's tell GDB where to find those debug symbols: > > (gdb) set debug-file-directory > /gnu/store/32fjhp30k34fh0g9f1gmgcj8pc5wldq6-profile/lib/debug > > Let's also tell GDB to set the environment variables that upstream > > recommended when running the test program: > > --8<---cut here---start->8--- > > (gdb) set environment LD_PRELOAD=../src/libfaketime.so.1 > > (gdb) set environment FAKETIME=-10d > > (gdb) set environment NO_FAKE_STAT=1 > > --8<---cut here---end--->8--- > > Now run it: > > --8<---cut here---start->8--- > > (gdb) run > > Starting program: /tmp/guix-build-libfaketime-0.9.9.drv-0/source/test/timetest > > /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.33' not found > (required by ../src/libfaketime.so.1) /bin/sh: > /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found > (required by > /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libpthread.so.0) Are you using Guix on a foreign distro? This line looks like your distro's normal libc.so was being used and it was from glibc-2.31 or older. The x86-64 systems I have that run pure Guix don't have any /lib*/ directories. You might try running gdb with LD_LIBRARY_PATH=/gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib to have the Guix libc.so picked up before the other one. HTH Cheers, Kaelyn > > /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.32' not found > (required by > /gnu/store/kmblbljiygayhlc5gb02an9imhy90ws9-glibc-2.33/lib/libdl.so.2) > /bin/sh: /lib/powerpc64le-linux-gnu/libc.so.6: version` GLIBC_2.32' not found >
