bug#64783: Build of texlive-font-maps fails

[Dr. Arne Babenhauserheide]

Dear Guix Hackers,

I see consistent failures of the package texlive-font-maps. It logs the error:

updmap [ERROR]: The following map file(s) couldn't be found:
updmap [ERROR]: dvips35.map (in builtin)
updmap [ERROR]: pdftex35.map (in builtin)
updmap [ERROR]: ps2pk35.map (in builtin)
updmap [ERROR]: Did you run mktexlsr?

You can disable non-existent map entries using the option
  --syncwithtrees.

This currently prevents me from updating my system.

The full log and the drv-file are attached.


3i10xkdgfwpkf27yk3bvc305v81jc0-texlive-font-maps.drv.gz
Description: Binary data

bug#64663: obs is broken (does not open window)

[Dr. Arne Babenhauserheide]

This problem was resolved for me with the trick from the thread at
help-guix "OBS Studio memory leak":

Robby Zambito <…> writes:

> Guillaume Le Vaillant <…> writes:
>
>> It looks like an issue with the shader cache of mesa.
>> After clearing it, I don't see the memory leak anymore.
>>
>> Could you try doing a "rm -r $HOME/.cache/mesa_shader_cache/*" and see
>> if it also solves the issue for you?
>
> This worked for me! Thank you!

It also works for me.

Can we somehow automate this solution?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

bug#64736: pipewire doesn't provide libspa-libcamera.so

[宋文武 via Bug reports for GNU Guix]

Alexandre Hannud Abdo  writes:

> Uou, thank you. Let me know if and how I can help. Best, .~´
>

I had submit patches for it at https://issues.guix.gnu.org/64767.
It builds fine, but I haven't test the camera (no camera here), it
will be good if you can test it...

It can be fetched in a local guix checkout:
  git remote add qa https://git.guix-patches.cbaines.net/guix-patches
  git fetch qa issue-64767
  git checkout -f qa/issue-64767

And then do a build of guix, and update local packages...
If this seems too much, you can wait the patches get merged, no worry!

Thank you!

bug#64782: Installing guile-imanifest in Profile Causes Problems with Guix

[Christopher Rodriguez]

Hello All,

I have recently tried to expand my use and knowledge of guile libraries,
and in doing so came across guile-imanifest, which is meant to be a
library to create guix manifests interactively. However, upon installing
it in my guix-home profile, I found that it propagates the guix package…
which then shadows ~/.config/guix/current/bin/guix and thus causes
problems for the end user going forward.

I've since removed it from my profile, but I wanted to report it as a
bug in case this was not expected behavior: I could conceive of a user,
excited to learn more about using guile and guix together, installing
the library and then thinking that their guix installation is broken
because nothing works after it.

If it isn't intended, I can submit a patch. If it is intended, perhaps a
note in the description might be warranted about this package causing
problems with guix if installed in a profile? Happy to submit a patch
there too.

What do You think?

-- 
Christopher Rodriguez
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


signature.asc
Description: PGP signature

bug#64753: compute-guix-derivation

[Александр Марюхин]

Hello! I can't update my Guix derivation for a few weeks. Here's the output:

Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 6547d38 (2 231 new 
commits)...

Building from this channel:
 guix https://git.savannah.gnu.org/git/guix.git   6547d38
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 
  0.0%guix substitute: warning: ci.guix.gnu.org: connection failed: 
Connection timed out

substitute:
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
building /gnu/store/bsl00ffyngq9644w4j479ahij6gvl2ld-module-import.drv...
building /gnu/store/mfsi682vryghcazkgj0d84m2ri7ffvfp-module-import.drv...
building 
/gnu/store/l60qyrhxpm21dadlygb7rwy5w6g2l9g0-module-import-compiled.drv...
building 
/gnu/store/52bpyj836vir0spfamk6aadnd2fzk7aa-module-import-compiled.drv...
building 
/gnu/store/v9hqd2r4qh9jgkqxi3gd16m1y5addnvk-compute-guix-derivation.drv...

substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
-Backtrace:
 17 (primitive-load 
"/gnu/store/gyjmpc5sn08b210hsv1h61vwyv0s86gj-compute-guix-derivation")

In ice-9/eval.scm:
   155:9 16 (_ _)
   159:9 15 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:
   152:2 14 (with-fluid* _ _ _)
   152:2 13 (with-fluid* _ _ _)
In ./guix/store.scm:
 2168:24 12 (run-with-store # 
# ?)

  1996:8 11 (_ #)
In ./guix/gexp.scm:
  299:22 10 (_ #)
  1180:2  9 (_ #)
  1046:2  8 (_ #)
   892:4  7 (_ #)
In ./guix/store.scm:
 2053:12  6 (_ #)
  1401:5  5 (map/accumulate-builds #7f37bffb40a0> # ?)
 1417:15  4 (_ # 
("/gnu/store/00lz8100v86nzcbcl9yp1jfd63ianr2z-guix-daemo?" ?) ?)

 1417:15  3 (loop #f)
  711:11  2 (process-stderr # _)
In ./guix/serialization.scm:
  101:11  1 (read-int #)
79:6  0 (get-bytevector-n* # 8)

./guix/serialization.scm:79:6: In procedure get-bytevector-n*:
ERROR:
 1. :
 file: #f
 port: #
\guix pull: error: You found a bug: the program 
'/gnu/store/gyjmpc5sn08b210hsv1h61vwyv0s86gj-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"6547d3852b11966271535962110d9e68f50c95fc"; system: "x86_64-linux";

host version: "dffaf42e5eac3822bd6b44e9749fc8e5f48fb99c"; pull-version: 1).

bug#48018: [PATCH core-updates 2/4] gnu: imagemagick: Fix converting webp images

[Saku Laesvuori via Bug reports for GNU Guix]

Fixes .

* gnu/packages/imagemagick.scm (imagemagick)[inputs]: Add libwebp.
---
The comments in the code imply that this could be applied to master, but
`guix refresh` claimed it to have over 3 000 dependents. Go figure.

 gnu/packages/imagemagick.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/imagemagick.scm b/gnu/packages/imagemagick.scm
index 169dc12f35..55e100a71c 100644
--- a/gnu/packages/imagemagick.scm
+++ b/gnu/packages/imagemagick.scm
@@ -158,6 +158,8 @@ (define-public imagemagick
(base32
 "0didbs10i9zb4dgripa851j7fivxb9jar7l3vvxz6i4kn6xvdv7r"))
   (patches (search-patches "imagemagick-Fix-tests.patch"
+(inputs (cons `("libwebp" ,libwebp)
+  (package-inputs imagemagick/stable)))
 (arguments
  (append (package-arguments imagemagick/stable)
  '(#:tests? #t)
-- 
2.41.0

bug#64775: /run should be cleaned on boot

[Saku Laesvuori via Bug reports for GNU Guix]

> > I vote for TMPFS, since that would also reduce flash wear.
> > Honestly I don't get why it's not already using TMPFS.
>
> One argument could be how much ram it takes:
> 
>   $ du -sc /run/*
>   12  /run/blkid
>   0   /run/booted-system
>   0   /run/current-system
>   1312/run/setuid-programs
>   524 /run/udev
>   1848total
> 
> That is with no explicit setuid programs configured, on a machine with a
> fairly minimal configuration.
> 
> Not a *huge* amount of ram, but not nothing, either...

I'd say it's effectively nothing for almost all devices capable of
running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
test one terminal window with only zsh running in it took almost 10
times as much ram.


signature.asc
Description: PGP signature

bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

[Sergey Trofimov]

Hi Ludovic,

shouldn't it be `(bootloader grub-efi-bootloader)` if you're 
building a `efi-raw` image?
With efi grub it builds and boots just fine, as I've tested before 
submitting the patch.


Ludovic Courtès  writes:


Hello,

There seems to be a recent regression:

$ cat mini-os.scm
(use-modules (gnu))

(operating-system
  (host-name "mini-1")

  (bootloader (bootloader-configuration
(bootloader grub-bootloader)
(targets '("/dev/sda"
  (file-systems (cons (file-system
(device (file-system-label "my-root"))
(mount-point "/")
(type "ext4")) %base-file-systems))
  (kernel-arguments (list "console=tty0 console=ttyS0,115200")))
$ guix system image mini-os.scm

bug#64593: ‘guix system image’ fails to create image while invoking ‘grub-bios-setup’

[Yann Dupont]

Hello, as it was after discussion with Ludovic that he posted this bug 
report, let me express my opinion as a simple user.


it's just a matter of consistency: very basically, the examples mention 
grub-bootloader. With the default image type (efi-raw), it's been 
working perfectly for years (maybe by chance, but in any case it seemed 
to be a compatible combination). The recent change means that it no 
longer works :-).  What's more, the error message isn't very explicit, 
and doesn't point to a configuration error but to what may appear to be 
a recently-introduced bug. Switching to grub-efi-bootloader allows you 
to build the image (and start it).


I don't know if it's simply possible to have a consistency check between 
the image type and the bootloader used: "Bootloader probably not 
compatible with image type, please use grub-efi-bootloader".


Maybe just change the doc to include grub-efi-bootloader in the 
examples. Or indeed have a format that remains compatible with MBR 
partitioning and the appropriate grub.


--

Yann



smime.p7s
Description: Signature cryptographique S/MIME

bug#64774: RISC-V 64 Python 3.10.7 build failure when building git 2.41.0 @ commit eb12f3f

[Juliana Sims]

Hello,

The command `guix shell -s riscv64-linux -Kc $(($(nproc)/2)) git` fails 
due to test failures while building Python 3.10.7. Notably, creating a 
shell with just Python (so, swapping "python" for "git" in the command) 
works fine.


Here is my channel information:
```
(channel
   (name 'guix)
   (url "")
   (branch "master")
   (commit
 "eb12f3fd8bee99920118ec802ffbac8f1ab676b9")
   (introduction
 (make-channel-introduction
   "9edb3f66fd807b096b48283debdcddccfea34bad"
   (openpgp-fingerprint
 "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"
```

I have attached the build log as well.

Thanks,
Juli



ihv7x816k38gkknnkaj9pdrxivrqcz-python-3.10.7.drv.gz
Description: application/gzip

bug#64775: /run should be cleaned on boot

[Vagrant Cascadian]

On 2023-07-21, Csepp wrote:
> Vagrant Cascadian  writes:
>> While I know that Guix does not really follow the FHS in most respects,
>> maybe the intention of /run defined there should still be respected?
>>
>>   https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>>
>>   3.15. /run : Run-time variable data
>>   3.15.1. Purpose
>>
>>   This directory contains system information data describing the system
>>   since it was booted. Files under this directory must be cleared
>>   (removed or truncated as appropriate) at the beginning of the boot
>>   process.
>>   ...
>>
>> Many distros implement this by having /run on a tmpfs, but making sure
>> to clean up /run at boot seems like a reasonable thing to do at the very
>> least.
>>
>> I am not sure if it makes sense to do housecleaning of /run from guix
>> system reconfigure ... as there may be legitimate uses for other
>> processes to write there.
...
> I vote for TMPFS, since that would also reduce flash wear.
> Honestly I don't get why it's not already using TMPFS.

One argument could be how much ram it takes:

  $ du -sc /run/*
  12  /run/blkid
  0   /run/booted-system
  0   /run/current-system
  1312/run/setuid-programs
  524 /run/udev
  1848total

That is with no explicit setuid programs configured, on a machine with a
fairly minimal configuration.

Not a *huge* amount of ram, but not nothing, either...

live well,
  vagrant


signature.asc
Description: PGP signature

bug#64775: /run should be cleaned on boot

[Csepp]

Vagrant Cascadian  writes:

> [[PGP Signed Part:Undecided]]
> So, if there are files sitting around in /run, they do not get cleaned
> up unless it is something guix is already aware of
> (e.g. /run/setuid-programs).
>
> I noticed this when experimenting with:
>
>   https://issues.guix.gnu.org/61462
>   Add support for file capabilities(7)
>
> Even after a reboot, the leftovers from that experimental patchset were
> still present in /run...
>
> While I know that Guix does not really follow the FHS in most respects,
> maybe the intention of /run defined there should still be respected?
>
>   https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>
>   3.15. /run : Run-time variable data
>   3.15.1. Purpose
>
>   This directory contains system information data describing the system
>   since it was booted. Files under this directory must be cleared
>   (removed or truncated as appropriate) at the beginning of the boot
>   process.
>   ...
>
> Many distros implement this by having /run on a tmpfs, but making sure
> to clean up /run at boot seems like a reasonable thing to do at the very
> least.
>
> I am not sure if it makes sense to do housecleaning of /run from guix
> system reconfigure ... as there may be legitimate uses for other
> processes to write there.
>
>
> live well,
>   vagrant
>
> [[End of PGP Signed Part]]

I vote for TMPFS, since that would also reduce flash wear.
Honestly I don't get why it's not already using TMPFS.

bug#64775: /run should be cleaned on boot

[Vagrant Cascadian]

So, if there are files sitting around in /run, they do not get cleaned
up unless it is something guix is already aware of
(e.g. /run/setuid-programs).

I noticed this when experimenting with:

  https://issues.guix.gnu.org/61462
  Add support for file capabilities(7)

Even after a reboot, the leftovers from that experimental patchset were
still present in /run...

While I know that Guix does not really follow the FHS in most respects,
maybe the intention of /run defined there should still be respected?

  https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html

  3.15. /run : Run-time variable data
  3.15.1. Purpose

  This directory contains system information data describing the system
  since it was booted. Files under this directory must be cleared
  (removed or truncated as appropriate) at the beginning of the boot
  process.
  ...

Many distros implement this by having /run on a tmpfs, but making sure
to clean up /run at boot seems like a reasonable thing to do at the very
least.

I am not sure if it makes sense to do housecleaning of /run from guix
system reconfigure ... as there may be legitimate uses for other
processes to write there.


live well,
  vagrant


signature.asc
Description: PGP signature

bug#64772: TeXlive (specifically LuaLaTeX) has become terribly slow

[Malte Frank Gerdes]

Hi,

i'm building a small document with LuaLaTeX, for that i have use the
following manifest

--8<---cut here---start->8---
(specifications->manifest
  (list
"texlive-amsmath"
"texlive-todonotes"
"texlive-xpatch"
"texlive-collection-luatex"
"texlive-collection-basic"
"texlive-latexmk"
"texlive-scheme-basic"
"texlive-biber"
"texlive-booktabs"
"texlive-microtype"
"texlive-koma-script"
"texlive-lipsum"
"texlive-pgfplots"
"texlive-biblatex"))
--8<---cut here---end--->8---

This command takes quite a long time
--8<---cut here---start->8---
guix time-machine --commit=21b718f4d6c3ded8ef50d12f6e9ae6474f74620f \
   shell --manifest=guix.scm -- latexmk -lualatex -auxdir=.tex-cache main
--8<---cut here---end--->8---

To be precise:
--8<---cut here---start->8---
Command being timed: "guix shell -m guix.scm -- latexmk -lualatex 
-auxdir=.tex-cache main"
User time (seconds): 14.60
System time (seconds): 87.58
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 1:43.18
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 179368
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 118914
Voluntary context switches: 2146
Involuntary context switches: 3693
Swaps: 0
File system inputs: 462280
File system outputs: 6584
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
--8<---cut here---end--->8---

Running `latexmk -lualatex -auxdir=.tex-cache main` takes under 10
seconds.  These times are for fresh builds, i.e. the intermediate files
have been removed.  Still even recompilation is many times slower with
guix provided LuaLaTeX than it is on Arch.  I should also note, that
using the modular TeX packages actually helps here, with the full
TeXlive package the compilation time is nearly twice as much.

Another thing i noticed is, that a directory with the following
structure gets created:

--8<---cut here---start->8---
{
└── gnu
└── store
└── 3wsicprhgxhcncaf5mv26wwbhhh8p6yj-profile
└── share
└── texmf-dist
└── luatex-cache
└── generic
├── fonts
│   └── otl
│   ├── lmroman10-italic.lua
│   ├── lmroman10-italic.luc
│   ├── lmroman10-regular.lua
│   ├── lmroman10-regular.luc
│   ├── lmroman12-regular.lua
│   ├── lmroman12-regular.luc
│   ├── lmroman17-regular.lua
│   ├── lmroman17-regular.luc
│   ├── lmromanslant10-regular.lua
│   ├── lmromanslant10-regular.luc
│   ├── lmsans10-bold.lua
│   ├── lmsans10-bold.luc
│   ├── lmsans10-regular.lua
│   └── lmsans10-regular.luc
└── names
├── luaotfload-lookup-cache.lua
├── luaotfload-lookup-cache.luc
├── luaotfload-names.lua.gz
└── luaotfload-names.luc.gz

11 directories, 18 files
--8<---cut here---end--->8---

This is obviously for caching purposes, but (seemingly random) having a
folder named '{' in your working directory certainly is confusing.


mfg

bug#64745: [guix-past] channel derivation broken after recent u-boot update

[Maxim Cournoyer]

Hi Ludovic,

Thanks a lot for the prompt resolution.

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> It appears that the Guix-Past channel now fails to build like so:
>>
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://ci.guix.gnu.org'...  0.0%^Msubstitute: ESC[Kupdating
>> substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://bordeaux.guix.gnu.org'...  0.0%^Msubstitute: ESC[Kupdating
>> substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>> @ build-started
>> /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv -
>> x86_64-linux
>> /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv
>> 4536
>> (repl-version 0 1 1)
>> (exception unbound-variable (value #f) (value "Unbound variable:
>> ~S") (value (crust-pine64-plus)) (value #f))
>> builder for
>> `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed
>> to produce output path
>> `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>> @ build-failed
>> /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1
>> builder for
>> `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed
>> to produce output path
>> `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>>
>> I suspect it's caused by the commit
>> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
>> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
>> understand why.
>
> This can be reproduced like so:
>
> $ guix time-machine --commit=a4038c4f783b05040cfdb262d9f4c0119b612371 -- repl 
> <(echo '(use-modules (gnu packages firmware))')
> Backtrace:
> In ice-9/boot-9.scm:
>222:29 19 (map1 (((gnu packages acl)) ((gnu packages admin)) ((gnu 
> packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu 
> packages backup)) ((gnu # #)) # …))
>222:29 18 (map1 (((gnu packages admin)) ((gnu packages assembly)) ((gnu 
> packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu 
> packages base)) ((gnu # #)) # …))
>222:29 17 (map1 (((gnu packages assembly)) ((gnu packages attr)) ((gnu 
> packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu 
> packages bash)) ((gnu # #)) # …))
>222:29 16 (map1 (((gnu packages attr)) ((gnu packages autotools)) ((gnu 
> packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages 
> bison)) ((gnu # #)) ((…)) …))
>222:29 15 (map1 (((gnu packages autotools)) ((gnu packages backup)) ((gnu 
> packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages 
> bootloaders)) ((gnu …)) …))
>222:29 14 (map1 (((gnu packages backup)) ((gnu packages base)) ((gnu 
> packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu 
> packages build-tools)) ((# …)) …))
>222:29 13 (map1 (((gnu packages base)) ((gnu packages bash)) ((gnu 
> packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) 
> ((gnu packages check)) ((gnu …)) …))
>222:29 12 (map1 (((gnu packages bash)) ((gnu packages bison)) ((gnu 
> packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) 
> ((gnu packages cluster)) ((…)) …))
>222:29 11 (map1 (((gnu packages bison)) ((gnu packages bootloaders)) ((gnu 
> packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((gnu 
> packages cmake)) ((…)) …))
>222:17 10 (map1 (((gnu packages bootloaders)) ((gnu packages build-tools)) 
> ((gnu packages check)) ((gnu packages cluster)) ((gnu packages cmake)) ((gnu 
> packages #)) ((gnu …)) …))
>   3327:17  9 (resolve-interface (gnu packages bootloaders) #:select _ #:hide 
> _ #:prefix _ #:renamer _ #:version _)
> In ice-9/threads.scm:
> 390:8  8 (_ _)
> In ice-9/boot-9.scm:
>   3253:13  7 (_)
> In ice-9/threads.scm:
> 390:8  6 (_ _)
> In ice-9/boot-9.scm:
>   3544:20  5 (_)
>2836:4  4 (save-module-excursion # ice-9/boot-9.scm:3545:21 ()>)
>   3564:26  3 (_)
> In unknown file:
>2 (primitive-load-path "gnu/packages/bootloaders" # 7f15e68a0c00 at ice-9/boot-9.scm:3551:37 ()>)
> In gnu/packages/bootloaders.scm:
>   1061:31  1 (_)
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: crust-pine64-plus: unbound variable
>
> This is the dreaded “circular top-level references” case: to load
> firmware.scm, you need to (indirectly) load bootloaders.scm

I suspected it had to do with top level cycles, but how did you work out
the indirect dependencies of firmware.scm on bootloaders.scm ?  I simply
thought "firmware doesn't pull the bootloaders module directly, so we
should be good".

Is there some trick (Guile traces?) to print which modules are getting
pulled or something useful to know?

-- 
Thanks,
Maxim

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

[Christopher Baines]

Christopher Baines  writes:

> To confirm that this is an issue with the supported systems as reported
> by Guix, I had the data service print out the transitive supported
> systems for the guix package:
>
>   debug: Starting getting derivations for (i686-linux . #f)
>   looking at guix package (supported systems: (), system supported: #f, 
> target supported: #t
>   debug: Finished getting derivations for (i686-linux . #f), took 12  seconds
>
>   debug: Starting getting derivations for (armhf-linux . #f)
>   looking at guix package (supported systems: (), system supported: #f, 
> target supported: #t
>   debug: Finished getting derivations for (armhf-linux . #f), took 41 seconds

I realised that this could be non-deterministic because the order in
which the data service processes derivations is non-deterministic, from
the order of the systems returned by (guix platforms).

That led me to a reproducer:

  (use-modules (gnu packages) (guix packages) (gnu packages package-management))

  (fold-packages (lambda (pkg result)
   (package-transitive-supported-systems pkg "i586-gnu")
   #f)
 #f)

  (peek "guix package supported systems" (package-transitive-supported-systems 
guix "i686-linux"))

If you look at the %final-inputs packages, there's an issue with libc:

  (use-modules (ice-9 match)
   (gnu packages) (guix packages) (gnu packages package-management)
   (gnu packages commencement))

  (fold-packages (lambda (pkg result)
   (package-transitive-supported-systems pkg "i586-gnu")
   #f)
 #f)

  (for-each
   (match-lambda
 ((name pkg rest ...)
  (peek name
(package-transitive-supported-systems
 pkg
 "i686-linux"
   (%final-inputs "i686-linux"))

I think this could be because %final-inputs is cached based on system,
but doesn't seem to use system. Setting %current-system to system seems
to help, so I've sent a patch for that [1].

1: https://issues.guix.gnu.org/64763


signature.asc
Description: PGP signature

bug#64760: make check fails on 182be30fb1a8b847c30492462ec22c08ec7a9849

[Janneke Nieuwenhuizen]

Josselin Poiret writes:

Hi Josselin,

>> Make check gives three failures for me on current master
>>
>> FAIL: tests/packages (package->bag)
>> FAIL: tests/store-roots  (gc-roots, initial)  
>> FAIL: tests/texlive  (texlive->guix-package, meta-package)
>>
>> using this snippet.
>
> I have local fixes for all of them

Nice!  I can confirm they work for me.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

bug#64760: [PATCH 3/3] tests: texlive: Remove texlive-texworks from propagated-inputs.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* tests/texlive.scm ("texlive->guix-package, meta-package"): Remove
texlive-texworks from expected propagated-inputs, as it is now ignored by
texlive->guix-package.
---
 tests/texlive.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/texlive.scm b/tests/texlive.scm
index 98461f7e51..b8b1d5c6d6 100644
--- a/tests/texlive.scm
+++ b/tests/texlive.scm
@@ -542,7 +542,7 @@ (define %fake-tlpdb
('arguments
 ('list '#:builder ('gexp ('mkdir ('ungexp 'output)
('propagated-inputs
-('list 'texlive-collection-basic 'texlive-texworks))
+('list 'texlive-collection-basic))
('home-page "https://www.tug.org/texlive/;)
('synopsis (? string?))
('description (? string?))
-- 
2.40.1

bug#64760: [PATCH 1/3] tests: packages: Set system for expected result of package->bag.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* tests/packages.scm ("package->bag"): Parameterize the expected result by the
system used to lower the package to a bag.
---
 tests/packages.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/packages.scm b/tests/packages.scm
index 2b7ab01f7d..2b4f9f8e90 100644
--- a/tests/packages.scm
+++ b/tests/packages.scm
@@ -1277,8 +1277,9 @@ (define compressors '(("gzip"  . "gz")
 ;;   #:guile guile
 
 (test-equal "package->bag"
-  `("foo86-hurd" #f (,(package-source gnu-make))
-(,(canonical-package glibc)) (,(canonical-package coreutils)))
+  (parameterize ((%current-system "foo86-hurd"))
+`("foo86-hurd" #f (,(package-source gnu-make))
+  (,(canonical-package glibc)) (,(canonical-package coreutils
   (let ((bag (package->bag gnu-make "foo86-hurd")))
 (list (bag-system bag) (bag-target bag)
   (assoc-ref (bag-build-inputs bag) "source")

base-commit: 182be30fb1a8b847c30492462ec22c08ec7a9849
-- 
2.40.1

bug#64760: [PATCH 2/3] tests: store-roots: Initial gc-roots should be empty.

[Josselin Poiret via Bug reports for GNU Guix]

From: Josselin Poiret 

* tests/store-roots.scm ("gc-roots, initial"): Set expected result to empty.
Also do not error out if /profiles doesn't exist.
---
 tests/store-roots.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/store-roots.scm b/tests/store-roots.scm
index 9877987a65..d82a29e313 100644
--- a/tests/store-roots.scm
+++ b/tests/store-roots.scm
@@ -31,10 +31,11 @@ (define %store #f)
 (test-begin "store-roots")
 
 (test-equal "gc-roots, initial"
-  (list (string-append %state-directory "/profiles"))
+  '()
   (begin
 ;; 'gc-roots' should gracefully handle lack of that directory.
-(delete-file-recursively (string-append %state-directory "/profiles"))
+(false-if-exception
+ (delete-file-recursively (string-append %state-directory "/profiles")))
 (gc-roots)))
 
 ;; The 'open-connection' call below gets guix-daemon to create
-- 
2.40.1

bug#64760: make check fails on 182be30fb1a8b847c30492462ec22c08ec7a9849

[Josselin Poiret via Bug reports for GNU Guix]

Hi Janneke,

Janneke Nieuwenhuizen  writes:

> Hi,
>
> Make check gives three failures for me on current master
>
> FAIL: tests/packages (package->bag)
> FAIL: tests/store-roots  (gc-roots, initial)  
> FAIL: tests/texlive  (texlive->guix-package, meta-package)
>
> using this snippet.

I have local fixes for all of them, but I am not 100% sure about the
gc-roots one.  Ludo, WDYT?  Also, guix-shell fails on the fdes test
locally for me, probably because I'm using zsh.  All should be fine in
the package though.

Best,

Josselin Poiret


signature.asc
Description: PGP signature

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

[Christopher Baines]

Hey,

I spotted this issue a few days ago, but I'm still pretty confused by
it. Both instances of the data service have sometimes been reporting
only a small number of package derivations for i686-linux and
armhf-linux.

I think the first revisions to exhibit this on the master branch for the
two data service instances are [1] and [2]. Given that for each of these
revisions, the other data service instance reports an expected number of
derivations, this issue seems to be non-deterministic.

1: https://data.guix.gnu.org/revision/67fb8efdf782592c133726a1ab7bc6692259e385
2: 
https://data.qa.guix.gnu.org/revision/09e73683a2c303016fa57bf5d84a8e997d4c0a30

To confirm that this is an issue with the supported systems as reported
by Guix, I had the data service print out the transitive supported
systems for the guix package:

  debug: Starting getting derivations for (i686-linux . #f)
  looking at guix package (supported systems: (), system supported: #f, target 
supported: #t
  debug: Finished getting derivations for (i686-linux . #f), took 12  seconds

  debug: Starting getting derivations for (armhf-linux . #f)
  looking at guix package (supported systems: (), system supported: #f, target 
supported: #t
  debug: Finished getting derivations for (armhf-linux . #f), took 41 seconds

This log output is from https://data.qa.guix.gnu.org/job/47888

This isn't just a one off thing though, it seems to happen quite
frequently for many revisions.

Any ideas?

Thanks,

Chris


signature.asc
Description: PGP signature

bug#64760: make check fails on 182be30fb1a8b847c30492462ec22c08ec7a9849

[Janneke Nieuwenhuizen]

Hi,

Make check gives three failures for me on current master

FAIL: tests/packages (package->bag)
FAIL: tests/store-roots  (gc-roots, initial)  
FAIL: tests/texlive  (texlive->guix-package, meta-package)

using this snippet.

--8<---cut here---start->8---
export SCM_LOG_DRIVER_FLAGS="--select='^(package->bag|gc-roots, 
initial|texlive->guix-package, meta-package)'"
make check TESTS="tests/packages.scm tests/store-roots.scm tests/texlive.scm"
--8<---cut here---end--->8---

Find log excerpts attached.

I have bisected the first (package->bag) to be broken by

0dd293b4d9095137c9952e16ca951f887b7e7018
gnu: Add libc-for-target and glibc/hurd.

but as yet fail to why.

Greetings,
Janneke



packages.log
Description: Binary data


store-roots.log
Description: Binary data


texlive.log
Description: Binary data

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com