bug#57878: Minimal reproducible setup

[Konrad Hinsen]

Hi David and Liliana,

Thanks David for the added observations. This does indeed look like an
upstream bug, but it also seems to have a context dependence because the
Debian bug reports list some packages are affected that cause no problem
under Guix (e.g. git-timemachine).

As for Liliana's idea of disabling deferred compilation : shouldn't it
be sufficient to have all Emacs Lisp packages in Guix AOT-compiled?
There would be nothing left to compile in deferred mode. A quick scan of
the relevant page on Emacs Wiki
(https://www.emacswiki.org/emacs/GccEmacs) suggests that some package
manager do this.

Cheers,
  Konrad.

bug#58247: Using guix time-machine results in unsupported manifest format error

[david larsson]

Hi,
Im on commit 729ce5f and Im running: guix time-machine --commit=7e8e070 
-- package -i hello


and it outputs:

  guix package: error: unsupported manifest format

I have tried nesting time-machine as well like:

  guix time-machine --commit= -- time-machine 
--commit= -- package -i hello


but it gives the same error.

Any ideas?


Regards,
David

bug#58250: guix import json: GUIX_PACKAGE_PATH -- no code for module

[itd]

Hi,

I'm having an issue with the JSON importer.  The following example
attempts to illustrate the problem:

> $ cd $(mktemp -d) # -> /tmp/tmp.J3f9qsyDIL
> /tmp/tmp.J3f9qsyDIL$ cat myhello.json
> {
>   "name": "myhello",
>   "version": "2.10",
>   "source": "mirror://gnu/hello/hello-2.10.tar.gz",
>   "build-system": "gnu",
>   "license": "GPL-3.0+",
>   "native-inputs": ["gettext", "myotherhello"]
> }
> /tmp/tmp.J3f9qsyDIL$ cat non-gnu.scm
> (define-module (non-gnu)
>   #:use-module (gnu packages base)
>   #:use-module (guix packages))
>
> (define-public myotherhello
>   (package (inherit hello) (name "myotherhello")))

As expected, both `hello` and `myotherhello` are found by `guix search
-L /tmp/tmp.J3f9qsyDIL hello`:

> name: hello
> ...
> location: gnu/packages/base.scm:86:2
> ...
> name: myotherhello
> ...
> location: /tmp/tmp.J3f9qsyDIL/non-gnu.scm:6:2

But importing `myhello` fails:

> /tmp/tmp.J3f9qsyDIL$ export GUIX_PACKAGE_PATH=/tmp/tmp.J3f9qsyDIL/
> /tmp/tmp.J3f9qsyDIL$ guix import json myhello.json
>
> Starting download of /tmp/guix-file.bQ5VSS
> From https://ftpmirror.gnu.org/gnu/hello/hello-2.10.tar.gz...
> following redirection to 
> `https://gnu.askapache.com/hello/hello-2.10.tar.gz'...
>  …10.tar.gz  709KiB671KiB/s 00:01 [##] 100.0%
> Backtrace:
>   14 (primitive-load "/home/itd/.config/guix/current/bin/…")
> In guix/ui.scm:
>2263:7 13 (run-guix . _)
>   2226:10 12 (run-guix-command _ . _)
> In guix/scripts/import.scm:
> 92:11 11 (guix-import . _)
> In ice-9/boot-9.scm:
>   1747:15 10 (with-exception-handler # …)
> In guix/scripts/import/json.scm:
> 91:16  9 (_)
> In ice-9/boot-9.scm:
>   1747:15  8 (with-exception-handler # …)
> In guix/import/json.scm:
> 86:18  7 (_)
> In guix/import/print.scm:
>220:37  6 (package->code _)
>161:17  5 (inputs->code (("gettext" #) #))
> In srfi/srfi-1.scm:
>586:29  4 (map1 (("gettext" #) #))
>586:17  3 (map1 (("myotherhello" #)))
> In guix/import/print.scm:
>164:40  2 (_ _)
> 60:31  1 (variable-name _ (#{}# tmp tmp.J3f9qsyDIL non-gnu))
> In ice-9/boot-9.scm:
>3330:6  0 (resolve-interface (#{}# tmp tmp.J3f9qsyDIL non-gnu) # _ …)
>
> ice-9/boot-9.scm:3330:6: In procedure resolve-interface:
> no code for module (#{}# tmp tmp.J3f9qsyDIL non-gnu)

One can influence the name of the mentioned module via
GUIX_PACKAGE_PATH, e.g.:

> /tmp/tmp.J3f9qsyDIL$ export GUIX_PACKAGE_PATH=.
> /tmp/tmp.J3f9qsyDIL$ guix import json myhello.json
> ...
> ice-9/boot-9.scm:3330:6: In procedure resolve-interface:
> no code for module (#{.}# non-gnu)

But the issue remains.

Suspected cause: the value of GUIX_PACKAGE_PATH is considered part of
the module name but shouldn't.  This results in an unexpected module
name / missing module.  Idea: when constructing the module name from the
file name, this prefix should be removed.

Regards
itd

bug#58250: [PATCH 1/2] modules: Remove load path prefix from module name.

[itd]

* guix/modules.scm (file-name->module-name): Ignore load path prefix
when building module name.
---
It was mentioned on IRC, that (guix modules)'s file-name->module-name
might be function to be used by the JSON importer (and fixed if needed).
This patch attempts to implement the idea from the bug report.

 guix/modules.scm | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/guix/modules.scm b/guix/modules.scm
index 61bc8e1978..269d52ae1e 100644
--- a/guix/modules.scm
+++ b/guix/modules.scm
@@ -100,11 +100,23 @@ (define module-file-dependencies
'()))
 
 (define file-name->module-name
-  (let ((not-slash (char-set-complement (char-set #\/
+  (let ((not-slash (char-set-complement (char-set #\/)))
+   (load-path-prefix-length
+(lambda (file)
+  ;; Length of the longest prefix among all given load paths.
+  (apply max (map
+  (lambda (path) (if (string-prefix? path file)
+   (string-length path)
+   0))
+  %load-path)
 (lambda (file)
   "Return the module name (a list of symbols) corresponding to FILE."
   (map string->symbol
-   (string-tokenize (string-drop-right file 4) not-slash)
+   (string-tokenize
+ (string-drop
+  (string-drop-right file 4)
+  (load-path-prefix-length file))
+   not-slash)
 
 (define (module-name->file-name module)
   "Return the file name for MODULE."

base-commit: ae221813745783ef1b7eee47561a2208cd5ad512
-- 
2.37.3

bug#58250: [PATCH 2/2] import: print: Use file-name->module-name.

[itd]

* guix/import/print.scm (package->code)[package-module-name]: Use
file-name->module-name to build the package module name.
---
This patch updates the JSON importer to use (guix modules)'s
file-name->module-name to determine the module name.

 guix/import/print.scm | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/guix/import/print.scm b/guix/import/print.scm
index 2f54adbd8c..04e6b0a7b1 100644
--- a/guix/import/print.scm
+++ b/guix/import/print.scm
@@ -21,6 +21,7 @@ (define-module (guix import print)
   #:use-module (guix base32)
   #:use-module (guix utils)
   #:use-module (guix licenses)
+  #:use-module (guix modules)
   #:use-module (guix packages)
   #:use-module (guix search-paths)
   #:use-module (guix build-system)
@@ -45,10 +46,7 @@ (define (package->code package)
 when evaluated."
   ;; The module in which the package PKG is defined
   (define (package-module-name pkg)
-(map string->symbol
- (string-split (string-drop-right
-(location-file (package-location pkg)) 4)
-   #\/)))
+(file-name->module-name (location-file (package-location pkg
 
   ;; Return the first candidate variable name that is bound to VAL.
   (define (variable-name val mod)
-- 
2.37.3

bug#58251: Mesa missing patches for Vulkan shared libraries

[maya . tomasek--- via Bug reports for GNU Guix]

As per https://issues.guix.gnu.org/57297

> It was only recently that I was able to fix an issue with the tutorial
> program not finding the .so for the validation layer, by patching the
> layer manifest file with the full store path of the .so. A similar
> phase would need to be added to the mesa package definition for its
> device selection layer to work properly. The error from the mesa layer
> not being found when I run the basic tutorial program is:
>
> !! validation layer: libVkLayer_MESA_device_select.so: cannot open
> shared object file: No such file or directory

And the mentioned patch is:

> + #:phases #~(modify-phases %standard-phases
> +  (add-after 'install 'set-layer-path-in-manifest
> +(lambda* (#:key outputs #:allow-other-keys)
> +  (let* ((out (assoc-ref outputs "out"))
> +  (manifest (string-append out
> +"/share/vulkan/explicit_layer.d"
> +"/VkLayer_khronos_validation.json")))
> +  (substitute* manifest
> + (("\"libVkLayer_khronos_validation.so\"")
> +  (string-append "\"" out
> "/lib/libVkLayer_khronos_validation.so\"")

This errors actually appears in more packages, for example vulkan-info
prints this error.

Patches to all shared vulkan libraries should be added into mesa, so
applications can actually load vulkan.

bug#57490: UPower ignores ‘critical-power-action’

[Ludovic Courtès]

Hi!

Maxime Devos  skribis:

> On 05-09-2022 14:56, Ludovic Courtès wrote:
>> I’d like to test whether UPower invokes the intended critical action,
>> but I’m not sure how to simulate a low battery level.  Thoughts?
>
> I've found a 'Virtual Battery Driver': https://lwn.net/Articles/440097/
>
> The gmane links are dead, but the linux source tree as a
> drivers/power/supply/test_power.c that seems to be about the same
> thing.

I was able to give that a try.  Since the default ‘percentage-action’ in
 is 2, I did this (I configured syslogd to log to
/dev/console):

--8<---cut here---start->8---
root@antelope ~# modprobe test-power ac_online=off usb_online=off 
battery_capacity=2 battery_status=discharging
modprobe test-power ac_online=off usb_online=off battery_capacity=2 
battery_status=discharging
Oct  2 17:00:20 localhost vmunix: [   44.294530] __power_supply_register: 
Expected proper parent device for 'test_ac'
Oct  2 17:00:20 localhost vmunix: [   44.295049] __power_supply_register: 
Expected proper parent device for 'test_battery'
Oct  2 17:00:20 localhost vmunix: [   44.295147] __power_supply_register: 
Expected proper parent device for 'test_usb'
root@antelope ~# Oct  2 17:00:20 localhost shepherd[1]: [upowerd]  
Oct  2 17:00:20 localhost shepherd[1]: [upowerd] (upowerd:186): 
UPower-Linux-WARNING **: 17:00:20.457: no valid voltage value found for device 
/sys/devices/virtual/power_supply/test_battery, assuming 10V 
Oct  2 17:00:20 localhost shepherd[1]: [upowerd]  
Oct  2 17:00:20 localhost shepherd[1]: [upowerd] (upowerd:186): 
UPower-Linux-WARNING **: 17:00:20.473: USB power supply 
/sys/devices/virtual/power_supply/test_usb without usb_type property, please 
report 


root@antelope ~# Oct  2 17:00:41 localhost elogind[185]: System is powering 
down..
Oct  2 17:00:41 localhost elogind[185]: System is powering down..
Oct  2 17:00:41 localhost shepherd[1]: Exiting shepherd... 
Oct  2 17:00:41 localhost shepherd[1]: Service ntpd has been stopped. 
Oct  2 17:00:41 localhost ntpd[184]: ntpd exiting on signal 15 (Terminated)
Oct  2 17:00:41 localhost avahi-daemon[191]: Got SIGTERM, quitting.
Oct  2 17:00:41 localhost avahi-daemon[191]: Leaving mDNS multicast group on 
interface ens3.IPv6 with address fec0::e35c:509d:d937:2087.
Oct  2 17:00:41 localhost avahi-daemon[191]: Leaving mDNS multicast group on 
interface ens3.IPv4 with address 10.0.2.15.
Oct  2 17:00:41 localhost shepherd[1]: Service avahi-daemon has been stopped. 
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2220] caught 
SIGTERM, shutting down normally.
Oct  2 17:00:41 localhost shepherd[1]: Service networking has been stopped. 
Oct  2 17:00:41 localhost shepherd[1]: Service console-font-tty6 has been 
stopped. 
Oct  2 17:00:41 localhost shepherd[1]: Service term-tty6 has been stopped. 
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2318] dhcp4 
(ens3): canceled DHCP transaction
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2318] dhcp4 
(ens3): activation: beginning transaction (timeout in 45 seconds)
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2318] dhcp4 
(ens3): state changed no lease
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2326] 
manager: NetworkManager state is now CONNECTED_SITE
Oct  2 17:00:41 localhost NetworkManager[183]:   [1664722841.2335] 
exiting (success)
Oct  2 17:00:41 localhost avahi-daemon[191]: Leaving mDNS multicast group on 
interface lo.IPv6 with address ::1.
Oct  2 17:00:41 localhost syslogd: exiting on signal 15
[   70.670560] reboot: Power down
--8<---cut here---end--->8---

So 20s after a battery at 2% got plugged in, UPower told elogind to
turn off the VM, which told shepherd to do that—exactly as expected.

It’s kinda disappointing to debug something just to find out it’s
working as advertised.  I think the conclusion is that 2% is too low a
threshold, at least for my laptop, or maybe the charge estimate is
slightly off on my laptop.  I’ll raise that threshold and see if it
works correctly next time I run out of battery…

If someone has better ideas, I’d love to hear them!

Ludo’.

bug#58247: Using guix time-machine results in unsupported manifest format error

[zimoun]

Hi,

On dim., 02 oct. 2022 at 13:17, david larsson  
wrote:

> Im on commit 729ce5f and Im running: guix time-machine --commit=7e8e070 
> -- package -i hello
>
> and it outputs:
>
>guix package: error: unsupported manifest format

It is probably because an issue with version of manifest; e.g, fixed by
67a6828b2bb821274757f686f7c685b664339a96.  See 
.

What does

$ cat ~/.guix-profile/manifest | grep -A 1 manifest

report?


Cheers,
simon

bug#58247: Using guix time-machine results in unsupported manifest format error

[david larsson]

On 2022-10-02 19:02, zimoun wrote:

[..]


It is probably because an issue with version of manifest; e.g, fixed by
67a6828b2bb821274757f686f7c685b664339a96.  See
.


Note that the commit I'm on, is from 2 days ago, which is after the fix 
commit you're mentioning.




What does

$ cat ~/.guix-profile/manifest | grep -A 1 manifest

report?


(manifest
  (version 4)

Not sure it matters, but Im able to run guix time-machine 
--commit= -- describe but not package -i 


Best regards,
David

bug#58205: reconfiguration stuck unless using '--no-grafts'

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> While working on Berlin today from a chroot, and with --no-substitutes
> used for guix-daemon, I wasn't able to complete the 'guix system
> reconfigure' step; it'd hand on a read call (seen using strace):
>
> statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, 
> f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, 
> f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, 
> f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
> write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 
> 152) = 152
> read(14, "gmlo\0\0\0\0", 8) = 8
> read(14, "\276\0\0\0\0\0\0\0", 8)   = 8
> read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
> ) = 12
> write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for 
> guix-1.3.0-29.9e46320 ...
> ) = 48
> read(14, "gmlo\0\0\0\0", 8) = 8
> read(14, "\255\0\0\0\0\0\0\0", 8)   = 8
> read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
> \)= 5
> read(14,

The build process is probably actually grafting things, and while doing
that it doesn’t output anything.  Thus it’s not surprising that the
client is stuck on read(2) waiting for data on the daemon socket.  It
might be that the grafting process is just taking a long time?

The way to debug that would be to run ‘sudo guix processes’, to identify
the build process and hand (the one that builds /gnu/store/kv1hg….drv in
the example above), and to strace that process.

HTH!

Ludo’.

bug#58040: "guix style" puts closing parentheses on the wrong line

[Ludovic Courtès]

Hi,

Maxime Devos  skribis:

> and running "guix style -f a.scm" on it, it becomes
>
> (define (find-latest-release releases)
>   (fold (match-lambda* (((key . value) result)
> (cond
>   ((even-minor-version? key)
>(match result
>  (#f (cons key value))
>  ((newest . _) (if (version>? key newest)
>(cons key value) result
>   (else result)))
>   ) #f releases)).
>
> In particular, note the ") #f releases" -- IMO ) should be on the
> previous line, after (else result))), to avoid lonely parentheses and
> to align the arguments of 'fold'.

Fixed in 4bd75d79e5ad8bb0f6cdcc0d15b9afb25f54afbd: ‘match-lambda*’ had
an incorrect special form declaration.

Thanks,
Ludo’.

bug#58090: Missing bin/ffplay in ffmpeg@4

[Ludovic Courtès]

Hi,

Zhu Zihao  skribis:

> citreu@asus-laptop:~$ guix describe
> Generation 1149月 26 2022 13:24:04 (当前)
>   guix 754ce58
> repository URL: https://mirror.guix.org.cn/git/guix
> branch: master
> commit: 754ce586e013582b0f6d28337fdc46db35395997
> citreu@asus-laptop:~$ guix shell ffmpeg@4 --pure -- ffplay
> guix shell: error: ffplay: command not found

This is apparently caused by the switch from SDL2 2.0.14 to SDL2 2.24.0
in commit f24bf279d41fab25ceb3fcc88bcd5da6fb1404ae.

Fixed in 782c7455e1ea3785e8c7e9b300d55c9ebb441a35.

Thanks,
Ludo’.

bug#58247: Using guix time-machine results in unsupported manifest format error

[zimoun]

Hi,

On Sun, 02 Oct 2022 at 20:57, david larsson  
wrote:
> On 2022-10-02 19:02, zimoun wrote:

>> It is probably because an issue with version of manifest; e.g, fixed by
>> 67a6828b2bb821274757f686f7c685b664339a96.  See
>> .
>
> Note that the commit I'm on, is from 2 days ago, which is after the fix 
> commit you're mentioning.

Yes, note that the earlier mentioned commit
7e8e07033d2a6b0ecef566a05084c534c774cd4a is from Oct 2021 if I read
correctly.


> Not sure it matters, but Im able to run guix time-machine 
> --commit= -- describe but not package -i 

IIUC, ’describe’ reads from ~/.config/guix/current/manifest and here the
issue is from ~/.guix-profile/manifest.

Maybe I am wrong, but I think the issue is coming from an
incompatibility about the version of ~/.guix-profile/manifest.

This manifest is at the version 4.  When you run

  guix time-machine --commit= -- package -i hello

then I guess it works or not depending on .

The manifest file ~/.guix-profile/manifest needs to be updated and there
is a conflict because some versions of the profile manifest.  For
instance, consider two profiles generated using 2 different revisions of
Guix – a recent one and an old one:

--8<---cut here---start->8---
$ guix time-machine --commit=729ce5f -- package -i hello -p /tmp/new

$ cat /tmp/new/manifest | grep -A 1 '(manifest'
(manifest
  (version 4)
--8<---cut here---end--->8---

and

--8<---cut here---start->8---
$ guix time-machine --commit=7e8e070 -- package -i hello -p /tmp/old

$ cat /tmp/old/manifest | grep -A 1 '(manifest'
(manifest
  (version 3)
--8<---cut here---end--->8---


Now, consider the recent profile named /tmp/new and try to install a
previous package from an old commit,

--8<---cut here---start->8---
$ guix time-machine --commit=7e8e070 -- package -i hello -p /tmp/new
guix package: error: unsupported manifest format
--8<---cut here---end--->8---

The old Guix uses version 3 and cannot read/write version 4 and bang!

Let try the converse,

--8<---cut here---start->8---
$ guix time-machine --commit=729ce5f -- package -i hello -p /tmp/old

$ cat /tmp/old/manifest | grep -A 1 '(manifest'
(manifest
  (version 4)

$ guix package --list-generations -p /tmp/old
Generation 1oct. 02 2022 18:53:10
  hello 2.10out /gnu/store/xg67cpxq2p6q7wn4y2z194pndwdymhpf-hello-2.10

Generation 2oct. 02 2022 21:25:11   (current)
 + hello2.12.1  out 
/gnu/store/s5pd3rnzymliafb4la5sca63j86xs0y0-hello-2.12.1
 - hello2.10out 
/gnu/store/xg67cpxq2p6q7wn4y2z194pndwdymhpf-hello-2.10
--8<---cut here---end--->8---

This profile /tmp/old is thus converted from version 3 to version 4, and
then, reusing old version of Guix fails,

--8<---cut here---start->8---
$ guix time-machine --commit=7e8e070 -- package -i hello -p /tmp/old
guix package: error: unsupported manifest format
--8<---cut here---end--->8---


Well, I do not know if a fix is possible.  The issue is a
backward compatibility issue.


Cheers,
simon