bug#59474: Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros
On 2022-11-22 08:09, Liliana Marie Prikler wrote: > Am Montag, dem 21.11.2022 um 22:02 -0800 schrieb Matt Armstrong: >> The first thing I see is that $HOME/.guix-home/seutp-environment is >> modifying various XDG_ variables incorrectly. It prepends new values >> without honor the variable's default value if it doesn't happen to be >> set already. > This is a known problem with Debian. Unlike Ubuntu, which relies on > Flatpak and Snaps for its basic operations, Debian doesn't and hence > hasn't set up these variables explicitly. Note that this isn't unique > to Guix Home or even just Guix. > >> For example, if XDG_DATA_DIRS is not set its default value is >> "/usr/local/share/:/usr/share/". > None of these directories exist in Guix System. Assuming them would be > a fault. Note that the install script you're meant to use already > initializes these variables since July [1]. > I understand the inconvinience, but not sure that it has to be fixed on Guix Home side. According to the specification it's a fallback value not a default value. --8<---cut here---start->8--- If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used. --8<---cut here---end--->8--- XDG_DATA_DIRS is not empty in our case and hence /usr/local/share and /usr/share doesn't have to be used. If it's critical for operation it should be set before ~/.guix-home/setup-environment called, I would say it looks like a debian bug, not Guix Home. They same thing is true for XDG_CONFIG_DIRS. >> XDG_STATE_HOME is set to a non-standard value. In the current XDG >> Base Directory Specification it defaults to "$HOME/.local/state", but >> Guix Home sets it to "$HOME/.local/var/lib". > This is a genuine bug with Guix Home. > >> XDG_LOG_HOME is a non-standard variable. The spec suggests that logs >> should go in XDG_STATE_HOME. Why not a establish a GUIX_LOG_HOME >> variable instead? (if it ever does become a standard XDG variable, >> its default may not be the same one picked by Guix Home, causing the >> same issue as above). > Another genuine bug with Guix Home, although the variable does predate > our support for XDG_STATE_HOME. I suggest finding all uses of this > variable in Guix Home and replacing them accordingly. > XDG_STATE_HOME and XDG_LOG_HOME apppeared in Guix Home before they were described in xdg base directory specification, so the values was picked to mimic FHS. Probably they should be adjusted to the values defined in specification. >> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to >> do -- it is the job of whatever logs the user in. > I'm unsure about that one. > If it's set by elogind or whatever - cool, we will use value provided, if not we explicitly set it, looks ok to me. >> XDG_CACHE_HOME, XDG_CONFIG_HOME, XDG_DATA_HOME are set to their >> defaults unnecessarily. > Explicit is better than implicit. > > Cheers > > > [1] > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=23aafc800c9e678662766440916449ec5bbce830 > > > > -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#60026: Failed to compute derivation bug
Building from this channel: guix https://git.savannah.gnu.org/git/guix.git e84042f Computing Guix derivation for 'x86_64-linux'... |guix pull: error: You found a bug: the program '/gnu/store/2xp4c2dsiyjpfa uix-derivation' failed to compute the derivation for Guix (version: "e84042fdd4ac2f903224e1b5f366537a22b4d593"; system: "x86_64-linux"; host version: "1.2.0"; pull-version: 1).
bug#60002: installer console garbled on 1984.is VPS
> So the admins are using a Web interface to QEMU. Which one? What -vga > option is it using? i'll ask them and report back. > Perhaps when in GRUB, press E to edit the linux boot command-line and > append to it: nomodeset this didn't help. the behavior appears to be the exact same. > IIRC there had been discussions about QEMU Bochs graphics and such, but > I can’t find them. > > > maybe the installer could be extended with something to start a > > temporary shell to configure te network, without the need to switch > > virtual consoles? > > > I don’t understand this. Can others help? let me put this another way: assume that 1) it's not possible to press CTRL+ALT+Fn to switch virtual consoles, and 2) there is no DHCP configured on the machine's network. this means that the installation is not possible, becuse it's stuck at checking for a functional network upstream. if there was a menu entry to start a temporary shell, then i could configure the network in that shell, exit the shell, and press retry in the installer's menu. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Do not be dismayed by the brokenness of the world. All things break. And all things can be mended. Not with time, as they say, but with intention. So go. Love intentionally, extravagantly, unconditionally. The broken world waits in darkness for the light that is you.” — L. R. Knost
bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Hi Florian,
"pelzflorian (Florian Pelz)" skribis:
> Just now I tried the installer on an AMD desktop but the graphical
> installer screen stays black. Same on an AMD laptop. After switching
> to another TTY, dmesg tells me this:
>
>> [ 11.625264] shepherd[1]: Service host-name has been started.
>> [ 11.625839] shepherd[1]: Service user-homes has been started.
>> [ 11.629846] shepherd[1]:
>> [ 11.630078] [
>> [ 11.630230] modprobe
>> [ 11.630382] ]
>> [ 11.630592] modprobe: FATAL: Module uvesafb not found in directory
>> /lib/modules/6.0.10-gnu
[...]
> @@ -289,11 +289,18 @@ (define (uvesafb-shepherd-service _)
> (provision '(maybe-uvesafb))
> (requirement '(file-systems))
> (start #~(lambda ()
> -(or (file-exists? "/dev/fb0")
> -(invoke #+(file-append kmod "/bin/modprobe")
> + (define (start-uvesafb)
> + ;; HOW TO DO THIS THE RIGHT WAY??
> + (if (file-exists? "/run/current-system/kernel/lib\
> +/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz")
> + (invoke #+(file-append kmod "/bin/modprobe")
> "uvesafb"
> (string-append "v86d=" #$v86d "/sbin/v86d")
> -"mode_option=1024x768"
> +"mode_option=1024x768")
The ‘kmod’ package is patched to honor $LINUX_MODULE_DIRECTORY.
However, that variable is unset here:
--8<---cut here---start->8---
$ sudo cat /proc/1/environ |xargs -0
HOME=/ TERM=linux
BOOT_IMAGE=/gnu/store/04ac4skvnrfdsdw7z3rl3ya8spcgsn6g-linux-libre-6.0.10/bzImage
PATH=/gnu/store/zyk2b4zmy3vcaqs67s2czb6nsrbf3b68-e2fsck-static-1.46.4/sbin:/gnu/store/cchslqkqm3qix71bsjr72mw9fd85p8a5-loadkeys-static-2.5.1/bin
GUIX_LOCPATH=/gnu/store/mw3py6smb1pk8yx298hd9ivz9lzbksqi-glibc-utf8-locales-2.33/lib/locale
--8<---cut here---end--->8---
So you may need to add:
(setenv "LINUX_MODULE_DIRECTORY" "/run/booted-system/kernel/lib/modules")
Besides, but that’s more about aesthetics, it would make sense to use
(gnu build linux-modules) instead of calling out to ‘modprobe’, along
these lines:
(load-linux-modules-from-directory '("uvesafb")
"/run/booted-system/kernel/lib/modules")
HTH!
Ludo’.
bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Hi Florian, "pelzflorian (Florian Pelz)" writes: > So I tried waiting until it exists before modprobe (in the attached > patch). But modprobe still fails in the same way, according to dmesg, > even though the file evidently already existed. I don't think there's a race issue with the files being available: shepherd should start after system activation (so /run/current-system exists), and after /gnu/store was mounted in the early userspace. > I will try tomorrow to get an strace. The installer worked fine in … > August I believe. You could also probably try logging the system* call in some temporary log file, by using some bash redirection (or with-current-output-port and friends). By the way, why is the modprobe binary inside a #+? The target will want to be able to run the binary itself, right? Shouldn't it be #$? Best, -- Josselin Poiret
bug#60016: Cuirass ignores failed dependencies
Hello, Cuirass ignores failed build dependencies on subsequent evaluations after the initial failure. To clarify, say package P has two dependencies: A and B. On evaluation 1, A fails. The job for package P is cancelled and P gets in the 'Dependency failed' state. So far so good. On evaluation 2, B is updated. P is scheduled for build, despite A still failing. A is not even listed in the "Dependencies" field. The build job for P starts, and under the hood it unsurprisingly builds A first, which is still broken, and the build job for P eventually fails. A real work example pulled from ci.guix is OpenCV. For reasons yet to be investigated, OpenCV consistently fails on the build farm: https://ci.guix.gnu.org/build/175246/details Yet 'hydrus-network' is scheduled for build: https://ci.guix.gnu.org/build/248218/details The log for hydrus-network reveals that it is indeed attempting to build OpenCV: https://ci.guix.gnu.org/build/248218/log/raw I suppose this has to do with OpenCV missing from the 'dependencies' field despite being an input to hydrus-network. Thoughts?
bug#60002: installer console garbled on 1984.is VPS
Hello Attila. So the admins are using a Web interface to QEMU. Which one? What -vga option is it using? Perhaps when in GRUB, press E to edit the linux boot command-line and append to it: nomodeset IIRC there had been discussions about QEMU Bochs graphics and such, but I can’t find them. > maybe the installer could be extended with something to start a > temporary shell to configure te network, without the need to switch > virtual consoles? I don’t understand this. Can others help? Regards, Florian
bug#60010: [version 1.4.0] AMD screen stays black; modprobe fails
Just now I tried the installer on an AMD desktop but the graphical installer screen stays black. Same on an AMD laptop. After switching to another TTY, dmesg tells me this: > [ 11.625264] shepherd[1]: Service host-name has been started. > [ 11.625839] shepherd[1]: Service user-homes has been started. > [ 11.629846] shepherd[1]: > [ 11.630078] [ > [ 11.630230] modprobe > [ 11.630382] ] > [ 11.630592] modprobe: FATAL: Module uvesafb not found in directory > /lib/modules/6.0.10-gnu > > [ 11.631734] shepherd[1]: Failed to start maybe-uvesafb in the background. > [ 15.185776] :04:00.0: Missing Free firmware (non-Free firmware loading > is disabled) I tried manually running the modprobe command from gnu/system/install.scm: /gnu/store/vh4g56m35wwlfg300s4qafykxjy09511-kmod-29/bin/modprobe uvesafb v86d=/gnu/store/na24a7653hyf0pghhw9nhfr6mi15v6cz-v86d-0.1.10/sbin/v86d mode_option=1024x768 Works fine. I can switch back by Ctrl-Alt-F1 and the graphical installer works. /run/current-system/kernel/lib/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz exists. So I tried waiting until it exists before modprobe (in the attached patch). But modprobe still fails in the same way, according to dmesg, even though the file evidently already existed. Why doesn’t modprobe find it? Where does it look? I will try tomorrow to get an strace. The installer worked fine in … August I believe. Regards, Florian From: Florian Pelz Date: Mon, 12 Dec 2022 15:33:26 +0100 Subject: [PATCH doesnt work] installer: Fix uvesafb not loading. * gnu/system/install.scm (uvesafb-shepherd-service): Wait before invoking modprobe. --- gnu/system/install.scm | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/gnu/system/install.scm b/gnu/system/install.scm index f6f1923121..ffde933990 100644 --- a/gnu/system/install.scm +++ b/gnu/system/install.scm @@ -4,7 +4,7 @@ ;;; Copyright © 2016 Andreas Enge ;;; Copyright © 2017 Marius Bakke ;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice -;;; Copyright © 2020 Florian Pelz +;;; Copyright © 2020, 2022 Florian Pelz ;;; Copyright © 2020 Efraim Flashner ;;; Copyright © 2022 Josselin Poiret ;;; @@ -289,11 +289,18 @@ (define (uvesafb-shepherd-service _) (provision '(maybe-uvesafb)) (requirement '(file-systems)) (start #~(lambda () -(or (file-exists? "/dev/fb0") -(invoke #+(file-append kmod "/bin/modprobe") + (define (start-uvesafb) + ;; HOW TO DO THIS THE RIGHT WAY?? + (if (file-exists? "/run/current-system/kernel/lib\ +/modules/6.0.10-gnu/kernel/drivers/video/fbdev/uvesafb.ko.gz") + (invoke #+(file-append kmod "/bin/modprobe") "uvesafb" (string-append "v86d=" #$v86d "/sbin/v86d") -"mode_option=1024x768" +"mode_option=1024x768") + ;; Wait and try again. + (begin (sleep 1) (start-uvesafb +(or (file-exists? "/dev/fb0") +(start-uvesafb (respawn? #f) (one-shot? #t -- 2.38.1
bug#59946: gnutls fails on armhf-linux
Hi, On Sat, 10 Dec 2022 at 16:38, Elias Howell via Bug reports for GNU Guix wrote: > System: Asus C201 > > CPU: Quad Core ARMv7 v7l (-MCP-) speed/min/max: 1800/126/1800 MHz Kernel: > 5.15.6-gnu-PrawnOS-libre armv7l Up: 12h 37m > Mem: 888.2/2011.9 MiB (44.1%) Storage: 252.98 GiB (2.1% used) Procs: 208 > Shell: Bash inxi: 3.3.01 [...] > ./guix/store.scm:1419:15: ERROR: > 1. : > message: "build of > `/gnu/store/637xy3m8znr76m0zblywvqijk3p3bm4d-gnutls-3.7.2.drv' failed" > status: 100 > guix pull: error: You found a bug: the program > '/gnu/store/cdmqkgik5mxnfm1ws194s1bc03w2w8lf-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "3ae6f30767f962da74d18d824b521462e149b89a"; system: "armhf-linux"; > host version: "1.3.0"; pull-version: 1). > Please report the COMPLETE output above by email to . Could you try instead, --8<---cut here---start->8--- guix time-machine --commit=6dbdb5fcf5640c126ac65479b835aba83aea2a6d \ -- help --8<---cut here---end--->8--- ? It is version-1.4-rc2. Cheers, simon
bug#35727: Connecting Geiser to Guile listening to a socket: No prompt found! (.guile to blame)
2019-05-14 06:17 sirga...@zoho.com: I'm getting a "No prompt found!" error when I try to connect Geiser to a Guile REPL like this: 1. In a terminal, run "$ guile --listen=/tmp/guile-socket" 2. In Emacs, "M-x geiser-connect-local", then "guile", and finally "/tmp/guile-socket" When the Guile REPL start in Emacs, I get a "No prompt found!" in the echo area, and the prompt in the REPL looks like this: https://multimedialib.files.wordpress.com/2019/05/emacs-geiser-guile-repl-no-prompt-found-2019-05-13.png After trying some things out with help from str1ngs on #guix, we found out that the problem is related to the ".guile" file that seems to be generated by the system by default. In my case, ".guile" looks like this: ## (cond ((false-if-exception (resolve-interface '(ice-9 readline))) => (lambda (module) ;; Enable completion and input history at the REPL. ((module-ref module 'activate-readline (else (display "Consider installing the 'guile-readline' package for convenient interactive line editing and input history.\n\n"))) (unless (getenv "INSIDE_EMACS") (cond ((false-if-exception (resolve-interface '(ice-9 colorized))) => (lambda (module) ;; Enable completion and input history at the REPL. ((module-ref module 'activate-colorized (else (display "Consider installing the 'guile-colorized' package for a colorful Guile experience.\n\n" ## When I remove this file and try to connect again, the "No prompt found!" error disappears, and the prompt looks normal. Does it work when you start the Guile REPL with an environment-variable called INSIDE_EMACS? That way, it worked fine for me: #+begin_src sh INSIDE_EMACS=true guix repl --listen=tcp:37146 #+end_src If this works, then I'd suggest that this is not a bug but rather you got to know that you need to deliver that environment variable to guix/guile. We could then close this ticket. Personally, I think this is only a bug in Geiser which should be able to parse colored prompts.
bug#58789: julia 1.6.7 Pkg.add fails with curl_multisocket error
On Tue, Oct 25, 2022 at 04:52:57PM -0400, John Biechele-Speziale via Bug reports for GNU Guix wrote: > After installing GuixSD and julia on the fairly minimal installation, > running julia and entering the following command ’] add DrWatson’ > fails with the following error: “ curl_multi_socket_action: 8”. > Oddly enough, some packages work, such as LibCURL, but most fail. > > The failure seems to occurs at the “resolving pkg versions” stage. > > I’m a bit new to guix and mailing lists in general, so if there’s > anything else I need to provide to help reproduce the bug, please > let me know and I’ll send it ASAP. With the update of Julia to 1.8.3 I have tested installing DrWatson using the Julia REPL and it now works. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#56711: libunwind-julia fails to build on aarch64
On Fri, Jul 22, 2022 at 02:45:42PM -0600, Akira Kyle wrote: > I've been trying to get julia working on aarch64 but I was running into a > linker error when guix was trying to build libunwind-julia. I tracked it > down to the libunwind-julia-fix-GCC10-fno-common.patch not including a fix > for aarch64 which is included in the upstream commit [1] which fixed this in > libunwind 1.5.0. I gather libunwind-julia is at 1.3.1 due to julia 1.6.3 > only building against that version, and checking the more recent julia > versions, it seems julia is only updating it's dependency on libunwind to > 1.5.0 with julia version 1.8.0 which is only a release candidate at this > point. So perhaps in the meantime, > libunwind-julia-fix-GCC10-fno-common.patch could be easily updated so julia > can start building on aarch64? > > [1] > https://github.com/libunwind/libunwind/commit/29e17d8d2ccbca07c423e3089a6d5ae8a1c9cb6e > > Thanks! > Akira With the recent patches to push julia to 1.8.3 libunwind-julia now builds for aarch64. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#59784: [version 1.4.0rc1] Retrying a failed install fails
"pelzflorian (Florian Pelz)" writes:
> shepherd: Service guix-daemon has been stopped.
> shepherd: Service guix-daemon has been started.
> guix system: Fehler: opening file
> `/gnu/store/4z81a7njyvnwa4kn46ad6vhvi0lcnrhh-shadow-4.9.drv': No such
> file or directory
> Befehl ("guix" "system" "init" "--fallback" "/mnt/etc/config.scm" "/mnt") hat
> mit Exit-Code 1 geendet
Still happens with 1.4.0rc2. I guess install-system in
gnu/installer/final.scm does not sync the disk on failure?
Regards,
Florian
