bug#68948: highlight error, cannot open filetypes.conf: No such file or directory
Below changes at the highlight package resolve the issue here but may adversely affect "highlight-gui" functionality. Will wait for https://issues.guix.gnu.org/70047 before trying to proceed, ```diff - #:make-flags #~(let ((confdir (string-append %output - "/share/highlight/config/"))) - (list (string-append "PREFIX=" %output) - (string-append "HL_CONFIG_DIR=" confdir) - (string-append "conf_dir=" confdir))) + #:make-flags #~(list (string-append "PREFIX=" %output) + (string-append "HL_CONFIG_DIR=" %output "/etc/") + (string-append "conf_dir=" %output "/etc/")) ```
bug#68948: temp fix
The following workaround can be used,
```
HLDIRS=$(guix build highlight); # returns two directories
HLDIR="${HLDIRS##*[[:space:]]}"; # returns the second dir, after whitespace
DATADIR="$HLDIR/etc/highlight/";
echo "(highlight (package bug))" | highlight --data-dir=$DATADIR -O xterm256
--syntax lisp
```
Based on my understanding, the current package definition is correct. Possibly
a patch like this could resolve the issue the current package definition seems
correct.
```
diff --git a/gnu/packages/pretty-print.scm b/gnu/packages/pretty-print.scm
index b95f56729a..2a7cf74009 100644
--- a/gnu/packages/pretty-print.scm
+++ b/gnu/packages/pretty-print.scm
@@ -389,7 +389,7 @@ (define-public highlight
(lambda* (#:key inputs outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(data (string-append out
-"/share/highlight/"))
+"/etc/highlight/"))
(conf (string-append out "/etc/highlight/"))
(doc (string-append out
"/share/doc/highlight/"))
```
bug#69667: build of sway-1.9-checkout.drv failed
All issues were resolved by removing grimshot and wlgreet
bug#69667: build of sway-1.9-checkout.drv failed
On 3月10日 日, 宋文武 wrote: > > Hello, sway build fine for me (and CI), this seems like a disk or > filesystem issue on your side. Booting to sway 1.9 results in a flashing screen and its necessary to restart and boot to a previous generation. This system uses seat and wlgreet. Have not tried to debug yet.
bug#69667: build of sway-1.9-checkout.drv failed
On 3月10日 日, 宋文武 wrote: > > Hello, sway build fine for me (and CI), this seems like a disk or > filesystem issue on your side. Removing grimshot resolved the issue for me.
bug#69667: build of sway-1.9-checkout.drv failed
guix home reconfigure fails at sway-1.9. The bottom of the drv file shows this, ``` `source is at 'sway-1.9-checkout' Backtrace: 10 (primitive-load "/gnu/store/5ahfcp5009pgdh17lg5y01w4vhv…") In ice-9/eval.scm: 619:8 9 (_ #(#(# "swa…") #)) In ice-9/boot-9.scm: 142:2 8 (dynamic-wind _ _ #) In system/base/compile.scm: 352:28 7 (compile _ #:from _ #:to _ #:env _ #:optimization-level …) 265:44 6 (_ _ _) 265:44 5 (_ _ _) 265:44 4 (_ _ _) 261:27 3 (_ _ _) In ice-9/boot-9.scm: 2836:4 2 (save-module-excursion #) In language/bytecode/spec.scm: 43:19 1 (_) In unknown file: 0 (delete-file "contrib/grimshot.1") ERROR: In procedure delete-file: In procedure delete-file: No such file or directory /gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Wallpaper_Blue_1136x640_Portrait.png' -> `sway-1.9-checkout/assets/Sway_Wallpaper_Blue_1136x640_Portrait.png' `/gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Wallpaper_Blue_768x1024.png' -> `sway-1.9-checkout/assets/Sway_Wallpaper_Blue_768x1024.png' `/gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Wallpaper_Blue_1920x1080.png' -> `sway-1.9-checkout/assets/Sway_Wallpaper_Blue_1920x1080.png' `/gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Logo+Text_Ver3.svg' -> `sway-1.9-checkout/assets/Sway_Logo+Text_Ver3.svg' `/gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Tree.svg' -> `sway-1.9-checkout/assets/Sway_Tree.svg' `/gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Logo+Text_Ver1_1500x716.png' -> `sway-1.9-checkout/assets/Sway_Logo+Text_Ver1_1500x716.png' `/gnu/store/5wqhngwwzaa9b9g1apxr8lawk3g8sxwm-sway-1.9-checkout/assets/Sway_Logo+Text_Ver4.png' -> `sway-1.9-checkout/assets/Sway_Logo+Text_Ver4.png' ```
bug#69655: WARNING: Use of 'load' in declarative module
Starting a long time ago, maybe a year ago, I begin seeing this warning screen.
The screen appears for a brief moment, after submitting login to wlgreet and
before sway desktop is started. I took a cellphone picture of the screen in
order to copy the message shown,
```
starting service root...
Service root started
Service root running with value #t.
Service root has been started.
WARNING: Use of 'load' in declarative module (#( gl107)#) Add #:declarative?
#f to your define-module invocation
Daemonizing...
Some deprecated features have been used. Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information. Set it to "no" to supress
this message.
Restarting signal handler.
Now running as process 330.
Starting services...
Configuration succesfully loaded from '/gnu/store/hcj[...]x96-shepherd.conf'.
Starting service gpg-agent
Service gpg-agent has been started.
Service gpg-agent started.
Service gpg-agent running with value (("ssh" . #)
("browser" . #) ("extra" . #)
("std" . #)).
Succesfully started 2 services in the background
```
Added GUILE_WARN_DEPRECATED="detailed" to my home config results in the
messages below,
```
starting service root...
Service root started
Service root running with value #t.
Service root has been started.
WARNING: Use of 'load' in declarative module (#( gl107)#) Add #:declarative?
#f to your define-module invocation
GOOPS method 'action' is deprecated in favor of procedure
'perform-service-action'
Daemonizing...
Restarting signal handler.
Now running as process 312.
Starting services...
Configuration succesfully loaded from '/gnu/store/m9q[...]w0f-shepherd.conf'.
Starting service gpg-agent
Service gpg-agent has been started.
Service gpg-agent started.
Service gpg-agent running with value (("ssh" . #)
("browser" . #) ("extra" . #)
("std" . #)).
Succesfully started 2 services in the background
```
Any help or advice is appreciated. Thank you,
Chris
bug#68948: highlight error, cannot open filetypes.conf: No such file or directory
Sergey, I believe you intended a related message for the debbugs service, but only sent the message to my mail address. I am unsure and want to avoid showing impoliteness, I rephrased your message a bit below. Thank you, Chris --- the highlight error goes away after copying the conf file this way ``` cp $(guix build highlight)/etc/highlight/filetypes.conf ~/.highlight/ ``` strace shows that the conf is searched in wrong place: --8<---cut here---start->8--- newfstatat(AT_FDCWD, "/home/user/.highlight/filetypes.conf", 0x7ffcd0778130, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/gnu/store/9mdd4ba8ri4j07acmbc2vhkiipbz9l63-highlight-4.8/share/highlight/filetypes.conf", 0x7ffcd0778130, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/gnu/store/9mdd4ba8ri4j07acmbc2vhkiipbz9l63-highlight-4.8/share/highlight/config/highlight/filetypes.conf", 0x7ffcd0778130, 0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "filetypes.conf", O_RDONLY) = -1 ENOENT (No such file or directory) futex(0x7f2c4827e1f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(2, "cannot open filetypes.conf: No s"..., 53cannot open filetypes.conf: No such file or directory) = 53 --8<---cut here---end--->8--- but it is installed to /gnu/store/...-highlight-.../etc/highlight/highlight.conf the package recipe has to be fixed
bug#68948: highlight error, cannot open filetypes.conf: No such file or directory
There is an issue using "highlight" https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/pretty-print.scm#n353 http://www.andre-simon.de/doku/highlight/en/highlight.php#ch3_8 This unexpected error is reproduced easily with the command below: "cannot open filetypes.conf" ``` $ echo "(highlight (package bug))" | highlight -O xterm256 --syntax lisp cannot open filetypes.conf: No such file or directory (highlight (package bug)) ``` Creating `~/.highlight/filetypes.conf` did not resolve the error. Setting "HIGHLIGHT_DATADIR=$HOME/.config/highlight/" did not resolve the error. Any advice is welcome. Thank you :) Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月26日 金, Sergey Trofimov wrote: > > The only dependency on `dbus` is that pipewire shepherd service has it in > the requirement field. > You can add a no-op shepherd service which would have (provision '(dbus)) to > satisfy the dependency. I don't know how to do this. If you share links to documentation or examples I will read those. It would be nice to use the home-pipewire-service rather than manage these files myself. Thank you and thank you for any further suggestions or advice you may give, Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月26日 金, Clément Lassieur wrote: > > Maybe you should check your GUILE_LOAD_PATH and > GUILE_LOAD_COMPILED_PATH. That's where guile finds the guix modules. > They might include folders from an old guix. I'm not sure how to investigate or verify that but here is the result of echo $ echo $GUILE_LOAD_PATH /home/bumble/.guix-home/profile/share/guile/site/3.0:/run/current-system/profile/share/guile/site/3.0 $ echo $GUILE_LOAD_COMPILED_PATH /home/bumble/.guix-home/profile/lib/guile/3.0/site-ccache:/home/bumble/.guix-home/profile/share/guile/site/3.0:/run/current-system/profile/lib/guile/3.0/site-ccache:/run/current-system/profile/share/guile/site/3.0 `.guix-home/profile/share/guile/site/3.0` only has a few symlinks ice-9/ ncurses shepherd shepherd.scm `/run/current-system/profile/share/guile/site/3.0` has many more symlinks
bug#68512: done
done
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月26日 金, Sergey Trofimov wrote: > > 0.3.77 is the previous version, from a month ago. Is your checkout fresh? > Did you `guix pull`? yes `guix pull` has been used :|
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月26日 金, Sergey Trofimov wrote:
>
> Ugh, why don't you use home-pipewire-service-type?
`home-pipewire-service-type` has no option to skip dbus and thus far this
system does not use dbus, ibus, elogind and systemd etc.
> Packages are file-like, i.e. replaced with their location when used in
> g-exp.
Interesting. Thanks for teaching me this.
> Here is an example how to define the configuration, I've adapted it from
> gnu/home/services/home.scm
>
> --8<---cut here---start->8---
> (simple-service 'pipewire-configs home-xdg-configuration-files-service-type
> `(("alsa/asoundrc")
>,(mixed-text-file
>"asoundrc"
>"<" pipewire "/share/alsa/alsa.conf.d/50-pipewire.conf>\n"
>"<" pipewire
> "/share/alsa/alsa.conf.d/99-pipewire-default.conf>\n"
>"pcm_type.pipewire {\n"
>" lib \"" pipewire
> "/lib/alsa-lib/libasound_module_pcm_pipewire.so\"\n"
>"}\n"
>"ctl_type.pipewire {\n"
>" lib \"" pipewire
> "/lib/alsa-lib/libasound_module_ctl_pipewire.so\"\n"
>"}\n")))
> --8<---cut here---end--->8---
The above does work :) thank you. I'm interested to explore writing a function
that wraps g-exp behaviour to return a package as store path string and might
do that outside of this ticket.
Thank you for your kind help and correspondence,
Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
This attempt from the discussion here https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00441.html ``` (define s (open-connection)) (display (derivation->output-path (package-derivation s pipewire #:graft? #f) "out")) ``` It runs but returns the wrong store path, /gnu/store/kqw8zs84px1vzw98yv9xax4rc0n612qy-pipewire-0.3.77 The $(guix build pipewire) command returns this, /gnu/store/8572wxb5138hanhvn1lbfdm1kicxsd2k-pipewire-1.0.0 Thanks, Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月25日 木, Sergey Trofimov wrote: > > I'm glad you sorted it out. Check what are the environment variables for > your sway process (cat /proc//environ | tr -s '\0' '\n'). > Maybe XDG_RUNTIME_DIR is missing there? Enabling debug logging for pipewire > might help as well: https://docs.pipewire.org/page_daemon.html Sergey, Yesterday after reporting back here, I found that I was able to change the commands used by sway from this ``` exec_always killall -wqr "(pipewire|wireplumber)" \ || sleep 1 && ((pipewire &); sleep 2 && (wireplumber &)) ``` To this ``` exec sleep 2 && pipewire exec sleep 4 && wireplumber ``` sound is working each time the machine is started or restarted. In order to script-generate the asoundrc file, I wish to use pipewire's store directory path inside a scheme function. WOuld you teach me how to do this? eg, `$(guix build pipewire) # /gnu/store/8572wxb5138hanhvn1lbfdm1kicxsd2k-pipewire-1.0.0` No success trying various things from this thread https://www.mail-archive.com/help-guix@gnu.org/msg11871.html 'have also tried the following ``` (use-modules (gnu packages linux) (gnu packages build-tools) (gnu packages package-management)) (guix build pipewire) ``` running the file fails with this message: ``` Wrong type to apply: # ``` Thanks in advance for any recommendations or advice. Thank you for conversing with me and helping me thus far, Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
Sergey, your configuration file is working and audio is heard from qutebrowser on this system. Internet searches surfaced commands like these, `pw-cli` `strace -e connect pw-dump >/dev/null` Error messages were seen relating to socket files not found, `$XDG_RUNTIME_DIR/pipewire-0` `$XDG_RUNTIME_DIR/pipewire-0-manager` Various things attempted, but the socket files missing every time sway started Finally, tried removing the pipewire-starting parts of the sway config ``` # exec_always killall -wqr "(pipewire|wireplumber)" \ # || sleep 1 && ((pipewire &); sleep 2 && (wireplumber &)) ``` Then separately started pipewire and wireplumber "manually" from the shell. The socket files were created and when qutebrowser sound could be heard. Thank you Sergey, Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月17日 水, chris wrote: > Sound did not work, but messages in the qutebrowser process output were > slightly different. foreign text translates as: "host dropped", The english variant of the same message is probably "Host is down"
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月17日 水, Sergey Trofimov wrote:
>
> Well, qtwebengine doesn't link with PipeWire anyway, you have to use either
> PulseAudio or ALSA. Here is an example ~/.config/alsa/asoundrc on my system,
> created by home-pipewire-service-type. If you add such file to your setup -
> qutebrowser should be able to use alsa lib to output audio through pipewire.
>
>
> --8<---cut here---start->8---
>
>
> pcm_type.pipewire {
> lib
> "/gnu/store/a331f91m9g8898lccyj7fniqsyv406y9-pipewire-1.0.0/lib/alsa-lib/libasound_module_pcm_pipewire.so"
> }
> ctl_type.pipewire {
> lib
> "/gnu/store/a331f91m9g8898lccyj7fniqsyv406y9-pipewire-1.0.0/lib/alsa-lib/libasound_module_ctl_pipewire.so"
> }
> --8<---cut here---end--->8---
Sergey,
Thanks for this help. Running `$(guix build pipewire)` returned the same path
shown in your example, so I tried simply copy-pasting your example to
~/.config/alsa/asoundrc and restarting my system
Sound did not work, but messages in the qutebrowser process output were
slightly different. foreign text translates as: "host dropped",
```
[1588:1588:0117/013614.549773:ERROR:alsa_util.cc(204)] PcmOpen:
default,ホストが落ちています
[1588:1588:0117/013614.559451:ERROR:alsa_util.cc(204)] PcmOpen:
plug:default,ホストが落ちています
[1588:1588:0117/013614.575316:ERROR:alsa_util.cc(204)] PcmOpen:
default,ホストが落ちています
[1588:1588:0117/013614.588043:ERROR:alsa_util.cc(204)] PcmOpen:
plug:default,ホストが落ちています
```
These messages differ from the earlier messages that basically said "file not
found".
Thanks for helping me. I will sleep now and maybe try more things tomorrow,
Chris
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月16日 火, Sergey Trofimov wrote: > How is pipewire configured on your system? The thing is that qtwebengine@5 > is linked with PulseAudio and ALSA libraries, but @6 is linked only with > alsa. You probably miss pipewire-alsa compatibility configuration. Do you > use home-pipewire-service-type? It sets both pulse/alsa shims and it works > for me this way. This system does not use dbus and pipewire was configured about a year ago when there were few options for using pipewire out of the box in any sort of way. Guix home is configured to write a pipewire and three wireplumber config files, as described at this link https://wiki.alpinelinux.org/wiki/PipeWire#Configuration .config/pipewire/pipewire.conf .config/wireplumber/wireplumber.conf .config/wireplumber/main.lua.d/80-disable-dbus.lua .config/wireplumber/bluetooth.lua.d/80-disable-logind.lua With with those files in place, pipewire and wireplumber are started sequentially to get working sound. I use this in my .config/sway/config (possibly this is copy-pasted from unmatched-paren) ``` exec_always killall -wqr "(pipewire|wireplumber)" \ || sleep 1 && ((pipewire &); sleep 2 && (wireplumber &)) ```
bug#68512: Qutebrowser 3, no sound from pipewire-only system
On 1月16日 火, chris wrote: > For convenience, links to the upstream qt.scm file > * https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n2933 >qtwebengine-5 args > * https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n2998 >qtwebengine (qtwebengine-6) > > Thanks for any input and a link to the commit with commit message https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d9368572abd3683bed4263eb5e149bb404baee59
bug#68512: Qutebrowser 3, no sound from pipewire-only system
For convenience, links to the upstream qt.scm file * https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n2933 qtwebengine-5 args * https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n2998 qtwebengine (qtwebengine-6) Thanks for any input
bug#68512: Qutebrowser 3, no sound from pipewire-only system
Possibly this was the change from Iyzsong which enabled sound here, ```sh $ git diff fbbbc2088ce933d83f5b0be75308fdcb6b40fa57 d9368572abd3683bed4263eb5e149bb404baee59 diff --git a/gnu/packages/qt.scm b/gnu/packages/qt.scm index 76e9e519c7..01327f6ccf 100644 --- a/gnu/packages/qt.scm +++ b/gnu/packages/qt.scm @@ -2708,7 +2708,8 @@ (define-public qtwebengine-5 "src/buildtools/config/linux.pri" (lambda (in out) (display (get-string-all in) out) -(display "\ngn_args += use_system_openh264=true\n" out))) +(display "\ngn_args += use_system_openh264=true\n" out) +(display "\ngn_args += link_pulseaudio = true\n" out))) ;; Qtwebengine is not installed into the same prefix as ;; qtbase. Some qtbase QTLibraryInfo constants will not ;; work. Replace with the full path to the qtwebengine-5 ``` No equivalent is found by me in the qtwebengine definition that supplies qtwebgine 6
bug#68483: Qutebrowser QT platform plugin could not be initialized
Hey everyone the close email is sent and two separate issues opened, linked below, * https://issues.guix.gnu.org/68512 Qutebrowser 3, no sound from pipewire-only system, * https://issues.guix.gnu.org/68513 Qutebrowser 3, PermissionError qtwebengine_devtools_resources.pak
bug#68513: Qutebrowser 3, PermissionError qtwebengine_devtools_resources.pak
When starting Qutebrowser 3, the shell process shows these messages related to a permission error. The messages include a CJK error that is rendered by debbugs as "??" and the message basically translates as "no permission" ```sh $ qutebrowser 08:17:14 ERROR: Failed to copy webengine resources, not applying quirk Traceback (most recent call last): File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/misc/pakjoy.py", line 253, in patch_webengine webengine_resources_path = copy_webengine_resources() File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/misc/pakjoy.py", line 197, in copy_webengine_resources shutil.rmtree(work_dir) File "/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py", line 724, in rmtree _rmtree_safe_fd(fd, path, onerror) File "/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py", line 680, in _rmtree_safe_fd onerror(os.unlink, fullname, sys.exc_info()) File "/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py", line 678, in _rmtree_safe_fd os.unlink(entry.name, dir_fd=topfd) PermissionError: [Errno 13] 許可がありません: 'qtwebengine_devtools_resources.pak' ``` Thanks in advance for any advice or input Related: https://issues.guix.gnu.org/67289, https://issues.guix.gnu.org/68483
bug#68512: Qutebrowser 3, no sound from pipewire-only system
Hello, The latest qutebrowser v3 from this pipewire-only system has no sound. Related messages from the shell process pasted below include CJK characters which debbugs renders as "??", all CJK messages translate as "file or directory not found" ``` ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3003:3003:0116/083803.232761:ERROR:alsa_util.cc(204)] PcmOpen: default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3003:3003:0116/083803.233758:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3003:3003:0116/083808.743619:ERROR:alsa_util.cc(204)] PcmOpen: default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3003:3003:0116/083808.744661:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,そのようなファイルやディレクトリはありません ``` About a year ago, user @iyzsong enabled pipewire support at qutebrowser v2 for me and sound has been good here until today when qutebrowser v3 was installed. iirc, a flag was enabled in qutebrowser or one of its dependencies. Related: https://issues.guix.gnu.org/68483, https://issues.guix.gnu.org/67289
bug#68483: closing
closing
bug#68483: Qutebrowser QT platform plugin could not be initialized
I'm not sure what the correct protocol or etiquette is but I think this issue could be closed by sending an email to 68483-d...@debbugs.gnu.org Maybe the 'done' email should be sent from Sergey who provided the solution? I would like to close this issue and open new separate issues for sound and the PermissionError shown in the process output around 'qtwebengine_devtools_resources.pak'
bug#68483: Qutebrowser QT platform plugin could not be initialized
The snippet should be attributed to Sergey, my apology for incorrectly editing the reply
bug#68483: Qutebrowser QT platform plugin could not be initialized
On 1月16日 火, Sergey Trofimov wrote:
>
> Clément Lassieur writes:
>
> --8<---cut here---start->8---
> (simple-service 'qtwayland-vars-service
> home-environment-variables-service-type
> `(("QT_PLUGIN_PATH" . ,(file-append qtwayland "/lib/qt6/plugins"))
> ("QT_QPA_PLATFORM_PLUGIN_PATH" . ,(file-append qtwayland
> "/lib/qt6/plugins/platforms"
> --8<---cut here---end--->8---
This works here. After adding the above to my home config, qutebrowser starts
as `qutebrowser` without the extra params.
As for the sound issue, this system uses pipewire only, without dbus. mpv,
musikcube and the previous version of qutebrowser have/had sound. When I first
setup guix about a year ago, qutebrowser 2 did not produce sound and, to
resolve the issue, Iyzsong, in the matrix or irc channel, said they would
enable native support for pipewire through a flag at qutebrowser (or maybe one
of the dependencies... I don't remember) and the next day after pull and
reconfigure the sound began working and there were no sound problems until
updating to qutebrowser 3 today.
bug#68483: Qutebrowser QT platform plugin could not be initialized
Qutebrowser 3 does not have sound and this appears in the process output. "そのようなファイルやディレクトリはありません" means "the file or directory is not found". ``` [3158:3158:0116/000131.568005:ERROR:interface_endpoint_client.cc(694)] Message 4 rejected by interface blink.mojom.WidgetHost ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3473:3473:0116/000734.652713:ERROR:alsa_util.cc(204)] PcmOpen: default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3473:3473:0116/000734.653460:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3473:3473:0116/000824.855365:ERROR:alsa_util.cc(204)] PcmOpen: default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3473:3473:0116/000824.856521:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3473:3473:0116/000826.415347:ERROR:alsa_util.cc(204)] PcmOpen: default,そのようなファイルやディレクトリはありません ALSA lib pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave [3473:3473:0116/000826.416368:ERROR:alsa_util.cc(204)] PcmOpen: plug:default,そのようなファイルやディレクトリはありません ```
bug#68483: Qutebrowser QT platform plugin could not be initialized
On 1月15日 月, chris wrote: > On 1月16日 火, Sergey Trofimov wrote: > > > > Here you go: > > ```sh > > qtw=$(guix build qtwayland@6)/lib/qt6/plugins > > QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser > > -s qt.force_platform wayland > > ``` > > I think it needed the extra slash after at the end of $qtw... the shell output looks problematic, but otherwise the browser has started. Thank you ``` $ qtw=$(guix build qtwayland@6)/lib/qt6/plugins; QT_PLUGIN_PATH=$qtw/; QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms; qutebrowser -s qt.force_platform wayland 23:47:07 ERROR: Failed to copy webengine resources, not applying quirk Traceback (most recent call last): File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/misc/pakjoy.py", line 253, in patch_webengine webengine_resources_path = copy_webengine_resources() File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/misc/pakjoy.py", line 197, in copy_webengine_resources shutil.rmtree(work_dir) File "/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py", line 724, in rmtree _rmtree_safe_fd(fd, path, onerror) File "/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py", line 680, in _rmtree_safe_fd onerror(os.unlink, fullname, sys.exc_info()) File "/gnu/store/3lxr2xg3yscdb3979blgjg0h7xd1n9la-python-3.10.7/lib/python3.10/shutil.py", line 678, in _rmtree_safe_fd os.unlink(entry.name, dir_fd=topfd) PermissionError: [Errno 13] 許可がありません: 'qtwebengine_devtools_resources.pak' 23:47:08 INFO: Showing changelog after upgrade to qutebrowser v3.1.0. ```
bug#68483: Qutebrowser QT platform plugin could not be initialized
On 1月15日 月, chris wrote: > On 1月16日 火, Sergey Trofimov wrote: > > > > Here you go: > > ```sh > > qtw=$(guix build qtwayland@6)/lib/qt6/plugins > > QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser > > -s qt.force_platform wayland > > ``` I tried this command again just now and succeeded this time. I must have done something wrong the first time. Thank you Sergey!
bug#68483: Qutebrowser QT platform plugin could not be initialized
On 1月16日 火, Sergey Trofimov wrote: > > Here you go: > ```sh > qtw=$(guix build qtwayland@6)/lib/qt6/plugins > QT_PLUGIN_PATH=$qtw QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms qutebrowser -s > qt.force_platform wayland > ``` > > Maybe a qutebrowser-wayland package variant should be defined to do the > required wrapping. Otherwise you can just install qtwayland@6 to your > profile and use ~/.guix-home/profile/lib/qt6/plugins in paths. Neither approach succeeded for me. What am I doing wrong... ```sh $ ls $qtw platforms/ wayland-graphics-integration-client/ wayland-shell-integration/ wayland-decoration-client/ wayland-graphics-integration-server/ $ ls $qtw/platforms libqwayland-egl.so libqwayland-generic.so $ qtw=/home/bumble/.guix-home/profile/lib/qt6/plugins; QT_PLUGIN_PATH=$qtw; QT_QPA_PLATFORM_PLUGIN_PATH=$qtw/platforms; qutebrowser -s qt.force_platform wayland 23:00:47 WARNING: Could not find the Qt platform plugin "wayland" in "" 23:00:47 CRITICAL: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: offscreen, vnc, minimal, xcb, vkkhrdisplay, linuxfb, minimalegl, eglfs. Fatal Python error: Aborted Current thread 0x7f7b99434740 (most recent call first): File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py", line 545 in __init__ File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py", line 80 in run File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/qutebrowser.py", line 231 in main File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/bin/.qutebrowser-real", line 33 in Extension modules: PyQt6.QtCore, PyQt6.QtGui, PyQt6.QtWidgets, markupsafe._speedups, yaml._yaml, PyQt6.QtNetwork, PyQt6.QtQml, PyQt6.QtOpenGL, PyQt6.QtDBus, PyQt6.QtPrintSupport, PyQt6.QtWebChannel, PyQt6.QtWebEngineCore, PyQt6.QtWebEngineWidgets, PyQt6.QtSql (total: 14) ```
bug#68483: Qutebrowser QT platform plugin could not be initialized
On 1月15日 月, Josselin Poiret wrote:
> Hi chris,
>
> chris writes:
>
> > Related to https://issues.guix.gnu.org/67289#7
> >
> > Here is the qutebrowser 3 process shell output. Would anyone recommend a
> > solution?
> > ```
> > $ qutebrowser
> > 20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in ""
>
> Have you installed qt-wayland? Are you setting QT_QPA_PLATFORM
> anywhere?
Hey Josselin,
I've tried installing qtwayland through guix home by specifying "qtwayland" in
my home config file. QT_QPA_PLATFORM is specified in my home config this way
```
(simple-service 'env-vars home-environment-variables-service-type
'(("EDITOR" . "emacs")
("OPENER" . "sh.opener.sh")
("BROWSER" . "qutebrowser")
("GTK_IM_MODULE" . "fcitx")
("QT_IM_MODULE" . "fcitx")
("XMODIFIERS" . "@im=fcitx")
("QT_QPA_PLATFORM" . "wayland")
("QT_SCALE_FACTOR" . "1")
("XDG_SESSION_TYPE" . "wayland")
("XDG_SESSION_DESKTOP" . "sway")
("XDG_CURRENT_DESKTOP" . "sway")
("DESKTOP_SESSION" . "sway")
("LIBSEAT_BACKEND" . "seatd")))
```
QT_QPA_PLATFORM prints at the shell this way
```
$ echo $QT_QPA_PLATFORM
wayland
```
I tried changing "qtwayland" to "qtwayland@6.5" in my home config and
reconfiguring home. I've also tried installing qtwayland without guix home
using "guix install qtwayland" but those did not resolve the issue.
I can try any suggestion and if it doesn't work, revert back using guix home
switch-generation
bug#68483: Qutebrowser QT platform plugin could not be initialized
Related to https://issues.guix.gnu.org/67289#7 Here is the qutebrowser 3 process shell output. Would anyone recommend a solution? ``` $ qutebrowser 20:40:33 WARNING: Could not find the Qt platform plugin "wayland" in "" 20:40:33 CRITICAL: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: offscreen, vnc, minimal, xcb, vkkhrdisplay, linuxfb, minimalegl, eglfs. Fatal Python error: Aborted Current thread 0x7f36c07e6740 (most recent call first): File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py", line 545 in __init__ File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/app.py", line 80 in run File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/lib/python3.10/site-packages/qutebrowser/qutebrowser.py", line 231 in main File "/gnu/store/xc2z9q7z036ny3fipgqvwc01yn20j2jh-qutebrowser-3.1.0/bin/.qutebrowser-real", line 33 in Extension modules: PyQt6.QtCore, PyQt6.QtGui, PyQt6.QtWidgets, markupsafe._speedups, yaml._yaml, PyQt6.QtNetwork, PyQt6.QtQml, PyQt6.QtOpenGL, PyQt6.QtDBus, PyQt6.QtPrintSupport, PyQt6.QtWebChannel, PyQt6.QtWebEngineCore, PyQt6.QtWebEngineWidgets, PyQt6.QtSql (total: 14) ```
bug#66182: rm -r /root/.cache/guix # works
The issue is resolved here. Per irc discussion, root's guix cache was removed ``` sudo rm -r /root/.cache/guix sudo rm -r /root/.cache/guile ``` After that, `guix pull` and `sudo guix system reconfigure guix.system.scm` succeeded
bug#66182: git error: object not found when running system reconfigure
Hello, https://paste.debian.net/1292978/ For the past day or so `sudo guix system reconfigure guix.system.scm` results in the error attached to this mail. The id value has changed from yesterday. I visited the irc channel and someone there recommended the same advice found here https://issues.guix.gnu.org/40769 to delete "~/.cache/guix" and actually I deleted all "~/.cache" but the error is still there. This morning, again, I tried "rm -r ~/.cache/guix" and "sudo guix system reconfigure guix.system.scm" and the same error occurred and I don't know how to resolve. Thanks for any advice, Chris Backtrace: In guix/ui.scm: 2286:10 19 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 18 (with-exception-handler _ _ #:unwind? _ # _) In guix/status.scm: 859:3 17 (_) 839:4 16 (call-with-status-report _ _) In guix/scripts/system.scm: 1278:4 15 (_) In ice-9/boot-9.scm: 1752:10 14 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 659:37 13 (thunk) 1298:8 12 (call-with-build-handler # …) 2168:25 11 (run-with-store # …) In guix/scripts/system.scm: 1302:15 10 (_ _) 831:5 9 (perform-action reconfigure #< name: #f format:…> …) In guix/scripts/system/reconfigure.scm: 346:3 8 (check-forward-update _ #:current-channels _) In srfi/srfi-1.scm: 691:23 7 (filter-map # . #) In guix/scripts/system/reconfigure.scm: 353:39 6 (_ #< name: guix url: "https://git.savannah.gn…>) In guix/git.scm: 481:21 5 (update-cached-checkout _ #:ref _ #:recursive? _ # _ # _ …) 367:15 4 (reference-available? _ _) In git/commit.scm: 172:8 3 (_ # #) In git/bindings.scm: 77:2 2 (raise-git-error _) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Git error: object not found - no match for id (e134686cead6db62ea8b941b2ed7c0bd660804da)
bug#65769: greetd-wlgreet-sway-session result is blinking cursor
Josselin sent this message intended for the thread and I think they are okay with re-pasting here, > Usually elogind is responsible (through a PAM module) for creating this > runtime directory. If you're not using elogind, you'll need to create this > directory yourself somehow. I don't really think this is a bug per-se, as > running without elogind is advanced stuff and its consequences should be > understood by the user. I support any conclusion from Josselin and unmatched-paren and want to add these observations, * wlgreet *does require* the greeter lock file * wlgreet *does not require* elogind/logind * not-advanced users like me may want to use wlgreet without elogind
bug#65769: greetd-wlgreet-sway-session result is blinking cursor
On 9月08日 金, ( wrote: > I believe that may have been moi :) This is really odd. I seem to be > the only person who has ever managed to make it work (though there's a > bit of a reporting bias there in that people who do manage probably > won't bring it up...) > > It would be great if anyone trying to use it could possibly reply here > with a link, attachment, or copy of the config.scm they use (whether > it's working for them or not; both are useful.) > > I'll start: > > https://git.sr.ht/~unmatched-paren/conf/tree/root/item/system.scm > > -- ( Thanks for replying to my issue :) A "solution" is discussed earlier in the thread https://issues.guix.gnu.org/65769#4 > The greeter works after creating /run/user/986/wayland-1.lock and changing > the owner of /run/user/986 and /run/user/986/wayland-1.lock to "greeter". My system config is here https://raw.githubusercontent.com/iambumblehead/guix-home/main/guix.system.scm
bug#65769: no elogind
Josselin, > Do you use elogind? No. elogind is not used.
bug#65769: wlgreet-sway-session
The greeter works after creating /run/user/986/wayland-1.lock and changing the owner of /run/user/986 and /run/user/986/wayland-1.lock to "greeter". This seems to be a bug.
bug#65769: wlgreet-sway-session
This directory for the greeter user does not exist in the system /run/user/986
bug#65769: wlgreet-sway-session
In case the attachment is not-accessible, important last lines of sway-greeter.388.log are pasted here. ``` 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-1.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-2.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-3.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-4.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-5.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-6.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-7.lock check permissions 00:00:00.066 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-8.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-9.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-10.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-11.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-12.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-13.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-14.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-15.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-16.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-17.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-18.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-19.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-20.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-21.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-22.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-23.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-24.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-25.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-26.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-27.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-28.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-29.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-30.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-31.lock check permissions 00:00:00.067 [INFO] [wlr] [wayland] unable to open lockfile /run/user/986/wayland-32.lock check permissions 00:00:00.067 [ERROR] [sway/server.c:231] Unable to open wayland socket 00:00:00.067 [DEBUG] [wlr] [types/wlr_drm_lease_v1.c:103] Destroying wlr_drm_lease_device_v1 for /dev/dri/card0 ```
bug#65769: wlgreet-sway-session
Attached to this message is the content of /tmp/sway-greeter.388.log 00:00:00.000 [INFO] [sway/main.c:338] Sway version 1.8.1 00:00:00.000 [INFO] [sway/main.c:339] wlroots version 0.16.2 00:00:00.003 [INFO] [sway/main.c:120] Linux guix-xps 6.4.12 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux 00:00:00.003 [INFO] [sway/main.c:136] Contents of /etc/os-release: 00:00:00.003 [INFO] [sway/main.c:120] NAME="Guix System" 00:00:00.003 [INFO] [sway/main.c:120] ID=guix 00:00:00.003 [INFO] [sway/main.c:120] PRETTY_NAME="Guix System" 00:00:00.003 [INFO] [sway/main.c:120] LOGO=guix-icon 00:00:00.003 [INFO] [sway/main.c:120] HOME_URL="https://guix.gnu.org; 00:00:00.003 [INFO] [sway/main.c:120] DOCUMENTATION_URL="https://guix.gnu.org/en/manual; 00:00:00.003 [INFO] [sway/main.c:120] SUPPORT_URL="https://guix.gnu.org/en/help; 00:00:00.003 [INFO] [sway/main.c:120] BUG_REPORT_URL="https://lists.gnu.org/mailman/listinfo/bug-guix; 00:00:00.003 [INFO] [sway/main.c:108] LD_LIBRARY_PATH= 00:00:00.003 [INFO] [sway/main.c:108] LD_PRELOAD= 00:00:00.003 [INFO] [sway/main.c:108] PATH=/run/setuid-programs:/home/greeter/.config/guix/current/bin:/home/greeter/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin 00:00:00.003 [INFO] [sway/main.c:108] SWAYSOCK= 00:00:00.004 [INFO] [sway/main.c:376] Starting sway version 1.8.1 00:00:00.004 [DEBUG] [sway/server.c:67] Initializing Wayland server 00:00:00.004 [INFO] [wlr] [libseat] [libseat/libseat.c:73] Seat opened with backend 'seatd' 00:00:00.004 [INFO] [wlr] [libseat] [libseat/backend/seatd.c:212] Enabling seat 00:00:00.004 [INFO] [wlr] [backend/session/session.c:109] Successfully loaded libseat session 00:00:00.005 [INFO] [wlr] [backend/backend.c:220] Found 1 GPUs 00:00:00.005 [INFO] [wlr] [backend/drm/backend.c:200] Initializing DRM backend for /dev/dri/card0 (i915) 00:00:00.005 [DEBUG] [wlr] [backend/drm/drm.c:88] Using atomic DRM interface 00:00:00.005 [DEBUG] [wlr] [backend/drm/drm.c:100] ADDFB2 modifiers supported 00:00:00.005 [INFO] [wlr] [backend/drm/drm.c:253] Found 3 DRM CRTCs 00:00:00.005 [INFO] [wlr] [backend/drm/drm.c:180] Found 9 DRM planes 00:00:00.006 [INFO] [wlr] [render/egl.c:201] Supported EGL client extensions: EGL_EXT_client_extensions EGL_EXT_device_base EGL_EXT_device_enumeration EGL_EXT_device_query EGL_EXT_platform_base EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_EXT_platform_device EGL_EXT_platform_wayland EGL_KHR_platform_wayland EGL_EXT_platform_x11 EGL_KHR_platform_x11 EGL_EXT_platform_xcb EGL_MESA_platform_gbm EGL_KHR_platform_gbm EGL_MESA_platform_surfaceless 00:00:00.006 [DEBUG] [wlr] [render/egl.c:469] Using EGL device /dev/dri/card0 00:00:00.036 [INFO] [wlr] [render/egl.c:347] Using EGL 1.5 00:00:00.036 [INFO] [wlr] [render/egl.c:348] Supported EGL display extensions: EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_EXT_image_dma_buf_import_modifiers EGL_IMG_context_priority EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_context_flush_control EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image_base EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_MESA_query_driver EGL_WL_bind_wayland_display 00:00:00.036 [INFO] [wlr] [render/egl.c:350] Supported EGL device extensions: EGL_EXT_device_drm EGL_EXT_device_drm_render_node 00:00:00.036 [INFO] [wlr] [render/egl.c:352] EGL vendor: Mesa Project 00:00:00.036 [DEBUG] [wlr] [render/egl.c:121] Supported DMA-BUF formats: 00:00:00.036 [DEBUG] [wlr] [render/egl.c:165] AB4H (0x48344241) 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] INVALID (0x00FF): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] LINEAR (0x): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] X_TILED (0x0101): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] Y_TILED (0x0102): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:165] XB4H (0x48344258) 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] INVALID (0x00FF): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] LINEAR (0x): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] X_TILED (0x0101): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] Y_TILED (0x0102): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr] [render/egl.c:165] AB48 (0x38344241) 00:00:00.036 [DEBUG] [wlr] [render/egl.c:104] INVALID (0x00FF): ✓ texture ✓ render 00:00:00.036 [DEBUG] [wlr]
bug#65769: greetd-wlgreet-sway-session result is blinking cursor
Hello and thank you in advance for reading me. When defining wlgreet-sway-session in my system config, the result is a blinking cursor. There is no login screen. To login or issue any command, it is necessary to switch to a different tty with something like Alt+fn+F2. In irc, I messaged the user who created greetd-wlgreet-sway-session and it seems other users have encountered the blinking cursor and no one knows of a solution. If possible, I would like help troubleshoot and resolve the issue. My config file is here, https://raw.githubusercontent.com/iambumblehead/guix-home/main/guix.system.scm ```bash $ sudo tail -5 /var/log/greetd-1.log 2023-09-05 18:59:22 error: check_children: greeter exited without creating a session 2023-09-05 18:59:23 error: check_children: greeter exited without creating a session 2023-09-05 18:59:24 error: check_children: greeter exited without creating a session 2023-09-05 18:59:25 error: check_children: greeter exited without creating a session 2023-09-05 18:59:27 error: check_children: greeter exited without creating a session ``` I've tried defining some XDG vars in /home/greeter/.profile and sometimes this causes error messages to appear above the blinking cursor, but no positive result. Please anyone feel free to give advice or suggest any things that I might try.
bug#65541: want this patch
As a CJK user hoping Julien's patch is accepted soon, this message is my "+1".
bug#49337: Guix pull fails on my Talos II
That's fine with me. Thank you for letting us know. If others have similar issues, they can open a new bug for it. Sorry for the top post. On Thu, Aug 10, 2023, 16:18 wrote: > This bug appears to be solved. I was able to run guix pull successfully on > my friends Talos II > yesterday and take advantage of the new guix locate command. > > Chris I vote that we close this bug report. > > Thanks, > > Joshua > > FYI, my friend is running Chimera Linux on said Talos II. >
bug#64488: qtbase and qmake are showing incorrect include folders
With the qtbase package, qmake is showing incorrect info about it's installation when you run qmake -query. If you need include files or libraries from other packages, these won't be used in the qmake utility. It appears as if qmake is only seeing info in the qtbase directory in the store rather than the installed profile directory. This seems to be the same situation of what happened in the nix package too. <https://github.com/NixOS/nixpkgs/issues/239971> I was trying to use a tool that requires this in a project of mine but it doesn't really help me much when I can't use qmake to access info in the qtdeclarative package. Even if both are installed in the same profile or shell. I hope someone smarter than me knows how to fix that. Also, first time posting in the mailing list, so I hope I did it all right. -- *Chris* /Praising God in all things!/
bug#57990: Add package: python-mat2 (remove metadata from images to improve privacy)
Apologies for the top post. I noticed this email and wanted to point you to prior work, in case it proves useful: https://issues.guix.gnu.org/31307#14 On Thu, Sep 22, 2022 at 12:24 PM Maxime Devos wrote: > > > On 22-09-2022 13:38, Dr. Arne Babenhauserheide wrote: > > > > Tobias Geerinckx-Rice writes: > > > >>> can I express "any version of ffmpeg"? > >> > >> No, this would go against the goals of Guix: packages can't depend on > properties of the environment they'll end up in (if any). > > > > What’s the right way to deal with this, then? I need ffmpeg at as > > propagated-input, but I do not want to create a conflict with a manifest > > that just defines "ffmpeg". > > In one my replies, I have proposed a method that avoids propagating ffmpeg: > > > To avoid profile collisions when the user installed a different version > of ffmpeg (e.g. ffmpeg@5) in their profile, could you modify the code to > look at a /gnu/store/.../bin/ffmpeg instead? Likewise for bubblewrap, > gdk-pixbuf, poppler and librsvg, if feasible. > > > > For ffmpeg, the following function needs to be modified: > > > > https://0xacab.org/jvoisin/mat2/-/blob/master/libmat2/video.py#L139 > > > > (substitute* + search-input-file can be useful). > > Greetings, > Maxime. >
bug#56667: test failures tests/channels.scm and tests/texlive.scm
Ludovic Courtès writes: > Hi, > > Chris Keschnat skribis: > >> test-name: channel-news, one entry >> location: /home/ck/tmp/guix/tests/channels.scm:323 >> source: >> + (test-assert >> + "channel-news, one entry" > > [...] > >> + (entry (tag "tag-for-first-news-entry") >> + (title (en "Old news.") (eo "Malnova?oj.")) > > The question mark above suggests you were not running the test in a > Unicode-capable locale. I think you may need to first run: > > export LC_ALL=en_US.UTF-8 > > or something similar. > > Could you check whether that helps? Hi Ludovic, thank you, that does indeed make the test pass. > [...]
bug#56667: test failures tests/channels.scm and tests/texlive.scm
t;doc/man/man1/" "doc/otherformats/texsis/base/"
"tex/texsis/base/" "tex/texsis/config/") (base32
"17ckkii656y2g1h5h8lc1bsy10a0bfgnsakhxii4hxfmvrfvc097") #:trivial? #t))
(version "59745") (propagated-inputs (list texlive-cm texlive-hyphen-base
texlive-knuth-lib texlive-plain texlive-tex)) (home-page
"https://www.tug.org/texlive/;) (synopsis "Plain TeX macros for Physicists")
(description "TeXsis is a TeX macro package which provides useful features for
typesetting\nresearch papers and related documents. For example, it includes
support\nspecifically for: Automatic numbering of equations, figures, tables
and\nreferences; Simplified control of type sizes, line spacing, footnotes,
running\nheadlines and footlines, and tables of contents, figures and tables;
Specialized\ndocument formats for research papers, preprints and \"e-prints\",
conference\nproceedings, theses, books, referee reports, letters, and
memoranda; Simplified\nmeans of constructing an index for a book or thesis;
Easy to use double column\nformatting; Specialized environments for lists,
theorems and proofs, centered or\nnon-justified text, and listing computer
code; Specialized macros for easily\nconstructing ruled tables. TeXsis was
originally developed for physicists, but\nothers may also find it useful. It
is completely compatible with Plain TeX.") (license lppl))
;;; (fail (package (inherit (simple-texlive-package "texlive-texsis" (list
"bibtex/bst/texsis/" "doc/man/man1/" "doc/otherformats/texsis/base/"
"tex/texsis/base/" "tex/texsis/config/") (base32
"17ckkii656y2g1h5h8lc1bsy10a0bfgnsakhxii4hxfmvrfvc097") #:trivial? #t))
(version "59745") (propagated-inputs (list texlive-cm texlive-hyphen-base
texlive-knuth-lib texlive-plain texlive-tex)) (home-page
"https://www.tug.org/texlive/;) (synopsis "Plain TeX macros for Physicists")
(description "TeXsis is a TeX macro package which provides useful features for
typesetting\nresearch papers and related documents. For example, it includes
support\nspecifically for: Automatic numbering of equations, figures, tables
and\nreferences; Simplified control of type sizes, line spacing, footnotes,
running\nheadlines and footlines, and tables of contents, figures and tables;
Specialized\ndocument formats for research papers, preprints and \"e-prints\",
conference\nproceedings, theses, books, referee reports, letters, and
memoranda; Simplified\nmeans of constructing an index for a book or thesis;
Easy to use double column\nformatting; Specialized environments for lists,
theorems and proofs, centered or\nnon-justified text, and listing computer
code; Specialized macros for easily\nconstructing ruled tables. TeXsis was
originally developed for physicists, but\nothers may also find it useful. It
is completely compatible with Plain TeX.") (license lppl)) #f)
test-name: texlive->guix-package
location: /home/ck/tmp/guix/tests/texlive.scm:161
source:
+ (test-assert
+ "texlive->guix-package"
+ (mock ((guix build svn)
+ svn-fetch
+ (lambda* (url
+revision
+directory
+#:key
+(svn-command "svn")
+(user-name #f)
+(password #f)
+(recursive? #t))
+(mkdir-p directory)
+(with-output-to-file
+ (string-append directory "/foo")
+ (lambda () (display "source")
+ (let ((result
+ (texlive->guix-package
+ "texsis"
+ #:package-database
+ (lambda _ %fake-tlpdb
+ (match result
+ (('package
+('inherit
+ ('simple-texlive-package
+ "texlive-texsis"
+ ('list
+ "bibtex/bst/texsis/"
+ "doc/man/man1/"
+ "doc/otherformats/texsis/base/"
+ "tex/texsis/base/"
+ "tex/texsis/config/")
+ ('base32 (? string? hash))
+ #:trivial?
+ #t))
+('propagated-inputs
+ ('list
+ 'texlive-cm
+ 'texlive-hyphen-base
+ 'texlive-knuth-lib
+ 'texlive-plain
+ 'texlive-tex))
+('home-page "https://www.tug.org/texlive/;)
+('synopsis "Plain TeX macros for Physicists")
+('description (? string? description))
+('license 'lppl))
+ #t)
+ (_ (begin
+ (format #t "~s~%" result)
+ (pk 'fail result #f)))
actual-value: #f
result: FAIL
Am I doing anything wrong? I tried reading the results but cannot figure
out what is wrong.
.
[1] https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
Thank you
Chris
bug#51466: bug#53355: guix shell --check: confusing error message
Hi Maxime, Maxime Devos writes: > Chris Marusich schreef op za 25-06-2022 om 02:07 [-0700]: >> It turns out that it is probably not OK to rely on shell redirection >> in >> this case, after all. For example, "dash does not support multi- >> digit >> file descriptors": >> >> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620 > > I consider temporary files to be more fragile -- you have to take care > of file permissions, removing the file afterwards even after an > interrupt with C-c, deleting the temporary file can fail, there might > be an out-of-space error, in case of file system corruption things > might be remounted read-only, some other program could read, write or > delete the file ..., so I think it would be best to just fix the bug in > dash instead. Yes, I agree those are good reasons to avoid a temporary file if we can. To that end, do you know if we can somehow force Guile to use a specific file descriptor for the pipe? In the patch I wrote earlier, which uses redirection, the problem was that I could not control Guile's choice of file descriptors. Guile chose file descriptor 19 for one end of the pipe, and I don't know how to make it use anything else. If we can arrange for Guile to consistently use file descriptor 7, for example, then probably it would work in all the shell I've tested. I wonder if maybe I can just duplicate the file descriptor? I don't know; if for example Guile reserves all the file descriptors below 10 for other uses, it might be hard. What do you think? Is there a way to do it? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#53355: guix shell --check: confusing error message
Hi Ludo & Everyone,
Chris Marusich writes:
> Is it OK to rely on shell redirection?
It turns out that it is probably not OK to rely on shell redirection in
this case, after all. For example, "dash does not support multi-digit
file descriptors":
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/249620
Indeed, the patch I proposed earlier to rely on shell redirection caused
a command like
./pre-inst-env env
SHELL=/gnu/store/nm0hccsphymxi8c24xmg6ixm9vcf25xb-dash-0.5.11.5/bin/dash guix
shell --check --container -D guix
to hang. It hangs because the FD Guile chooses to create and embed in
the script is 19 (on my machine, at least). A redirection like
"env >&19" causes dash to error out, so no environment information gets
sent back to the parent process. The same issue seemed to occur for the
ksh from our oksh package.
To resolve this, I changed the code so that it just writes to a
temporary file. This is simple and more robust. With the attached
patch, I was able to use a command like the one above to verify that
"guix environment --check" works correctly for Guix-built bash, dash,
ksh, fish, zsh, and ash. I also verified that it works for Fedora's
/bin/sh and /bin/bash.
What do you think of this file-based approach? Supporting many
different shells is pretty tricky, but I think this patch does a good
enough job.
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
From ef8d12a1d44903eafca7153c9344263b1d5d7d56 Mon Sep 17 00:00:00 2001
From: Chris Marusich
Date: Fri, 11 Mar 2022 00:20:12 -0800
Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
Fixes: <https://issues.guix.gnu.org/51466>.
* guix/scripts/environment.scm (child-shell-environment) [temporary-file-port]
[temporary-file]: New local variables.
[script]: Redirect stdout to the temporary file.
[lines]: In the parent, send the script to the shell, wait for the shell to
exit, and then read lines from the temporary file. Use a dynamic-wind
expression to ensure we always close port, close temporary-file-port, and
delete temporary-file.
---
guix/scripts/environment.scm | 63
1 file changed, 43 insertions(+), 20 deletions(-)
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 3216235937..b02b0771e3 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -48,6 +48,7 @@ (define-module (guix scripts environment)
#:autoload (gnu packages bash) (bash)
#:autoload (gnu packages bootstrap) (bootstrap-executable %bootstrap-guile)
#:use-module (ice-9 match)
+ #:use-module (ice-9 format)
#:autoload (ice-9 rdelim) (read-line)
#:use-module (ice-9 vlist)
#:use-module (srfi srfi-1)
@@ -418,14 +419,27 @@ (define (child-shell-environment shell profile manifest)
(define-values (controller inferior)
(openpty))
+ (define temporary-file-port (mkstemp "/tmp/guix-env.XX"))
+
+ (define temporary-file (port-filename temporary-file-port))
+
(define script
-;; Script to obtain the list of environment variable values. On a POSIX
-;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
-;; 'set' truncates values and prints them in a different format.)
-"env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
+;; Script to obtain the list of environment variable values.
+;;
+;; On a POSIX shell we can rely on 'set', but on fish we have to use 'env'
+;; (fish's 'set' truncates values and prints them in a different format).
+;;
+;; Unless we redirect output to a file, there is a risk that the shell's
+;; PS1 prompt might clobber the output. See:
+;; https://issues.guix.gnu.org/53355
+(format
+ #f "env >~a || /usr/bin/env >~a || set >~a; \
+echo GUIX-CHECK-DONE >>~a; exit\n"
+ temporary-file temporary-file temporary-file temporary-file))
(define lines
(match (primitive-fork)
+ ;; Child
(0
(catch #t
(lambda ()
@@ -436,24 +450,33 @@ (define lines
(execl shell shell))
(lambda _
(primitive-exit 127
+ ;; Parent
(pid
(close-fdes inferior)
- (let* ((port (fdopen controller "r+l"))
- (result (begin
-(display script port)
-(let loop ((lines '()))
- (match (read-line port)
-((? eof-object?) (reverse lines))
-("GUIX-CHECK-DONE\r"
- (display "done\n" port)
- (reverse lines))
-(line
- ;; Drop the '\r' from LINE.
- (loop (cons (string-drop-right line 1)
- lines)))
bug#51466: bug#53355: guix shell --check: confusing error message
Hi Ludo,
Thank you for the review!
Ludovic Courtès writes:
> LGTM, please push!
Before pushing, I did some more tests to make sure it was still working.
When I did this, I noticed that read-line was no longer returning
strings that end in "\r". This prevents child-shell-environment from
behaving correctly, since it incorrectly assumes that all the lines end
in "\r", stripping it off unconditionally. In the past, I'm sure
read-line was returning strings that end in "\r". I don't know what
changed, but I've attached a second patch that fixes this issue, also.
Unless you have more feedback, I'll go ahead and push both patches to
master in a few days.
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
From c4fee9e63f8cb694de86ae46bd1e2e4c692eb6f6 Mon Sep 17 00:00:00 2001
From: Chris Marusich
Date: Sun, 19 Jun 2022 13:16:04 -0700
Subject: [PATCH] environment: Don't assume that lines have a trailing "\r".
I've noticed that the child-shell-environment procedure is misbehaving on my
computer because the lines returned by read-line do not have a trailing "\r".
In the past, I recall that such lines did in fact have a trailing "\r". I'm
not sure why it changed, but it seems prudent to just rewrite this code to
tolerate both cases, since it seems that both cases can happen.
* guix/scripts/environment.scm (child-shell-environment) [lines]: Instead of
checking if the line exactly matches "GUIX_CHECK_DONE\r"; check if the line
begins with "GUIX_CHECK_DONE". Instead of always stripping the trailing
character from the line, only do it if the line has a trailing "\r".
---
guix/scripts/environment.scm | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index f0cb341aab..1fb4f5b7c6 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -462,13 +462,18 @@ (define lines
;; prompt from getting mixed into what we read.
(match (read-line shell-pipe-in)
((? eof-object?) (reverse lines))
-("GUIX-CHECK-DONE\r"
+((? (lambda (line)
+ ;; The line might or might not have a trailing \r.
+ (string-prefix? "GUIX-CHECK-DONE" line)))
(display "done\n" port)
(reverse lines))
(line
- ;; Drop the '\r' from LINE.
- (loop (cons (string-drop-right line 1)
- lines
+ ;; Strip the trailing '\r' from LINE if present.
+ (let ((stripped-line
+(if (string-suffix? "\r" line)
+(string-drop-right line 1)
+line)))
+ (loop (cons stripped-line lines)
(close-port port)
(close-port shell-pipe-in)
(waitpid pid)
--
2.34.0
signature.asc
Description: PGP signature
bug#53355: guix shell --check: confusing error message
Hi Ludo, Ludovic Courtès writes: > So you confirm that a single “echo” is not enough, right? I didn't test one specifically. It might work with just one, but it did work with three. If we want to proceed with the "echo" approach, let me know and I'll test just one echo to see if that is reliable enough. > Perhaps we should unroll the ‘for’ loop for portability, to be on the > safe side. Initially I tested with Bash, Zsh, and Fish: > > https://issues.guix.gnu.org/51285#0-lineno49 > > I think Fish has a very non-POSIX syntax, hence the suggestion to avoid > ‘for’. I see. Yes, I'll do that if we decide to go with the echo-based approach. > I realized that setting PS1 could interfere with the logic below that > checks for PS1. And since it doesn’t seem to help, perhaps we can > remove “PS1=;”? I recall that I tried removing PS1, and I still had trouble. I believe it was because even if we unset PS1 as the very first command we do, the original prompt is still printed. Foreign distros usually set PS1 to something, and whatever that is will be printed before we have a chance to input any commands. It's hard to avoid that in general. > Thoughts? One alternative method I tried successfully in a variety of shells was to use shell redirection (see attached). I like this approach. However, this will only work in shells that support redirection. I recall testing with bash, ash (busybox's shell), dash, zsh, fish, ksh, and csh. I recall that only csh failed, since it doesn't support redirection. I personally like the attached patch better than what I proposed earlier. The earlier patch just echoes a few times. Presumably, it only works because the PS1 prompt is likely (but not guaranteed) to be emitted before the last of the echo commands finishes printing. I'd rather just control the desired output and ignore PS1 entirely, and that is what the attached patch accomplishes using FDs. However, if support for shells without redirection is a requirement, then maybe the original hack (echo a few times) is OK, or perhaps we need something else. How would you like to proceed? Is it OK to rely on shell redirection? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From 9a1cef589abf01b61e22656f44c76441f4c50ffd Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Fri, 11 Mar 2022 00:20:12 -0800 Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'. Fixes: <https://issues.guix.gnu.org/51466>. * guix/scripts/environment.scm (child-shell-environment) [shell-pipe] [shell-pipe-in, shell-pipe-out]: New local variables. [script]: Redirect the stdout of each command to the file descriptor of the shell-pipe-out port. [lines]: In the child, close shell-pipe-in before starting the shell. In the parent, close shell-pipe-out before sending the script to the shell. Read lines from shell-pipe-in, not port, so that the shell's PS1 prompt cannot clobber the lines. Close shell-pipe-in just before waiting on the child. --- guix/scripts/environment.scm | 29 - 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm index 3216235937..f0cb341aab 100644 --- a/guix/scripts/environment.scm +++ b/guix/scripts/environment.scm @@ -48,6 +48,7 @@ (define-module (guix scripts environment) #:autoload (gnu packages bash) (bash) #:autoload (gnu packages bootstrap) (bootstrap-executable %bootstrap-guile) #:use-module (ice-9 match) + #:use-module (ice-9 format) #:autoload (ice-9 rdelim) (read-line) #:use-module (ice-9 vlist) #:use-module (srfi srfi-1) @@ -418,11 +419,23 @@ (define (child-shell-environment shell profile manifest) (define-values (controller inferior) (openpty)) + (define shell-pipe (pipe)) + (define shell-pipe-in (car shell-pipe)) + (define shell-pipe-out (cdr shell-pipe)) + (define script -;; Script to obtain the list of environment variable values. On a POSIX -;; shell we can rely on 'set', but on fish we have to use 'env' (fish's -;; 'set' truncates values and prints them in a different format.) -"env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n") +;; Script to obtain the list of environment variable values. +;; +;; On a POSIX shell we can rely on 'set', but on fish we have to use 'env' +;; (fish's 'set' truncates values and prints them in a different format). +;; +;; Unless we redirect output to a dedicated file descriptor, there is a +;; risk that the shell's PS1 prompt might clobber the output. See: +;; https://issues.guix.gnu.org/53355 +(let ((out-fd (port->fdes shell-pipe-out))) + (format + #f "env 1>&~d || /usr/bin/env 1>&~d || set 1>&~d; \ +echo GUIX-CHECK-DONE 1>&~d; read x; exit\n" out-fd out-fd out-fd out-fd))) (define lines (match
bug#51466: bug#53355: guix shell --check: confusing error message
le/site/3.0" "GUILE_LOAD_PATH") ;;; (variable "HOME=/home/marusich" "HOME") ;;; (variable "LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:" "LS_COLORS") ;;; (variable "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_COMPILED_PATH") ;;; (variable "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info" "INFOPATH") ;;; (variable "TERM=screen.xterm-256color" "TERM") ;;; (variable "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "CPLUS_INCLUDE_PATH") ;;; (variable "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal" "ACLOCAL_PATH") ;;; (variable "USER=marusich" "USER") ;;; (variable "LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "LIBRARY_PATH") ;;; (variable "SHLVL=1" "SHLVL") ;;; (variable "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale" "GUIX_LOCPATH") ;;; (variable "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile" "GUIX_ENVIRONMENT") ;;; (variable "PS1=" "PS1") ;;; (variable "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin" "PATH") ;;; (variable "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "C_INCLUDE_PATH") ;;; (variable "_=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin/env" "_") guix shell: All is good! The shell gets correct environment variables. [0] [env] marusich@suzaku:~/guix-master $ --8<---cut here---end--->8--- As you can see, it seems to be working correctly here. Here's a version of the patch that is ready for committing, with the debug statements removed and comments added: From c3eea81846ae71a246e6b592be74062f4bf26474 Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Sun, 13 Feb 2022 14:15:14 -0800 Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'. Fixes: <https://issues.guix.gnu.org/51466>. * guix/scripts/environment.scm (child-shell-environment): In the script executed the child shell, set PS1 to an empty value and then echo three sentinel lines to try to "flush" the original PS1 value before printing the environment variables. In the parent process, read and discard all lines up to and including the last sentinel line. After that, read the remaining lines as usual. --- guix/scripts/environment.scm | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm index ec071402f4..0b137467f9 100644 --- a/guix/scripts/environment.scm +++ b/guix/scripts/environment.scm @@ -2,6 +2,7 @@ ;;; Copyright © 2014, 2015, 2018 David Thompson ;;; Copyright © 2015-2022 Ludovic Courtès ;;; Copyright © 2018 Mike Gerwitz +;;; Copyright © 2022 Chris Marusich ;;; ;;; This file is part of GNU Guix. ;;; @@ -420,7 +421,16 @@ by running 'set' in the shel
bug#51466: bug#53355: guix shell --check: confusing error message
Hi, I also observed this bug and reported it as 53355. I tried to search for bugs, but I didn't find this bug report until Ludo mentioned it. I think it's probably the same bug, so I've merged them. Ludovic Courtès writes: > It looks like the shell-check machinery is misdiagnosing things, as > Vagrant reported in <https://issues.guix.gnu.org/51466> (is this on > Debian too?). Yes, it's also Debian. Debian Bullseye. I've also verified that similar behavior occurs on Fedora, although the problematic env vars are different. I tried fiddling with SHELL like Vagrant did, but I couldn't make the error go away like he did. Maybe I did something differently. > Could you try the debugging tricks I proposed there? Sure thing! Thank you for taking the time to make the patch, even though it was simple. Here is the result on my Debian Bullseye ppc64el system: --8<---cut here---start->8--- [0] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell --check --pure --development guix guix shell: checking the environment variables visible from shell '/bin/sh'... ;;; (dropped "env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit" #) ;;; (variable "$ LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ LIBRARY_PATH") ;;; (variable "C_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "C_INCLUDE_PATH") ;;; (variable "USER=marusich" "USER") ;;; (variable "GUIX_LOCPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/locale" "GUIX_LOCPATH") ;;; (variable "HOME=/home/marusich" "HOME") ;;; (variable "GUILE_LOAD_COMPILED_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/guile/3.0/site-ccache:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_COMPILED_PATH") ;;; (variable "CPLUS_INCLUDE_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include/c++:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/include" "CPLUS_INCLUDE_PATH") ;;; (variable "INFOPATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/info" "INFOPATH") ;;; (variable "LOGNAME=marusich" "LOGNAME") ;;; (variable "PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig" "PKG_CONFIG_PATH") ;;; (variable "TERM=screen.xterm-256color" "TERM") ;;; (variable "ACLOCAL_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/aclocal" "ACLOCAL_PATH") ;;; (variable "PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/bin:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/sbin" "PATH") ;;; (variable "GUIX_ENVIRONMENT=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile" "GUIX_ENVIRONMENT") ;;; (variable "GUILE_LOAD_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/share/guile/site/3.0" "GUILE_LOAD_PATH") ;;; (variable "PWD=/home/marusich/guix-master" "PWD") guix shell: warning: variable 'LIBRARY_PATH' is missing from shell environment hint: One or more environment variables have a different value in the shell than the one we set. This means that you may find yourself running code in an environment different from the one you asked Guix to prepare. This usually indicates that your shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in `~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash startup files, run: info "(bash) Bash Startup Files" Alternatively, you can avoid the problem by passing the `--container' or `-C' option. That will give you a fully isolated environment running in a "container", immune to the issue described above. [1] [env] marusich@suzaku:~/guix-master $ --8<---cut here---end--->8--- The presence of the "$" in front of LIBRARY_PATH seems suspicious: ;;; (variable "$ LIBRARY_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib" "$ LIBRARY_PATH") I'm not sure why the "$" is being added. I tried various things to remove it. I tried explicitly setting PS1 to an empty string in my ~/.bashrc. I also tried setting it explicitly to an empty string in /etc/profile. Maybe if we can figure out where that "$ " prefix is coming from, we can resolve this issue? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#53355: guix shell --check: confusing error message
nvironment variable is different (PKG_CONFIG_PATH in this case): --8<---cut here---start->8--- [0] marusich@suzaku:~/guix-master $ guix environment guix [0] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell --check -D guix -- bash -c 'echo in env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH"' guix shell: checking the environment variables visible from shell '/bin/bash'... guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment hint: One or more environment variables have a different value in the shell than the one we set. This means that you may find yourself running code in an environment different from the one you asked Guix to prepare. This usually indicates that your shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in `~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash startup files, run: info "(bash) Bash Startup Files" Alternatively, you can avoid the problem by passing the `--container' or `-C' option. That will give you a fully isolated environment running in a "container", immune to the issue described above. [1] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell --check --pure -D guix -- bash -c 'echo in env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH"' guix shell: checking the environment variables visible from shell '/bin/bash'... guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment hint: One or more environment variables have a different value in the shell than the one we set. This means that you may find yourself running code in an environment different from the one you asked Guix to prepare. This usually indicates that your shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in `~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash startup files, run: info "(bash) Bash Startup Files" Alternatively, you can avoid the problem by passing the `--container' or `-C' option. That will give you a fully isolated environment running in a "container", immune to the issue described above. [1] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell --check --container -D guix -- bash -c 'echo in env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH"' guix shell: warning: '--check' is unnecessary when using '--container'; doing nothing in env, PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig [0] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell -D guix -- bash -c 'echo in env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH"' in env, PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig:/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig [0] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell --pure -D guix -- bash -c 'echo in env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH"' in env, PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig [0] [env] marusich@suzaku:~/guix-master $ ./pre-inst-env guix shell --container -D guix -- bash -c 'echo in env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH"' in env, PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig [0] [env] marusich@suzaku:~/guix-master $ echo out of env, PKG_CONFIG_PATH="$PKG_CONFIG_PATH" out of env, PKG_CONFIG_PATH=/gnu/store/hvcq6yjfjjc7060pq09zm1rj02mivg4h-profile/lib/pkgconfig [0] [env] marusich@suzaku:~/guix-master $ --8<---cut here---end--->8--- It seems this issue happens regardless of whether I use pre-inst-env or run Guix from a "guix pull" installation. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#53355: guix shell --check: confusing error message
Hi, I've grown so used to using "guix environment," I thought I'd try out "guix shell." It looks pretty neat! It's good to try to improve the CLI. However, when I tried "guix shell," I quickly observed this confusing behavior: --8<---cut here---start->8--- [130] marusich@suzaku:~/guix-master $ guix shell --container --check -D guix guix shell: checking the environment variables visible from shell '/bin/bash'... guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment hint: One or more environment variables have a different value in the shell than the one we set. This means that you may find yourself running code in an environment different from the one you asked Guix to prepare. This usually indicates that your shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in `~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash startup files, run: info "(bash) Bash Startup Files" Alternatively, you can avoid the problem by passing the `--container' or `-C' option. That will give you a fully isolated environment running in a "container", immune to the issue described above. [1] marusich@suzaku:~/guix-master $ env | grep PKG_CONF [1] marusich@suzaku:~/guix-master $ guix shell --check -D guix guix shell: checking the environment variables visible from shell '/bin/bash'... guix shell: warning: variable 'PKG_CONFIG_PATH' is missing from shell environment hint: One or more environment variables have a different value in the shell than the one we set. This means that you may find yourself running code in an environment different from the one you asked Guix to prepare. This usually indicates that your shell startup files are unexpectedly modifying those environment variables. For example, if you are using Bash, make sure that environment variables are set or modified in `~/.bash_profile' and _not_ in `~/.bashrc'. For more information on Bash startup files, run: info "(bash) Bash Startup Files" Alternatively, you can avoid the problem by passing the `--container' or `-C' option. That will give you a fully isolated environment running in a "container", immune to the issue described above. [1] marusich@suzaku:~/guix-master $ guix shell -D guix [0] [env] marusich@suzaku:~/guix-master $ env | grep PKG PKG_CONFIG_PATH=/gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/lib/pkgconfig [0] [env] marusich@suzaku:~/guix-master $ exit [0] marusich@suzaku:~/guix-master $ guix shell --container -D guix marusich@suzaku ~/guix-master [env]$ env | grep PKG PKG_CONFIG_PATH=/gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/lib/pkgconfig marusich@suzaku ~/guix-master [env]$ --8<---cut here---end--->8--- I found the following things to be confusing: (1) The error message claims that PKG_CONFIG_PATH is "missing from shell environment." However, it seems to be present when I run "env". (2) It says I can avoid the problem by passing the `--container' option, but even when I do that, the problem seems to persist. If that is expected behavior, then perhaps the wording should be changed to something less certain, such as "you might be able to avoid the problem". It does not seem to be the case that I can avoid the problem by passing the `--container' option in this case. What's really going on here? It's good to be able to look at this feature with the eyes of a newbie, since I'm very used to using "guix environment", but "guix shell" is totally new to me. I thought it would be a good opportunity to provide feedback. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
Hi, Chris Marusich writes: > If nobody has further comments, I will commit the attached version to > master in about 24 hours. I've committed this in 24c3485bb3ffc05e687ef6513ac287b8d3048bab. We still need to update the "guix" package, so even if you run "guix pull" right now, you won't be able to successfully build "guix" after pulling on aarch64-linux yet. I will coordinate with the other people who are helping to make the 1.4.0 release to ensure that this fix makes it into the 1.4.0 release. See this guix-devel email thread for details: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00296.html -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
Hi Pierre, FYI, it looks like you included bug-guix@gnu.org in the CC list of your last email. If you do that, I believe it will create a new bug report, which may not be what you intended to do. Pierre Langlois writes: > I'm afraid I don't have any new insight if this is an issue or just > working as intended. Given we have a limited bandwidth to address this > thoroughly, would it make sense to apply a temporary work-around in the > mean time? I'd be good for at least guix to build on aarch64 in the 1.4 > release. > > I have the attached patch in my tree for instance (along with an update > of the guix package), and I've not noticed any issues on a rockpro64, > running cgit, DHCP and dnsmasq. That's just anecdotal :-), but I'm also > thinking if we unblock the guix package then the farm might catch other > issues that could help getting to the bottom of this. > > WDYT? I agree with you. That said, I don't personally run any aarch64-linux machines, and I don't plan to investigate the aarch64-linux issue further right now. Although I will defer to anyone who actually runs aarch64-linux and knows better, at the moment to me it seems reasonable to commit a patch like the one you've proposed in order to ensure that the "guix" package builds successfully on that platform for the 1.4.0 release. The fact that you have successfully built and used various pieces of software on aarch64-linux with this patch suggests that maybe the current behavior is OK, after all. I've made some rather trivial modifications to your patch, mainly to make it conform to our required ChangeLog format. If nobody has further comments, I will commit the attached version to master in about 24 hours. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From f502bab1e09276982acfd3ac0c151b241f7aa07d Mon Sep 17 00:00:00 2001 From: Pierre Langlois Date: Wed, 22 Dec 2021 22:02:08 + Subject: [PATCH] tests: Fix file-needed/recursive on aarch64-linux. Fixes: <https://issues.guix.gnu.org/52943>. * tests/gremlin.scm (file-needed/recursive)[ground-truth]: On aarch64-linux, remove the dynamic linker from this list. --- tests/gremlin.scm | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/tests/gremlin.scm b/tests/gremlin.scm index 9e0017337a..3dbb8d3643 100644 --- a/tests/gremlin.scm +++ b/tests/gremlin.scm @@ -1,6 +1,7 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2015, 2018, 2020, 2022 Ludovic Courtès ;;; Copyright © 2022 Chris Marusich +;;; Copyright © 2022 Pierre Langlois ;;; ;;; This file is part of GNU Guix. ;;; @@ -20,9 +21,11 @@ (define-module (test-gremlin) #:use-module (guix elf) #:use-module (guix tests) - #:use-module ((guix utils) #:select (call-with-temporary-directory)) + #:use-module ((guix utils) #:select (call-with-temporary-directory + target-aarch64?)) #:use-module (guix build utils) #:use-module (guix build gremlin) + #:use-module (gnu packages bootstrap) #:use-module (srfi srfi-1) #:use-module (srfi srfi-26) #:use-module (srfi srfi-34) @@ -99,7 +102,12 @@ (define ground-truth (or (string-prefix? "linux-vdso.so" entry) (string-prefix? "linux-vdso32.so" entry) ;32-bit powerpc (string-prefix? "linux-vdso64.so" entry) ;64-bit powerpc -(string-prefix? "linux-gate.so" entry))) ;i386 +(string-prefix? "linux-gate.so" entry) ;i386 +;; FIXME: ELF files on aarch64 do not always include a +;; NEEDED entry for the dynamic linker, and it is unclear +;; if that is OK. See: https://issues.guix.gnu.org/52943 +(and (target-aarch64?) + (string-contains entry (glibc-dynamic-linker) (read-ldd-output pipe))) (and (zero? (close-pipe pipe)) base-commit: 172bd0b5cde2609389fd16d18862b5b612c4b000 -- 2.33.1 signature.asc Description: PGP signature
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
Hi Maxime, Aiko, and Leo, Maxime Devos writes: > Chris Marusich schreef op do 06-01-2022 om 20:32 [-0800]: >> + (if (string-prefix? "x86_64" >> system) > > There's a target-x86-64? procedure in (guix utils) you could use here. > > Greetings, > Maxime Good call! I implemented your suggestion in commit dc2b901. Aiko Kyle writes: > On Thu, Jan 6, 2022 at 9:32 PM Chris Marusich wrote: >> >> Aiko, can you confirm that after running "guix pull" the issue is >> resolved on your end, too? >> > > I can confirm that this test passes here. However guix system > reconfigure is still failing for me on aarch64 due to the test > 'file-needed/recursive' in tests/gremlin.scm failing. There was an > email on guix-devel starting to look into this issue on aarch64 but I > haven't had the time to follow up. Thank you for confirming! Leo Famulari writes: > On Fri, Jan 07, 2022 at 06:26:13PM -0700, Aiko Kyle wrote: > > I can confirm that this test passes here. > > Awesome, I am closing this bug. Thanks everybody, for collaborating on a > quick fix! > > > However guix system > > reconfigure is still failing for me on aarch64 due to the test > > 'file-needed/recursive' in tests/gremlin.scm failing. There was an > > email on guix-devel starting to look into this issue on aarch64 but I > > haven't had the time to follow up. > > I think there is a fix being discussed here: > > https://issues.guix.gnu.org/52940 I think the issue described in 52940 is similar but slightly different to the one Aiko mentioned. I have resolved 52940 because that issue (only happening on powerpc64le-linux, to my knowledge) has been fixed. However, I have re-opened Aiko's existing report for the aarch64-specific issue here: https://issues.guix.gnu.org/52943 Let's continue the discussion of that issue there. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#52943: Cannot build guix as part of guix system reconfigure after commit 224d437fb4 on aarch64
24 (bytes)
0x6ffe (VERNEED)0x1848
0x6fff (VERNEEDNUM) 2
0x6ff0 (VERSYM) 0x1826
0x (NULL) 0x0
marusich@suzaku ~/guix-master [env]$ ./pre-inst-env guix repl
GNU Guile 3.0.7
Copyright (C) 1995-2021 Free Software Foundation, Inc.
Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.
Enter `,help' for help.
scheme@(guix-user)> ,use (guix build gremlin)
scheme@(guix-user)> ,pp (file-needed/recursive
"/gnu/store/qr79b2m6cfdj8ar7g0psqg4hglm6djfm-profile/bin/guile")
$1 = ("/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libc.so.6"
"/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib/libgcc_s.so.1"
"/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libm.so.6"
"/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libdl.so.2"
"/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libcrypt.so.1"
"/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistring-0.9.10/lib/libunistring.so.2"
"/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib/libffi.so.7"
"/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/libpthread.so.0"
"/gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib/libgc.so.1"
"/gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1"
"/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/ld64.so.2"
"/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib/libc.so.6")
$2 = ("ld64.so.2")
scheme@(guix-user)>
--8<---cut here---end--->8---
I don't know if it's related, but I just noticed this: it's a little
strange that in the above output (for powerpc64le-linux), ld64.so.2 is
included in the second value ($2). This is supposedly the list of .so
file names that could not be found. It's strange that ld64.so.2 shows
up in $2 because it seems to contradict the fact that it is included in
$1, which is the list of files that were found successfully.
Since Pierre shared information about the libguile shared object
specifically, I'll do the same here. On powerpc64le-linux, the
"ld64.so.2" entry is present in the dynamic section of the
/gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1
ELF file:
--8<---cut here---start->8---
marusich@suzaku ~/guix-master [env]$ readelf -d
/gnu/store/47s31zvkhk2ixqn0z7gq6hpz7j7cn9dl-guile-3.0.7/lib/libguile-3.0.so.1|
grep -e NEEDED -e RUNPATH
0x0001 (NEEDED) Shared library: [libgc.so.1]
0x0001 (NEEDED) Shared library: [libpthread.so.0]
0x0001 (NEEDED) Shared library: [libffi.so.7]
0x0001 (NEEDED) Shared library: [libunistring.so.2]
0x0001 (NEEDED) Shared library: [libcrypt.so.1]
0x0001 (NEEDED) Shared library: [libdl.so.2]
0x0001 (NEEDED) Shared library: [libm.so.6]
0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0001 (NEEDED) Shared library: [libc.so.6]
0x0001 (NEEDED) Shared library: [ld64.so.2]
0x001d (RUNPATH)Library runpath:
[/gnu/store/csqz3w2axyci2qm79xsj11cpfxqh7zb1-libgc-8.0.4/lib:/gnu/store/kmgva3hbpk1bv0gvx5s4w01n0fdvd2l9-libffi-3.3/lib/../lib:/gnu/store/zf87w2xccli6yvxpplfwd82gcgm6jyrd-libunistr
ing-0.9.10/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib:/gnu/store/l0hnwrv8ma03shjg84a03s05wmj7a0sk-gcc-10.3.0-lib/lib:/gnu/store/3jr84ajdz821y480c454pqrswxbhgzlq-glibc-2.33/lib/../lib:/gnu/store/l0hnwrv8ma03shjg84a03s05
wmj7a0sk-gcc-10.3.0-lib/lib/gcc/powerpc64le-unknown-linux-gnu/10.3.0/../../../../lib]
--8<---cut here---end--->8---
Maybe this information can help somehow.
It seems fishy that on aarch64-linux, there is no NEEDED entry for
ld-linux-aarch64.so.1 in the ELF files under consideration. As shown
above, a similar entry DOES exist on both x86_64-linux and
powerpc64le-linux. For this reason, it seems plausible that maybe the
missing NEEDED entry is bad. However, I don't really know enough to say
whether it's indicative of a problem with our aarch64-linux port. Is
there an aarch64-linux or ELF expert in the room who can help? :-)
It also seems fishy that, on powerpc64le-linux, file-needed/recursive
apparently resolves ld64.so.2 successfully, even though it
simultaneously includes it in the "failed to resolve" list. Confusing
as that is to me, I don't know if that's really related to the
aarch64-linux issue.
More investigation is needed...
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
signature.asc
Description: PGP signature
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
Hi Ludo and Aiko,
Ludovic Courtès writes:
> I’d rather not move things and fix the bug in the same commit. (I’m not
> even convinced sddm needs to leave its own module, plus it would break
> the API, which is not something to do lightly.)
You're right! I was able to avoid moving the (gnu services sddm) module
by autoloading it from (gnu services xorg). I've committed the fix as
79260c8695cc5e3cd64f5b01e262369d5a67f141, along with two commits that
update the guix package.
> Thanks for fixing it!
>
> And yes, we’ll need to update the ‘guix’ package once this fix is in.
Thank you for the review!
Aiko, can you confirm that after running "guix pull" the issue is
resolved on your end, too?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
From 79260c8695cc5e3cd64f5b01e262369d5a67f141 Mon Sep 17 00:00:00 2001
From: Chris Marusich
Date: Thu, 6 Jan 2022 18:43:47 -0800
Subject: [PATCH] services: Consistently use SDDM rather than GDM on
non-x86_64.
This is a follow-up to 49599fab564f203b8e92d32e9b28c99e99849bfb.
Fixes: <https://issues.guix.gnu.org/52908>.
* gnu/services/xorg.scm (set-xorg-configuration)[login-manager-service-type]:
When the current system or target system begins with the string "x86_64", use
gdm-service-type as before; otherwise, use sddm-service-type.
* gnu/system/examples/vm-image.tmpl (services): Add sddm-service-type to the
list of service types to remove.
---
gnu/services/xorg.scm | 11 ++-
gnu/system/examples/vm-image.tmpl | 6 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 82a7d25602..35f8dbc5f8 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -11,6 +11,7 @@
;;; Copyright © 2021 Brice Waegeneire
;;; Copyright © 2021 Oleg Pykhalov
;;; Copyright © 2021 Josselin Poiret
+;;; Copyright © 2022 Chris Marusich
;;;
;;; This file is part of GNU Guix.
;;;
@@ -28,6 +29,7 @@
;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
(define-module (gnu services xorg)
+ #:autoload (gnu services sddm) (sddm-service-type)
#:use-module (gnu artwork)
#:use-module (gnu services)
#:use-module (gnu services shepherd)
@@ -1040,10 +1042,17 @@ the GNOME desktop environment.")
"Run the GNOME Desktop Manager (GDM), a program that allows
you to log in in a graphical session, whether or not you use GNOME."
+;; Since GDM depends on Rust (gdm -> gnome-shell -> gjs -> mozjs -> rust)
+;; and Rust is currently unavailable on non-x86_64 platforms, default to
+;; SDDM there (FIXME).
(define* (set-xorg-configuration config
#:optional
(login-manager-service-type
- gdm-service-type))
+ (let ((system (or (%current-target-system)
+(%current-system
+(if (string-prefix? "x86_64" system)
+gdm-service-type
+sddm-service-type
"Tell the log-in manager (of type @var{login-manager-service-type}) to use
@var{config}, an record."
(simple-service 'set-xorg-configuration
diff --git a/gnu/system/examples/vm-image.tmpl b/gnu/system/examples/vm-image.tmpl
index a59d91587b..ccb0b045db 100644
--- a/gnu/system/examples/vm-image.tmpl
+++ b/gnu/system/examples/vm-image.tmpl
@@ -5,7 +5,7 @@
;;
(use-modules (gnu) (guix) (srfi srfi-1))
-(use-service-modules desktop mcron networking spice ssh xorg)
+(use-service-modules desktop mcron networking spice ssh xorg sddm)
(use-package-modules bootloaders certs fonts nvi
package-management wget xorg)
@@ -107,12 +107,12 @@ root ALL=(ALL) ALL
;; Use the DHCP client service rather than NetworkManager.
(service dhcp-client-service-type))
- ;; Remove GDM, ModemManager, NetworkManager, and wpa-supplicant,
- ;; which don't make sense in a VM.
+ ;; Remove some services that don't make sense in a VM.
(remove (lambda (service)
(let ((type (service-kind service)))
(or (memq type
(list gdm-service-type
+ sddm-service-type
wpa-supplicant-service-type
cups-pk-helper-service-type
network-manager-service-type
base-commit: c4240dfdb433239108edaf12acb5c51138f9dc74
--
2.30.2
signature.asc
Description: PGP signature
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
Hi Pierre and Aiko, Pierre Langlois writes: > I believe we'll have to update the package as well. For example on > aarch64 I can do a `guix pull' just fine, however `guix system reconfigure' > fails because it builds the full guix package, including running the > tests. > > You've mentioned that `guix pull' was not working for you on ppc64 > though right? I wonder why, is this a difference between using Guix as > the OS as opposed to a package manager on top of another OS? Aiko Kyle writes: > I actually encountered this issue not doing a "guix pull" but in doing > a "guix system reconfigure" after a guix pull. I don't really > understand why, but I think guix system reconfigure will continue to > fail until the "guix" package is updated. I may be totally incorrect > here though as I'm still new to this. You're right. I was confused. I incorrectly thought that Leo and Aiko were saying that they couldn't run "guix pull". However, Leo's original message (on Thu, 30 Dec 2021) explained that the problem occurred for him while building the "guix" package, not while running "guix pull". In fact, I've just confirmed that "guix pull" DOES work for me on powerpc64le-linux using commit b9c5dff57ff961a16c8fc24843a4535ea817e732. I ran this command: guix pull --cores=14 --commit=b9c5dff57ff961a16c8fc24843a4535ea817e732 --profile=/tmp/test-pull-b9c5dff57 I'm not sure why I was confused, but I apologize. The "guix pull" command actually works fine on powerpc64le-linux. However, the "guix" package fails to build, exactly as described in this bug report. So, I agree: in addition to the patch, we do also need to update the guix package. To that end, when I commit the patch to the master branch in about 24 hours, I will also add two commits to update the "guix" package twice, since the comment in the "guix" package (added in commit c0a693dfec3e0c3361dab40f354966730dde4ef3) explains that it must be updated twice: ;; If you are updating this package because it fails to build, you need to ;; actually update it *twice*, as the installer is pointing to the N-1 guix ;; package revision. I'll let you know once I've done that. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
Hi Aiko and Leo, Aiko Kyle writes: > It would be great to get this upstreamed soon so I can start guix > pulling master. I think the guix commit and revision in > package-management.scm will also need to be bumped after applying this > fix. It shouldn't be necessary to update the guix commit and revision in package-management.scm. My understanding is that "guix pull" will install Guix at the specified commit; it does not use the guix package to decide which version to install. In other words, even if at the specified commit the "guix" package is defined to use an older version (I believe this is always the case, actually), it will not stop "guix pull" from installing Guix at the specified commit. If it's necessary to update the "guix" package, we can certainly do it. However, I don't recall that it's necessary for fixing "guix pull" problems like this. If you still believe it's necessary, can you help me to understand why it's necessary? Leo Famulari writes: > On Mon, Jan 03, 2022 at 08:43:27PM -0700, Aiko Kyle wrote: >> I'll defer to you and Leo for that judgment! > > I defer to you and Chris! And I agree, let's push the fix ASAP :) OK. I want to give people time to comment on the patch, but I also want to help fix "guix pull" on master sooner rather than later. I will commit my patch in about 48 hours to the master branch if nobody has any further feedback. I don't think my patch will trigger many rebuilds. To verify this, I tried building coreutils on powerpc64le-linux before and after applying my patch. It did not trigger a rebuild of coreutils, so I don't think it will trigger many rebuilds. It's conceivable that some derivation that uses the (gnu services xorg) or (gnu services sddm) modules might change (maybe something related to Guix System?), but I don't know of an easy way to check that. -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 signature.asc Description: PGP signature
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
Hi Aiko,
Aiko Kyle writes:
> Commit 9309b48 seems to be a week old and I can't seem to apply this
> patch on top of the latest commit on master e6fe4e5819.
How did you apply the patch? I was able to apply the patch locally to
commit 80ebf564e3e264a006d7c7b1f7f2e57fc2468ef1 (".guix-authorizations:
Remove Miguel Ángel Arruga Vivas due to inactivity."), which is
currently the latest commit on master.
I applied by patch by saving the MIME part to a file named "/tmp/patch".
Then I ran the following command from a clean Git checkout of commit
80ebf564e3e264a006d7c7b1f7f2e57fc2468ef1:
git am /tmp/patch
For the record, the SHA-256 hash value of the patch file is
6650872d41068f6031633d2720553eeb05e7d650a51723dfdd2a3c2df3df294e. If
you run "sha256sum /tmp/patch", do you see the same hash value?
--
Chris
PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836
signature.asc
Description: PGP signature
bug#52908: 'tests/guix-system.sh' fails on aarch64-linux
Hi Leo and Aiko, This issue also affects powerpc64le-linux. Aiko's patch would indeed fix the failing test. Thank you, Aiko, for taking the initiative to help investigate and solve the issue! However, even though that patch would fix the test, anyone who is using set-xorg-configuration on a non-x86_64 system would still need to change the way they call it, which is not ideal. I've attached a different patch that attempts to fix the issue without requiring callers of set-xorg-configuration to update their code. I believe this is more consistent with the intent of Ludo's original change in commit 49599fab564f203b8e92d32e9b28c99e99849bfb. You'll notice that this patch moves the (gnu services sddm) code into (gnu services xorg) and deprecates (gnu services sddm). I did this in order to avoid a circular dependency between the two modules. Perhaps there's a better way. However, many of the existing display managers already live in (gnu services xorg), so it seemed reasonable to me. I've verified that the tests/guix-system.sh test passes on powerpc64le-linux after applying this patch to current master branch (on top of commit 9309b488ca4ceef4fcc9283546e3b05c57b16ca8). I've also verified that the deprecation warnings are being emitted, and that the existing bindings in (gnu services sddm) are still usable, at the REPL: --8<---cut here---start->8--- $ ./pre-inst-env guix repl GNU Guile 3.0.7 Copyright (C) 1995-2021 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guix-user)> ,use (gnu services sddm) scheme@(guix-user)> (sddm-configuration) guix repl: warning: 'sddm-configuration' is deprecated, use '(@ (gnu services xorg) sddm-configuration)' instead $1 = #< sddm: [... omitted for brevity ...] scheme@(guix-user)> (sddm-configuration? $1) guix repl: warning: 'sddm-configuration?' is deprecated, use '(@ (gnu services xorg) sddm-configuration?)' instead $2 = #t scheme@(guix-user)> sddm-service-type guix repl: warning: 'sddm-service-type' is deprecated, use '(@ (gnu services xorg) sddm-service-type)' instead $3 = # scheme@(guix-user)> (sddm-service) guix repl: warning: 'sddm-service' is deprecated, use '(@ (gnu services xorg) sddm-service)' instead guix repl: warning: 'sddm-service' is deprecated, use 'sddm-service-type' instead $4 = #< type: # value: #< sddm: [... omitted for brevity ...] scheme@(guix-user)> --8<---cut here---end--->8--- What do you think? -- Chris PGP: https://savannah.gnu.org/people/viewgpg.php?user_id=106836 From 09091cc8495e0b4c302a58961e79ac8455ecd208 Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Mon, 3 Jan 2022 14:59:35 -0800 Subject: [PATCH] services: Consistently use SDDM rather than GDM on non-x86_64. This is a follow-up to 49599fab564f203b8e92d32e9b28c99e99849bfb. Notably, it also deprecates (gnu services sddm) and moves what was there into (gnu services xorg). Fixes: <https://issues.guix.gnu.org/52908>. * gnu/services/sddm.scm (sddm-configuration, sddm-configuration?) (sddm-service-type, sddm-service): Move the code for these exported bindings to gnu/services/xorg.scm. Use (guix deprecation) to ensure that existing code can continue to call these original bindings in the (gnu services sddm) module, in which case a deprecation warning will be issued to the caller. (gnu-services-sddm-sentinel): New exported variable. * gnu/services/xorg.scm (sddm-configuration, sddm-configuration?) (sddm-service-type, sddm-service): New exported bindings. The code was moved verbatim from gnu/services/sddm.scm. These bindings were moved here to avoid introducing a circular dependency between the (gnu services sddm) and (gnu services xorg) modules. (set-xorg-configuration)[login-manager-service-type]: When the current system or target system begins with the string "x86_64", use gdm-service type as before; otherwise, use sddm-service-type (i.e., the one from the (gnu services xorg) module). * gnu/system/examples/vm-image.tmpl (services): Add sddm-service-type to the list of service types to remove. * gnu/services/desktop.scm: Remove the #:autoload for (gnu services sddm). It is no longer required, since (gnu services xorg) exports sddm-service-type. --- gnu/services/desktop.scm | 1 - gnu/services/sddm.scm | 320 ++ gnu/services/xorg.scm | 311 - gnu/system/examples/vm-image.tmpl | 4 +- 4 files changed, 332 insertions(+), 304 deletions(-) diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm index c6761ca784..8395b51242 100644 --- a/gnu/services/desktop.scm +++ b/gnu/services/desktop.scm @@ -40,7 +40,6 @@ #:use-module (gnu se
bug#24841: close 24841
Hi, As there has been no more feedback recently, I will now close this bug report. -- Chris signature.asc Description: PGP signature
bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
est" received signal SIGINT, Interrupt.
0x77eccba0 in __futex_abstimed_wait_common64
(futex_word=0x77aaf1c0, expected=, clockid=,
abstime=0x0, private=, cancel=) at
../sysdeps/nptl/futex-internal.c:74
74 ../sysdeps/nptl/futex-internal.c: No such file or directory.
(gdb) backtrace
#0 0x77eccba0 in __futex_abstimed_wait_common64
(futex_word=0x77aaf1c0, expected=, clockid=,
abstime=0x0, private=, cancel=) at
../sysdeps/nptl/futex-internal.c:74
#1 0x77eb9934 in __pthread_clockjoin_ex (threadid=140737348563184,
thread_return=0x7fffe2d0, clockid=, abstime=,
block=) at pthread_join_common.c:102
#2 0x77eb9684 in __pthread_join (threadid=,
thread_return=) at pthread_join.c:24
#3 0x10001784 in main (argc=1, argv=0x7fffe718) at timetest.c:146
(gdb) backtrace -full
#0 0x77eccba0 in __futex_abstimed_wait_common64
(futex_word=0x77aaf1c0, expected=, clockid=,
abstime=0x0, private=, cancel=) at
../sysdeps/nptl/futex-internal.c:74
r4 = 265
r7 = 0
_arg5 = 0
_arg2 =
r5 = 2140545
r8 = 4294967295
_arg6 = 4294967295
_arg3 =
r0 = 221
r3 = -512
r6 = 0
_arg4 =
_arg1 =
sc_cancel_oldtype = 0
sc_ret =
clockbit =
err =
op =
#1 0x77eb9934 in __pthread_clockjoin_ex (threadid=140737348563184,
thread_return=0x7fffe2d0, clockid=, abstime=,
block=) at pthread_join_common.c:102
ret =
_buffer = {__routine = 0x77eb97d0 , __arg =
0x77aaf518, __canceltype = -6000, __prev = 0x0}
tid =
pd = 0x77aaf0f0
self =
result = 0
pd_result =
#2 0x77eb9684 in __pthread_join (threadid=,
thread_return=) at pthread_join.c:24
No locals.
#3 0x10001784 in main (argc=1, argv=0x7fffe718) at timetest.c:146
now = 140737488347536
tb = {time = 140737354082104, millitm = 1, timezone = 0, dstflag = 0}
tv = {tv_sec = 140737354081200, tv_usec = 1}
ts = {tv_sec = 140737354092312, tv_nsec = 0}
timerid1 = 0x0
timerid2 = 0x77f313ca
sev = {sigev_value = {sival_int = -134273224, sival_ptr =
0x77ff2738}, sigev_signo = -1358151624, sigev_notify = 0, _sigev_un = {_pad
= {-7632, 32767, 1140867716, 32767, -134571396, 32767, -134251008, 32767,
-7888, 32767,
-135299328, 32767}, _tid = -7632, _sigev_thread = {_function =
0x7fffe230, _attribute = 0x7fff44004284}}}
its = {it_interval = {tv_sec = 140737488347536, tv_nsec =
140737353288760}, it_value = {tv_sec = 140737488347512, tv_nsec =
7737577984389116719}}
mask = {__val = {4294967297, 140737488347472, 1, 0, 1, 140737354081200,
140737488347648, 0, 384, 140737353252608, 140737350926336, 140737350298984,
140737354086848, 0, 4294967295, 7883960601630828079}}
sa = {__sigaction_handler = {sa_handler = 0x31325f6d68735f65,
sa_sigaction = 0x31325f6d68735f65}, sa_mask = {__val = {215624265780, 9, 0,
140737354076688, 0, 0, 0, 0, 0, 0, 1392, 140737353287368, 140737353293872,
140737353482696, 140737353288760, 140737353481312}}, sa_flags =
-134274128, sa_restorer = 0x7fffe2b0}
buf = {st_dev = 140733797368452, st_ino = 140737353809984, st_nlink =
140737354104320, st_mode = 4294959792, st_uid = 32767, st_gid = 4294959992,
__pad2 = 32767, st_rdev = 268633376, st_size = 0, st_blksize = 0,
st_blocks = 140737354076688, st_atim = {tv_sec = 140737488347824,
tv_nsec = 140737488348952}, st_mtim = {tv_sec = 1, tv_nsec = 8}, st_ctim =
{tv_sec = 0, tv_nsec = 140737352442432}, __glibc_reserved4 = 140737488347904,
__glibc_reserved5 = 8, __glibc_reserved6 = 268442956}
thread = 140737348563184
ret = 0x7fffe300
timer_getoverrun_timerid1 = -7816
timer_getoverrun_timerid2 = 32767
(gdb)
--8<---cut here---end--->8---
I'll forward this information to upstream and ask if they need more.
I'll also let them know which version of the libraries (e.g., glibc) are
being used, since they said it might help to know.
--
Chris
signature.asc
Description: PGP signature
bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
Hi Kaelyn, Thank you for the reply. Kaelyn writes: > 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 Yes, I'm using Guix on a foreign distro. It isn't clear to me what is trying to access the /lib directories. That's what I'm trying to figure out. In a --pure environment using only Guix-built tools, one would expect that I would not have to set LD_LIBRARY_PATH. However, if I can't figure it out, that's another trick I can try. -- Chris signature.asc Description: PGP signature
bug#49516: [core-updates] glibc-2.31 patches fail to apply
Ludovic Courtès writes: > Hi! > > Chris Marusich skribis: > >> As an aside, when do we remove old versions of glibc? > > Good question. I’d say it’s enough to keep 3 versions in total. > Currently the main (only?) use case for these is when computing locale > data via the ‘locale-libcs’ field of operating system definitions. > > Thoughts? 3 seems fine to me. I suppose if they are particularly important for some reason, an old version could be moved to the Guix-Past channel, but I guess in most cases we would just remove them and move forward. >> From ef169adea6f9ca971e22845b839511b015cbc76c Mon Sep 17 00:00:00 2001 >> From: Chris Marusich >> Date: Sat, 10 Jul 2021 16:49:49 -0700 >> Subject: [PATCH] gnu: glibc-2.31: Restore patches. >> >> Commit 87961fc965b96ac0c7a5909ac2faab2d023b5339 inadvertently modified the >> patch set for glibc-2.31. This change restores the original patch set. >> >> Fixes: <https://bugs.gnu.org/49516>. >> >> * gnu/packages/base.scm (glibc-2.31) [source]: Use the same patches as glibc, >> but replace glibc-hurd-clock_gettime_monotonic.patch with >> glibc-2.31-hurd-clock_gettime_monotonic.patch, and add >> glibc-hurd-signal-sa-siginfo.patch. >> * gnu/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch: Add it. >> * gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch: Add it. >> * gnu/local.mk (dist_patch_DATA): Adjust accordingly. > > LGTM, thanks! > > Ludo’. Thank you for taking a look! I've committed this in 93a5e89008af440655527d03d62d4726683a89ac. I'll close this report now. -- Chris signature.asc Description: PGP signature
bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
way. I'm operating in a --pure environment. All the tools are provided by Guix. I'm surprised that /bin/sh and /lib are even mentioned above. If anyone can provide any advice, I'd be very grateful. I'm not sure how to proceed. -- Chris signature.asc Description: PGP signature
bug#49337: Guix pull fails on my Talos II
Hi Tobias, Were you able to "guix pull" successfully? -- Chris signature.asc Description: PGP signature
bug#49516: [core-updates] glibc-2.31 patches fail to apply
Chris Marusich writes: > On core-updates, the glibc-2.31 patch no longer apply cleanly. Looks like the other old glibc versions explicitly declare their patches, like this: --8<---cut here---start->8--- (define-public glibc-2.30 (package (inherit glibc) (version "2.30") (source (origin (inherit (package-source glibc)) (uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz")) (sha256 (base32 "1bxqpg91d02qnaz837a5kamm0f43pr1il4r9pknygywsar713i72")) (patches (search-patches "glibc-ldd-x86_64.patch" "glibc-CVE-2019-19126.patch" "glibc-hidden-visibility-ldconfig.patch" "glibc-versioned-locpath.patch" "glibc-allow-kernel-2.6.32.patch" "glibc-reinstate-prlimit64-fallback.patch" "glibc-2.29-supported-locales.patch")) --8<---cut here---end--->8--- I've updated my patch to do the same thing; see attached. As an aside, when do we remove old versions of glibc? -- Chris From ef169adea6f9ca971e22845b839511b015cbc76c Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Sat, 10 Jul 2021 16:49:49 -0700 Subject: [PATCH] gnu: glibc-2.31: Restore patches. Commit 87961fc965b96ac0c7a5909ac2faab2d023b5339 inadvertently modified the patch set for glibc-2.31. This change restores the original patch set. Fixes: <https://bugs.gnu.org/49516>. * gnu/packages/base.scm (glibc-2.31) [source]: Use the same patches as glibc, but replace glibc-hurd-clock_gettime_monotonic.patch with glibc-2.31-hurd-clock_gettime_monotonic.patch, and add glibc-hurd-signal-sa-siginfo.patch. * gnu/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch: Add it. * gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch: Add it. * gnu/local.mk (dist_patch_DATA): Adjust accordingly. --- gnu/local.mk | 2 + gnu/packages/base.scm | 16 +- ...bc-2.31-hurd-clock_gettime_monotonic.patch | 84 +++ .../glibc-hurd-signal-sa-siginfo.patch| 637 ++ 4 files changed, 738 insertions(+), 1 deletion(-) create mode 100644 gnu/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch create mode 100644 gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch diff --git a/gnu/local.mk b/gnu/local.mk index 901fc7c4ba..dfb862ed72 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -1114,10 +1114,12 @@ dist_patch_DATA = \ %D%/packages/patches/glibc-dl-cache.patch \ %D%/packages/patches/glibc-hidden-visibility-ldconfig.patch \ %D%/packages/patches/glibc-hurd-clock_gettime_monotonic.patch \ + %D%/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch \ %D%/packages/patches/glibc-hurd-clock_t_centiseconds.patch \ %D%/packages/patches/glibc-hurd-gettyent.patch \ %D%/packages/patches/glibc-hurd-mach-print.patch \ %D%/packages/patches/glibc-hurd-magic-pid.patch \ + %D%/packages/patches/glibc-hurd-signal-sa-siginfo.patch \ %D%/packages/patches/glibc-ldd-powerpc.patch \ %D%/packages/patches/glibc-ldd-x86_64.patch \ %D%/packages/patches/glibc-locales.patch \ diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm index 9c1c946e4a..bdccf2702d 100644 --- a/gnu/packages/base.scm +++ b/gnu/packages/base.scm @@ -938,7 +938,21 @@ with the Linux kernel.") (uri (string-append "mirror://gnu/glibc/glibc-" version ".tar.xz")) (sha256 (base32 -"05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")) +"05zxkyz9bv3j9h0xyid1rhvh3klhsmrpkf3bcs6frvlgyr2gwilj")) + (patches (search-patches +"glibc-ldd-powerpc.patch" +"glibc-ldd-x86_64.patch" +"glibc-dl-cache.patch" +"glibc-hidden-visibility-ldconfig.patch" +"glibc-versioned-locpath.patch" +"glibc-allow-kernel-2.6.32.patch" +"glibc-reinstate-prlimit64-fallback.patch" +"glibc-supported-locales.patch" +"glibc-hurd-clock_t_centiseconds.patch" +"glibc-2.31-hurd-clock_gettime_monotonic.patch" +"glibc-hurd-signal-sa-siginfo.patch" +"glibc-hurd-mach-print.patch" +"glibc-hurd-gettyent.patch&qu
bug#49516: [core-updates] glibc-2.31 patches fail to apply
Hi,
On core-updates, the glibc-2.31 patch no longer apply cleanly. This
causes glibc-2.31 to fail to build. This causes downstream problems;
for example, building a Guix System from bare-bones.tmpl fails because
%default-locale-libcs still contains glibc-2.31.
Example:
--8<---cut here---start->8---
source is at 'glibc-2.31'
applying
'/gnu/store/5icxvnlbac76mm49g6sq7vzznjxmn2s6-glibc-ldd-powerpc.patch'...
applying '/gnu/store/v1h2i4i5xmrs9d4c44w5wshv5zyszb8k-glibc-ldd-x86_64.patch'...
applying '/gnu/store/bpds9cz27ghqf64y8xz4vs35p7275d6n-glibc-dl-cache.patch'...
applying
'/gnu/store/lgrlsr3qnxxvic3y472qwybv5wbyabm6-glibc-hidden-visibility-ldconfig.patch'...
applying
'/gnu/store/mvq0q2f211bxb4syfxvng9kgdxzkr5f3-glibc-versioned-locpath.patch'...
applying
'/gnu/store/sz5nmndsway8bq7283ihdgvmm3xb14l8-glibc-allow-kernel-2.6.32.patch'...
applying
'/gnu/store/vh29xqy3daavjpi0ikpmqzfczzpbscix-glibc-reinstate-prlimit64-fallback.patch'...
applying
'/gnu/store/rnqkir22908x6z3i1mk4phyvskz15qc4-glibc-supported-locales.patch'...
applying
'/gnu/store/svva3cym2n04d2x3bpi4rs6qpnw0m162-glibc-hurd-clock_t_centiseconds.patch'...
applying
'/gnu/store/45ra3k89b3kisarlgvmijy507k6m12ll-glibc-hurd-clock_gettime_monotonic.patch'...
Backtrace:
5 (primitive-load "/gnu/store/bablv90wm5xkd0vinal0gsifm0l…")
In ice-9/eval.scm:
619:8 4 (_ #(#(# "gli…") #))
In ice-9/boot-9.scm:
142:2 3 (dynamic-wind # …)
In ice-9/eval.scm:
619:8 2 (_ #(#(#)))
In srfi/srfi-1.scm:
634:9 1 (for-each # _)
In guix/build/utils.scm:
721:6 0 (invoke "/gnu/store/i5md0v46jp7ahap0vbj4hwyh6lxsny3g-p…" …)
guix/build/utils.scm:721:6: In procedure invoke:
ERROR:
1. :
program:
"/gnu/store/i5md0v46jp7ahap0vbj4hwyh6lxsny3g-patch-2.7.6/bin/patch"
arguments: ("--force" "--no-backup-if-mismatch" "-p1" "--input"
"/gnu/store/45ra3k89b3kisarlgvmijy507k6m12ll-glibc-hurd-clock_gettime_monotonic.patch")
exit-status: 1
term-signal: #f
stop-signal: #f
builder for `/gnu/store/jlpanpgns01sv3jr63c13fn133pj7ik5-glibc-2.31.tar.xz.drv'
failed with exit code 1
--8<---cut here---end--->8---
Judging by the git log for gnu/system/locale.scm, it seems that we
sometimes keep old versions of glibc in %default-locale-libs, in order
to make it easier for people to upgrade across glibc version changes.
Therefore, we probably can't just drop glibc-2.31.
The commit which introduced the failure is
87961fc965b96ac0c7a5909ac2faab2d023b5339. The problem does not occur on
the prior commit. For glibc-2.31, commit
87961fc965b96ac0c7a5909ac2faab2d023b5339 effectively removed the
glibc-hurd-signal-sa-siginfo.patch and modified
libc-hurd-clock_gettime_monotonic.patch. We should probably retain
2.31-specific versions of these patches so that users can continue to
build glibc-2.31 until we decide to remove it entirely.
I have attached a patch which accomplishes this.
--
Chris
From b1c2c75737a3a68c78d80ba31e3d70274d0af9fe Mon Sep 17 00:00:00 2001
From: Chris Marusich
Date: Sat, 10 Jul 2021 16:49:49 -0700
Subject: [PATCH] gnu: glibc-2.31: Restore patches.
Commit 87961fc965b96ac0c7a5909ac2faab2d023b5339 inadvertently modified the
patch set for glibc-2.31. This change restores the original patch set.
* gnu/packages/base.scm (glibc-2.31) [source]: Use the same patches as glibc,
but replace glibc-hurd-clock_gettime_monotonic.patch with
glibc-2.31-hurd-clock_gettime_monotonic.patch, and add
glibc-hurd-signal-sa-siginfo.patch.
* gnu/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch: Add it.
* gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch: Add it.
* gnu/local.mk (dist_patch_DATA): Adjust accordingly.
---
gnu/local.mk | 2 +
gnu/packages/base.scm | 11 +-
...bc-2.31-hurd-clock_gettime_monotonic.patch | 84 +++
.../glibc-hurd-signal-sa-siginfo.patch| 637 ++
4 files changed, 733 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch
create mode 100644 gnu/packages/patches/glibc-hurd-signal-sa-siginfo.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 901fc7c4ba..dfb862ed72 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1114,10 +1114,12 @@ dist_patch_DATA = \
%D%/packages/patches/glibc-dl-cache.patch \
%D%/packages/patches/glibc-hidden-visibility-ldconfig.patch \
%D%/packages/patches/glibc-hurd-clock_gettime_monotonic.patch \
+ %D%/packages/patches/glibc-2.31-hurd-clock_gettime_monotonic.patch \
%D%/packages/patches/glibc-hurd-clock_t_centiseconds.patch \
%D%/packages/patches/glibc-hurd-gettyent.patch \
%D%/packages/patches/glibc-hurd-mach-print.patch \
%D%/packages/patches/glibc-hurd-magic-pid.patch \
+ %D%/packages/patches/glibc-hurd-signal-sa-siginf
bug#49218: texlive-latex-base fails to build: "missing engine: luajithbtex"
Hi, I've committed the patch as 68b0e0d511c2873603636e9f783ff59aac4b7612 on core-updates. I'm closing this bug report. Chris Marusich writes: > - Will LuaJIT ever support the powerpc64le architecture? Until it does, > I guess we can't use LuaJIT on powerpc64le at all, not just for > TeX-related stuff. See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49220 In short, it does not seem like upstream support for powerpc64le is forthcoming in the near future. But maybe that will change with time. > - Is it correct to add "mfluajit" to the disabled-formats list, like I > do in my patch? It sounds like "mfluajit" is a related to "metafont", > but I don't yet really understand what that means. Is it an engine > like luajit? Is it correct to include mfluajit in the list of formats > to disable in fmtutil.cnf when running fmtutil-sys? I am totally > unfamiliar with these tools, so I have no idea. Perhaps it makes no > sense to include mfluajit here, even if maybe it is benign to do so. > If any TeX wizards out there can clarify this for me, I'd be happy to > adjust the patch as needed. FYI, I found this information about formats and engines: https://www.tug.org/levels.html According to that document, "engines" are "executable binaries which implement different TeX variants", and "formats" are "the TeX-based languages in which one actually writes documents". The config file contains lines like this: # from lollipop: lollipop tex - lollipop.ini # # from luatex: luatex luatex language.def,language.dat.lua luatex.ini dviluatex luatex language.def,language.dat.lua dviluatex.ini luajittex luajittex language.def,language.dat.lua luatex.ini # # from metafont: mf mf-nowin - -translate-file=cp227.tcx mf.ini It looks to me like it's fine to include "mfluajit" in the disabled-formats list. Clearly, some metafont "formats" and "engines" are included in this config file already. That said, adding "mfluajit" to the list does nothing right now, since the config file doesn't actually contain any lines beginning with the word "mfluajit", anyway. And in any case, if "mfluajit" ever does get added to the config file somehow, then surely we would want to disable it for powerpc64le-linux, since LuaJIT is not currently supported on that platform. Therefore, I think it's correct to include "mfluajit" in the disabled-formats list. -- Chris signature.asc Description: PGP signature
bug#49220: luajit doesn't support powerpc64le
Hi, Efraim Flashner writes: > On Thu, Jun 24, 2021 at 11:15:01PM -0700, Chris Marusich wrote: >> Hi LuaJIT community, >> >> Is anyone in the LuaJIT community actively working on adding support for >> the powerpc64le architecture? Specifically, I am wondering about the >> powerpc64le-linux-gnu triplet, running on POWER9-based systems like the >> Talos II and Blackbird sold by Raptor Computing Systems. >> >> I ask because LuaJIT has been packaged for Guix, but it currently fails >> to build on this platform, as explained in the following Guix bug >> report: >> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49220 >> >> Based on the error output, it seems that this platform just isn't >> supported yet: >> > > I have successfully built luajit on our ppc64le porter box using the > patch Debian uses to add powerpc64 support. I have tested it on my > 32-bit powerpc machine and adding the patch breaks luajit for it, but I > think we can work something out. > > ¹ > https://sources.debian.org/src/luajit/2.1.0%7Ebeta3+dfsg-6/debian/patches/0004-Add-ppc64-support-based-on-koriakin-GitHub-patchset.patch/ Thank you for sharing that. I see that it came from this GitHub pull request: "Enable !LJ_GC64 interpreter on PPC64." https://github.com/LuaJIT/LuaJIT/pull/140 I wonder if the LuaJIT maintainers are aware of that pull request? It looks like the pull request has been open for about 5 years, and it hasn't been merged. Unless the situation changes, this probably means that if we choose to use this patch in Guix, we (and the Debian folks, I guess) will be responsible for maintaining it and dealing with any bugs. Personally, I'm not interested in doing that right now, mainly because LuaJIT doesn't seem like a necessary dependency. The only reason this caught my attention is because Guix's texlive-latex-base package failed to build on powerpc64le-linux. It failed to build because the luajithbtex engine is missing on powerpc64le-linux. It's missing because LuaJIT doesn't support the platform. Issues like that can be worked around by just using the non-JIT version of Lua (the "luahbtex" engine in this case). That's good enough for me. Of course, if someone else wants to step up and maintain a port for powerpc64le platforms (ideally upstream in collaboration with the current LuaJIT maintainer(s)), that would be great. But it takes time and effort, and I'm happy enough to just use normal Lua for now. -- Chris signature.asc Description: PGP signature
bug#24841: Cross-building bootstrap binaries fail in current master
zimoun writes: > What is the status of this bug#24841 report [1]? > > 1: <http://issues.guix.gnu.org/issue/24841> I agree we can close this old bug report. As you mentioned, it is now possible to build bootstrap binaries for various architectures. If someone needs to build bootstrap binaries for a specific architecture, and they are unable to do so, then they should open a new bug report for that problem specifically. Currently, I have no need to do this, since I am not bootstrapping any new architectures at the moment, or updating any bootstrap binaries. If nobody else comments, I'll close this bug report in a week or two. -- Chris signature.asc Description: PGP signature
bug#49360: Updating cataclysm-dda to 0.F
Nicolas Goaziou writes: > Hello, > > Chris Lemmer-Webber writes: > >>> There are two options. >>> >>> 1) We could mess with the build phase order, do a make install, then a >>>fresh make clean, then make again with the tiles support on: >>> >>> https://github.com/CleverRaven/Cataclysm-DDA/issues/42598#issuecomment-667702746 >>> >>> 2) But that seems strange so we could make a separate >>>cataclysm-dda-tiles output. We already do a similar thing for crawl >>>and crawl-tiles, so why not? >>> >>> What do people think? I'm leaning towards (2). >>> - Chris >> >> I've pushed a new version in b65af6ed91. I took the first of these two >> routes, though I think in the long run the latter approach probably >> makes more sense. > > FWIW, I also think the second path makes more sense. > > Regards, Yes, it would be good to go that route if someone is willing to take the time to split it up.
bug#49360: Updating cataclysm-dda to 0.F
Chris Lemmer-Webber writes:
> Hello!
>
> Here's a quick paste at the start of what's necessary to make this
> change:
>
> #+BEGIN_SRC diff
> diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
> index 831f6079f2..c2a8e4bb43 100644
> --- a/gnu/packages/games.scm
> +++ b/gnu/packages/games.scm
> @@ -104,6 +104,7 @@
>#:use-module (gnu packages check)
>#:use-module (gnu packages cmake)
>#:use-module (gnu packages compression)
> + #:use-module (gnu packages code)
>#:use-module (gnu packages cpp)
>#:use-module (gnu packages curl)
>#:use-module (gnu packages crypto)
> @@ -835,7 +836,7 @@ high a score as possible.")
> (define-public cataclysm-dda
>(package
> (name "cataclysm-dda")
> -(version "0.E-3")
> +(version "0.F")
> (source
> (origin
> (method git-fetch)
> @@ -843,7 +844,7 @@ high a score as possible.")
> (url "https://github.com/CleverRaven/Cataclysm-DDA;)
> (commit version)))
> (sha256
> -(base32 "108cs6vp99qmqqfnmczad0xjgcl82bypm5xszwnlfcswdsrfs4da"))
> +(base32 "1jid8lcl04y768b3psj1ifhx96lmd6fn1j2wzxhl4ic7ra66p2z3"))
> (file-name (git-file-name name version
> (build-system gnu-build-system)
> (arguments
> @@ -874,7 +875,8 @@ high a score as possible.")
> "tiles"));for tile graphics and sound support
> (native-inputs
> `(("gettext" ,gettext-minimal)
> - ("pkg-config" ,pkg-config)))
> + ("pkg-config" ,pkg-config)
> + ("astyle" ,astyle)))
> (inputs
> `(("freetype" ,freetype)
> ("libogg" ,libogg)
> #+END_SRC
>
> However it turns out this is not enough because building the
> curses-and-then-tiles versions is no longer supported. The following
> error will occur:
>
> cc1plus: error: pch/main-pch.hpp.gch: not used because `_XOPEN_SOURCE' not
> defined [-Werror=invalid-pch]
> cc1plus: error: unrecognized command line option
> ‘-Wno-unknown-warning-option’ [-Werror]
> cc1plus: all warnings being treated as errors
> make: *** [Makefile:962: obj/tiles/achievement.o] Error 1
> command "make" "TILES=1" "SOUND=1"
> "PREFIX=/gnu/store/s3r1hc84ph27jc0q648dx6yfpm9mgydh-cataclysm-dda-0.F-tiles"
> "USE_HOME_DIR=1" "DYNAMIC_LINKING=1" "RELEASE=1" "LOCALIZE=1" "LANGUAGES=all"
> failed with status 2
>
> There are two options.
>
> 1) We could mess with the build phase order, do a make install, then a
>fresh make clean, then make again with the tiles support on:
>
> https://github.com/CleverRaven/Cataclysm-DDA/issues/42598#issuecomment-667702746
>
> 2) But that seems strange so we could make a separate
>cataclysm-dda-tiles output. We already do a similar thing for crawl
>and crawl-tiles, so why not?
>
> What do people think? I'm leaning towards (2).
> - Chris
I've pushed a new version in b65af6ed91. I took the first of these two
routes, though I think in the long run the latter approach probably
makes more sense.
bug#49360: Updating cataclysm-dda to 0.F
Hello!
Here's a quick paste at the start of what's necessary to make this
change:
#+BEGIN_SRC diff
diff --git a/gnu/packages/games.scm b/gnu/packages/games.scm
index 831f6079f2..c2a8e4bb43 100644
--- a/gnu/packages/games.scm
+++ b/gnu/packages/games.scm
@@ -104,6 +104,7 @@
#:use-module (gnu packages check)
#:use-module (gnu packages cmake)
#:use-module (gnu packages compression)
+ #:use-module (gnu packages code)
#:use-module (gnu packages cpp)
#:use-module (gnu packages curl)
#:use-module (gnu packages crypto)
@@ -835,7 +836,7 @@ high a score as possible.")
(define-public cataclysm-dda
(package
(name "cataclysm-dda")
-(version "0.E-3")
+(version "0.F")
(source
(origin
(method git-fetch)
@@ -843,7 +844,7 @@ high a score as possible.")
(url "https://github.com/CleverRaven/Cataclysm-DDA;)
(commit version)))
(sha256
-(base32 "108cs6vp99qmqqfnmczad0xjgcl82bypm5xszwnlfcswdsrfs4da"))
+(base32 "1jid8lcl04y768b3psj1ifhx96lmd6fn1j2wzxhl4ic7ra66p2z3"))
(file-name (git-file-name name version
(build-system gnu-build-system)
(arguments
@@ -874,7 +875,8 @@ high a score as possible.")
"tiles"));for tile graphics and sound support
(native-inputs
`(("gettext" ,gettext-minimal)
- ("pkg-config" ,pkg-config)))
+ ("pkg-config" ,pkg-config)
+ ("astyle" ,astyle)))
(inputs
`(("freetype" ,freetype)
("libogg" ,libogg)
#+END_SRC
However it turns out this is not enough because building the
curses-and-then-tiles versions is no longer supported. The following
error will occur:
cc1plus: error: pch/main-pch.hpp.gch: not used because `_XOPEN_SOURCE' not
defined [-Werror=invalid-pch]
cc1plus: error: unrecognized command line option
‘-Wno-unknown-warning-option’ [-Werror]
cc1plus: all warnings being treated as errors
make: *** [Makefile:962: obj/tiles/achievement.o] Error 1
command "make" "TILES=1" "SOUND=1"
"PREFIX=/gnu/store/s3r1hc84ph27jc0q648dx6yfpm9mgydh-cataclysm-dda-0.F-tiles"
"USE_HOME_DIR=1" "DYNAMIC_LINKING=1" "RELEASE=1" "LOCALIZE=1" "LANGUAGES=all"
failed with status 2
There are two options.
1) We could mess with the build phase order, do a make install, then a
fresh make clean, then make again with the tiles support on:
https://github.com/CleverRaven/Cataclysm-DDA/issues/42598#issuecomment-667702746
2) But that seems strange so we could make a separate
cataclysm-dda-tiles output. We already do a similar thing for crawl
and crawl-tiles, so why not?
What do people think? I'm leaning towards (2).
- Chris
bug#49337: Guix pull fails on my Talos II
Hi, FYI, I was able to successfully "guix pull" from 83f8b6d (Apr 09) to c33e200 (Jul 02) just now on my own POWER9 machine (a Blackbird). -- Chris signature.asc Description: PGP signature
bug#49337: Guix pull fails on my Talos II
Hi Tobias, Tobias Platen writes: > /gnu/store/vc2j3816jx9z4vgrw6zmk357xrka3zy0-texlive-latex-amsmath-51265.drv > wird erstellt … > \ „build“-PhaseBacktrace: > 13 (primitive-load > "/gnu/store/y5sniqlw2x5aaixyk4bw162v2a7bwdpl-compute-guix-derivation") > In ice-9/eval.scm: > 155:9 12 (_ _) > 159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) > ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) > In ice-9/boot-9.scm: > 152:2 10 (with-fluid* _ _ _) > 152:2 9 (with-fluid* _ _ _) > In ./guix/store.scm: > 2090:24 8 (run-with-store # _ > #:guile-for-build _ #:system _ #:target _) >1927:8 7 (_ _) > In ./guix/gexp.scm: >275:18 6 (_ _) >1156:2 5 (_ _) >1022:2 4 (_ _) > 868:4 3 (_ _) > In ./guix/store.scm: > 1975:12 2 (_ #) >1377:5 1 (map/accumulate-builds # _ > _) > 1388:15 0 (_ # _ _) > > ./guix/store.scm:1388:15: ERROR: > 1. : > message: "build of > `/gnu/store/bbvxcaa31h006wg2kp1ysly55hkm56hn-po4a-0.63.drv' failed" > status: 100 > guix pull: error: You found a bug: the program > '/gnu/store/y5sniqlw2x5aaixyk4bw162v2a7bwdpl-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "6243ad3812f8c689599a19f0e8b9719ba14461f2"; system: "powerpc64le-linux"; > host version: "1.3.0"; pull-version: 1). > Please report it by email to . Thanks for the report! I'll try reproducing it locally, but in the meantime, if you could provide the following information, it would be helpful. What is the output of "guix describe" on your Talos II? When you ran "guix pull", did you just run "guix pull" or did you pass some options in? I.e., were you trying to pull to a specific branch or commit? If you are pulling using a channel file (e.g., ~/.config/guix/channels.scm), could you share it? Does "guix build po4a" successfully build po4a? Does "guix build -d po4a" show the same derivation as above (/gnu/store/bbvxcaa31h006wg2kp1ysly55hkm56hn-po4a-0.63.drv)? -- Chris signature.asc Description: PGP signature
bug#49220: LuaJIT on powerpc64le-linux-gnu (POWER9)?
Hi LuaJIT community, Is anyone in the LuaJIT community actively working on adding support for the powerpc64le architecture? Specifically, I am wondering about the powerpc64le-linux-gnu triplet, running on POWER9-based systems like the Talos II and Blackbird sold by Raptor Computing Systems. I ask because LuaJIT has been packaged for Guix, but it currently fails to build on this platform, as explained in the following Guix bug report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49220 Based on the error output, it seems that this platform just isn't supported yet: --8<---cut here---start->8--- Building LuaJIT 2.1.0-beta3 make -C src make[1]: Entering directory '/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src' lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ make[1]: *** No rule to make target 'vm_ppc64.dasc', needed by 'host/buildvm_arch.h'. Stop. make[1]: Leaving directory '/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src' make: *** [Makefile:113: default] Error 2 --8<---cut here---end--->8--- I have CC'd the Guix bug report for this issue. When replying, if you could please keep 49...@debbugs.gnu.org in the CC list so that your replies will be recorded in the bug report, that would be helpful. That will make it easier for Guix contributors to follow the conversation. Best regards, -- Chris Marusich signature.asc Description: PGP signature
bug#49220: luajit doesn't support powerpc64le
Hi, When attempting to build luajit on powerpc64le-linux, you will get errors like this: --8<---cut here---start->8--- Building LuaJIT 2.1.0-beta3 make -C src make[1]: Entering directory '/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src' lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ lj_arch.h:428:2: error: #error "No support for PowerPC 64 bit mode (yet)" 428 | #error "No support for PowerPC 64 bit mode (yet)" | ^ make[1]: *** No rule to make target 'vm_ppc64.dasc', needed by 'host/buildvm_arch.h'. Stop. make[1]: Leaving directory '/tmp/guix-build-luajit-2.1.0-beta3.drv-0/LuaJIT-2.1.0-beta3/src' make: *** [Makefile:113: default] Error 2 --8<---cut here---end--->8--- This has downstream impacts, such as being unable to build LuaJITTeX. If we can't use LuaJIT on powerpc64le-linux, we should probably remove it from the luajit package's list of supported systems. I checked their email list and website, but I can't find information about whether the LuaJIT project is actively working on support for powerpc64le architecture specifically. I'll ask their email list (lua...@freelists.org) in a moment, and we'll see what they say. -- Chris signature.asc Description: PGP signature
bug#49218: texlive-latex-base fails to build: "missing engine: luajithbtex"
Hi,
On powerpc64le-linux, using Guix commit
45dd2b4505095d24e253bd62d74474cad135cf3b (the current tip of
core-updates), texlive-latex-base fails to build because the engine
"luajithbtex" is missing:
--8<---cut here---start->8---
Transcript written on pdflatex-dev.log.
fmtutil [INFO]: log file copied to:
/tmp/guix-build-texlive-latex-base-54632.drv-0/source/web2c/pdftex/pdflatex-dev.log
fmtutil [INFO]:
/tmp/guix-build-texlive-latex-base-54632.drv-0/source/web2c/pdftex/pdflatex-dev.fmt
installed.
fmtutil [ERROR]: not building luajithbtex due to missing engine: luajithbtex
fmtutil [INFO]: disabled formats: 40
fmtutil [INFO]: successfully rebuilt formats: 19
fmtutil [INFO]: failed to build: 1 (luajithbtex/luajithbtex)
fmtutil [INFO]: total formats: 60
fmtutil [INFO]: exiting with status 1
error: in phase 'build': uncaught exception:
%exception #< program: "fmtutil-sys" arguments: ("--all"
"--fmtdir=web2c" "--cnffile=web2c/fmtutil.cnf") exit-status: 1 term-signal: #f
stop-signal: #f>
phase `build' failed after 55.3 seconds
command "fmtutil-sys" "--all" "--fmtdir=web2c" "--cnffile=web2c/fmtutil.cnf"
failed with status 1
builder for
`/gnu/store/n3j2vrlm1vb7hy8wf0afy7qv8yd4dcqb-texlive-latex-base-54632.drv'
failed with exit code 1
build of
/gnu/store/n3j2vrlm1vb7hy8wf0afy7qv8yd4dcqb-texlive-latex-base-54632.drv failed
--8<---cut here---end--->8---
Previously, we have disabled luajittex because "LuaJIT is not ported to
powerpc64le* yet":
--8<---cut here---start->8---
commit 1a0f4013d33535ed9b8518cfb3ac502f48132fd8
Author: Leo Le Bouter
Date: Mon Feb 8 04:47:03 2021 +0100
gnu: texlive-latex-base: Fix compilation on powerpc64le*.
* gnu/packages/tex.scm (texlive-latex-base)[arguments]: LuaJIT is not
ported to
powerpc64le* yet. Update replacement 'build phase to add "luajittex" within
the
"disabled-formats" list on powerpc64le*.
Signed-off-by: Chris Marusich
commit e9938dc8f0e081e4407a96502a04ea63f07e5a8c
Author: Leo Le Bouter
Date: Mon Feb 8 03:13:53 2021 +0100
gnu: texlive-bin: Fix compilation on powerpc64le*.
* gnu/packages/tex.scm (texlive-bin)[arguments]: Append
"--disable-luajittex"
and "--disable-mfluajit" to keyword argument "#:configure-flags" on
powerpc64le* because LuaJIT is not ported to powerpc64le* yet. Also set
"#:tests?" to "#f" on powerpc64le*.
Signed-off-by: Chris Marusich
--8<---cut here---end--->8---
The attached patch fixes the issue. However, I'm curious about a few
things, so I would welcome any input others might have:
- Is it a problem to disable LuaJIT-related things? Based on what I've
found on the Internet, I think it's fine to disable LuaJIT. It looks
like luatex and luatexhb are preferred in most cases. It seems that
luajittex and luajithbtex alternatives do essentially the same thing
as their luatex and luahbtex counterparts, but they run Lua using
LuaJIT (just-in-time compilation capability) instead of the regular
Lua. In their "Short report on the state of LuaTEX, 2020", Luigi
Scarso wrote that luajittex and luajithbtex "should also be considered
a research tool in digital typesetting" [1]. So I don't think we lose
much by disabling it, especially if it isn't supported on powerpc64le.
- Will LuaJIT ever support the powerpc64le architecture? Until it does,
I guess we can't use LuaJIT on powerpc64le at all, not just for
TeX-related stuff.
- Is it correct to add "mfluajit" to the disabled-formats list, like I
do in my patch? It sounds like "mfluajit" is a related to "metafont",
but I don't yet really understand what that means. Is it an engine
like luajit? Is it correct to include mfluajit in the list of formats
to disable in fmtutil.cnf when running fmtutil-sys? I am totally
unfamiliar with these tools, so I have no idea. Perhaps it makes no
sense to include mfluajit here, even if maybe it is benign to do so.
If any TeX wizards out there can clarify this for me, I'd be happy to
adjust the patch as needed.
Footnotes:
[1] https://www.tug.org/TUGboat/tb41-3/tb129scarso-luatex.pdf
--
Chris
From afdcba86e90a784e3857a27dccb1110165bd2ecd Mon Sep 17 00:00:00 2001
From: Chris Marusich
Date: Thu, 24 Jun 2021 21:39:39 -0700
Subject: [PATCH] gnu: Disable more LuaJIT components on powerpc64le systems.
* gnu/packages/tex.scm (texlive-bin)[#:configure-flags]: Add
"--disable-luajithbtex" on powerpc64le systems.
(texlive-latex-base)[#:phases][build]: Add "mfluajit" to the disabled-formats
list on powerpc64le systems.
---
gnu/packages/tex.scm | 4
bug#49100: make check fails: %derivation-cache
Ludovic Courtès writes: >> The attached patch fixes the issue for me. However, since I'm not sure >> how %derivation-cache is or was supposed to be used, I would appreciate >> a second opinion. > > You forgot to attach the patch, but I think it’s enough to remove the > ‘hash-clear!’ call from ‘call-with-external-store’. Sorry - but yes, that's all it did. I removed the hash-clear! call. I've gone ahead and committed this as 7f0af119a1e3ea9d0ae53811b619437b3e942702 on core-updates. -- Chris signature.asc Description: PGP signature
bug#47698: [powerpc64le-linux] "check" package fails to build
Committed to core-updates in bcdc13454c4afab37b650d4bbfa95e539060619f. -- Chris signature.asc Description: PGP signature
bug#49100: make check fails: %derivation-cache
Hi,
On core-updates (a6c292a6f123acc86429722619ccb51ca54f844f), "make check"
errors out in tests/builders.scm:
--8<---cut here---start->8---
Backtrace:
1 (primitive-load-path "tests/builders.scm")
In guix/tests.scm:
146:8 0 (call-with-external-store #)
guix/tests.scm:146:8: In procedure call-with-external-store:
error: %derivation-cache: unbound variable
--8<---cut here---end--->8---
The problem appears to have been caused by
7d873f194ca69d6096d28d7a224ab78e83e34fe1 ("build-system: Rewrite using
gexps.").
The attached patch fixes the issue for me. However, since I'm not sure
how %derivation-cache is or was supposed to be used, I would appreciate
a second opinion.
Note that %derivation-cache has been used to refer to two different
things in the past (see: 3182539875a67f5989c73c3c654fe3138bbc275c).
Note also that even after applying this fix, some tests relying on
call-with-external-store still fail when run (see: bug 47018).
--
Chris
signature.asc
Description: PGP signature
bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
Hi, Since I'm not sure how to proceed, I've reported this upstream and asked for help: https://github.com/wolfcw/libfaketime/issues/335 -- Chris signature.asc Description: PGP signature
bug#48941: [powerpc64le-linux] libfaketime CLOCK_MONOTONIC test hangs
Hi, On powerpc64le-linux, using Guix commit 7692295f970a292a3f3db31fc21d05efd97dcb25 on top of Debian unstable, the libfaketime package fails to build because one of its tests hangs. It appears to hang during the CLOCK_MONOTONIC test: --8<---cut here---start->8--- Running the test program with no faked time specified $ LD_PRELOAD=../src/libfaketime.so.1 ./timetest pthread_cond_timedwait: CLOCK_REALTIME test (Intentionally sleeping 1 second...) pthread_cond_timedwait: CLOCK_MONOTONIC test (Intentionally sleeping 1 second..., see docs about CLOCK_MONOTONIC test) --8<---cut here---end--->8--- There is no output after that last line. It just sits there. I left it there for about 24 hours, and it didn't make any progress. I tried with --cores=1, too, but the problem still occurred. Therefore, it probably isn't a multithreading issue. On x86_64-linux Guix, using the aforementioned commit, on top of Fedora 32, the tests pass and the libfaketime builds successfully. Therefore, this is probably a platform-specific issue. The README file for libfaketime says: > CLOCK_MONOTONIC test: Running "make test" performs a series of tests > after successful compilation of the libfaketime library. On some > platforms, the "CLOCK_MONOTONIC test" will apparently hang > forever. If and only if this happens on your platform, add the CFLAG > -DFORCE_MONOTONIC_FIX to src/Makefile and recompile libfaketime. Do > not set FORCE_MONOTONIC_FIX on platforms where the test does not > hang. In fact, we do set this in Guix, via the (apparently undocumented) FAKETIME_COMPILE_CFLAGS environment variable: --8<---cut here---start->8--- (define-public libfaketime (package (name "libfaketime") ... (arguments '(#:phases (modify-phases %standard-phases (replace 'configure (lambda* (#:key outputs #:allow-other-keys) (let ((out (assoc-ref outputs "out"))) (setenv "CC" "gcc") (setenv "PREFIX" out) ;; XXX: Without this flag, the CLOCK_REALTIME test hangs ;; indefinitely. See README.packagers for more information. ;; Try removing this for future versions of libfaketime. (setenv "FAKETIME_COMPILE_CFLAGS" "-DFORCE_MONOTONIC_FIX") ... --8<---cut here---end--->8--- In spite of this, the test hangs on powerpc64le-linux. Out of curiosity, I tried NOT setting FAKETIME_COMPILE_CFLAGS, but the behavior was the same: it still got stuck forever on powerpc64le-linux. -- Chris signature.asc Description: PGP signature
bug#47698: [powerpc64le-linux] "check" package fails to build
Chris Marusich writes: > [...] I've reported this issue upstream: > https://github.com/libcheck/check/issues/333 Branden Archer replied in the above issue. In short, the unreleased upstream commit 4fbe702fa4f35bee8a90512f9f59d1441c4ae82e fixes this issue on PPC platforms. Here's what the commit does: https://github.com/libcheck/check/commit/4fbe702fa4f35bee8a90512f9f59d1441c4ae82e.patch Adjust test suite for 106-bit long double precision On PowerPC architectures (ppc, ppc64el, powerp) 'long double' has a precision of 106-bit, compared to 80-bit precision on amd64. This leads to the test_ck_assert_(float|double|ldouble)_eq_tol succeed rather than fail as expected, cause 0.003-0.002 will be actually slightly bigger than 0.001 and not slightly smaller. Increase the change to the tolerance, so it will be on all architectures smaller than the difference of ~0.001 and the unit tests will fail as expected. This commit was merged to the check repository's master branch after its latest release (0.15.2). It will be included in the next check release, but until then, we will have to apply the fix as a patch to our check package. I've attached a patch that does this. -- Chris From 7692295f970a292a3f3db31fc21d05efd97dcb25 Mon Sep 17 00:00:00 2001 From: Chris Marusich Date: Thu, 3 Jun 2021 23:12:24 -0700 Subject: [PATCH] gnu: check: Fix failing tests on powerpc64le-linux. * gnu/packages/check.scm (check)[source]: Apply unreleased upstream commit 4fbe702 as a patch. --- gnu/packages/check.scm | 22 +- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm index 6641a0de58..069d4e05fc 100644 --- a/gnu/packages/check.scm +++ b/gnu/packages/check.scm @@ -146,7 +146,27 @@ like Jasmine or Mocha.") version "/check-" version ".tar.gz")) (sha256 (base32 -"02m25y9m46pb6n46s51av62kpd936lkfv3b13kfpckgvmh5lxpm8" +"02m25y9m46pb6n46s51av62kpd936lkfv3b13kfpckgvmh5lxpm8")) + (patches + (list +;; This patch fixes some tests that would otherwise fail on +;; powerpc64le-linux. Without this patch, the tests make certain +;; assumptions about floating point number precision that are not true +;; on that platform. +;; +;; TODO: Remove this patch when updating to the next check release, +;; since it will be included there. See: +;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47698 +(origin + (method url-fetch) + (uri + (string-append "https://github.com/libcheck/check/commit/; + "4fbe702fa4f35bee8a90512f9f59d1441c4ae82e.patch")) + (file-name (string-append name +"-fix-test-precision-for-ppc.patch")) + (sha256 + (base32 +"04qg1p9afdd6453k18qskazrvscysdcjz9j6w4i6p5x4xyma19v6"))) (build-system gnu-build-system) (home-page "https://libcheck.github.io/check/;) (synopsis "Unit test framework for C") -- 2.30.2 signature.asc Description: PGP signature
bug#48455: texlive-latex-graphics: non-deterministic build failure
Hi,
On commit 100281dd200d0a59958fb17dc6de75d3913e2b7a, the build for
texlive-latex-graphics sometimes fails and sometimes succeeds. To
reproduce the issue, just try "guix build texlive-latex-graphics" or
"guix build --check texlive-latex-graphics" a few times. I used this
cumbersome one-liner to try it a bunch:
while :; do if ./pre-inst-env guix build --cores=1 --check
texlive-latex-graphics; then echo SUCCESS; else echo FAIL; fi; done 2>&1 | tee
/tmp/out
Then you can summarize the results with another cumbersome one-liner
like this:
cat /tmp/out | grep -e ^FAIL -e ^SUCCESS | sort | uniq -c | awk '{arr[$2] = $1;
arr["TOTAL"] += $1} END {for (i in arr) printf("%5d (%6.2f%%): %s\n", arr[i],
100*arr[i]/arr["TOTAL"], i)}'
This failure happens on powerpc64le-linux and x86_64-linux. It might
happen on other architectures; I didn't test them. In my testing, it
happened about 18% of the time on powerpc64le-linux, and about 1% of the
time on x86_64-linux.
Here is the error from the powerpc64le-linux case. Except for the store
paths, the error is identical to the x86_64-linux case:
--8<---cut here---start->8---
Generating file(s) dvipdf.def dvipsone.def dviwin.def emtex.def pctexps.def
pctex32.def pctexhp.def pctexwin.def truetex.def tcidvi.def dvipsnam.def
Processing file drivers.dtx (dvipdf,color1,psrulesZ) -> dvipdf.def
(tiffrules,dvipsone,color1,dosrules,psrules) ->
dvipsone.def
(dviwin,nops) -> dviwin.def
(emtex,dosrules,nops) -> emtex.def
(pctexps,color3,colorfix) -> pctexps.def
(pctex32,color1) -> pctex32.def
(pctexhp,nops) -> pctexhp.def
(pctexwin,nops) -> pctexwin.def
(truetex,color4,nops) -> truetex.def
(tcidvi,color4,nops) -> tcidvi.def
(dvipsnames) -> dvipsnam.def
Lines processed: 1701
Comments removed: 776
Comments passed: 9
Codelines passed: 757
)
warning (pdf backend): no pages of output.
Transcript written on graphics-drivers.log.
realloc(): invalid next size
command "luatex" "-interaction=nonstopmode" "-output-directory=build" ""
"graphics-drivers.ins" failed with signal 6
builder for
`/gnu/store/r6xcixwj7y2336lg68clqck74prckzbd-texlive-latex-graphics-51265.drv'
failed with exit code 1
build of
/gnu/store/r6xcixwj7y2336lg68clqck74prckzbd-texlive-latex-graphics-51265.drv
failed
View build log at
'/var/log/guix/drvs/r6/xcixwj7y2336lg68clqck74prckzbd-texlive-latex-graphics-51265.drv.bz2'.
guix build: error: build of
`/gnu/store/r6xcixwj7y2336lg68clqck74prckzbd-texlive-latex-graphics-51265.drv'
failed
FAIL
--8<---cut here---end--->8---
Signal 6 is SIGABRT on these systems; I'm not sure what the failure
means or what might be causing it, but I haven't dug into it much yet.
--
Chris
signature.asc
Description: PGP signature
bug#47698: [powerpc64le-linux] "check" package fails to build
Hi, I tried to make a minimal reproduction case, but I couldn't figure it out after a few hours of messing around with it. So, I've reported this issue upstream: https://github.com/libcheck/check/issues/333 Hopefully they can help provide some guidance. -- Chris signature.asc Description: PGP signature
bug#43384: guix pull: backtrace "no route to host"
Jan Wielkiewicz writes: > Hello, > I tried running "guix pull" but it gave me a backtrace. > > guix substitute: error: connect: No route to host > @ substituter-failed > /gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57 256 fetching path > `/gnu/store/c4mzhay8jrg5r43wkn4f9004afvly0ad-po4a-0.57' failed with > exit code 1 @ substituter-started > /gnu/store/s6ha2sssblw06sjpw4zawzx98zwbj5m7-graphviz-2.42.3 substitute > killing process 6694 Backtrace: 11 (primitive-load > "/gnu/store/lardz9zqi5ypgrdrj6dyfgj9p3bca2ab-compute-guix-derivation") > In ice-9/eval.scm: 155:9 10 (_ _) 159:9 9 (_ > #(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) > ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?)) In ./guix/store.scm: 2042:24 8 > (run-with-store # _ > #:guile-for-build _ #:system _ #:target _) 1876:8 7 (_ _) In > ./guix/gexp.scm: 244:18 6 (_ _) >1064:2 5 (_ _) > 924:2 4 (_ _) > 785:4 3 (_ _) > In ./guix/store.scm: > 1924:12 2 (_ #) >1357:5 1 (map/accumulate-builds # 7fe2f10265f0> _ _) 1368:15 0 (_ # 7fe2f10265f0> 7fe2f10265f0> _ _) > > ./guix/store.scm:1368:15: ERROR: > 1. : > message: "some substitutes for the outputs of derivation > `/gnu/store/bxw2dzjmdrq7qmv0w1mpzqrkfqs9p7q2-po4a-0.57.drv' failed > (usually happens due to networking issues); try `--fallback' to build > derivation from source " status: 1 guix pull: error: You found a bug: > the program > '/gnu/store/lardz9zqi5ypgrdrj6dyfgj9p3bca2ab-compute-guix-derivation' > failed to compute the derivation for Guix (version: > "71992a532dd0bb88b39dda285482b332a24dae66"; system: "x86_64-linux"; > host version: "1192ae940434808560b3170107e4ce44855816c3"; pull-version: > 1). Please report it by email to . > > > Jan Wielkiewicz It sounds like perhaps this error was caused by a networking error. Although much time has passed since you opened this bug report, I think in situations like this, you can work around the issue by trying the command with the --fallback option, as the error message suggests. Did you try that? You could try something like this: guix pull --fallback You could also try building just that one problematic derivation with fallback, like this: guix build --fallback /gnu/store/bxw2dzjmdrq7qmv0w1mpzqrkfqs9p7q2-po4a-0.57.drv If successful, you can then retry "guix pull" without the --fallback option, but if a network error was the cause, the same kind of issue might happen again for any other derivation. Therefore, I would recommend trying "guix pull --fallback" if this sort of problem happens frequently for you. FYI, you can also add "--fallback" to various commands, like "guix build" and "guix package". -- Chris signature.asc Description: PGP signature
bug#47698: [powerpc64le-linux] "check" package fails to build
Chris Marusich writes:
> I don't really know what's going on, but I'll try compiling GCC 7.5.0
> with the --with-long-double option, and I'll report whether it fixes
> this issue. If someone has any other idea before then, I'm all ears.
It did not seem to fix the issue. I tried using a patch like the
attached, but the "check" package still seems to fail its test suite in
the same way as before.
Something else must be going on. Maybe the best thing to do is to try
to manually create a minimal reproducible case, and then investigate
using that simpler case.
--
Chris
From ad89f9f59d22cc10fbf7dd6f738ce15a6e79b640 Mon Sep 17 00:00:00 2001
From: Chris Marusich
Date: Sat, 10 Apr 2021 18:16:17 -0700
Subject: [PATCH] gnu: Simplify the use of --with-long-double-128 on
powerpc64le.
In short, this change adds the "--with-long-double-128" configure option in
one place and removes it from two other (now-redundant) places. It does not
cause any rebuilds on systems other than powerpc64le-linux.
* gnu/packages/gcc.scm (gcc-configure-flags-for-triplet): Add a clause for
targets starting with "powerpc64le-" which adds the "--with-long-double-128"
option. This causes any package using this procedure to be built using this
new option on powerpc64le systems. In particular, this affects the gcc
package and the gcc-final package, in addition to all the other versions of
GCC defined in (gnu packages gcc).
* gnu/packages/commencement.scm (gcc-boot0)[#:configure-flags]: Remove the
code that adds the "--with-long-double-128" configure option for powerpc64le,
since it is now redundant. The gcc-boot0 package uses (and adds to) the gcc
package's configure options. This means that the above change in gcc.scm is
sufficient to ensure that the gcc-boot0 package's configure options will
include "--with-long-double-128" on powerpc64le systems.
* gnu/packages/cross-base.scm (cross-gcc-arguments)[#:configure-flags]: Remove
the code that adds the "--with-long-double-128" configure option for
powerpc64le, since it is now redundant. The cross-gcc-arguments procedure
uses (and adds to) the configure options of its xgcc argument (a package).
This means that regardless of which gcc from gcc.scm is used as the xgcc, the
above change in gcc.scm is sufficient to ensure that the cross-gcc-arguments
procedure's configure options will include "--with-long-double-128" on
powerpc64le systems.
---
gnu/packages/commencement.scm | 7 ---
gnu/packages/cross-base.scm | 6 --
gnu/packages/gcc.scm | 3 +++
3 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index d4511ed914..db564db9c4 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -2819,13 +2819,6 @@ exec " gcc "/bin/" program
"--disable-shared"
"--enable-languages=c,c++"
- ;; boot-triplet inserts "guix" in the triplet.
- ,@(if (equal? "powerpc64le-guix-linux-gnu" (boot-triplet))
- ;; On POWER9 (little endian) glibc needs the
- ;; 128-bit long double type.
- '("--with-long-double-128")
- '())
-
;; libstdc++ cannot be built at this stage
;; ("Link tests are not allowed after
;; GCC_NO_EXECUTABLES.").
diff --git a/gnu/packages/cross-base.scm b/gnu/packages/cross-base.scm
index 180594509b..c1e5f2eb79 100644
--- a/gnu/packages/cross-base.scm
+++ b/gnu/packages/cross-base.scm
@@ -153,12 +153,6 @@ base compiler and using LIBC (which may be either a libc package or #f.)"
"--disable-decimal-float" ;would need libc
"--disable-libcilkrts"
- ,@(if (string-prefix? "powerpc64le-" target)
- ;; On POWER9 (little endian) glibc needs
- ;; the 128-bit long double type.
- '("--with-long-double-128")
- '())
-
;; When target is any OS other than 'none' these
;; libraries will fail if there is no libc
;; present. See
diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm
index a412c93c29..22a0f35422 100644
--- a/gnu/packages/gcc.scm
+++ b/gnu/packages/gcc.scm
@@ -79,6 +79,9 @@ where the OS part is overloaded to denote a specific ABI---into GCC
;; Cilk has been removed from GCC 8 anyway.
'("--disable-libcilkrts"))
+((string-prefix? "powerpc64le-" target)
+ '("--with-long-double-128"))
+
(else
;; TODO: Add `arm.*-gnueabi', etc.
'(
--
2.30.2
signature.asc
Description: PGP signature
bug#47375: guix test failure: tests/print
Hi, Julien Lepiller writes: > I don't think this is the right fix. Now you define packages with the > incorrect url-fetch, so the test passes, but package->code would still > not work as intended on actual packages that are properly defined. > > It seems that the issue is package->code uses the internal name > url-fetch* whereas it should be the exported name url-fetch. I think > this is a legitimate bug in package->code and your patch incorrectly > hides it. I think Julien is correct. The url-fetch* procedure from guix/download.scm is here: (define* (url-fetch* url hash-algo hash #:optional name #:key (system (%current-system)) (guile (default-guile)) executable?) "Return a fixed-output derivation that fetches data from URL (a string, or a list of strings denoting alternate URLs), which is expected to have hash HASH of type HASH-ALGO (a symbol). By default, the file name is the base name of URL; optionally, NAME can specify a different file name. When EXECUTABLE? is true, make the downloaded file executable. ... And the url-fetch procedure from guix/build/download.scm is here: (define* (url-fetch url file #:key (timeout 10) (verify-certificate? #t) (mirrors '()) (content-addressed-mirrors '()) (hashes '()) print-build-trace?) "Fetch FILE from URL; URL may be either a single string, or a list of string denoting alternate URLs for FILE. Return #f on failure, and FILE on success. ... They do different things, even though they share the same name. The problem, apparently introduced with commit f7008ca71351e5368a7c1c5bc3fe88fb80b01298, is that before the change, package->code produced code that uses url-fetch, and after the change, it produced code that uses url-fetch*. Reverting the change fixes it. I reverted it and tested it, and it does fix the test. I wonder if we can just revert it for now? What do you think, Ludo? In guix/import/print.scm, package->code generates the code by invoking (origin-method source) to get the origin's "method", and then invoking (procedure-name method) on the method thus obtained. It seems that procedure-name returns the name "url-fetch*" (the name used privately in the (guix download) module), but it should be returning the name "url-fetch" (the public name exported by the (guix download) module). I wonder if there is any way to get the public name of the procedure programmatically, instead of the private one? -- Chris signature.asc Description: PGP signature
bug#47018: core-updates: make check fails when guix-daemon is running
Hi Lars-Dominik and Maxim, Lars-Dominik, thank you for the quick reply! Maxim, do you have time to take a look at this bug? Lars-Dominik mentioned that it's possible that your recent changes to patch-and-repack might be related somehow. Lars-Dominik Braun writes: > I’m pretty sure it worked when I submitted the patch. Looking at the > untruncated backtrace and `git blame guix/packages.scm` I’d guess that the > recent changes to patch-and-repack somehow broke this. But that’s really all I > can say unfortunately. Maybe CC Maxim Cournoyer, who made that change > (cfcead2e515c0dae02127e5a76496463898be6b6)? Thank you for the tip. I haven't checked this yet due to lack of time, but I will eventually. I am posting mainly to note that this problem also affects tests/pack.scm, which appears to be the only other test (besides tests/builders.scm) using the with-external-store form. Both tests fail when a guix-daemon is running. So, I think something about the with-external-form is not playing well with the rest of the code, but I don't fully understand the problem yet. More investigation is required... -- Chris signature.asc Description: PGP signature
