bug#70877: guix-daemon fails to copy 4+GB file to store

[Efraim Flashner]

On Sat, May 11, 2024 at 12:52:53PM +0200, Ricardo Wurmus wrote:
> The guix-daemon's libutil/util.cc uses copy_file_range to copy a
> downloaded file into the store.  copy_file_range fails on files larger
> than 4GB with an error like this:
> 
> guix build: error: short write in copy_file_range `15' to `16': No such 
> file or directory
> 
> The man page for copy_file_range says that it could return EFBIG when
> the range exceeds the maximum range.  The daemon code does not check any
> limits and will attempt to copy the whole file.
> 
> I believe our code ought to check the value of st.size and fall back to
> a boring copy if it exceeds some "reasonable" value.
> 
> This is where copy_file_range is used:
> https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libutil/util.cc#n382
> 
> Here is a little reproducer:
> 

> (use-modules (guix download)
>  (guix packages)
>  (guix build-system trivial))
> 
> (package
>   (name "chungus")
>   (version "1")
>   (source
>(origin
>  (method url-fetch)
>  (uri "http://localhost:/chungus;)
>  (sha256
>   (base32 "0nx67d4ls2nfwcfdmg81vf240z6lpwpdqypssr1wzn3hyz4szci4"
>   (build-system trivial-build-system)
>   (home-page "")
>   (synopsis "")
>   (description "")
>   (license #f))

> 
> --8<---cut here---start->8---
> # generate a big file
> dd bs=1M count=4096 if=/dev/zero of=/tmp/chungus
> # serve it
> guix shell woof -- woof -i 127.0.0.1 -p  -c 1 /tmp/chungus
> # build the source derivation
> guix build --no-grafts -Sf bug.scm
> # observe the error
> # guix build: error: short write in copy_file_range `15' to `16': No such 
> file or directory
> --8<---cut here---end--->8---
> 

This sounds like a similar failure to bug 65714 that I ran into with
guix copy, but I wasn't able to diagnose it.

https://issues.guix.gnu.org/65714


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#70429: agate service broken

[Efraim Flashner]

Here's a potential patch. I'm not sure about how to deprecate fields

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff --git a/doc/guix.texi b/doc/guix.texi
index f4f21c4744..852b2eb706 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -32510,10 +32510,9 @@ Web Services
 
 @lisp
 (service agate-service-type
-(agate-configuration
-  (content "/srv/gemini")
-  (cert "/srv/cert.pem")
-  (key "/srv/key.rsa")))
+  (agate-configuration
+(content "/srv/gemini")
+(certs "/srv/gemini-certs")))
 @end lisp
 
 The example above represents the minimal tweaking necessary to get Agate
@@ -32544,13 +32543,10 @@ Web Services
 @item @code{content} (default: @file{"/srv/gemini"})
 The directory from which Agate will serve files.
 
-@item @code{cert} (default: @code{#f})
-The path to the TLS certificate PEM file to be used for encrypted
-connections.  Must be filled in with a value from the user.
-
-@item @code{key} (default: @code{#f})
-The path to the PKCS8 private key file to be used for encrypted
-connections.  Must be filled in with a value from the user.
+@item @code{certs} (default: @code{#f})
+The path to the directory containing the TLS certificate PEM and the PKCS8
+private key file to be used for encrypted connections.  Must be filled in
+with a value from the user.
 
 @item @code{addr} (default: @code{'("0.0.0.0:1965" "[::]:1965")})
 A list of the addresses to listen on.
@@ -32561,8 +32557,9 @@ Web Services
 @item @code{lang} (default: @code{#f})
 RFC 4646 language code(s) for text/gemini documents.  Optional.
 
-@item @code{silent?} (default: @code{#f})
-Set to @code{#t} to disable logging output.
+@item @code{only-tls13?} (default: @code{#f})
+Set to @code{#t} to allow only connections over TLS v1.3.  By default TLS
+v1.2 is also allowed.
 
 @item @code{serve-secret?} (default: @code{#f})
 Set to @code{#t} to serve secret files (files/directories starting with
diff --git a/gnu/services/web.scm b/gnu/services/web.scm
index 406117c457..57750e120b 100644
--- a/gnu/services/web.scm
+++ b/gnu/services/web.scm
@@ -302,12 +302,14 @@ (define-module (gnu services web)
 agate-configuration?
 agate-configuration-package
 agate-configuration-content
-agate-configuration-cert
-agate-configuration-key
+agate-configuration-cert; deprecated
+agate-configuration-key ; deprecated
+agate-configuration-certs
 agate-configuration-addr
 agate-configuration-hostname
 agate-configuration-lang
-agate-configuration-silent
+agate-configuration-silent  ; deprecated
+agate-configuration-only-tls13
 agate-configuration-serve-secret
 agate-configuration-log-ip
 agate-configuration-user
@@ -2181,6 +2183,8 @@ (define-record-type* 
 (default #f))
   (key  agate-configuration-key
 (default #f))
+  (certsagate-configuration-certs
+(default #f))
   (addr agate-configuration-addr
 (default '("0.0.0.0:1965" "[::]:1965")))
   (hostname agate-configuration-hostname
@@ -2189,6 +2193,8 @@ (define-record-type* 
 (default #f))
   (silent?  agate-configuration-silent
 (default #f))
+  (only-tls13?   agate-configuration-only-tls13
+ (default #f))
   (serve-secret? agate-configuration-serve-secret
  (default #f))
   (log-ip?  agate-configuration-log-ip
@@ -2202,8 +2208,8 @@ (define-record-type* 
 
 (define agate-shepherd-service
   (match-lambda
-(($  package content cert key addr
-  hostname lang silent? serve-secret?
+(($  package content cert key certs addr
+  hostname lang only-tls13? serve-secret?
   log-ip? user group log-file)
  (list (shepherd-service
 (provision '(agate))
@@ -2213,8 +2219,13 @@ (define agate-shepherd-service
  #~(make-forkexec-constructor
 (list #$agate
   "--content" #$content
-  "--cert" #$cert
-  "--key" #$key
+  #$@(if certs
+ (list "--certs" certs)
+ (if (and cert key
+  (equal? (dirname cert)
+  (dirname key)))
+ (list "--certs" (dirname cert))
+ '()))
  

bug#70140: Missing ./doc/guix-cookbook.pt_BR.texi

[Efraim Flashner]

Rerun ./bootstrap and configure, then make

On Tue, Apr 02, 2024 at 03:59:36PM +0200, Rostislav Svoboda wrote:
> $ guix shell --development guix direnv gnupg --pure --
> bost@ecke ~/dev/guix [env]$ make doc/guix.texi
>  cd . && /bin/sh /home/bost/dev/guix/build-aux/missing automake-1.16
> --gnu Makefile
> Makefile.am:922: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS
> automake-1.16: error: cannot open < ./doc/guix-cookbook.pt_BR.texi: No
> such file or directory
> make: *** [Makefile:4349: Makefile.in] Error 1
> 
> And I think it is caused by:
> 
> $ git show --format=medium fa98837b1d9586b9ca7bf77dae22c3bde0fc59b5 
> doc/local.mk
> commit fa98837b1d9586b9ca7bf77dae22c3bde0fc59b5
> Author: Florian Pelz 
> Date:   Mon Apr 1 00:54:32 2024
> 
> nls: Update translations.
> 
> * po/guix/ar.po: New file.
> * po/guix/LINGUAS: Add 'ar'.
> * po/doc/guix-cookbook.pt_BR.po: New file.
> * po/doc/local.mk: Add 'pt_BR' cookbook.
> * doc/local.mk: Add 'pt_BR' cookbook.
> * doc/htmlxref.cnf: Update URLs for cookbook.
> * doc/build.scm (%cookbook-languages): Add 'ko', 'pt_BR'.
> * doc/guix-cookbook.texi (Top): Mention 'ko', 'pt_BR' cookbook.
> 
> Change-Id: Id1846ca100263b3fc1fa2ed52654c670270ee809
> 
> diff --git a/doc/local.mk b/doc/local.mk
> index 97f0c3a92a..0ff317a19e 100644
> --- a/doc/local.mk
> +++ b/doc/local.mk
> @@ -23,7 +23,7 @@
> 
>  # If adding a language, update the following variables, and info_TEXINFOS.
>  MANUAL_LANGUAGES = de es fr pt_BR ru zh_CN
> -COOKBOOK_LANGUAGES = de fr ko sk
> +COOKBOOK_LANGUAGES = de fr ko pt_BR sk
> 
>  # Arg1: A list of languages codes.
>  # Arg2: The file name stem.
> @@ -42,6 +42,7 @@ info_TEXINFOS = %D%/guix.texi \
>%D%/guix-cookbook.de.texi\
>%D%/guix-cookbook.fr.texi\
>%D%/guix-cookbook.ko.texi    \
> +  %D%/guix-cookbook.pt_BR.texi \
>%D%/guix-cookbook.sk.texi
> 
>  %C%_guix_TEXINFOS = \
> 
> 
> 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#53129: Zathura: Index for epub files only go to show page 1

[Efraim Flashner]

On Fri, Mar 29, 2024 at 03:17:13PM +, Sharlatan Hellseher wrote:
> 
> Hi,
> 
> Is it still relevant for you or it may be closed as resolved?
> The issue can't be reproduced as not commit or version provided.
> 
> Thanks,
> Oleg

I was able to read an epub using zathura and zathura-pdf-mupdf. I read
the first ~160 pages.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#69130: Request for merging "rust-team" branch

[Efraim Flashner]

On Wed, Feb 14, 2024 at 08:58:13PM +0200, Efraim Flashner wrote:
> It's been a few months since the last merge. We have rust-1.75, riscv64
> support is back, and we almost have support for powerpc64le.  I figure
> it's time to merge back into master.

Branch merged!


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#69401: /etc/guix/machines.scm symlink can be garbage collected

[Efraim Flashner]

Some of the build nodes behind the Berlin build farm have a childhurd
which can build packages.  Unfortunately, the symlink from
/etc/guix/machines.scm to the generated file in the store to setup
offloading has been garbage collected on several of the machines.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#69130: Request for merging "rust-team" branch

[Efraim Flashner]

It's been a few months since the last merge. We have rust-1.75, riscv64
support is back, and we almost have support for powerpc64le.  I figure
it's time to merge back into master.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#68466: guile-2.0 FTBFS on powerpc-linux

[Efraim Flashner]

guile-2.0 fails to build on powerpc-linux, breaking the ability to do
any grafting.  True on commit f6afaf58b0a0b04e5023141c8f56c204f9779e19,
haven't checked backward to see when it happened.  Occurs on real
hardware and using qemu emulation.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


wgrxrdna9lyzp4h44dczzz5x74r5pq-guile-2.0.14.drv.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#68229: go.powerpc64le-linux 1.14.15 fails test suite

[Efraim Flashner]

On January 10, 2024 4:31:07 AM UTC, Maxim Cournoyer  
wrote:
>reopen 68229
>quit
>
>Hi,
>
>Efraim Flashner  writes:
>
>> On January 3, 2024 5:59:22 PM UTC, Maxim Cournoyer 
>>  wrote:
>>>Hello,
>>>
>>>Efraim Flashner  writes:
>>>
>>>> On Wed, Jan 03, 2024 at 11:29:50AM -0500, Maxim Cournoyer wrote:
>>>>> Hello,
>>>>> 
>>>>> cuir...@gnu.org (Cuirass) writes:
>>>>> 
>>>>> > The build go.powerpc64le-linux for specification
>>>>> > master is broken. You can find the detailed information
>>>>> > about this build >>>> > href="https://ci.guix.gnu.org/build/3139760/details;>here.
>>>>> >
>>>>> > https://ci.guix.gnu.org/build/3139760/details
>>>>> 
>>>>> The test failure is:
>>>>> 
>>>>> --8<---cut here---start->8---
>>>>> --- FAIL: TestScript (0.00s)
>>>>> --- FAIL: TestScript/vendor_complex (2.07s)
>>>>> script_test.go:193: 
>>>>> # smoke test for complex build configuration (1.990s)
>>>>> > go build -o complex.exe complex
>>>>> > [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
>>>>> [stderr]
>>>>> # complex
>>>>> gccgo: error: unrecognized command-line option
>>>>> '-rpath=/gnu/store/qj6cnccz6vsffqa32rviw4zaqgh7xd6q-gcc-11.3.0-lib/lib'
>>>>> [exit status 2]
>>>>> FAIL: testdata/script/vendor_complex.txt:5: unexpected 
>>>>> command failure
>>>>> 
>>>>> FAIL
>>>>> FAIL  cmd/go  46.068s
>>>>> --8<---cut here---end--->8---
>>>>> 
>>>>> I don't see an obvious relationship with the recent commit touching
>>>>> gccgo-12, but I'm CC'ing its author in case it could be.
>>>>
>>>> This one is go-1.14. That one already failed for ppc64le.
>>>
>>>OK; Cuirass got it wrong again.  Should we leave the ticket open though,
>>>since it's an actual problem?
>>>
>> Fine with me. We should probably remove go-1.14 anyway if nothing
>> depends on it. And either make it build on ppc64le or mark it not
>> supported otherwise.
>
>Alright, I'll leave this open for someone to pick up.  The task would be
>to remove go-1.14, incorporating it into go-1.16, which currently
>inherits from it.  Any takers?
>

https://issues.guix.gnu.org/68300

Although it currently rebuilds all go packages. I should probably fix that.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#68243: alacritty segmentation fault

[Efraim Flashner]

I meant more of what's the guix version from the generation which
contains the non-working alacritty.

On Fri, Jan 05, 2024 at 02:51:34PM +, ste...@roose.io wrote:
> How can I check generations for packages? `guix package -l` doesn't seem to 
> show any useful information.
> 
> I can't seem to find out what the syntax should be for the PATTERN arguments 
> in guix package, like `guix package --list-generations=PATTERN`.
> 
> I try `guix package -l alacritty`, `guix package 
> --list-generations=alacritty` but always get `invalid syntax: alacritty`..
> 
> On 1/5/24 12:52 PM, Efraim Flashner  wrote:
> > On Thu, Jan 04, 2024 at 03:32:55PM +, Steven Roose wrote:
> > > I've been using alacritty as my default terminal for about a year without
> > > much issues. I'm currently on v0.12.3 of alacritty and use it with i3 and
> > > Xorg. A month or two ago I noticed that upgrading GuixSD broke alacritty.
> > > Since it's my main terminal and I didn't have any other terminals 
> > > installed,
> > > I was forced to rollback my system through GRUB because I couldn't 
> > > literally
> > > not even open a terminal to investigate or roll-back by CLI. I was trying
> > > another system upgrade now and noticed the issue is still not fixed. When
> > > running alacritty from an already-open alacritty only shows me 
> > > "segmentation
> > > fault". The working and broken version is both 0.12.3, so I think it might
> > > not be an alacritty issue but more a linking/build issue. I'm basically
> > > stuck on a months-old Guix until this is fixed.
> > >
> > > If there is any way I can be of use by providing debug/log files of some
> > > kind, please let me know.
> > 
> > Looking at 'alacritty --help' it looks like you can try adding -v (up to
> > 3) to get a more verbose output so hopefully we get more of an error
> > message.
> > 
> > Which generation are you on that is working for you? Which one do you
> > know is segfaulting? I'd like to try to narrow it down.
> > 
> > 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#68243: alacritty segmentation fault

[Efraim Flashner]

On Thu, Jan 04, 2024 at 03:32:55PM +, Steven Roose wrote:
> I've been using alacritty as my default terminal for about a year without
> much issues. I'm currently on v0.12.3 of alacritty and use it with i3 and
> Xorg. A month or two ago I noticed that upgrading GuixSD broke alacritty.
> Since it's my main terminal and I didn't have any other terminals installed,
> I was forced to rollback my system through GRUB because I couldn't literally
> not even open a terminal to investigate or roll-back by CLI. I was trying
> another system upgrade now and noticed the issue is still not fixed. When
> running alacritty from an already-open alacritty only shows me "segmentation
> fault". The working and broken version is both 0.12.3, so I think it might
> not be an alacritty issue but more a linking/build issue. I'm basically
> stuck on a months-old Guix until this is fixed.
> 
> If there is any way I can be of use by providing debug/log files of some
> kind, please let me know.

Looking at 'alacritty --help' it looks like you can try adding -v (up to
3) to get a more verbose output so hopefully we get more of an error
message.

Which generation are you on that is working for you? Which one do you
know is segfaulting? I'd like to try to narrow it down.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#68229: go.powerpc64le-linux 1.14.15 fails test suite

[Efraim Flashner]

On Wed, Jan 03, 2024 at 11:29:50AM -0500, Maxim Cournoyer wrote:
> Hello,
> 
> cuir...@gnu.org (Cuirass) writes:
> 
> > The build go.powerpc64le-linux for specification master is 
> > broken. You can find the detailed information about this build  > href="https://ci.guix.gnu.org/build/3139760/details;>here.
> >
> > https://ci.guix.gnu.org/build/3139760/details
> 
> The test failure is:
> 
> --8<---cut here---start->8---
> --- FAIL: TestScript (0.00s)
> --- FAIL: TestScript/vendor_complex (2.07s)
> script_test.go:193: 
> # smoke test for complex build configuration (1.990s)
> > go build -o complex.exe complex
> > [exec:gccgo] go build -compiler=gccgo -o complex.exe complex
> [stderr]
> # complex
> gccgo: error: unrecognized command-line option 
> '-rpath=/gnu/store/qj6cnccz6vsffqa32rviw4zaqgh7xd6q-gcc-11.3.0-lib/lib'
> [exit status 2]
> FAIL: testdata/script/vendor_complex.txt:5: unexpected command 
> failure
> 
> FAIL
> FAIL  cmd/go  46.068s
> --8<---cut here---end--->8---
> 
> I don't see an obvious relationship with the recent commit touching
> gccgo-12, but I'm CC'ing its author in case it could be.

This one is go-1.14. That one already failed for ppc64le.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#68017: Clarification on why cargo-build-system should propagate inputs and native-inputs.

[Efraim Flashner]

On Mon, Dec 25, 2023 at 03:02:22PM -0500, Jaeme Sifat wrote:
> The culprit to your problem is `rust-ffmpeg-sys-the-third-1', which requires
> all the packages you just mentioned for building. `rust-av1an-core` requires
> `rust-ffmpeg-the-third-1' which in turn requires the sys libraries as well.
> 
> --8<---cut here---start->8---
> 
> rust-ffmpeg-sys-the-third-1 -> Requires vapoursynth ffmpeg clang nasm
> pkg-config
> 
> rust-ffmpeg-the-third-1 -> Requires rust-ffmpeg-sys-the-third-1
> 
> rust-av1an-core -> Requires rust-ffmpeg-the-third-1
> 
> rust-av1an -> Requires rust-av1an-core
> 
> --8<---cut here---end--->8---
> 
> Thus, the native-inputs and inputs of rust-ffmpeg-sys-the-third are required
> for any packages that depend on it in #:cargo-inputs.
> 
> I see your point now, it would be very helpful if cargo-build-system could
> grab the inputs and native-inputs of dependent packages in the case of
> crates like `rust-ffmpeg-sys-the-third-1.' That way the dependencies
> wouldn't have to be duplicated across packages.
> 
> This sounds like a good suggestion, I can bring this up to Efraim, who is on
> the Rust team, about this who is much more knowledgeable about the
> implementation of the cargo-build-system than me.

I haven't looked too closely at that part of the cargo-build-system but
in general my mental model is that it grabs the sources of the named
packages in the cargo{,-development}-inputs. I suppose we could tell the
crates to also grab the {propagated-,native-,}inputs also and carry
those forward to the next crate.  I suppose in theory we might end up
with multiple versions of libgit2 or other packages, and I'm not sure if
that'd point to various packages having the wrong inputs or needing to
adjust it somehow to prefer one version over another.

A similar issue is the perl dependency for rust-ring. I've finally fixed
it on the rust-team branch using a computed-origin but I think both are
the type of thing the antioxidant build system would help solve.

I suppose we could end up with using propagated-inputs for things like
perl or ffmpeg (in your package above) like we do with the python build
systems and adjusting the cargo-build-system to grab those when it
traverses the tree.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66809: ovmf-aarch64 package fails to build

[Efraim Flashner]

This seems to be fixed with the update to ovmf

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66808: ovmf-arm package fails to build

[Efraim Flashner]

This seems to be fixed with the update to ovmf

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#50172: mozjs (60.2.3-2) bundles a lot

[Efraim Flashner]

On Mon, Aug 23, 2021 at 12:51:37PM +0200, Maxime Devos wrote:
> Hi guix,
> 
> mozjs@60.2.3-2 bundles a lot.
> 
> In 'third_party/python', there are 35 separate directories,
> presumably all different software projects:
> 
> /gnu/store/j2sz7dg35vkcz38sim71jll2ix1nk554-mozjs-60.2.3-2-checkout$ ls 
> third_party/python/
> attrs/dlmanager/  json-e/  pyasn1/  pytoml/   
> six/
> blessings/fluent/ lldbutils/   pyasn1-modules/  pyyaml/   
> slugid/
> cbor2/futures/mock-1.0.0/  PyECC/   redo/ 
> virtualenv/
> compare-locales/  gdbpp/  moz.buildpylru/   requests/ 
> voluptuous/
> configobj/hglib/  psutil/  pystache/
> requests-unixsocket/  which/
> cram/ jsmin/  py/  pytest/  rsa/

This package has been removed from guix so I'm going to close the bug
report.  We should check the other mozjs packages though.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67829: qtwebengine new failure on i686

[Efraim Flashner]

On Fri, Dec 15, 2023 at 06:04:30AM +, John Kehayias wrote:
> Hello Maxim,
> 
> On Thu, Dec 14, 2023 at 03:33 PM, Maxim Cournoyer wrote:
> 
> > Hello,
> >
> > qtwebengine was marked as newly failing by Cuirass on Berlin, as a
> 
> This "newly failing" is the same false alarm as we saw recently. I
> think Cuirass gets confused on same package with different versions as
> the only one I see on i686-linux building in the past year is v5.
> 
> > result to the xorg-server update in
> > <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8083c7abbf3a346162fcc4b8d5aa50555c0f3179>.
> >
> > v8_use_external_startup_data=false
> > CMake Error at 
> > /tmp/guix-build-qtwebengine-6.5.2.drv-0/qtwebengine-everywhere-src-6.5.2/cmake/Gn.cmake:75
> >  (message):
> >
> >
> >   -- GN FAILED
> >
> >   ERROR at //BUILD.gn:1652:1: Assertion failed.
> >
> >   assert(
> >
> >   ^-
> >
> >   'target_cpu=x86' is not supported for 'target_os=linux'.  Consider 
> > omitting
> >   'target_cpu' (default) or using 'target_cpu=x64' instead.
> >
> >   See //BUILD.gn:1653:5:
> >
> >   is_valid_x86_target || target_cpu != "x86" || v8_target_cpu == "arm",
> >   ^---
> >
> >   This is where it was set.
> >
> >   1
> >
> > ninja: build stopped: subcommand failed.
> >
> > I don't see how the two would be related, but I've CC'd John in case
> > they'd have some hunch.
> >
> > Perhaps some non-deterministic issue with the 'gn' build system?  It had
> > succeeded here: <https://ci.guix.gnu.org/build/2803939/details> about a
> > week ago.
> 
> As for the actual error, no idea (I saw the same thing when I noticed
> the "new failure"). But I'm cc'ing Efraim as having figured out the
> fix for the other package (sorry don't remember which, qt something)
> on i686 recently...

Upstream chromium removed support for i686 so that's why it's failing.

https://sources.debian.org/src/qt6-webengine/6.6.1%2Bdfsg-1/debian/patches/support-i386.patch/
https://sources.debian.org/src/qt6-webengine/6.6.1%2Bdfsg-1/debian/patches/disable_32bit_node_check.patch/
https://sources.debian.org/src/qt6-webengine/6.6.1%2Bdfsg-1/debian/patches/compressing_files.patch/

There's two or three patches we can add to re-enable builds on i686, or
we can mark it as unsupported.  I don't have a strong opinion either
way.

It also looks like debian doesn't support very many architectures with
qtwebengine@6

https://buildd.debian.org/status/logs.php?pkg=qt6-webengine

They also have limited architectures for qtwebengine@5

https://buildd.debian.org/status/logs.php?pkg=qtwebengine-opensource-src

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#29644: bug#66965: Acknowledgement ([CORE-UPDATES PATCH] gnu: gcc: Support objc, objc++ by default.)

[Efraim Flashner]

Patch pushed to core-updates with minimal changes.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67651: [gnome-team] What should we do with the "gnome" package?

[Efraim Flashner]

On Tue, Dec 05, 2023 at 09:55:56PM +0100, Vivien Kraus via Bug reports for GNU 
Guix wrote:
> Dear guix,
>
> The gnome package disables eog on 32-bit machines because it depends on
> librsvg-next. It seems a bit outdated to me, as most of gnome won’t
> work on 32-bit machines, not only eog. Should we try and find which
> ones work on 32-bit systems?

One option would be to wrap everything in 'supported-package?' and
append everything together. Then if something depends on the newer
librsvg and that isn't supported on that architecture it will just be
skipped.

Something to keep in mind though is the rust-team branch adds support
for cross-building rust, so you could end up with a different set of
packages depending on cross-building.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux

[Efraim Flashner]

On Wed, Nov 29, 2023 at 03:55:15PM -0500, Leo Famulari wrote:
> I see that ci.guix.gnu.org's builders seem to run out of memory while
> building kernel headers for i686-linux:
> 
> --
> xz: (stdin): Cannot allocate memory
> /gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar: 
> /gnu/store/536ifp75wv8i1kb1k0szv7zd57ygpg0n-linux-libre-6.5.13-guix.tar.xz: 
> Wrote only 2048 of 10240 bytes
> /gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar: Child returned 
> status 1
> /gnu/store/ns71xxkb3fzr37934bim9l8xiv68kc7w-tar-1.34/bin/tar: Error is not 
> recoverable: exiting now
> --
> 
> https://ci.guix.gnu.org/build/2736161/details

This looks like more of the too-many-cores while decompressing tarballs
issues we've had in the past on i686-linux.  Can we change that phase to
use a maximum of 4 cores or would that cause everything to rebuild?

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67608: qtbase fails to build on i686

[Efraim Flashner]

On Sun, Dec 03, 2023 at 06:42:10PM -0500, Maxim Cournoyer wrote:
> John Kehayias  writes:
> 
> > Hi Maxim,
> >
> > On Sun, Dec 03, 2023 at 01:32 PM, Maxim Cournoyer wrote:
> >
> >> Hi,
> >>
> >> After recent mesa/xorg upgrades, qtbase fails to build on i686, per
> >> <https://ci.guix.gnu.org/build/2700964/details>.
> >
> > I saw this when I was working on the mesa-updates branch, but I didn't
> > think it was a new failure. I looked back just now and even going to
> > July or further back I don't see any successful builds of qtbase-6.*
> > on i686-linux. The most recent version has the same failures as this
> > log, pre-mesa-updates. Looked like a previous version of qtbase-6 had
> > a different failure though.
> 
> Indeed.  I wonder why Cuirass flagged the failure as a new one.

Maybe it was mixing up qtbase@5 and qtbase@6 for determining if it had
successfully built before?

> [...]
> 
> > As for the actual cause, I don't have a clue. There was a failure
> > cause by an update on that branch, which I had fixed in
> > aee3c5a894fddf88810f18fa8880b423b078b3fa (from libxkbcommon update).
> >
> > Was there a version of qtbase-6 that builds on i686?
> 
> OK.  I don't seem to find one looking at CI.  We should probably report
> this upstream if it hasn't already been.

I found it broken when I was going through a big rebuild and I believe
it tracked it down to the -DFEATURE_xxx=OFF flags that we've been
carrying since qt-4.  Once I removed them i686 stopped trying to use
128-bit numbers and compiled successfully.  As a comparison, Debian
doesn't use those flags.

I've closed the bug since it now builds, but feel free to re-open it if
we want to revisit removing the flags or anything.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67431: nsq.powerpc64le-linux Testinflightworker test failure

[Efraim Flashner]

On Fri, Nov 24, 2023 at 08:48:59AM -0500, Maxim Cournoyer wrote:
> Hello,
> 
> cuir...@gnu.org (Cuirass) writes:
> 
> > The build nsq.powerpc64le-linux for specification master 
> > is broken. You
> > can find the detailed information about this build  > href="https://ci.guix.gnu.org/build/2674716/details;>here.
> >
> > https://ci.guix.gnu.org/build/2674716/details
> 
> Excerpt:

> 
> Cuirass says the new failure was a result from
> https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=0083a2265960f8228112c36e0d10eb974ff9d1f1..e4397a32ac81d0b23b168df27424001a7d20aee7;
> I suppose the test is flaky.
> 
> -- 
> Thanks,
> Maxim

I sent it through again and it passed the tests

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67432: actionlint.powerpc64le-linux is broken (test failure)

[Efraim Flashner]

On Fri, Nov 24, 2023 at 08:51:13AM -0500, Maxim Cournoyer wrote:
> Hello,
> 
> cuir...@gnu.org (Cuirass) writes:
> 
> > The build actionlint.powerpc64le-linux for specification 
> > master is
> > broken. You can find the detailed information about this build  > href="https://ci.guix.gnu.org/build/2674865/details;>here.
> >
> > https://ci.guix.gnu.org/build/2674865/details
> 
> Excerpt:
> 

> 
> This one also was a result of
> https://git.savannah.gnu.org/cgit/guix.git/log/?qt=range=0083a2265960f8228112c36e0d10eb974ff9d1f1..e4397a32ac81d0b23b168df27424001a7d20aee7.
> 
> -- 
> Thanks,
> Maxim

I sent it through again and it passed

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#67156: Build insight-toolkit.x86_64-linux.skylake on master is broken.

[Efraim Flashner]

On Mon, Nov 13, 2023 at 11:21:53PM -0500, Maxim Cournoyer wrote:
> Hello!
> 
> Apparently, the recently pushed LLVM/Clang update broke this package,
> according to the Cuirass notifications:
> 
> cuir...@gnu.org (Cuirass) writes:
> 
> > The build insight-toolkit.x86_64-linux.skylake for specification 
> > master is
> > broken. You can find the detailed information about this build  > href="https://ci.guix.gnu.org/build/2602507/details;>here.
> >
> > https://ci.guix.gnu.org/build/2602507/details
> 
> I haven't investigated it, but this appears to be where it fails:
> 
> --8<---cut here---start->8---
> cd /tmp/guix-build-insight-toolkit-4.12.2.drv-0/build/Modules/Video/Core/src 
> && 
> /gnu/store/q2qlfc0997p1zfqcil8c5raklqkq1214-tuning-compiler-skylake/bin/c++  
> -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/build/Modules/ThirdParty/KWIML/src
>  
> -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/ThirdParty/KWIML/src
>  
> -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/build/Modules/ThirdParty/KWSys/src
>  
> -I/gnu/store/av2gd2fdg2llv3rpwlacskc1v2mh44c5-vxl-1.18.0/include/vxl/v3p/netlib
>  -I/gnu/store/av2gd2fdg2llv3rpwlacskc1v2mh44c5-vxl-1.18.0/include/vxl/vcl 
> -I/gnu/store/av2gd2fdg2llv3rpwlacskc1v2mh44c5-vxl-1.18.0/include/vxl/core 
> -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/ThirdParty/VNLInstantiation/include
>  -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/build/Modules/Core/Common 
> -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Core/Common/include
>  
> -I/tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Video/Core/include
>  -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch 
> -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings 
> -funit-at-a-time -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof 
> -Woverloaded-virtual -Wstrict-null-sentinel  -O2 -g -DNDEBUG -fPIC -MD -MT 
> Modules/Video/Core/src/CMakeFiles/ITKVideoCore.dir/itkTemporalProcessObject.cxx.o
>  -MF CMakeFiles/ITKVideoCore.dir/itkTemporalProcessObject.cxx.o.d -o 
> CMakeFiles/ITKVideoCore.dir/itkTemporalProcessObject.cxx.o -c 
> /tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Video/Core/src/itkTemporalProcessObject.cxx
> In file included from 
> /tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Numerics/Polynomials/src/itkMultivariateLegendrePolynomial.cxx:18:
> /tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Numerics/Polynomials/include/itkMultivariateLegendrePolynomial.h:145:3:
>  error: ISO C++17 does not allow dynamic exception specifications
>   145 |   throw ( CoefficientVectorSizeMismatch );
>   |   ^
> /tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Numerics/Polynomials/include/itkMultivariateLegendrePolynomial.h:148:3:
>  error: ISO C++17 does not allow dynamic exception specifications
>   148 |   throw ( CoefficientVectorSizeMismatch );
>   |   ^
> /tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Numerics/Polynomials/src/itkMultivariateLegendrePolynomial.cxx:126:1:
>  error: ISO C++17 does not allow dynamic exception specifications
>   126 | throw ( MultivariateLegendrePolynomial::CoefficientVectorSizeMismatch 
> )
>   | ^
> /tmp/guix-build-insight-toolkit-4.12.2.drv-0/InsightToolkit-4.12.2/Modules/Numerics/Polynomials/src/itkMultivariateLegendrePolynomial.cxx:149:1:
>  error: ISO C++17 does not allow dynamic exception specifications
>   149 | throw ( MultivariateLegendrePolynomial::CoefficientVectorSizeMismatch 
> )
>   | ^
> make[2]: *** 
> [Modules/Numerics/Polynomials/src/CMakeFiles/ITKPolynomials.dir/build.make:79:
>  
> Modules/Numerics/Polynomials/src/CMakeFiles/ITKPolynomials.dir/itkMultivariateLegendrePolynomial.cxx.o]
>  Error 1
> make[2]: Leaving directory 
> '/tmp/guix-build-insight-toolkit-4.12.2.drv-0/build'
> make[1]: *** [CMakeFiles/Makefile2:5804: 
> Modules/Numerics/Polynomials/src/CMakeFiles/ITKPolynomials.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> --8<---cut here---end--->8---

It looks like insight-toolkit-4.12 was failing for a while and now the
optimized versions were starting to fail too.  I added a configure-flag
to insight-toolkit-4.12 to specifically used C++14 and then the build
succeeded.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#29644: gcc-objc is unusable without its 'gcc' executable

[Efraim Flashner]

On Sat, Sep 02, 2023 at 11:01:44PM +0200, Vivien Kraus via Bug reports for GNU 
Guix wrote:
> Hello!
> 
> I would like to learn and play with gnustep with objective-C, but it
> seems like GCC does not come with objective-C in Guix.
> 
> I don’t know much about GCC or how Guix packages it. There is an early
> comment by Ricardo Wurmus:
> 
> > The fix here is to patch “lang-spec.h”, so that it does not limit the
> > gcc executable to the configured set of languages.  This way we will
> > be
> > able to use the same gcc executable with different languages.
> 
> The source of gcc-objc has a file named gcc-12.3.0/gcc/objc/lang-
> specs.h that claims to be included as a static array literal, but I
> don’t know what the rest of this citation means.

I've appended a diff of the lib output of gcc and gcc-objc. According to
du adding objc support to regular gcc would increase the lib output by
368K. I think our best option is to move forward with adding objc/objc++
as languages which gcc simply provides without needing a separate
package.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
1c1
< /gnu/store/sxnv230gv2mj5x9v3gfadw118gkl2rcf-gcc-10.5.0-lib/
---
> /gnu/store/1p8hc8mrigismnndycwih2k2015v0z1q-gcc-objc-10.5.0-lib/
78a79,89
> │   │   │   ├── objc
> │   │   │   │   ├── message.h
> │   │   │   │   ├── NXConstStr.h
> │   │   │   │   ├── objc-decls.h
> │   │   │   │   ├── objc-exception.h
> │   │   │   │   ├── objc.h
> │   │   │   │   ├── objc-sync.h
> │   │   │   │   ├── Object.h
> │   │   │   │   ├── Protocol.h
> │   │   │   │   ├── runtime.h
> │   │   │   │   └── thr.h
645a657,661
> │   ├── libobjc.a
> │   ├── libobjc.la
> │   ├── libobjc.so -> libobjc.so.4.0.0
> │   ├── libobjc.so.4 -> libobjc.so.4.0.0
> │   ├── libobjc.so.4.0.0
682c698
< │   └── gcc-10.5.0
---
> │   └── gcc-objc-10.5.0
697c713
< 34 directories, 661 files
---
> 35 directories, 676 files


signature.asc
Description: PGP signature

bug#66553: bug#66576: Request for merging "rust-team" branch

[Efraim Flashner]

On Wed, Oct 18, 2023 at 12:56:57AM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Efraim Flashner  skribis:
> 
> > IMO rust-team branch is ready to merge. We've updated rust to 1.70,
> > librsvg to 2.56.4 and many new and updated packages. We've added a phase
> > to the cargo-build-system to fail if it detects pre-built files and
> > we've set the cargo-build-system to skip the test phase by default,
> > allowing us to make sure that the packages have the correct inputs. With
> > these changes I've gotten 100% of the packages built using the
> > cargo-build-system to build successfully.
> 
> The ‘rust-team’ jobset at https://ci.guix.gnu.org is now at 78%, which
> is actually better than ‘master’ (74%).  There are still ~6K
> aarch64-linux builds queued but from the numbers it seems ready to be
> merged.

I'm going to rebase it on master to get the changes over the past month
or so, including the qt-team branch, and let that build out a bit before
merging it.

> (Besides, I’m curious about the answers to the questions Maxim asked
> earlier in this thread regarding skipping tests.)

I'm going to refer everyone back to the RFC thread on guix-devel to try
to keep everything in one place. I've reverted it for now while we
discuss it further.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66553: bug#66576: Request for merging "rust-team" branch

[Efraim Flashner]

On Tue, Oct 17, 2023 at 11:41:11AM -0400, Maxim Cournoyer wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> 
> > IMO rust-team branch is ready to merge. We've updated rust to 1.70,
> > librsvg to 2.56.4 and many new and updated packages. We've added a phase
> > to the cargo-build-system to fail if it detects pre-built files and
> > we've set the cargo-build-system to skip the test phase by default,
> > allowing us to make sure that the packages have the correct inputs. With
> > these changes I've gotten 100% of the packages built using the
> > cargo-build-system to build successfully.
> 
> This sounds good except I don't understand how disabling the tests by
> default help to "make sure that the packages have the correct inputs" ?
> 
> You've explained the rationale here:
> <https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00182.html>,
> saying we sometimes use a newer Rust than the package tests are
> expecting; how does it work in the Rust world?  Don't they always build
> even older versions against the most recent compiler?  What about the
> test suites then?  Are these not typically run by users/distributions?

I've copied your questions to the thread above and answered them there
so we can keep the discussion in one place.

> For one thing the 'guix lint' command would need to be told that
> cargo-build-system has #:tests? set to #f by default to not warn without
> reasons that '#:tests? #t' is unnecessary.

I've reverted it for now so we can get the rust-team branch merged and
continue discussing if this is a good idea or not.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66553: Request for merging "rust-team" branch

[Efraim Flashner]

IMO rust-team branch is ready to merge. We've updated rust to 1.70,
librsvg to 2.56.4 and many new and updated packages. We've added a phase
to the cargo-build-system to fail if it detects pre-built files and
we've set the cargo-build-system to skip the test phase by default,
allowing us to make sure that the packages have the correct inputs. With
these changes I've gotten 100% of the packages built using the
cargo-build-system to build successfully.

We're looking forward to this merge so we can continue bumping the rust
version, work on cross-compilation and try to reduce the number of
packages which skip the build phase entirely.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#66553: Request to merge rust-team

[Efraim Flashner]

On Sun, Oct 15, 2023 at 02:30:07PM +0200, Csepp wrote:
> 
> Efraim Flashner  writes:
> 
> > [[PGP Signed Part:Undecided]]
> > IMO rust-team branch is ready to merge. We've updated rust to 1.70,
> > librsvg to 2.56.4 and many new and updated packages. We've added a
> > phase
> > to the cargo-build-system to fail if it detects pre-built files and
> > we've set the cargo-build-system to skip the test phase by default,
> > allowing us to make sure that the packages have the correct inputs.
> > With
> > these changes I've gotten 100% of the packages built using the
> > cargo-build-system to build successfully.
> >
> > We're looking forward to this merge so we can continue bumping the
> > rust
> > version, work on cross-compilation and try to reduce the number of
> > packages which skip the build phase entirely.
> 
> Is the new build system still being worked on?

I haven't started working on integrating it yet.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66553: Request to merge rust-team

[Efraim Flashner]

IMO rust-team branch is ready to merge. We've updated rust to 1.70,
librsvg to 2.56.4 and many new and updated packages. We've added a phase
to the cargo-build-system to fail if it detects pre-built files and
we've set the cargo-build-system to skip the test phase by default,
allowing us to make sure that the packages have the correct inputs. With
these changes I've gotten 100% of the packages built using the
cargo-build-system to build successfully.

We're looking forward to this merge so we can continue bumping the rust
version, work on cross-compilation and try to reduce the number of
packages which skip the build phase entirely.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#66306: Too many services depend on ‘networking’

[Efraim Flashner]

On Mon, Oct 02, 2023 at 02:24:49PM +0200, Ludovic Courtès wrote:
> I believe too many services depend on ‘networking’ for no good reason.
> There’s a good discussion of the problem at:
> 
>   https://systemd.io/NETWORK_ONLINE/

This exactly! How much 'network' counts as 'good enough' to start the
next services?

> For example, bitlbee, ntpd, hurd-vm, and avahi-daemon all depend on
> ‘networking’.
> 
> Is it always justified?  For example, avahi-daemon unconditionally
> listens on 0.0.0.0 and [::], so there’s no need to depend on
> ‘networking’.
> 
> --8<---cut here---start->8---
> $ sudo netstat -tupla |grep avahi
> udp0  0 0.0.0.0:mdns0.0.0.0:* 
>   650/avahi-daemon: r 
> udp6   0  0 [::]:mdns   [::]:*
>   650/avahi-daemon: r 
> --8<---cut here---end--->8---
> 
> In other cases, such as bitlbee, it’s not as obvious because users can
> specify different addresses to listen to, and those might depend on
> ‘networking’ to set up the corresponding interfaces.
> 
> Thoughts?  Should we do an audit of these?

Probably should do an audit. For bitlbee, I guess the question is how
does it respond to changes in networking? If it comes up when only
loopback is up will it need to be restarted once an actual network shows
up?

For ntpd, I've had trouble with openntpd coming up while only loopback
was active and then I'd have to restart it for it to get the initial big
jump when starting.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#50015: Rust packages are not reproducible

[Efraim Flashner]

On Tue, Oct 03, 2023 at 11:30:15PM -0400, Maxim Cournoyer wrote:
> Hello,
> 
> Ludovic Courtès  writes:
> 
> > Hello!
> >
> > Efraim Flashner  skribis:
> >
> >> I tried patching this a couple of ways, but it looks like the best
> >> option is going to be a 'patch-and-repack phase after 'install. the
> >> .crate file is really a gzip tarball, and I suspect that each time we
> >> run 'cargo ' the timestamp gets updated.
> >
> > So that ‘Cargo.toml’ file is not something taken from the build tree?
> > In that case we could reset the timestamp before the tarball is
> > created.  But otherwise yeah, patch’n’repack.
> 
> A better solution would be to have cargo honor SOURCE_DATE_EPOCH,
> perhaps?  They'd probably accept such an improvement upstream.

That'd be an interesting idea, having 'cargo package' set the timestamp
of all the files to SOURCE_DATE_EPOCH.  I guess I can look into how
feasible that would be and if they'd be likely to accept a change like
that.

I have a local patch which unpacks, resets the timestamp and repacks the
crate. I'll definitely push it to the rust-team branch before the next
merge.

With it I introduced an issue where the 'package phase would repack all
the crates, not just the current one, and ran into our
underscore-to-dash naming convention causing issues with how I'm reusing
the filename to work on the crate. I'll fix that, probably by only
repacking the current crate instead of all crates in the environment.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Fri, Sep 29, 2023 at 10:46:07AM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner  skribis:
> 
> > On Mon, Sep 25, 2023 at 04:46:57PM +0200, Ludovic Courtès wrote:
> 
> [...]
> 
> >> >   
> >> > /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/bin/../lib/julia/liblapack.so:
> >> >  undefined symbol: dsfrk_64_
> >> 
> >> The ‘_64’ suffix is added by a patch in this very series, that adds
> >> ‘SYMBOLSUFFIX=64_’ to ‘openblas-ilp64’.
> >> 
> >> I don’t know what the rationale was for that configuration change, but
> >> this is a good area of investigation.
> >> 
> >> Efraim, WDYT?
> >
> > the SYMBOLSUFFIX change seems to be standard across other distributions,
> > and in fact there seem to be packages out there which rely on it
> > directly.
> >
> > Looking at this error specifically and also the pcre2-8 errors we get
> > during the 'test phase for julia, it seems the suggested fix is to build
> > those libraries with julia. So we'd want to replace the pcre2 and the
> > lapack libraries in the julia sources (for pcre2 for all the
> > architectures, for lapack for x86_64 specifically) and let julia build
> > and link to them during the build phase.
> 
> That would seem like a step backwards though, no?  Usually we prefer to
> unbundle things.

I tried it with inserting our source for pcre2 and adding a patch to fix
the configure phase of pcre2, we ended up with other failures, so I
think we're best off with what we have now.

> Actually, why does liblapack.so end up in Julia itself, as opposed to
> just linking to libopenblas.so?

Julia links to both (open)blas and to lapack. If we build openblas so
that it also provides lapack, or use (c)blas from lapack, then we can
use only one or the other. I suppose in theory it should be possible to
tell julia that libopenblas64_.so is really lapack and to use that for
both of them. I don't know how well that would work though.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Wed, Sep 20, 2023 at 05:57:30PM +0200, Simon Tournier wrote:
> Hi Efraim,
> 
> Applying the patch is done in v3 of #66030.
> 
> https://issues.guix.gnu.org/issue/66030
> 
> and QA processed all.
> 
> https://qa.guix.gnu.org/issue/66030/
> 
> It is almost good except one strong annoyance [1]@
> 
> --8<---cut here---start->8---
> Singular value decomposition |   57 57  5.0s
> Hermitian: Error During Test at 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:12
>   Got exception outside of a @test
>   could not load symbol "dsfrk_64_":
>   
> /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/bin/../lib/julia/liblapack.so:
>  undefined symbol: dsfrk_64_
>   Stacktrace:
> [1] sfrk!(transr::Char, uplo::Char, trans::Char, alpha::Float64, 
> A::Matrix{Float64}, beta::Float64, C::Vector{Float64})
>   @ GenericLinearAlgebra.LAPACK2 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/src/lapack.jl:523
> [2] Ac_mul_A_RFP(A::Matrix{Float64}, uplo::Symbol)
>   @ GenericLinearAlgebra 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/src/rectfullpacked.jl:77
> [3] macro expansion
>   @ 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:13
>  [inlined]
> [4] macro expansion
>   @ 
> /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/share/julia/stdlib/v1.8/Test/src/Test.jl:1360
>  [inlined]
> [5] macro expansion
>   @ 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:13
>  [inlined]
> [6] macro expansion
>   @ 
> /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/share/julia/stdlib/v1.8/Test/src/Test.jl:1436
>  [inlined]
> [7] macro expansion
>   @ 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:7
>  [inlined]
> [8] macro expansion
>   @ 
> /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/share/julia/stdlib/v1.8/Test/src/Test.jl:1360
>  [inlined]
> [9] top-level scope
>   @ 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:7
>[10] include(fname::String)
>   @ Base.MainInclude ./client.jl:476
>[11] top-level scope
>   @ 
> /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/runtests.jl:10
>[12] include(mod::Module, _path::String)
>   @ Base ./Base.jl:419
>[13] exec_options(opts::Base.JLOptions)
>   @ Base ./client.jl:303
>[14] _start()
>   @ Base ./client.jl:522
> --8<---cut here---end--->8---
> 
> Any idea?  I have no idea and it is blocking the merge because ~20
> packages are then broken.  Well, if we have no idea, I will push the fix
> for “Julia is slow” and we will fix later these ~20 failures.  WDYT?

This one was easy, I just upgraded it to 0.3.0. Then I had to adjust
julia-bandedmatrices and julia-arraylayouts and everything looks good.
Except for julia-optim.

I spent a few hours trying to get Julia to use accept '64' instead of
'64_' for SYMBOLSUFFIX and even packaged a newer version of lapack but I
wasn't able to force the issue. Ultimately any other  julia packages
need to use libblastrampoline to determine whether to use openblas or
lapack.

Patches pushed, issue closed. I even tested the original reproducer from
the first email.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Mon, Sep 25, 2023 at 04:46:57PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Simon Tournier  skribis:
> 
> > It is almost good except one strong annoyance [1]@
> >
> > Singular value decomposition |   57 57  5.0s
> > Hermitian: Error During Test at 
> > /gnu/store/zkx6p7kz3m5k5w5iy0l1d09b2n8b0ib3-julia-genericlinearalgebra-0.2.5/share/julia/loadpath/GenericLinearAlgebra/test/rectfullpacked.jl:12
> >   Got exception outside of a @test
> >   could not load symbol "dsfrk_64_":
> >   
> > /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3/bin/../lib/julia/liblapack.so:
> >  undefined symbol: dsfrk_64_
> 
> The ‘_64’ suffix is added by a patch in this very series, that adds
> ‘SYMBOLSUFFIX=64_’ to ‘openblas-ilp64’.
> 
> I don’t know what the rationale was for that configuration change, but
> this is a good area of investigation.
> 
> Efraim, WDYT?

the SYMBOLSUFFIX change seems to be standard across other distributions,
and in fact there seem to be packages out there which rely on it
directly.

Looking at this error specifically and also the pcre2-8 errors we get
during the 'test phase for julia, it seems the suggested fix is to build
those libraries with julia. So we'd want to replace the pcre2 and the
lapack libraries in the julia sources (for pcre2 for all the
architectures, for lapack for x86_64 specifically) and let julia build
and link to them during the build phase.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Sun, Aug 20, 2023 at 10:53:44PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Friendly ping.  :-)
> 
>   https://issues.guix.gnu.org/63986
> 
> Ludo’.
> 
> Ludovic Courtès  skribis:
> 
> > Hi there!
> >
> > What’s the status?  Sounds like we have a couple of fixes already.
> >
> > Maybe you can submit one of them to guix-patc...@gnu.org so qa.guix can
> > pick it up.  And if one of them is more intrusive (more rebuilds), then
> > submit it separately so it gets merged later?  How does that sound?
> >
> > Ludo’.

I've attached a diff to adjust openblas64 and to use it for x86_64 in
julia. I don't know if it's faster than the current openblas.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff --git a/gnu/packages/julia.scm b/gnu/packages/julia.scm
index ba54175822..8ba2b480ce 100644
--- a/gnu/packages/julia.scm
+++ b/gnu/packages/julia.scm
@@ -269,7 +269,10 @@ (define-public julia
(substitute* (jlpath "nghttp2")
  (((from "libnghttp2")) (to "libnghttp2" "libnghttp2")))
(substitute* (jlpath "OpenBLAS")
- (((from "libopenblas")) (to "openblas" "libopenblas")))
+ (((from "libopenblas"))
+  ,@(if (target-x86-64?)
+  `((to "openblas" "libopenblas64_" "libopenblas"))
+  `((to "openblas" "libopenblas")
(substitute* (jlpath "OpenLibm")
  (((from "libopenlibm")) (to "openlibm" "libopenlibm")))
(substitute* (jlpath "PCRE2")
@@ -479,12 +482,13 @@ (define-public julia
  "NO_GIT=1" ; build from release tarball.
  "USE_GPL_LIBS=1"   ; proudly
 
- ,@(if (target-aarch64?)
- `("USE_BLAS64=0")
- '())
-
- "LIBBLAS=-lopenblas"
- "LIBBLASNAME=libopenblas"
+ ,@(if (target-x86-64?)
+ `("USE_BLAS64=1"
+   "LIBBLAS=-lopenblas64_"
+   "LIBBLASNAME=libopenblas64_")
+ `("USE_BLAS64=0"
+   "LIBBLAS=-lopenblas"
+   "LIBBLASNAME=libopenblas"))
 
  (string-append "UTF8PROC_INC="
 (assoc-ref %build-inputs "utf8proc")
@@ -513,7 +517,9 @@ (define-public julia
("llvm" ,llvm-julia)
("mbedtls-apache" ,mbedtls-apache)
("mpfr" ,mpfr)
-   ("openblas" ,openblas)
+   ,@(if (target-x86-64?)
+ `(("openblas" ,openblas-ilp64))
+ `(("openblas" ,openblas)))
("openlibm" ,openlibm)
("p7zip" ,p7zip)
("pcre2" ,pcre2)
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index f5a2181905..2d3ce41cb7 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -4645,7 +4645,9 @@ (define-public openblas-ilp64
 (arguments
  (substitute-keyword-arguments (package-arguments openblas)
((#:make-flags flags #~'())
-#~(append (list "INTERFACE64=1" "LIBNAMESUFFIX=ilp64")
+#~(append (list "INTERFACE64=1"
+"SYMBOLSUFFIX=64_"
+"LIBPREFIX=libopenblas64_")
  #$flags
 (synopsis "Optimized BLAS library based on GotoBLAS (ILP64 version)")
 (license license:bsd-3)))


signature.asc
Description: PGP signature

bug#65684: kaidan package is broken and does not start

[Efraim Flashner]

On Fri, Sep 01, 2023 at 02:00:11PM -0500, bdju via Bug reports for GNU Guix 
wrote:
> I am running Guix System and using Sway (Wayland).
> When trying to launch Kaidan from a shell I get the following errors:
> 13:58:25.845|qt.qpa.plugin|W|Could not find the Qt platform plugin "wayland" 
> in ""
> 13:58:26.210|default|D|QT_QUICK_CONTROLS_STYLE not set, setting to 
> "org.kde.desktop"
> 13:58:26.704|default|W|QQmlApplicationEngine failed to load component
> 13:58:26.704|default|W|qrc:/qml/main.qml:90:29: Type RosterPage unavailable
> 13:58:26.704|default|W|qrc:/qml/RosterPage.qml:50:2: Type 
> RosterAddContactSheet unavailable
> 13:58:26.704|default|W|qrc:/qml/elements/RosterAddContactSheet.qml:84:3: Type 
> Controls.TextArea unavailable
> 13:58:26.704|default|W|file:///gnu/store/y7lkx97ylj0aidzsp06b0455kr300b1i-qqc2-desktop-style-5.108.0/lib/qt5/qml/QtQuick/Controls.2/org.kde.desktop/TextArea.qml:15:1:
>  module "org.kde.sonnet" is not installed
> 
> Based on discussion in IRC it sounds like some inputs are missing,
> sonnet and kdeclarative
> Other users were able to reproduce this issue on their machine.
> 
> Discussion: https://logs.guix.gnu.org/guix/2023-09-01.log#203513

Fixed in c535374ef4f6c81db94003c626d2464b9c13a867

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#65714: guix-copy 32-bit integer limit

[Efraim Flashner]

On Mon, Sep 04, 2023 at 11:55:19PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner  skribis:
> 
> > `guix copy` seems unable to deal with store items larger than
> > 2**32 bytes (about 4.3 GiB).
> >
> > (ins)efraim@3900XT ~$ guix copy --from=192.168.1.196 
> > /gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
> > retrieving 1 store item from '192.168.1.196'...
> > guix copy: error: implementation cannot deal with > 32-bit integers
> >
> > (ins)efraim@3900XT ~$ ssh 192.168.1.196 du -sch 
> > /gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
> > 7.5G/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
> > 7.5Gtotal
> 
> Hmm that vaguely rings a bell, but we’ve had things like texlive-texmf
> from the start and I think we’ve definitely been able to fetch them via
> the offload/copy code.
> 
> Are you able to copy other store items from that host?  Could there be
> another issue leading to a bogus diagnostic?

ins)efraim@3900XT ~$ ssh 192.168.1.196 guix archive --export --recursive 
/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313 | guix 
archive --import
guix archive: error: hash of path 
`/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313' has changed 
from `33df143f9607fcdbd0be68ee7612779d330ac2fefad5749429b8a5b5d2931886' to 
`ea77f319bd62d0c53b132d545e44a41baea385fd49ad21a94402299b09488085'!
Backtrace:
  13 (primitive-load "/home/efraim/.config/guix/current/bin/…")
In guix/ui.scm:
   2323:7 12 (run-guix . _)
  2286:10 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/status.scm:
859:3  9 (_)
839:4  8 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   659:37  6 (thunk)
   1298:8  5 (call-with-build-handler # …)
  1719:22  4 (import-paths # #)
   729:14  3 (process-stderr _ _)
In guix/serialization.scm:
   122:12  2 (write-bytevector #vu8(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 …) …)
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:
In procedure modulo: Wrong type argument in position 1: #

I'm running `guix gc --verify=contents,repair` on the other machine now
to make sure there's nothing wrong with the archive item.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#65714: guix-copy 32-bit integer limit

[Efraim Flashner]

`guix copy` seems unable to deal with store items larger than
2**32 bytes (about 4.3 GiB).

(ins)efraim@3900XT ~$ guix copy --from=192.168.1.196 
/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
retrieving 1 store item from '192.168.1.196'...
guix copy: error: implementation cannot deal with > 32-bit integers

(ins)efraim@3900XT ~$ ssh 192.168.1.196 du -sch 
/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
7.5G/gnu/store/0f8pgl9cyh8bknl50nw6yj9wykzm6ymc-texlivetexmf-20230313
7.5Gtotal

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#64981: GTK4 applications broken (missing libGLESv2)

[Efraim Flashner]

On Tue, Aug 01, 2023 at 12:06:31AM +0200, Csepp wrote:
> for example:
> $ transmission-gtk
> Couldn't open libGLESv2.so.2: libGLESv2.so.2
> 
> I get the same error with Tuba.  It likely affects other applications.
> 
> Guix commit: 182be30
> System: x86_64

I've been getting this too, I'm "glad" to see I'm not the only one.  If
I set GSK_RENDERER=cairo (the fallback renderer) then I can launch gtk4
applications.

(ins)efraim@pbp ~$ guix shell mesa-utils -- glxinfo | grep 'profile version 
string'
OpenGL core profile version string: 3.1 Mesa 23.1.4
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 23.1.4
(ins)efraim@pbp ~$ guix shell mesa-utils -- eglinfo | grep -B2 -A1 'version 
string'
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
--
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES
--
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs: OpenGL OpenGL_ES

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#64410: Acknowledgement (Request for merging "rust-team" branch)

[Efraim Flashner]

Branch merged

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#64410: Request for merging "rust-team" branch

[Efraim Flashner]

As I see it the rust-team branch is ready for merging. It updates rust
to 1.68 and updates a bunch of crates.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Fri, Jun 23, 2023 at 03:23:17PM +0200, Simon Tournier wrote:
> Hi Efraim,
> 
> On Fri, 23 Jun 2023 at 12:16, Efraim Flashner  wrote:
> 
> > It should be, but julia fails the precompile stage with openblas-ilp64
> >
> > Precompilation complete. Summary:
> > Total ─── 1006.632176 seconds
> > Generation ── 690.274180 seconds 68.5726%
> > Execution ─── 316.357997 seconds 31.4274%
> >
> > signal (15): Terminated
> > in expression starting at none:0
> > unknown function (ip: 0xf4d81b24)
> > unknown function (ip: 0xf4ed10bb)
> > unknown function (ip: 0xf4eda16f)
> > _ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE at 
> > /gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
> > (unknown line)
> > _ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at 
> > /gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
> > (unknown line)
> > _ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at 
> > /gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
> > (unknown line)
> > _ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at 
> > /gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
> > (unknown line)
> > operator() at 
> > /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/aotcompile.cpp:580 
> > [inlined]
> > jl_dump_native_impl at 
> > /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/aotcompile.cpp:592
> > jl_write_compiler_output at 
> > /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/precompile.c:94
> > ijl_atexit_hook at 
> > /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/init.c:207
> > jl_repl_entrypoint at 
> > /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/jlapi.c:720
> > main at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/cli/loader_exe.c:59
> > __libc_start_call_main at 
> > /gnu/store/a19xbynxc3sg25xpkwmx7g0mdl7g31hx-glibc-2.35/lib/libc.so.6 
> > (unknown line)
> > __libc_start_main at 
> > /gnu/store/a19xbynxc3sg25xpkwmx7g0mdl7g31hx-glibc-2.35/lib/libc.so.6 
> > (unknown line)
> > _start at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/bin/julia 
> > (unknown line)
> > unknown function (ip: (nil))
> > Allocations: 145655328 (Pool: 145582643; Big: 72685); GC: 120
> > *** This error is usually fixed by running `make clean`. If the error 
> > persists, try `make cleanall`. ***
> > make[1]: *** [sysimage.mk:89: 
> > /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/lib/julia/sys-o.a] Error 1
> > make[1]: Leaving directory '/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3'
> > make: *** [Makefile:88: julia-sysimg-release] Error 2
> 
> Using my patch, it fails with:
> 
> --8<---cut here---start->8---
> Error in testset OpenBLAS_jll:
> Test Failed at 
> /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/share/julia/stdlib/v1.8/OpenBLAS_jll/test/runtests.jl:16
>   Expression: dlsym(OpenBLAS_jll.libopenblas_handle, #= 
> /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/share/julia/stdlib/v1.8/OpenBLAS_jll/test/runtests.jl:16
>  =# @blasfunc(openblas_set_num_threads); throw_error = false) != nothing
>Evaluated: nothing != nothing
> ERROR: LoadError: Test run finished with errors
> in expression starting at 
> /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/test/runtests.jl:93
> --8<---cut here---end--->8---

Mine was on aarch64

> Well, I am still missing why the expression
> 
>   dlsym(OpenBLAS_jll.libopenblas_handle,
>   #= 
> /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/share/julia/stdlib/v1.8/OpenBLAS_jll/test/runtests.jl:16
>  =#
>   @blasfunc(openblas_set_num_threads); throw_error = false)
> 
> is evaluated to nothing.  Any idea?

It is something about the wrong internal interface in openblas, I don't
remember exactly what that error came from.

Try with the attached diff.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff --git a/gnu/packages/julia.scm b/gnu/packages/julia.scm
index ba54175822..8ba2b480ce 100644
--- a/gnu/packages/julia.scm
+++ b/gnu/packages/julia.scm
@@ -269,7 +269,10 @@ (define-public julia
(substitute* (jlpath "nghttp2")
  (((from "libnghttp2")) (to "libnghttp2" "libnghttp2")))
(substitute* (jlpath "OpenBLAS")
- (((from "libopenblas")) (to "openblas" "libopenblas")))
+ (((from "libopenblas&q

bug#63986: Julia is very slow

[Efraim Flashner]

On Fri, Jun 23, 2023 at 11:09:44AM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Simon Tournier  skribis:
> 
> > + ,@(if (target-x86-64?)
> > + `("USE_BLAS64=1"
> > +   "LIBBLAS=-lopenblas_ilp64"
> > +   "LIBBLASNAME=libopenblas_ilp64")
> > + `("LIBBLAS=-lopenblas"
> > +   "LIBBLASNAME=libopenblas"))
> >  
> >   (string-append "UTF8PROC_INC="
> >  (assoc-ref %build-inputs "utf8proc")
> > @@ -513,7 +517,9 @@ (define-public julia
> > ("llvm" ,llvm-julia)
> > ("mbedtls-apache" ,mbedtls-apache)
> > ("mpfr" ,mpfr)
> > -   ("openblas" ,openblas)
> > +   ,@(if (target-x86-64?)
> > + `(("openblas" ,openblas-ilp64))
> > + `(("openblas" ,openblas)))
> 
> Should it be ‘target-64bit?’ instead?

It should be, but julia fails the precompile stage with openblas-ilp64

Precompilation complete. Summary:
Total ─── 1006.632176 seconds
Generation ── 690.274180 seconds 68.5726%
Execution ─── 316.357997 seconds 31.4274%

signal (15): Terminated
in expression starting at none:0
unknown function (ip: 0xf4d81b24)
unknown function (ip: 0xf4ed10bb)
unknown function (ip: 0xf4eda16f)
_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE at 
/gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
(unknown line)
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE at 
/gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
(unknown line)
_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE at 
/gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
(unknown line)
_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE at 
/gnu/store/wa28l476c1bfshfiqcqbmk75zr8ml152-llvm-13.0.1/lib/libLLVM-13jl.so 
(unknown line)
operator() at 
/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/aotcompile.cpp:580 [inlined]
jl_dump_native_impl at 
/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/aotcompile.cpp:592
jl_write_compiler_output at 
/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/precompile.c:94
ijl_atexit_hook at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/init.c:207
jl_repl_entrypoint at 
/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/src/jlapi.c:720
main at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/cli/loader_exe.c:59
__libc_start_call_main at 
/gnu/store/a19xbynxc3sg25xpkwmx7g0mdl7g31hx-glibc-2.35/lib/libc.so.6 (unknown 
line)
__libc_start_main at 
/gnu/store/a19xbynxc3sg25xpkwmx7g0mdl7g31hx-glibc-2.35/lib/libc.so.6 (unknown 
line)
_start at /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/bin/julia (unknown 
line)
unknown function (ip: (nil))
Allocations: 145655328 (Pool: 145582643; Big: 72685); GC: 120
*** This error is usually fixed by running `make clean`. If the error persists, 
try `make cleanall`. ***
make[1]: *** [sysimage.mk:89: 
/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/lib/julia/sys-o.a] Error 1
make[1]: Leaving directory '/tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3'
make: *** [Makefile:88: julia-sysimg-release] Error 2

> Thumbs up for finding the solution!
> 
> Ludo’.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Thu, Jun 22, 2023 at 08:47:48PM +0200, Simon Tournier wrote:
> Hi,
> 
> On Thu, 22 Jun 2023 at 19:25, Efraim Flashner  wrote:
> 
> > (ins)efraim@3900XT ~/workspace/guix$ cat 
> > /gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib/pkgconfig/openblas.pc
> > libdir=/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib
> > includedir=/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/include
> > openblas_config= USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 NO_CBLAS= 
> > NO_LAPACK= NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP= generic MAX_THREADS=128
> > version=0.3.20
> > extralib=-lm -lpthread -lgfortran -lm -lpthread -lgfortran
> > Name: openblas
> > Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 
> > BSD version
> > Version: ${version}
> > URL: https://github.com/xianyi/OpenBLAS
> > Libs: -L${libdir} -lopenblas
> > Libs.private: ${extralib}
> > Cflags: -I${includedir}
> >
> > Looks like it should be "LIBBLAS=-lopenblas"
> 
> I propose to tweak openblas-ilp64.  Currently it looks like:
> 
> --8<---cut here---start->8---
> $ tree $(guix build openblas-ilp64)/lib
> /gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib
> ├── cmake
> │   └── openblas
> │   ├── OpenBLASConfig.cmake
> │   └── OpenBLASConfigVersion.cmake
> ├── libopenblas_ilp64p-r0.3.20.so
> ├── libopenblas_ilp64.so -> libopenblas_ilp64p-r0.3.20.so
> ├── libopenblas_ilp64.so.0 -> libopenblas_ilp64p-r0.3.20.so
> └── pkgconfig
> └── openblas.pc
> --8<---cut here---end--->8---
> 
> which is inconsistent with pkgconfig as you noticed above.  Therefore, I
> am proposing the addition of a symlink of libopenblas_ilp64p.so to
> libopenblas.so.  For instance this attached patch.

I've attached the patch that I've made it to. julia is built with
openblas-ilp64 on 64-bit architectures, openblas-ilp64 has its
configure-flags adjusted to match what other programs are expecting, and
I've also patched python-numpy to use openblas-ilp64 as another test
target.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff --git a/gnu/packages/julia.scm b/gnu/packages/julia.scm
index ba54175822..e96131dfc0 100644
--- a/gnu/packages/julia.scm
+++ b/gnu/packages/julia.scm
@@ -269,7 +269,10 @@ (define-public julia
(substitute* (jlpath "nghttp2")
  (((from "libnghttp2")) (to "libnghttp2" "libnghttp2")))
(substitute* (jlpath "OpenBLAS")
- (((from "libopenblas")) (to "openblas" "libopenblas")))
+ (((from "libopenblas"))
+  ,@(if (target-64bit?)
+  `((to "openblas" "libopenblas64_" "libopenblas"))
+  `((to "openblas" "libopenblas")
(substitute* (jlpath "OpenLibm")
  (((from "libopenlibm")) (to "openlibm" "libopenlibm")))
(substitute* (jlpath "PCRE2")
@@ -479,12 +482,12 @@ (define-public julia
  "NO_GIT=1" ; build from release tarball.
  "USE_GPL_LIBS=1"   ; proudly
 
- ,@(if (target-aarch64?)
- `("USE_BLAS64=0")
- '())
-
- "LIBBLAS=-lopenblas"
- "LIBBLASNAME=libopenblas"
+ ,@(if (target-64bit?)
+ `("USE_BLAS64=1"
+   "LIBBLAS=-lopenblas64_"
+   "LIBBLASNAME=libopenblas64_")
+ `("LIBBLAS=-lopenblas"
+   "LIBBLASNAME=libopenblas"))
 
  (string-append "UTF8PROC_INC="
 (assoc-ref %build-inputs "utf8proc")
@@ -513,7 +516,9 @@ (define-public julia
("llvm" ,llvm-julia)
("mbedtls-apache" ,mbedtls-apache)
("mpfr" ,mpfr)
-   ("openblas" ,openblas)
+   ,@(if (target-64bit?)
+ `(("openblas" ,openblas-ilp64))
+ `(("openblas" ,openblas)))
("openlibm" ,openlibm)
("p7zip" ,p7zip)
("pcre2" ,pcre2)
diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index f5a2181905..2d3ce41cb7 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -4645,7 +4645,9 @@ (define-public openblas-ilp64
 (arguments
  (substitute-keyword-arguments (package-argume

bug#63986: Julia is very slow

[Efraim Flashner]

On Thu, Jun 22, 2023 at 08:47:48PM +0200, Simon Tournier wrote:
> Hi,
> 
> On Thu, 22 Jun 2023 at 19:25, Efraim Flashner  wrote:
> 
> > (ins)efraim@3900XT ~/workspace/guix$ cat 
> > /gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib/pkgconfig/openblas.pc
> > libdir=/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib
> > includedir=/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/include
> > openblas_config= USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 NO_CBLAS= 
> > NO_LAPACK= NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP= generic MAX_THREADS=128
> > version=0.3.20
> > extralib=-lm -lpthread -lgfortran -lm -lpthread -lgfortran
> > Name: openblas
> > Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 
> > BSD version
> > Version: ${version}
> > URL: https://github.com/xianyi/OpenBLAS
> > Libs: -L${libdir} -lopenblas
> > Libs.private: ${extralib}
> > Cflags: -I${includedir}
> >
> > Looks like it should be "LIBBLAS=-lopenblas"
> 
> I propose to tweak openblas-ilp64.  Currently it looks like:
> 
> --8<---cut here---start->8---
> $ tree $(guix build openblas-ilp64)/lib
> /gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib
> ├── cmake
> │   └── openblas
> │   ├── OpenBLASConfig.cmake
> │   └── OpenBLASConfigVersion.cmake
> ├── libopenblas_ilp64p-r0.3.20.so
> ├── libopenblas_ilp64.so -> libopenblas_ilp64p-r0.3.20.so
> ├── libopenblas_ilp64.so.0 -> libopenblas_ilp64p-r0.3.20.so
> └── pkgconfig
> └── openblas.pc
> --8<---cut here---end--->8---
> 
> which is inconsistent with pkgconfig as you noticed above.  Therefore, I
> am proposing the addition of a symlink of libopenblas_ilp64p.so to
> libopenblas.so.  For instance this attached patch.

If we drop the "LIBNAMESUFFIX=ilp64" from openblas-ilp64 then we get
libopenblas.so by default without needing to also symlink it into place.
One benefit of this is we'd be able to easily do some package
transformations between openblas and openblas-ilp64.

Currently I'm looking around online to see what the consensus seems to
be with naming openblas-ilp64, and there seems to be a lot of options.


> From 0c8c7e9371d11972f4a6012ef503ef3057c91364 Mon Sep 17 00:00:00 2001
> Message-Id: 
> <0c8c7e9371d11972f4a6012ef503ef3057c91364.1687459454.git.zimon.touto...@gmail.com>
> From: Simon Tournier 
> Date: Thu, 22 Jun 2023 20:31:26 +0200
> Subject: [PATCH v3 1/2] gnu: openblas-ilp64: Install symlink to libopenblas.
> 
> * gnu/packages/maths.scm (openblas-ilp64)[arguments]: Add phases for
> installing symlink to libopenblas.
> ---
>  gnu/packages/maths.scm | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
> index f5a2181905..5c39ab8b94 100644
> --- a/gnu/packages/maths.scm
> +++ b/gnu/packages/maths.scm
> @@ -4646,7 +4646,13 @@ (define-public openblas-ilp64
>   (substitute-keyword-arguments (package-arguments openblas)
> ((#:make-flags flags #~'())
>  #~(append (list "INTERFACE64=1" "LIBNAMESUFFIX=ilp64")
> - #$flags
> + #$flags))
> +   ((#:phases phases)
> +#~(modify-phases #$phases
> +(add-after 'install 'install-symlink
> +  (lambda _
> +(symlink "libopenblas_ilp64.so"
> + (string-append #$output 
> "/lib/libopenblas.so"
>  (synopsis "Optimized BLAS library based on GotoBLAS (ILP64 version)")
>  (license license:bsd-3)))
>  
> 
> base-commit: 37c2e94cec6cb8b5e0e93e7b6c712c3b187ca5db
> -- 
> 2.38.1
> 

> 
> Then, the patch for Julia looks like the other attached patch.
> 

> From 8563a738703d133b44ae05b91b7448ca56d280b5 Mon Sep 17 00:00:00 2001
> Message-Id: 
> <8563a738703d133b44ae05b91b7448ca56d280b5.1687459454.git.zimon.touto...@gmail.com>
> In-Reply-To: 
> <0c8c7e9371d11972f4a6012ef503ef3057c91364.1687459454.git.zimon.touto...@gmail.com>
> References: 
> <0c8c7e9371d11972f4a6012ef503ef3057c91364.1687459454.git.zimon.touto...@gmail.com>
> From: Simon Tournier 
> Date: Thu, 22 Jun 2023 17:45:50 +0200
> Subject: [PATCH v3 2/2] gnu: julia: Conditionally use openblas with ILP64
>  support.
> 
> Fixes <https://bugs.gnu.org/63986>.
> Reported by Cayetano Santos .
> 
> * gnu/packages/julia.scm (julia)[arguments]<#:make-flags>: Conditionally use
> 64-bit BLAS for x86-64 target.
> [inputs]: Conditionally replace openblas by 

bug#63986: Julia is very slow

[Efraim Flashner]

On Thu, Jun 22, 2023 at 05:52:15PM +0200, Simon Tournier wrote:
> Hi,
> 
> On Thu, 22 Jun 2023 at 15:26, Cayetano Santos via Bug reports for GNU Guix 
>  wrote:
> >> Are we following all instructions here ?
> >>
> >>   
> >> https://docs.julialang.org/en/v1.8/devdocs/build/distributing/#Notes-on-BLAS-and-LAPACK
> 
> [...]
> 
> >   Base.USE_BLAS64
> >
> > gives "true" when running fast. Guix julia gives "false".
> 
> When I try USE_BLAS64=1, then I get:
> 
> --8<---cut here---start->8---
> ┌ Error: No loaded BLAS libraries were built with ILP64 support
> └ @ LinearAlgebra.BLAS 
> /tmp/guix-build-julia-1.8.3.drv-0/julia-1.8.3/usr/share/julia/stdlib/v1.8/LinearAlgebra/src/blas.jl:155
> Quitting.
> --8<---cut here---end--->8---
> 
> And from the documentation above, it reads:
> 
> [...] while on 64-bit architectures, Julia builds OpenBLAS to
> use 64-bit integers (ILP64). It is essential that all Julia
> functions that call BLAS and LAPACK API routines use integers of
> the correct width.
> 
> Well using the patch attached, I get:
> 
> 6.884 ms (2 allocations: 7.63 MiB)
> 
> compared to the previous
> 
> 494.345 ms (2 allocations: 7.63 MiB)
> 
> WDYT about this patch?

(ins)efraim@3900XT ~/workspace/guix$ cat 
/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib/pkgconfig/openblas.pc
libdir=/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/lib
includedir=/gnu/store/v6z5ykkjfzbc72x1x900xflspqc5wd5r-openblas-ilp64-0.3.20/include
openblas_config= USE_64BITINT= DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 NO_CBLAS= 
NO_LAPACK= NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP= generic MAX_THREADS=128
version=0.3.20
extralib=-lm -lpthread -lgfortran -lm -lpthread -lgfortran
Name: openblas
Description: OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD 
version
Version: ${version}
URL: https://github.com/xianyi/OpenBLAS
Libs: -L${libdir} -lopenblas
Libs.private: ${extralib}
Cflags: -I${includedir}

Looks like it should be "LIBBLAS=-lopenblas"

It might need some tuning anyway, currently we have julia for i686 and
switching to solely openblas-ilp64 we'd lose 32-bit support.

I also noticed the julia expects the 64-bit openblas to be libopenblas64
(which happens to be what Debian¹ has). Would we need to adapt anything
in stdlib/OpenBLAS_jll/src/OpenBLAS_jll.jl?

Also, are we supposed to build lapack with our openblas as an input?

¹ https://sources.debian.org/src/openblas/0.3.21%2Bds-4/debian/rules/#L71

> From 024c92fac091f59dcdbd3a78eb6ea77bb15b2170 Mon Sep 17 00:00:00 2001
> Message-Id: 
> <024c92fac091f59dcdbd3a78eb6ea77bb15b2170.1687449033.git.zimon.touto...@gmail.com>
> From: Simon Tournier 
> Date: Thu, 22 Jun 2023 17:45:50 +0200
> Subject: [PATCH] gnu: julia: Use openblas with ILP64 support.
> 
> Fixes <https://bugs.gnu.org/63986>.
> Reported by Cayetano Santos .
> 
> * gnu/packages/julia.scm (julia)[arguments]<#:make-flags>: Use OpenBLAS with
> ILP64 support.
> [inputs]: Replace openblas by openblas-ilp64.
> ---
>  gnu/packages/julia.scm | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/gnu/packages/julia.scm b/gnu/packages/julia.scm
> index ba54175822..a034cbf543 100644
> --- a/gnu/packages/julia.scm
> +++ b/gnu/packages/julia.scm
> @@ -481,10 +481,10 @@ (define-public julia
>  
>   ,@(if (target-aarch64?)
>   `("USE_BLAS64=0")
> - '())
> + `("USE_BLAS64=1"))
>  
> - "LIBBLAS=-lopenblas"
> - "LIBBLASNAME=libopenblas"
> + "LIBBLAS=-lopenblas_ilp64"
> + "LIBBLASNAME=libopenblas_ilp64"
>  
>   (string-append "UTF8PROC_INC="
>  (assoc-ref %build-inputs "utf8proc")
> @@ -513,7 +513,7 @@ (define-public julia
> ("llvm" ,llvm-julia)
> ("mbedtls-apache" ,mbedtls-apache)
> ("mpfr" ,mpfr)
> -   ("openblas" ,openblas)
> +   ("openblas" ,openblas-ilp64)
> ("openlibm" ,openlibm)
> ("p7zip" ,p7zip)
> ("pcre2" ,pcre2)
> 
> base-commit: 37c2e94cec6cb8b5e0e93e7b6c712c3b187ca5db
> -- 
> 2.38.1
> 

> 
> Well, I need to do more tests but I guess that’s the good direction. :-)
> 
> Cheers,
> simon


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63986: Julia is very slow

[Efraim Flashner]

On Thu, Jun 22, 2023 at 03:26:30PM +0200, Cayetano Santos wrote:
> 
> 
> >mer. 21 juin 2023 at 22:39, Cayetano Santos  wrote:
> 
> >>mer. 21 juin 2023 at 16:36, Ludovic Courtès  
> >>wrote:
> >
> >> Hey!
> >>
> >> The benchmark you posted, Cayetano, is:
> >>
> >>   julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N 
> >> = 1000; A = rand(N, N); B = rand(N, N); @btime $A*$B'

I've been having a hard time with that command, so I've been running
julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N = 1000; 
A = rand(N, N); B = rand(N, N); @time A*B'

I'm not sure if that's useful or not but I didn't see a different with
LIBBLAS* set.

> >>
> >> This is a matrix multiplication that gets delegated to the underlying
> >> BLAS right.  Running it under ‘perf record’ confirms it:
> >>
> >> Samples: 139K of event 'cycles:u', Event count (approx.): 99624880590
> >> Overhead  Command  Shared Object   Symbol
> >>   35.27%  .julia-real  libblas.so.3.9.0[.] dgemm_
> >>3.99%  .julia-real  libjulia-internal.so.1.8[.] gc_mark_loop
> >>2.60%  .julia-real  libjulia-internal.so.1.8[.] apply_cl
> >>1.06%  .julia-real  libjulia-internal.so.1.8[.] jl_get_binding_
> >>
> >> We’re using libblas.so (presumably from the ‘lapack’ package) and not
> >> OpenBLAS, so no wonder it’s slow.
> >>
> >> Could it be that:
> >>
> >>  "LIBBLAS=-lopenblas"
> >>  "LIBBLASNAME=libopenblas"
> >>
> >> is ineffective?  I think we have a lead!
> >
> > Are we following all instructions here ?
> >
> >   
> > https://docs.julialang.org/en/v1.8/devdocs/build/distributing/#Notes-on-BLAS-and-LAPACK
> >
> > I’m thinking about the variables LIBLAPACK and LIBLAPACKNAME.
> 
> To complete my previous comment, I just realised that
> 
>   Base.USE_BLAS64
> 
> gives "true" when running fast. Guix julia gives "false".
> 
> C.

I'll see what comes with switching it to blas64

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63205: quodlibet fails to build after python 3.10 update

[Efraim Flashner]

Looks good to me. Patch pushed!

On Mon, Jun 12, 2023 at 10:47:44AM +0200, Remco van 't Veer wrote:
> Hi,
> 
> Forgotten patch:
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63205#11
> 
> The supplied patch by Alice works and looks good to me.  Can somebody
> please have a look and consider committing it?
> 
> Thanks!
> 
> Cheers,
> Remco
> 
> 
> 

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63934: sonnet uses hardcoded paths for hunspell dictionaries

[Efraim Flashner]

In sonnet's source code, in src/plugins/hunspell/hunspellclient.cpp, we
have the following code snippet:

#ifdef Q_OS_WIN
maybeAddPath(QStringLiteral(SONNET_INSTALL_PREFIX "/bin/data/hunspell/"));
#else
maybeAddPath(QStringLiteral("/System/Library/Spelling"));
maybeAddPath(QStringLiteral("/usr/share/hunspell/"));
maybeAddPath(QStringLiteral("/usr/share/myspell/"));
#endif

This is probably why sonnet can't find any hunspell dictionaries.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63719: Acknowledgement (can't cross-build guix)

[Efraim Flashner]

Fixed with ef5a05bac8a539268c564f392d85ab707fdb3843.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63719: can't cross-build guix

[Efraim Flashner]

I just now attempted to cross-build guix from x86_64 to riscv64 and I
got an error in the 'set-font-path phase. Build log attached.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


4sxkafsd9nwwlivnxgjjyl7vqijyrs-guix-1.4.0-6.dc5430c.drv.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#63572: [PATCH] Re: bug#63572: htmlcxx-0.87 fails to build

[Efraim Flashner]

On Sat, May 20, 2023 at 11:43:46PM +0200, Dr. Arne Babenhauserheide wrote:
> Hi Bruno,
> 
> Bruno Victal  writes:
> >> So this may just need compiler parameters to set C++11 instead of C++17
> >> as target.
> >
> > Looking at the README file from 
> > <https://sourceforge.net/p/htmlcxx/code/ci/master/tree/>,
> > it looks to me that upstream has moved to 
> > <https://github.com/bonitao/htmlcxx>. (judging by the name of the repo 
> > owner)
> > Can you try asking upstream for a new release? The last commit 
> > (<https://github.com/bonitao/htmlcxx/commit/0ffa3e90b7dc3944f199fd80ab47c2a82589209a>)
> > has the message 'Fix c+11 compilation'.
> 
> I tried to build from the latest commit, but it did not build.
> 
> But I could now test adding the std argument and that works.

Thanks for checking.

> $ ./pre-inst-env guix build htmlcxx
> /gnu/store/3bqrqs2zzx1gy4xc1g9i59z8nnhwv2rs-htmlcxx-0.87
> 
> A patch is attached.

I didn't see any dependant packages. Patch pushed! Thanks.


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63485: Broken build libfprint

[Efraim Flashner]

On Mon, May 22, 2023 at 09:32:03PM +0100, Alex Devaure wrote:
> 
> Hi,
> Here is the patch to build libfprint.

I've adjusted the patch to remove all the styling changes so it's
clearer what changes were made. I've also added a copyright line for you
and pushed the patch. Thanks!


-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63659: 'guix offload status' should continue on missing machine

[Efraim Flashner]

I have 8 machines in my /etc/guix/machines.scm file and I often find
myself editing it often. Most of the machines are various aarch64 or
riscv64 boards, and they go online and offline often depending on the
weather and what I have them build.

Currently I have this:
(ins)efraim@3900XT ~$ guix offload status
guix offload: getting status of 5 build machines defined in 
'/etc/guix/machines.scm'...
guix offload: error: failed to connect to 'pine64': Failed to resolve hostname 
pine64 (Name or service not known)

What I'd like:
(ins)efraim@3900XT ~$ guix offload status
guix offload: getting status of 5 build machines defined in 
'/etc/guix/machines.scm'...
guix offload: error: failed to connect to 'pine64': Failed to resolve hostname 
pine64 (Name or service not known)
guix offload: warning: machine 'pbp' is 6 seconds behind
pbp
  kernel: Linux 6.2.10-1-MANJARO-ARM
  architecture: aarch64
  host name: pbp
  normalized load: 0.00
  free disk space: 18542.41 MiB
  time difference: -6 s
...

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63150: [PATCH 1/2] gnu: quilt: Fix build because of grep warnings.

[Efraim Flashner]

On Sun, Apr 30, 2023 at 02:34:27PM +0200, Josselin Poiret via Bug reports for 
GNU Guix wrote:
> From: Josselin Poiret 
> 
> * gnu/packages/patches/quilt-avoid-grep-warnings.patch: New patch.
> * gnu/local.mk (dist_patch_DATA): Register it.
> * gnu/packages/patchutils.scm (quilt): Use it.
> ---
> Hi everyone,
> 
> This should fix the build and also update quilt.

It seems I applied basically the same patch and didn't see this patch.
Sorry!

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Efraim Flashner]

On Mon, May 15, 2023 at 09:18:01AM +0200, Lars-Dominik Braun wrote:
> Hi Efraim,
> 
> since the upgrade from alacritty 0.9 to 0.12 it does not work any more
> with the DISPLAY environment variable unset (i.e. without xwayland). The
> error message is:
> 
> thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
> NoWaylandLib X11 status: XOpenDisplayFailed', 
> /tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
> 
> Could you have a look?

This should now be fixed, feel free to re-open if its still not working
for you.

(ins)efraim@3900XT ~/workspace/guix$ ./pre-inst-env guix shell alacritty
(ins)efraim@3900XT ~/workspace/guix [env]$ DISPLAY="" alacritty
warning: queue 0x7f40bcc0 destroyed while proxies still attached:
  zwp_primary_selection_offer_v1@4278190081 still attached
  wl_data_offer@4278190080 still attached
  zwp_primary_selection_device_v1@29 still attached
  zwp_primary_selection_device_manager_v1@21 still attached
  wl_data_device@28 still attached
  wl_seat@27 still attached
  wl_data_device_manager@25 still attached
  wl_registry@20 still attached
warning: queue 0x55d2489cbe70 destroyed while proxies still attached:
  wl_shm_pool@40 still attached
  xdg_wm_base@32 still attached
  wl_output@15 still attached
  wl_output@14 still attached
  wl_seat@13 still attached
  xdg_activation_v1@12 still attached
  wp_viewporter@11 still attached
  zwp_text_input_manager_v3@10 still attached
  zwp_pointer_constraints_v1@9 still attached
  zwp_relative_pointer_manager_v1@8 still attached
  zxdg_decoration_manager_v1@7 still attached
  wl_subcompositor@6 still attached
  wl_compositor@5 still attached
  wl_shm@4 still attached
  wl_registry@2 still attached
warning: queue 0x55d2489fbe80 destroyed while proxies still attached:
  wl_callback@45 still attached


-- 
Efraim Flashner  פלשנר אפרים
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Efraim Flashner]

On Mon, May 15, 2023 at 11:07:50AM +0200, Lars-Dominik Braun wrote:
> Hi,
> 
> > easy reproducer: 'DISPLAY="" alacritty' gives the same error.
> 
> that’s exactly what I used under Wayland, otherwise it’ll fall back
> to XWayland with ugly font rendering (because of my hidpi monitor).
> 
> > Do you know if the X11 error is also a problem?
> 
> Not sure what you mean. As I wrote it works with XWayland, so I’m
> guessing X11 is not broken.

I parsed the error like this:

(ins)efraim@3900XT ~$ DISPLAY="" alacritty
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
NoWaylandLib X11 status: XOpenDisplayFailed', 
/tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


(ins)efraim@3900XT ~$ DISPLAY="" alacritty
thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
NoWaylandLib
(no wayland library found!)

X11 status: XOpenDisplayFailed', 
/tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
(something something XOpenDislay failed! with that source location)

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

> Thank you,
> Lars
> 

One bug per bug report :)

> PS: What *is* entirely broken is swaylock, which also got updated
> recently:
> 
> wl_registry@2: error 0: invalid version for global wl_output (39): have 3, 
> wanted 4
> 



-- 
Efraim Flashner  פלשנר אפרים
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63514: alacritty>=0.12.0 does not work with Wayland

[Efraim Flashner]

On Mon, May 15, 2023 at 09:18:01AM +0200, Lars-Dominik Braun wrote:
> Hi Efraim,
> 
> since the upgrade from alacritty 0.9 to 0.12 it does not work any more
> with the DISPLAY environment variable unset (i.e. without xwayland). The
> error message is:
> 
> thread 'main' panicked at 'Failed to initialize any backend! Wayland status: 
> NoWaylandLib X11 status: XOpenDisplayFailed', 
> /tmp/guix-build-alacritty-0.12.0.drv-0/source/guix-vendor/rust-winit-0.28.3.tar.gz/src/platform_impl/linux/mod.rs:757:9
> 
> Could you have a look?

That's certainly annoying. I'll take a look and see if I can find a good
way to fix that.

easy reproducer: 'DISPLAY="" alacritty' gives the same error.

Do you know if the X11 error is also a problem?

-- 
Efraim Flashner  פלשנר אפרים
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63178: shepherd 0.10.0-rc1 riscv64 build failure

[Efraim Flashner]

On Sat, May 06, 2023 at 07:59:39PM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Efraim Flashner  skribis:
> 
> > On Wed, May 03, 2023 at 09:29:49PM +0200, Ludovic Courtès wrote:
> >> Hey Efraim,
> >> 
> >> Efraim Flashner  skribis:
> >> 
> >> > I reran it and got a different test failure
> >> 
> >> > FAIL: tests/starting-status.sh
> >> 
> >> Could you retry from the ‘master’ branch?  I pushed a couple of commits
> >> since your message that probably fixed this one.
> >> 
> >> Thanks a lot for testing!
> >
> > I ran the build on aarch64 and on riscv64 from commit
> > d6e4f59705f8526bea320a19e00d0aca552c1270. aarch64 for armhf succeeded (2
> > cores on a pine64). aarch64 failed (6 cores on a pinebook pro) and
> > riscv64 failed (2 cores on a starfive1). Second time through aarch64
> > succeeded on the same machine (which was definitely not doing anything
> > else at the time) and the riscv64 build succeeded on a 4 core starfive2.
> 
> I believe 7c79df11c7a9d938ed9b48e00c4366da95301d4b fixes a race
> condition that these tests were showing: ‘herd stop root’ can return
> before the shepherd process has terminated.
> 
> Could you try again?
> 
> For AArch64, what machine are you using, with what CPU?  There’s a
> Guile (?) bug manifesting on the OverDrive 1000 that causes more or
> less random test failures, unless you set GUILE_JIT_THRESHOLD=-1:
> 
>   https://github.com/wingo/fibers/issues/83
> 
> Thanks for your help!

The pine64¹ is an allwinner A64 with 4 A53 cores and the pinebook pro²
uses an RK3399, 4 cores of A53 and 2 cores of A72. I've also picked up 2
rock64³s using an RK3328 with 4 A53 cores.

¹ https://wiki.pine64.org/wiki/PINE_A64
² https://wiki.pine64.org/wiki/Pinebook_Pro
³ https://wiki.pine64.org/wiki/ROCK64

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#63178: shepherd 0.10.0-rc1 riscv64 build failure

[Efraim Flashner]

On Wed, May 03, 2023 at 09:29:49PM +0200, Ludovic Courtès wrote:
> Hey Efraim,
> 
> Efraim Flashner  skribis:
> 
> > I reran it and got a different test failure
> 
> > FAIL: tests/starting-status.sh
> 
> Could you retry from the ‘master’ branch?  I pushed a couple of commits
> since your message that probably fixed this one.
> 
> Thanks a lot for testing!

I ran the build on aarch64 and on riscv64 from commit
d6e4f59705f8526bea320a19e00d0aca552c1270. aarch64 for armhf succeeded (2
cores on a pine64). aarch64 failed (6 cores on a pinebook pro) and
riscv64 failed (2 cores on a starfive1). Second time through aarch64
succeeded on the same machine (which was definitely not doing anything
else at the time) and the riscv64 build succeeded on a 4 core starfive2.

I can run it through a few more times if you want.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


shepherd-aarch64.log.gz
Description: application/gunzip


shepherd-riscv64.log.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#63178: shepherd 0.10.0-rc1 riscv64 build failure

[Efraim Flashner]

I reran it and got a different test failure

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


shepherd-riscv64-buildlog2.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#63178: shepherd 0.10.0-rc1 riscv64 build failure

[Efraim Flashner]

I replaced gettext with gettext-minimal and built from commit
ca3e31d6dbc0c4b811497edeb519a7060c2309f4. tests/stopping-status.sh
failed, build log attached.



-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


shepherd-riscv64-buildlog.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#61121: Cannot import IJulia in Julia

[Efraim Flashner]

On Tue, Jan 31, 2023 at 12:34:16PM +0100, Simon Tournier wrote:
> 
> --8<---cut here---start->8---
> function __init__()
> global artifact_dir = dirname(Sys.BINDIR)
> global cacert = normpath(Sys.BINDIR, Base.DATAROOTDIR, "julia", 
> "cert.pem")
> end
> --8<---cut here---end--->8---

I've changed this line to:

global cacert = get(ENV, \"SSL_CERT_FILE\", 
"\"/etc/ssl/certs/ca-certificates.crt\")

and then tested it with the example at the beginning of the bug report.

> Well, somehow turn back these tests:
> 
> --8<---cut here---start->8---
>  ;; julia embeds a certificate, we are not doing that
>  (substitute* "stdlib/MozillaCACerts_jll/test/runtests.jl"
>(("@test isfile\\(MozillaCACerts_jll.cacert\\)")
> "@test_broken isfile(MozillaCACerts_jll.cacert)"))
>  ;; since certificate is not present some tests are failing in 
> network option
>  (substitute* 
> "usr/share/julia/stdlib/v1.8/NetworkOptions/test/runtests.jl"
>(("@test isfile\\(bundled_ca_roots\\(\\)\\)")
> "@test_broken isfile(bundled_ca_roots())")
>(("@test ispath\\(ca_roots_path\\(\\)\\)")
> "@test_broken ispath(ca_roots_path())")
>(("@test ca_roots_path\\(\\) \\!= bundled_ca_roots\\(\\)")
> "@test_broken ca_roots_path() != bundled_ca_roots()"))
> --8<---cut here---end--->8---

I wasn't able to turn these tests back on though.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#61121: Cannot import IJulia in Julia

[Efraim Flashner]

On Tue, Jan 31, 2023 at 12:34:16PM +0100, Simon Tournier wrote:
> Hi,
> 
> On Mon, 30 Jan 2023 at 21:55, Theodore Ehrenborg 
>  wrote:
> 
> > Gentoo appears to have fixed this bug by linking julia/cert.pem to the
> > system's ca-certificates.crt.
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26b59330b5222996defa4536237e62404bf21168
> 
> This trick is not possible, IIUC.
> 
> > Is there a way I could rebuild my own slightly modified Julia with a link
> > like that?
> 
> Maybe, by adding the package nss-certs as propagated-inputs in the
> definition of julia.

By itself I don't think this would do anything.

> > I understand that there's probably a good reason that Guix's Julia doesn't
> > by default have cert.pem, but I would be pleased with a hacky custom
> > solution if it made Jupyter notebooks work.
> 
> The reason is security. ;-)  It’s Julia that does poorly here.
> 
> As pointed with the upstream package MbedTLS.jl, the fix should come
> from Julia itself; therefore, it could be worth to open an issue, if it
> is not already the case. ;-)
> 
> From my understanding, the culprit is this [1]:
> 
> --8<---cut here---start->8---
> function __init__()
> global artifact_dir = dirname(Sys.BINDIR)
> global cacert = normpath(Sys.BINDIR, Base.DATAROOTDIR, "julia", 
> "cert.pem")
> end
> --8<---cut here---end--->8---
> 
> And it is not clear for me if NetworkOptions.jl [2] provides the option
> of not, and I am missing why Julia itself does not depend on it.
> 
> 1: 
> https://github.com/JuliaLang/julia/blob/master/stdlib/MozillaCACerts_jll/src/MozillaCACerts_jll.jl#L20
> 2: https://github.com/JuliaLang/NetworkOptions.jl
> 
> 
> Efraim, do you think it would be possible to patch Julia to point to
> some certificates via bundled_ca_roots or ca_roots_path?

In the initial patch for julia-1.8.1 I think there was a substitution to
hardcode /etc/ssl/something instead for 'global cacert' but I took that
out since we don't like hardcoding that.

GIT_SSL_CAINFO=/home/efraim/.guix-home/profile/etc/ssl/certs/ca-certificates.crt
SSL_CERT_DIR=/run/current-system/profile/etc/ssl/certs
CURL_CA_BUNDLE=/home/efraim/.guix-home/profile/etc/ssl/certs/ca-certificates.crt
SSL_CERT_FILE=/run/current-system/profile/etc/ssl/certs/ca-certificates.crt

I think it would be fine to tell Julia to look at SSL_CERT_FILE as the
cacert so it can be overridden as desired, and then we can add a
(native-?)search-path to Julia for SSL_CERT_FILE.

Does anyone know offhand how to get the environment variable? If not
I'll grep the sources and then look online.

> Well, somehow turn back these tests:
> 
> --8<---cut here---start->8---
>  ;; julia embeds a certificate, we are not doing that
>  (substitute* "stdlib/MozillaCACerts_jll/test/runtests.jl"
>(("@test isfile\\(MozillaCACerts_jll.cacert\\)")
> "@test_broken isfile(MozillaCACerts_jll.cacert)"))
>  ;; since certificate is not present some tests are failing in 
> network option
>  (substitute* 
> "usr/share/julia/stdlib/v1.8/NetworkOptions/test/runtests.jl"
>(("@test isfile\\(bundled_ca_roots\\(\\)\\)")
> "@test_broken isfile(bundled_ca_roots())")
>(("@test ispath\\(ca_roots_path\\(\\)\\)")
> "@test_broken ispath(ca_roots_path())")
>(("@test ca_roots_path\\(\\) \\!= bundled_ca_roots\\(\\)")
>     "@test_broken ca_roots_path() != bundled_ca_roots()"))
> --8<---cut here---end--->8---

That one might be a little harder, I'd rather not add nss-certs to the
build just for the test suite, but I'll see how it goes. Or at least
update the comment afterward.

> 
> Cheers,
> simon

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#61011: ‘guix system vm’ spawns QEMU and hangs

[Efraim Flashner]

On Sun, Jan 22, 2023 at 10:36:21PM +0100, Ludovic Courtès wrote:
> Hello,
> 
> On my Guix System machine, the ‘qemu-system-x86_64’ spawned by ‘guix
> system vm’ hangs after printing “Booting from ROM...”; it has to be
> terminated with SIGKILL, SIGINT is not enough.
> 
> Specifically:
> 
>   $(guix time-machine --commit=66188398c446bdf9ce044fa539536e9b54c28c60 \
> -- system vm gnu/system/examples/bare-bones.tmpl) -m 1024  # Good.
> 
> … whereas:
> 
>   $(guix time-machine --commit=9923100a42ffa80f604c1c13a5e999e6a4c15146 \
> -- system vm gnu/system/examples/bare-bones.tmpl) -m 1024  # Bad!
> 
> I thought the culprit might be this commit:
> 
>   commit 9923100a42ffa80f604c1c13a5e999e6a4c15146
>   Date:   Fri Dec 23 09:42:27 2022 +0200
> 
>   gnu: sgabios: Fix build on cross-build architectures.
> 
>   * gnu/packages/firmware.scm (sgabios)[arguments]: When cross-building
>   add a make-flag to use the correct objcopy.
> 
> … but even after reverting it on today’s master, QEMU occasionally hangs
> as before, though not always.
> 
> ‘qemu-minimal’ as used for “make check-system” seems to work fine.
> 
> There have been a number of packages unbundled, so I wonder if another
> one of these might be causing problems.
> 
> What do you think?

I remember feeling overwhelmed by the build failures after the
unbundling (but I didn't reach out! I should've said something.) and
worked to try and quickly fix the builds.

I looked at reverting it locally, but with or without that patch I got
the same derivation for sgabios when built on x86_64. I tried firing up
diffoscope and I found no differences between the sgabios built on
x86_64, aarch64 or armhf (wow!).

I've run diffoscope against the sga I tried firing up diffoscope and I
found no differences between the sgabios built on x86_64, aarch64 or
armhf (wow!).

I've run diffoscope against the sgabios.bin that we build and the one
that comes in the qemu release tarball and I've included the output in
the email.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


sgabios.bin.diff.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#25235: [PATCH 1/1] build-system/pyproject: Do not wrap native-inputs.

[Efraim Flashner]

I'm still on my first cup of coffee...

If a python input is in inputs and in native-inputs would it be included
in the wrapper or not? At first glance I'd say no. Does the search path
do deduplication? If it doesn't then it'd work to only remove the first
instance matching from native-input-dirs.

On Mon, Jan 16, 2023 at 04:29:19PM -0500, Maxim Cournoyer wrote:
> Fixes <https://issues.guix.gnu.org/25235>.
> 
> * guix/build/pyproject-build-system.scm (wrap) [native-inputs]: New argument.
> Filter out native inputs from the values in GUIX_PYTHONPATH.
> 
> ---
> 
>  guix/build/pyproject-build-system.scm | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/guix/build/pyproject-build-system.scm 
> b/guix/build/pyproject-build-system.scm
> index a66c1fb34a..cd418f7ec9 100644
> --- a/guix/build/pyproject-build-system.scm
> +++ b/guix/build/pyproject-build-system.scm
> @@ -445,7 +445,7 @@ (define* (add-install-to-pythonpath #:key native-inputs 
> outputs
>"A phase that just wraps the 'add-installed-pythonpath' procedure."
>(add-installed-pythonpath native-inputs outputs))
>  
> -(define* (wrap #:key inputs outputs #:allow-other-keys)
> +(define* (wrap #:key native-inputs inputs outputs #:allow-other-keys)
>(define (list-of-files dir)
>  (find-files dir (lambda (file stat)
>(and (eq? 'regular (stat:type stat))
> @@ -464,9 +464,17 @@ (define bindirs
>(define %guile (delay (search-input-file inputs "bin/guile")))
>(define (guile) (force %guile))
>  
> -  (let* ((var `("GUIX_PYTHONPATH" prefix
> -,(search-path-as-string->list
> -  (or (getenv "GUIX_PYTHONPATH") "")
> +  ;; Use the same strategy to compute the native-input file names.
> +  (define %native-input-dirs (delay (match native-inputs
> +  (((_ . dir) ...)
> +   dir
> +  (define (native-input-dirs) (force %native-input-dirs))
> +
> +  (let ((var `("GUIX_PYTHONPATH" prefix
> +   ,(remove (lambda (x)
> +  (any (cut string-prefix? <> x) 
> (native-input-dirs)))
> +(search-path-as-string->list
> + (or (getenv "GUIX_PYTHONPATH") ""))
>  (for-each (lambda (dir)
>  (let ((files (list-of-files dir)))
>(for-each (cut wrap-script <> #:guile (guile) var)
> -- 
> 2.38.1
> 
> 
> 
> 

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#58789: julia 1.6.7 Pkg.add fails with curl_multisocket error

[Efraim Flashner]

On Tue, Oct 25, 2022 at 04:52:57PM -0400, John Biechele-Speziale via Bug 
reports for GNU Guix wrote:
> After installing GuixSD and julia on the fairly minimal installation,
> running julia and entering the following command ’] add DrWatson’
> fails with the following error: “ curl_multi_socket_action: 8”.
> Oddly enough, some packages work, such as LibCURL, but most fail.
> 
> The failure seems to occurs at the “resolving pkg versions” stage.
> 
> I’m a bit new to guix and mailing lists in general, so if there’s
> anything else I need to provide to help reproduce the bug, please
> let me know and I’ll send it ASAP.

With the update of Julia to 1.8.3 I have tested installing DrWatson
using the Julia REPL and it now works.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#56711: libunwind-julia fails to build on aarch64

[Efraim Flashner]

On Fri, Jul 22, 2022 at 02:45:42PM -0600, Akira Kyle wrote:
> I've been trying to get julia working on aarch64 but I was running into a
> linker error when guix was trying to build libunwind-julia. I tracked it
> down to the libunwind-julia-fix-GCC10-fno-common.patch not including a fix
> for aarch64 which is included in the upstream commit [1] which fixed this in
> libunwind 1.5.0. I gather libunwind-julia is at 1.3.1 due to julia 1.6.3
> only building against that version, and checking the more recent julia
> versions, it seems julia is only updating it's dependency on libunwind to
> 1.5.0 with julia version 1.8.0 which is only a release candidate at this
> point. So perhaps in the meantime,
> libunwind-julia-fix-GCC10-fno-common.patch could be easily updated so julia
> can start building on aarch64?
> 
> [1] 
> https://github.com/libunwind/libunwind/commit/29e17d8d2ccbca07c423e3089a6d5ae8a1c9cb6e
> 
> Thanks!
> Akira

With the recent patches to push julia to 1.8.3 libunwind-julia now
builds for aarch64.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#59695: ESP partition uses 1024 byte sectors

[Efraim Flashner]

On Tue, Nov 29, 2022 at 10:51:42PM +0200, Efraim Flashner wrote:
> I was working on using a grub-efi system image for aarch64 and I got the
> following error:
> 'Error: FAT sector size mismatch (fs=1024, dev=512)'
> I traced it back to u-boot¹. u-boot wouldn't chainload grub if the
> device block size and the filesystem sector size doesn't line up. I
> changed the line in (gnu build image) in make-vfat-image to use '-S 512'
> for esp partitions and was able to load the grub menu from u-boot.
> 
> I spent some time looking through the git history but I wasn't able to
> find anything to suggest why we have 1024 byte sectors there
> specifically.
> 
> ¹ https://source.denx.de/u-boot/u-boot/-/blob/master/fs/fat/fat.c#L589

Normally I'd be ok with hardcoding 512 for the sector size to fix this,
but then I remembered that there are 4k block size disks which actually
declare themselves as having 4k blocks and not emulating 512 byte
blocks.

What do you think? I suppose one option would be to patch u-boot to not
demand they be equal, but that only works with guix build u-boot. We
could force 512, u-boot is the only thing I've come across so far that
cares and most people² use µSD cards which advertise 512 byte blocks.

Maybe change it to 512 and add a TODO to revisit it later as needed?

² citation needed

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#59695: ESP partition uses 1024 byte sectors

[Efraim Flashner]

I was working on using a grub-efi system image for aarch64 and I got the
following error:
'Error: FAT sector size mismatch (fs=1024, dev=512)'
I traced it back to u-boot¹. u-boot wouldn't chainload grub if the
device block size and the filesystem sector size doesn't line up. I
changed the line in (gnu build image) in make-vfat-image to use '-S 512'
for esp partitions and was able to load the grub menu from u-boot.

I spent some time looking through the git history but I wasn't able to
find anything to suggest why we have 1024 byte sectors there
specifically.

¹ https://source.denx.de/u-boot/u-boot/-/blob/master/fs/fat/fat.c#L589

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#59696: openfwwf-firmware causes a boot hang on aarch64-linux

[Efraim Flashner]

I was trying to use my libre wifi dongle on my pinebook pro and I added
%base-firmware to my OS definition. By process of elimination I was able
to boot with the ath9k-htc-firmware added, but when I also added the
openfwwf-firmware package then the boot process would hang with a black
screen. I wasn't able to debug it to see where in the boot process it
was hanging.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#56290: Guix is at version 0, according to "guix --version"

[Efraim Flashner]

I've hunted this down using 'guix time-machine' and it looks like the
first commit where the version string returns 0 is
076e825dc5d585943ce820a279fffe4af09757fb. On that
commit 'guix time-machine --commit=076e... -- --version' returns 0 and
on the commit before that 5996aab354831d942b10253bc70217a4f2e6a247 we
get the commit as the version string.

Looking at the commits I'm guessing that the 076e825d commit interacts
with the af57d1bf commit 2 before it, and whether the guile is guile-3.0
or guile-final or guile-3.0-latest.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#34427: guile-bootstrap@2.2 segfault?

[Efraim Flashner]

We've moved the bootstrap guile to 3.0 for riscv64 and haven't seen any 
problems. I think we can just close this one and we'll revisit it if someone 
else decides to use guile-2.2 for a bootstrap guile and runs into this issue.


On October 18, 2022 4:14:32 PM UTC, zimoun  wrote:
>Hi,
>
>It is about this old report #34427x [1].
>
>1: 
>
>On Thu, 23 Jun 2022 at 10:17, zimoun  wrote:
>> On Fri, 15 Apr 2022 at 09:45, Ludovic Courtès  wrote:
>>
> The problem has to do specifically with powerpc-linux-gnu (this is with
> transparent emulation via QEMU+binfmt_misc):
>
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped 
> --target=powerpc-linux-gnu) /bin/guile
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main 
> thread
> GC Warning: Couldn't read /proc/stat
> Pre-boot error; key: wrong-type-arg, args: (#f "Wrong type to apply: ~S"
> (#f) (#f))qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted
> --8<---cut here---end--->8---
>
> Unfortunately I fail to get a backtrace from that core dump.
>
> Efraim, could you get a backtrace on the bare metal?
>>>
>>> Sorry I wasn’t clear; could you get a backtrace from GDB, as in:
>>>
>>>   …/bin/guile
>>>   # segfault
>>>   gdb …/bin/guile core
>>>
>>> and then at the GDB prompt:
>>>
>>>   bt
>
>What is the status?  Since a release is maybe coming, it could be the
>opportunity to tackle it… or not. :-)
>
>Cheers,
>simon

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#43432: trilinos source vanished

[Efraim Flashner]

On October 18, 2022 3:38:40 PM UTC, zimoun  wrote:
>Hi,
>
>I think it is a duplicate of #40074 [1].  I am in favour to close both.
>
>1: 
>
>
>Cheers,
>simon

Works for me
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

bug#58316: 5.19.12 kernel causes issues with Intel laptops

[Efraim Flashner]

On Wed, Oct 05, 2022 at 01:05:59PM +, Declan Rixon wrote:
> Hi all, I ran guix pull and system reconfigure today, updating my kernel to
> 5.19.12. On rebooting I was unable to get much past the bootloader before
> the screen started flashing. Aparrently there's a regression in 5.19.12
> that couses this issue in some intel laptops. Because guix is guix I just
> rolled back for now.
> 
> This regression was fixed in the 5.19.13 stable release.
> 
> https://www.neowin.net/news/beware-linux-kernel-51912-could-damage-your-intel-laptop-display-literally/
> shows the effect on someone elses laptop (not guix). They say that 5.19.11
> works fine and while I haven't checked that myself, I can say 5.19.9 works
> fine.

Thanks for the report. I was wondering if it was also happening with the
linux-libre kernel. The 5.19 kernel has been updated to 5.19.14, so all
should be good now.

Of course let us know if it comes back with the newer kernel version.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#43035: gpg-agent can't find pinentry with linux-libre-5.8.3

[Efraim Flashner]

On Wed, Sep 28, 2022 at 08:28:14PM -0400, Maxim Cournoyer wrote:
> Hi,
> 
> Efraim Flashner  writes:
> 
> > On Mon, Aug 31, 2020 at 03:33:34PM -0400, Leo Famulari wrote:
> >> On Mon, Aug 31, 2020 at 10:20:36PM +0300, Efraim Flashner wrote:
> >> > On Tue, Aug 25, 2020 at 04:14:59PM -0400, Leo Famulari wrote:
> >> > > On Tue, Aug 25, 2020 at 12:45:45PM +0300, Efraim Flashner wrote:
> >> > > > This bug report sounds absurd to me but I don't see anything else
> >> > > > obvious that changed. I reconfigured with (kernel linux-libre) and 
> >> > > > the
> >> > > > gpg-agent couldn't find any pinentry. I even tried killing gpg-agent 
> >> > > > and
> >> > > > manually launching it and giving it the path to pinentry. I then 
> >> > > > changed
> >> > > > to (kernel linux-libre-5.7) and used the same commit to reconfigure 
> >> > > > and
> >> > > > gpg-agent started working as expected again.
> >> > > 
> >> > > Weird! You should run gpg-agent with `strace -f` and see where it is
> >> > > looking.
> >> > 
> >> > I've attached the strace from gpg-agent when I tried to run 'gpg -s'
> >> > ^C+d. I'm not really sure what it could be but it looks like I should
> >> > boot back into the 5.8.5 kernel generation and strace some more
> >> > processes.
> >> 
> >> Okay, I'm still stumped. Next time use `strace -fv`, so that it doesn't
> >> abbreviate useful information.
> >
> > I have a new one with 'strace -fv' where it still didn't work. Then I
> > figured that maybe it was custom pinentry-efl so I removed that and
> > switched to pinentry-efl and that didn't work. Then I removed that and
> > installed pinentry-gnome3 and suddenly that worked. So it looks like
> > it's pinentry-efl specific
> 
> Is it OK to close this issue then?  The title is rather misleading! :-)
> 

Sure. I'm not even really sure what it's about right now. I assume the
problem is fixed.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Efraim Flashner]

On Fri, Sep 02, 2022 at 03:58:09PM -0400, Thompson, David wrote:
> On Fri, Sep 2, 2022 at 8:50 AM Thompson, David  
> wrote:
> >
> > On Fri, Sep 2, 2022 at 8:44 AM Efraim Flashner  
> > wrote:
> > >
> > > On Fri, Sep 02, 2022 at 07:11:54AM -0400, Thompson, David wrote:
> > > > On Fri, Sep 2, 2022 at 3:00 AM Efraim Flashner  
> > > > wrote:
> > > > >
> > > > > I took a look at the gitolite service finally and I hadn't realized
> > > > > there wasn't a running daemon to containerize. I assumed we could do
> > > > > something like:
> > > > >
> > > > > (start $~(make-forkexec-constructor/container
> > > > > (list ...)
> > > > > #:environment-variables
> > > > > '("PATH=...")
> > > > > #:mappings ...))
> > > > >
> > > > > Given that's not the case then I'd need to look at gitolite itself to
> > > > > see how it calls the other binaries it expects to be available, and if
> > > > > wrapping it would be enough or if we would need to just propagate the
> > > > > other packages for functionality.
> > > >
> > > > Gitolite simply expects tools like git to be on $PATH.  It's a pretty
> > > > naive system, there's nothing like a configure script that is
> > > > determining the absolute file name of these tools and substituting
> > > > those names into the built files.
> > > >
> > > > The executable is already wrapped so that coreutils, findutils, and
> > > > git are on $PATH, but notably not openssh:
> > > >
> > > > (add-after 'install 'wrap-scripts
> > > > (lambda* (#:key inputs outputs #:allow-other-keys)
> > > >   (let ((out (assoc-ref outputs "out"))
> > > > (coreutils (assoc-ref inputs "coreutils"))
> > > > (findutils (assoc-ref inputs "findutils"))
> > > > (git (assoc-ref inputs "git")))
> > > > (wrap-program (string-append out 
> > > > "/bin/gitolite")
> > > >   `("PATH" ":" prefix
> > > > ,(map (lambda (dir)
> > > > (string-append dir "/bin"))
> > > >   (list out coreutils findutils 
> > > > git)))
> > > >
> > > > However, git and openssh are still propagated inputs. I'm going to
> > > > move the propagated inputs to regular inputs, potentially add openssh
> > > > to the wrapper once I remind myself what gitolite does with those
> > > > tools, and test it all out on my server using the gitolite service.
> > > > If that all works, we have a good starting point for adding extension
> > > > support in the service.
> > >
> > > I like it. Let us know how it goes.
> >
> > The problem is that gitolite generates git hooks for the repositories
> > that it manages, and those hooks invoke git, so the only way those
> > scripts will be able to work (without input propagation) is to find a
> > way to inject the proper PATH or find a way to replace references to
> > things like 'git diff' with '/gnu/store/.../git diff'.  I'm going to
> > keep exploring and report back when I have something to show.
> 
> After several rounds of experimentation and breaking my git server a
> few times, here's what I've found:
> 
> * Changing git and openssh to be regular inputs and wrapping both
> gitolite and gitolite-shell with a $PATH that contains git works and
> it's very little extra code.
> 
> * Trying to replace every invocation of a git command took a lot of
> grepping and crafting of regexps to use for substitute* and I never
> got to a point where the result wasn't buggy.  In particular,
> gitolite-shell never worked properly so I couldn't push to my repos.
> 
> So, I think the simple wrapper approach is the way to go.  Patch
> attached.  I tested on my git server by making changes to my gitolite
> configuration and pushing those changes to the special gitolite-admin
> repo.  This causes gitolite to refresh internal configuration using a
> git hook, so I know that hooks can find the executables they need.
> That plus the 'gitolite setup' invocation made by the service
> a

bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Efraim Flashner]

On Fri, Sep 02, 2022 at 07:11:54AM -0400, Thompson, David wrote:
> On Fri, Sep 2, 2022 at 3:00 AM Efraim Flashner  wrote:
> >
> > I took a look at the gitolite service finally and I hadn't realized
> > there wasn't a running daemon to containerize. I assumed we could do
> > something like:
> >
> > (start $~(make-forkexec-constructor/container
> > (list ...)
> > #:environment-variables
> > '("PATH=...")
> > #:mappings ...))
> >
> > Given that's not the case then I'd need to look at gitolite itself to
> > see how it calls the other binaries it expects to be available, and if
> > wrapping it would be enough or if we would need to just propagate the
> > other packages for functionality.
> 
> Gitolite simply expects tools like git to be on $PATH.  It's a pretty
> naive system, there's nothing like a configure script that is
> determining the absolute file name of these tools and substituting
> those names into the built files.
> 
> The executable is already wrapped so that coreutils, findutils, and
> git are on $PATH, but notably not openssh:
> 
> (add-after 'install 'wrap-scripts
> (lambda* (#:key inputs outputs #:allow-other-keys)
>   (let ((out (assoc-ref outputs "out"))
> (coreutils (assoc-ref inputs "coreutils"))
> (findutils (assoc-ref inputs "findutils"))
> (git (assoc-ref inputs "git")))
> (wrap-program (string-append out "/bin/gitolite")
>   `("PATH" ":" prefix
> ,(map (lambda (dir)
> (string-append dir "/bin"))
>   (list out coreutils findutils git)))
> 
> However, git and openssh are still propagated inputs. I'm going to
> move the propagated inputs to regular inputs, potentially add openssh
> to the wrapper once I remind myself what gitolite does with those
> tools, and test it all out on my server using the gitolite service.
> If that all works, we have a good starting point for adding extension
> support in the service.

I like it. Let us know how it goes.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#25957: [EXT] Re: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Efraim Flashner]

On Thu, Sep 01, 2022 at 10:41:21AM -0400, Thompson, David wrote:
> Hi Efraim,
> 
> On Thu, Sep 1, 2022 at 10:20 AM Efraim Flashner  wrote:
> >
> > On Thu, Sep 01, 2022 at 09:59:55AM -0400, Thompson, David wrote:
> > > Hi all,
> > >
> > > Reviving this old thread.
> > >
> > > On Mon, Mar 28, 2022 at 2:51 AM Efraim Flashner  
> > > wrote:
> > > > >
> > > > > Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve'
> > > > > into a '/gnu/store/...' (untested), so seems actionable to me.
> > > > > Alternatively, as Efraim wrote, let it search the $PATH (that might be
> > > > > useful if adding svnserve would increase the closure too much and it 
> > > > > is
> > > > > an optional dependency in practice?).
> > > >
> > > > I spent some time looking at gitolite and the service. As I understand
> > > > it, with the exception of svnserve, it searches $PATH for a number of
> > > > different binaries, including git-annex. I believe that this would only
> > > > work if git-annex (and potentially other packages) are installed
> > > > globally.
> > > >
> > > > In addition, git (not git-minimal) and openssh are propagated inputs AND
> > > > wrapped. I haven't tested to see if wrapping only is enough.
> > > >
> > > > I think the best choice is to:
> > > > A: Replace /usr/bin/svnserve with svnserve so it will just search $PATH,
> > > > like it does with the other helpers.
> > >
> > > I see that you have done this.  Thanks!  We could also replace the
> > > reference to /usr/sbin/redis-server in src/lib/Gitolite/Cache.pm.
> > > That's the only other /usr reference I can find (that isn't in a
> > > comment) in the output.  I have the patch ready if that sounds good to
> > > you.
> >
> > Sounds good to me
> 
> Thanks, pushed as commit c053dfa52dc778eb3d965f58a85c435ae7fab0dd.
> 
> > > > B: Adjust the service so that it automatically creates a variant (or
> > > > just a wrapped version) of the package which is wrapped with a list of
> > > > additional packages so that they can be in gitolite's path. If I were
> > > > deploying this to an arm device I wouldn't want it wrapped with
> > > > git-annex since it doesn't build, but would definitely want it for an
> > > > x86_64 machine.
> > >
> > > The service configuration record could accept a list of addons like
> > > '(git-annex cache svnserve), with a default of no addons '(), and
> > > create a package that extends the gitolite package with the
> > > appropriate propagated inputs.  Does that sound like what you had in
> > > mind?  A more robust solution could modify the build to hardcode the
> > > store paths needed for the add-ons but given that we already propagate
> > > git and openssh I don't think it's necessary right now.
> >
> > Assuming this is deployed into some sort of container then propagated
> > inputs wouldn't help much, we'd need either the PATH for the container
> > to be extended to include those extra packages or to have gitolite
> > itself wrapped similar to icedove/wayland. Just extending the PATH in
> > the #:environment-variables would be enough I'd think.
> 
> Hmm, I hadn't thought about the container use case.  Your approach
> sounds like the way to go.  For what it's worth, I think the gitolite
> service as-is would suffer the same issue in a containerized
> environment because it relies upon the git and openssh propagated
> inputs to do anything at all.  With the gitolite service in my system,
> /run/current-system/profile/bin has both git and ssh in it due to the
> propagation.  So it sounds like there's 2 steps needed: 1) Use a
> wrapper like icedove/wayland for the base gitolite package so that git
> and openssh no longer need propagation, and then 2) extend the
> gitolite service to wrap up additional packages needed for the desired
> extensions.  Sound good?
> 
> > > > I suppose we should try to find someone who is using the gitolite
> > > > service and see if they can be our test subject for wrapping the package
> > > > with optional addons.
> > >
> > > I use the gitolite service and can be the test subject.  I don't
> > > currently use any add-ons, but the redis one sounds easy enough to try
> > > and hey maybe it's a good excuse to finally learn how to use
> > > git-annex.
> > >
> > > As a longer term thing, 

bug#25957: [EXT] bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks

[Efraim Flashner]

On Thu, Sep 01, 2022 at 09:59:55AM -0400, Thompson, David wrote:
> Hi all,
> 
> Reviving this old thread.
> 
> On Mon, Mar 28, 2022 at 2:51 AM Efraim Flashner  wrote:
> > >
> > > Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve'
> > > into a '/gnu/store/...' (untested), so seems actionable to me.
> > > Alternatively, as Efraim wrote, let it search the $PATH (that might be
> > > useful if adding svnserve would increase the closure too much and it is
> > > an optional dependency in practice?).
> >
> > I spent some time looking at gitolite and the service. As I understand
> > it, with the exception of svnserve, it searches $PATH for a number of
> > different binaries, including git-annex. I believe that this would only
> > work if git-annex (and potentially other packages) are installed
> > globally.
> >
> > In addition, git (not git-minimal) and openssh are propagated inputs AND
> > wrapped. I haven't tested to see if wrapping only is enough.
> >
> > I think the best choice is to:
> > A: Replace /usr/bin/svnserve with svnserve so it will just search $PATH,
> > like it does with the other helpers.
> 
> I see that you have done this.  Thanks!  We could also replace the
> reference to /usr/sbin/redis-server in src/lib/Gitolite/Cache.pm.
> That's the only other /usr reference I can find (that isn't in a
> comment) in the output.  I have the patch ready if that sounds good to
> you.

Sounds good to me

> > B: Adjust the service so that it automatically creates a variant (or
> > just a wrapped version) of the package which is wrapped with a list of
> > additional packages so that they can be in gitolite's path. If I were
> > deploying this to an arm device I wouldn't want it wrapped with
> > git-annex since it doesn't build, but would definitely want it for an
> > x86_64 machine.
> 
> The service configuration record could accept a list of addons like
> '(git-annex cache svnserve), with a default of no addons '(), and
> create a package that extends the gitolite package with the
> appropriate propagated inputs.  Does that sound like what you had in
> mind?  A more robust solution could modify the build to hardcode the
> store paths needed for the add-ons but given that we already propagate
> git and openssh I don't think it's necessary right now.

Assuming this is deployed into some sort of container then propagated
inputs wouldn't help much, we'd need either the PATH for the container
to be extended to include those extra packages or to have gitolite
itself wrapped similar to icedove/wayland. Just extending the PATH in
the #:environment-variables would be enough I'd think.

> > I suppose we should try to find someone who is using the gitolite
> > service and see if they can be our test subject for wrapping the package
> > with optional addons.
> 
> I use the gitolite service and can be the test subject.  I don't
> currently use any add-ons, but the redis one sounds easy enough to try
> and hey maybe it's a good excuse to finally learn how to use
> git-annex.
> 
> As a longer term thing, it would be cool to revisit propagating git
> and openssh in this package.  I punted on it back in 2015 for the
> reason stated in the source comments but maybe there's a reasonable
> and reliable way to directly embed the store paths now.

It's actually been forever since I looked at gitolite so I don't know
remember what those inputs were needed for, but it'd be great to improve
the service.

> - Dave

Interestingly, I almost have a working ghc-8.6 for aarch64 after all
these years.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#22020: [PATCH] gnu: guile-sdl: Update to 0.6.1

[Efraim Flashner]

It's been a while since you submitted this patch, but it's applied now.
Thanks!

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#57303: powerpc64le: rust build failure is bottleneck for many packages

[Efraim Flashner]

On Fri, Aug 19, 2022 at 08:56:10PM +0200, Marcel van der Boom wrote:
> 
> I use a Talos II machine as my daily driver and slowly migrating as many
> packages to GUIX along the way. The kernel I am running comes fromm
> https://archlinuxpower.org/
> 
> 
> For many packages, rust is getting to be the bottleneck as a dependency that
> does not build.
> 
> From what I can see there's a whole chain of rust dependencies going back to
> rust@1.39.0 which then ultimately fails with:
> 
> 
> --8<---cut here---start->8---
> (16/112) BUILDING bitflags v1.1.0
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> > rustc-1.39.0-src/vendor/bitflags/src/lib.rs -o
> > output/rustc-build/libbitflags-1_1_0.rlib --crate-name bitflags
> > --crate-type rlib -C
> > emit-depfile=output/rustc-build/libbitflags-1_1_0.rlib.d --crate-tag
> > 1_1_0 -g --cfg debug_assertions -O -L output -L output/rustc-build --cfg
> > bitflags_const_fn
> (17/112) BUILDING cc v1.0.35
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> > rustc-1.39.0-src/vendor/cc/src/lib.rs -o
> > output/rustc-build/libcc-1_0_35.rlib --crate-name cc --crate-type rlib
> > -C emit-depfile=output/rustc-build/libcc-1_0_35.rlib.d --crate-tag
> > 1_0_35 -g --cfg debug_assertions -O -L output -L output/rustc-build
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/bin/mrustc
> > rustc-1.39.0-src/src/librustc_llvm/build.rs --crate-name build
> > --crate-type bin -o output/rustc-build/build_rustc_llvm_run -L
> > output/rustc-build -g -L output --extern
> > build_helper=output/rustc-build/libbuild_helper-0_1_0.rlib --extern
> > cc=output/rustc-build/libcc-1_0_35.rlib --edition 2018
> > /tmp/guix-build-rust-1.39.0.drv-0/mrustc/output/rustc-build/build_rustc_llvm_run
> thread 'main' panicked at 'assertion failed: `(left == right)`
>  left: `1`,
> right: `0`', rustc-1.39.0-src/vendor/hashbrown/src/raw/mod.rs:1086:59
> Process was terminated with signal 6
> --8<---cut here---end--->8---
> 
> 
> The line in =mod.rs= points to an assertion in some sort of table iterator.
> Way over my head.
> 
> I know rust runs on powerpc64le because I have a binary version 1.62
> installed through https://archlinuxpower.org/
> 
> 
> Is anyone familiar with this working on rust on powerpc64 for the
> powerpc64le-linux system?

About 2 months ago I spent some time and got the rust bootstrap working
for riscv64-linux. I would suggest looking at the staging branch since
there the rust bootstrap version is at 1.54.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#56956: rust-pico-sys bundles PicoHTTPParser.

[Efraim Flashner]

On Wed, Aug 03, 2022 at 08:18:36PM +0200, Maxime Devos wrote:
> X-Debbugs-CC: Efraim Flashner 
> 
> (^ original package author+committer)
> 
> rust-pico-sys was added in commit
> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=eda57f4834b29ef17758f7f1f62d3af899e2d669>.
> 
> This package bundles PicoHTTPParser.
> 
> Fortunately, it is only used by a single dependency: rust-httparser, and
> only for benchmarks (which probably aren't compiled anyway), so simply
> removing the package definition and removing it from rust-httparser'
> #:dev-dependencies should be sufficient.  This appears to work in
> antioxidant.

It turns out rust-httparser-1 doesn't build on its own without
rust-pico-sys-0.0, but updating rust-httparser-1 from 1.5.1 to 1.7.1
changed the development-inputs and allowed me to remove
rust-pico-sys-0.0.



-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#56680: go-1.16.15 build fails in check phase on powerpc64le

[Efraim Flashner]

On Thu, Aug 04, 2022 at 11:02:53PM +0200, Marcel van der Boom wrote:
> 
> [Efraim Flashner]:
> > I'm currently working on bootstrapping go-1.17.11 directly from gccgo,
> > so we'd be able to skip 1.16 entirely. Currently it works on
> > x86_64-linux but not on riscv64-linux. If you want to test something
> > like that on powerpc64le that'd be great.
> 
> Sure, can you point me in the right direction and get me started on what
> would be useful for you?

Looking at the package definitions for go it looks like the inputs and
native-inputs need to be cleaned up some, but for our purposes I think
just removing the native-inputs field completely from 1.17 should try to
make go-1.17 build with gccgo. Then try to build go@1.17.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#56680: go-1.16.15 build fails in check phase on powerpc64le

[Efraim Flashner]

On Thu, Aug 04, 2022 at 06:24:47PM +0200, Marcel van der Boom wrote:
> 
> I see that the full build log expired on the paste site.
> 
> Is any additional info needed here, other than the excerpt of the log?
> 
> I suspect the check error is a safety precaution to ensure executables are
> of reasonable size, but reasonable is perhaps a bit different on the POWER9
> platform?

I'm currently working on bootstrapping go-1.17.11 directly from gccgo,
so we'd be able to skip 1.16 entirely. Currently it works on
x86_64-linux but not on riscv64-linux. If you want to test something
like that on powerpc64le that'd be great.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#56020: rust-libgit2-sys@0.12 bundles libgit2

[Efraim Flashner]

Fixed with 6f2df20b0f8555ab1568ad1d661cb6e737a4bb8f.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55721: Low cache usage in the presence of grafts

[Efraim Flashner]

On Mon, May 30, 2022 at 11:31:47AM +0200, Ludovic Courtès wrote:
> Ludovic Courtès  skribis:
> 
> > $ time GUIX_PROFILING="rpc reference-cache derivation-graft-cache" 
> > ./pre-inst-env  guix system vm gnu/system/examples/desktop.tmpl 
> > 0.2 MB will be downloaded
> >  polkit-0.121  198KiB   
> >  1.4MiB/s 00:00 [##] 100.0%
> > /gnu/store/sk1571rnh5jl2ilp0v1k8bqwsdrngwxy-run-vm.sh
> > Reference Cache:
> >   fresh caches: 8
> >   lookups:  77581
> >   hits: 52890 (68.2%)
> >   cache size: 838 entries
> > Derivation graft cache:
> >   fresh caches:39
> >   lookups:  704635
> >   hits: 627819 (89.1%)
> >   cache size:2946 entries
> > Remote procedure call summary: 33071 RPCs
> >   built-in-builders  ... 1
> >   query-substitutable-path-infos ... 2
> >   build-things   ... 2
> >   add-to-store/tree  ...56
> >   valid-path?...59
> >   add-to-store   ...   373
> >   add-text-to-store  ...  7887
> >   query-references   ... 24691
> >
> > real5m6.727s
> > user6m59.438s
> > sys 0m1.633s
> 
> With this patch:
> 

> diff --git a/guix/store.scm b/guix/store.scm
> index efba07bdcd..88cab1bb6a 100644
> --- a/guix/store.scm
> +++ b/guix/store.scm
> @@ -1337,7 +1337,12 @@ (define (build-accumulator expected-store)
>  (if (and (eq? (store-connection-socket store)
>(store-connection-socket expected-store))
>   (= mode (build-mode normal)))
> -(unresolved things continue)
> +(unresolved things
> +(lambda (new-store value)
> +  ;; Borrow caches from NEW-STORE.
> +  (set-store-connection-caches!
> +   store (store-connection-caches new-store))
> +  (continue value)))
>  (continue #t
>  
>  (define default-cutoff
> @@ -1397,7 +1402,8 @@ (define-values (result rest)
>(if (unresolved? obj)
>;; Pass #f because 'build-things' 
> is now
>;; unnecessary.
> -  ((unresolved-continuation obj) #f)
> +  ((unresolved-continuation obj)
> +   store #f)
>obj))
>  result #:cutoff cutoff)
>   (map/accumulate-builds store proc rest #:cutoff cutoff)

> 
> … we’re doing better:
> 
> --8<---cut here---start->8---
> $ guix gc -D $(guix build polkit --no-grafts)
> finding garbage collector roots...
> [0 MiB] deleting '/gnu/store/8vsfk8312m5p461wl4dq5lxjagfbwfhz-polkit-0.121'
> deleting `/gnu/store/trash'
> deleting unused links...
> note: currently hard linking saves 72397.13 MiB
> $ time GUIX_PROFILING="rpc reference-cache derivation-graft-cache" 
> ./pre-inst-env  guix system vm gnu/system/examples/desktop.tmpl 
> 0.2 MB will be downloaded
>  polkit-0.121  198KiB 
>1.6MiB/s 00:00 [##] 100.0%
> /gnu/store/wp3lv4xrh6vw79gnkyi5471c1l8j624n-run-vm.sh
> Reference Cache:
>   fresh caches: 8
>   lookups:  17232
>   hits: 14816 (86.0%)
>   cache size: 784 entries
> Derivation graft cache:
>   fresh caches:39
>   lookups:  128402
>   hits: 111336 (86.7%)
>   cache size: 328 entries
> Remote procedure call summary: 10796 RPCs
>   built-in-builders  ... 1
>   query-substitutable-path-infos ... 2
>   build-things   ... 2
>   add-to-store/tree  ...56
>   valid-path?...59
>   add-to-store   ...   373
>   query-references   ...  2416
>   add-text-to-store  ...  7887
> 
> real  1m31.550s
> user  2m7.107s
> sys   0m0.637s
> --8<---cut here---end--->8---
> 
> There’s still room for improvement though.
> 
> Ludo’.

With that change you've dropped the query-references from 24691 to 2416,
more than a 90% drop. If you want to take aim at improving it further
I'd say take a look at add-text-to-store and see if you can shrink that
number.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#54658: "pypi->guix-package, no wheel" test fails

[Efraim Flashner]

On Thu, Mar 31, 2022 at 10:26:06PM +0200, Maxime Devos wrote:
> I noticed "./pre-inst-env guix build guix" fails on my computer due to
> "pypi->guix-package, no wheel" failing.  Here is an excerpt from the log:
> 
< snip >
> 
> Greetings,
> Maxime.

FWIW this test also fails on riscv64-linux.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55523: Apostrophe does not run

[Efraim Flashner]

Thanks for the patch!

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55627: hurd exported twice in (guix platforms)

[Efraim Flashner]

hurd is defined in (guix platforms hurd) and in (guix platforms x86)

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Efraim Flashner]

This is now fixed with 41ed6db81e7b52673e5f973a1edc88b69a274614, with
fd00ac7e27c8a6d4b4d4719b4f8797bdce204623 adding actual detection for
aarch64 CPUs.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55373: efibootmgr fails to cross-compile: it looks for 'pkg-config' instead of 'TARGET-pkg-config'

[Efraim Flashner]

On Wed, May 11, 2022 at 07:23:41PM +0200, Maxime Devos wrote:
> X-Debbugs-CC: Denis 'GNUtoo' Carikli 
> 
> Title says it all.
> 
> Also see the following excerpt from the build log:
> 
> > make -f /tmp/guix-build-efibootmgr-17.drv-0/source/Make.deps deps 
> > SOURCES="efibootmgr.c efi.c unparse_path.c" 
> > SUBDIR_CFLAGS="-I/tmp/guix-build-efibootmgr-17.drv-0/source/src/include"
> > /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh: line 
> > 1: pkg-config: command not found
> 
> Looks like PKG_CONFIG needs to be added to #:make-flags:
> <https://github.com/rhboot/efibootmgr/blob/892cb7444ce6f2cded9c67ff2ab3ef35a4c810c8/Make.rules#L64>.
> 
> Maybe AR and CC as well.
> 

I also needed to adjust efivar so it would refer to the correct gcc when
cross-compiling. Anyway, this should now be fixed.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Efraim Flashner]

On Tue, May 10, 2022 at 05:43:43PM +0200, Ludovic Courtès wrote:
> Ludovic Courtès  skribis:
> 
> > (The bug reported at the beginning of this thread looks rather basic
> > though; I’ll follow up on that.)
> 
> Actually no.  :-)
> 
> I guess the first hunk of your patch, which modifies ‘current-cpu’ so
> that it does not return #f on AArch64, is the actual fix (it can be a
> patch of its own).
> 
> The second hunk, which modifies ‘cpu->gcc-architecture’, is an
> enhancement.
> 
> Ludo’.

On aarch64 Features (flags on x86_64) isn't last, so I changed the loop
to keep running until the end of the file. I suppose I could've changed
it to run until it hit a blank line and left the eof-object? for #f.

the change from (architecture architecture) at the end I tossed in at
the last minute. It was more to keep it from erroring on untuned
architectures.

(ins)efraim@3900XT ~$ ssh pbp cat /proc/cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer: 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 1
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer: 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 2
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer: 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 3
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer: 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

processor   : 4
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer: 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd08
CPU revision: 2

processor   : 5
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer: 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part    : 0xd08
CPU revision: 2

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Efraim Flashner]

On Tue, May 10, 2022 at 05:40:28PM +0200, Ludovic Courtès wrote:
> Hello!
> 
> Nice to have AArch64 support in (guix cpu)!
> 
> Efraim Flashner  skribis:
> 
> > diff --git a/guix/cpu.scm b/guix/cpu.scm
> > index a44cd082f1..37ed6f0a18 100644
> > --- a/guix/cpu.scm
> > +++ b/guix/cpu.scm
> > @@ -62,31 +62,51 @@ (define (prefix? prefix)
> >(lambda (port)
> >  (let loop ((vendor #f)
> > (family #f)
> > -   (model #f))
> > +   (model #f)
> > +   (flags (list->set '(
> 
> You can replace (list->set '()) by (set).
> 
> > +("aarch64"
> > + ;; Transcribed from GCC's list of aarch64 processors in 
> > aarch64-cores.def
> > + ;; What to do with big.LITTLE cores?
> > + (match (cpu-vendor cpu)
> > +   ("0x41"
> 
> Is /proc/cpuinfo more or less guaranteed to return hex numbers like
> this?

I'm almost certain it is on aarch64. I don't have an armhf machine to
check with.

> >  (architecture
> > - ;; TODO: AArch64.
> > - architecture)))
> > +  ;; TODO: More architectures
> > +  (utsname:machine (uname)
> 
> We can return ‘architecture’ as is, no need to re-call ‘uname’.

That's what we had before and we got the error.

> I haven’t run the code but at first sight it LGTM!
> 
> (The bug reported at the beginning of this thread looks rather basic
> though; I’ll follow up on that.)
> 
> Thanks,
> Ludo’.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Efraim Flashner]

On Mon, May 09, 2022 at 12:03:46PM +0200, Maxime Devos wrote:
> Efraim Flashner schreef op ma 09-05-2022 om 11:44 [+0300]:
> > +    (loop vendor family (string->number (string-append
> > "#x" (string-drop model 2)
> 
> #x is for hexadecimal, right?  If so, this can be simplified by using
> the second argument of string->number: (string->number (string-drop
> model 2) 16).

I hadn't realized that. I took the chance to take another look at it and
now it actually works, not just fills in each field with #f. I also
added more chips based on gcc-12 and fixed the fallback case.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
diff --git a/guix/cpu.scm b/guix/cpu.scm
index a44cd082f1..37ed6f0a18 100644
--- a/guix/cpu.scm
+++ b/guix/cpu.scm
@@ -62,31 +62,51 @@ (define (prefix? prefix)
   (lambda (port)
 (let loop ((vendor #f)
(family #f)
-   (model #f))
+   (model #f)
+   (flags (list->set '(
   (match (read-line port)
 ((? eof-object?)
- #f)
+ (cpu (utsname:machine (uname))
+  vendor family model flags))
+;; vendor for x86_64 and i686
 ((? (prefix? "vendor_id") str)
  (match (string-tokenize str)
(("vendor_id" ":" vendor)
-(loop vendor family model
+(loop vendor family model flags
+;; vendor for aarch64 and armhf
+((? (prefix? "CPU implementer") str)
+ (match (string-tokenize str)
+   (("CPU" "implementer" ":" vendor)
+(loop vendor family model flags
+;; family for x86_64 and i686
 ((? (prefix? "cpu family") str)
  (match (string-tokenize str)
(("cpu" "family" ":" family)
-(loop vendor (string->number family) model
+(loop vendor (string->number family) model flags
+;; model for x86_64 and i686
 ((? (prefix? "model") str)
  (match (string-tokenize str)
(("model" ":" model)
-(loop vendor family (string->number model)))
+(loop vendor family (string->number model flags)))
(_
-(loop vendor family model
+(loop vendor family model flags
+;; model for aarch64 and armhf
+((? (prefix? "CPU part") str)
+ (match (string-tokenize str)
+   (("CPU" "part" ":" model)
+(loop vendor family (string->number (string-drop model 2) 16) 
flags
+;; flags for x86_64 and i686
 ((? (prefix? "flags") str)
  (match (string-tokenize str)
(("flags" ":" flags ...)
-(cpu (utsname:machine (uname))
- vendor family model (list->set flags)
+(loop vendor family model (list->set flags)
+;; flags for aarch64 and armhf
+((? (prefix? "Features") str)
+ (match (string-tokenize str)
+   (("Features" ":" flags ...)
+(loop vendor family model (list->set flags)
 (_
- (loop vendor family model
+ (loop vendor family model flags
 
 (define (cpu->gcc-architecture cpu)
   "Return the architecture name, suitable for GCC's '-march' flag, that
@@ -191,6 +211,57 @@ (define (cpu->gcc-architecture cpu)
  ;; TODO: Recognize CENTAUR/CYRIX/NSC?
 
  "x86_64"))
+("aarch64"
+ ;; Transcribed from GCC's list of aarch64 processors in aarch64-cores.def
+ ;; What to do with big.LITTLE cores?
+ (match (cpu-vendor cpu)
+   ("0x41"
+(match (cpu-model cpu)
+  ((or #xd02 #xd04 #xd03 #xd07 #xd08 #xd09)
+   "armv8-a")
+  ((or #xd05 #xd0a #xd0b #xd0e #xd0d #xd41 #xd42 #xd4b #xd46 #xd43 
#xd44 #xd41 #xd0c #xd4a)
+   "armv8.2-a")
+  (#xd40
+   "armv8.4-a")
+  (#xd15
+   "armv8-r")
+  ((or #xd46 #xd47 #xd48 #xd49 #xd4f)
+   "armv9-a")))
+   ("0x42"
+"armv8.1-a")
+   ("0x43"
+(match (cpu-model cpu)
+  ((or #x0a0 #x0a1 #x0a2 #x0a3)
+   "armv8-a")
+  (#x0af
+   "armv8.1-a")
+  ((or #x0b0 #x0

bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Efraim Flashner]

On Mon, May 09, 2022 at 11:44:28AM +0300, Efraim Flashner wrote:
> On Mon, May 09, 2022 at 12:14:50AM +0200, Ludovic Courtès wrote:
> > Hi!
> > 
> > Vagrant Cascadian  skribis:
> > 
> > > Well, I guess I answered my initial question by reading the error
> > > message... guix/cpu.scm ... how did that work before for things like
> > > cross-building, where /proc/cpuinfo is *definitely* wrong to get
> > > information about the architecture you're building for?
> > 
> > (guix cpu) is used when passing ‘--tune’, which is used for native
> > builds:
> > 
> >   
> > https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu-micro-architecture/
> 
> I have a WIP patch for adding CPU detection for aarch64. Perhaps it'll
> help with the issues?

(ins)[efraim@pbp guix]$ ./pre-inst-env guix shell --export-manifest gsl 
openblas gcc-toolchain --tune
;;; note: source file /home/efraim/workspace/guix/guix/cpu.scm
;;;   newer than compiled /home/efraim/workspace/guix/guix/cpu.go

;;; ("aarch64" #f #f #f #< vhash: # insert: 
# ref: 
#>)
hint: Consider passing the `--check' option once to make sure your shell does 
not clobber environment variables.

guix shell: tuning gsl@2.7 for CPU armv8-a
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(use-modules (guix transformations))

(define transform1
  (options->transformation '((tune . "armv8-a"

(packages->manifest
  (list (transform1 (specification->package "gsl"))
(transform1 (specification->package "openblas"))
(transform1
  (specification->package "gcc-toolchain"


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#55283: ‘tests/guix-shell-export-manifest.sh’ fails on aarch64-linux

[Efraim Flashner]

On Mon, May 09, 2022 at 12:14:50AM +0200, Ludovic Courtès wrote:
> Hi!
> 
> Vagrant Cascadian  skribis:
> 
> > Well, I guess I answered my initial question by reading the error
> > message... guix/cpu.scm ... how did that work before for things like
> > cross-building, where /proc/cpuinfo is *definitely* wrong to get
> > information about the architecture you're building for?
> 
> (guix cpu) is used when passing ‘--tune’, which is used for native
> builds:
> 
>   
> https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu-micro-architecture/

I have a WIP patch for adding CPU detection for aarch64. Perhaps it'll
help with the issues?

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 26894a74e7a1ed861a170239e26d13f1298fe5ac Mon Sep 17 00:00:00 2001
Message-Id: 
<26894a74e7a1ed861a170239e26d13f1298fe5ac.1644401681.git.efr...@flashner.co.il>
In-Reply-To: 
References: 
From: Efraim Flashner 
Date: Wed, 9 Feb 2022 12:07:55 +0200
Subject: [PATCH 5/5] WIP: guix: cpu: Add detection for aarch64 CPUs.

* guix/cpu.scm (current-cpu): Extend existing implementation to also
read cpuinfo from aarch64 machines.
(cpu->gcc-architecture): Add case for aarch64.
---
 guix/cpu.scm | 70 
 1 file changed, 70 insertions(+)

diff --git a/guix/cpu.scm b/guix/cpu.scm
index 6d44599822..d4dbd5f6b8 100644
--- a/guix/cpu.scm
+++ b/guix/cpu.scm
@@ -66,25 +66,47 @@ (define (prefix? prefix)
   (match (read-line port)
 ((? eof-object?)
  #f)
+;; vendor for x86_64 and i686
 ((? (prefix? "vendor_id") str)
  (match (string-tokenize str)
(("vendor_id" ":" vendor)
 (loop vendor family model
+;; vendor for aarch64 and armhf
+((? (prefix? "CPU implementer") str)
+ (match (string-tokenize str)
+   (("CPU" "implementer" ":" vendor)
+(loop vendor family model
+;; family for x86_64 and i686
 ((? (prefix? "cpu family") str)
  (match (string-tokenize str)
(("cpu" "family" ":" family)
 (loop vendor (string->number family) model
+;; model for x86_64 and i686
 ((? (prefix? "model") str)
  (match (string-tokenize str)
(("model" ":" model)
 (loop vendor family (string->number model)))
(_
 (loop vendor family model
+;; model for aarch64 and armhf
+((? (prefix? "CPU part") str)
+ (match (string-tokenize str)
+   (("CPU" "part" ":" model)
+(loop vendor family (string->number (string-append "#x" 
(string-drop model 2)
+   (_
+(loop vendor family model
+;; flags for x86_64 and i686
 ((? (prefix? "flags") str)
  (match (string-tokenize str)
(("flags" ":" flags ...)
 (cpu (utsname:machine (uname))
  vendor family model (list->set flags)
+;; flags for aarch64 and armhf
+((? (prefix? "Features") str)
+ (match (string-tokenize str)
+   (("Features" ":" flags ...)
+(cpu (utsname:machine (uname))
+ vendor family model (list->set flags)
 (_
  (loop vendor family model
 
@@ -192,6 +214,54 @@ (define (cpu->gcc-architecture cpu)
  ;; TODO: Recognize CENTAUR/CYRIX/NSC?
 
  "x86_64"))
+("aarch64"
+ (pk (cpu-architecture cpu)(cpu-vendor cpu)(cpu-family cpu) (cpu-model 
cpu)(cpu-flags cpu))
+ ;; Currently returns ("aarch64" #f #f #f #< vhash: # insert: # ref: #>)
+ ;; Transcribed from GCC's list of aarch64 processors in aarch64-cores.def
+ (match (cpu-vendor cpu)
+   ("0x41"
+(match (cpu-model cpu)
+  ((or #xd02 #xd04 #xd03 #xd07 #xd08 #xd09)
+   "armv8-a")
+  ((or #xd05 #xd0a #xd0b #xd0e #xd0d #xd41 #xd42 #xd4b #xd46 #xd43 
#xd44 #xd41 #xd0c #xd4a)
+   "armv8.2-a")
+  (#xd40
+   "armv8.4-a")
+  (#xd15
+   "armv8-r")
+  ((or #xd46 #xd47 #xd48)
+   "armv9-a")))
+   ("0x42"
+"armv8.1-a")
+   ("0x43"
+(match (cpu-model cpu)
+  (

bug#34427: bug#34453: [PATCH] build guile-static with guile-2.0

[Efraim Flashner]

On Tue, Apr 12, 2022 at 12:10:09PM +0200, zimoun wrote:
> Hi,
> 
> What is the status of this old patch #34453?
> 
> http://issues.guix.gnu.org/issue/34453
> 
> 
> On Sat, 16 Feb 2019 at 17:06, Ludovic Courtès  wrote:
> > Efraim Flashner  skribis:
> >
> >> When experimenting I found that using guile@2.0 as a base for
> >> guile-static, the resulting guile-static didn't segfault on the target
> >> architecture.
> >
> > As discussed in <https://issues.guix.info/issue/34427>, I would rather
> > fix the segfault in 2.2 than move back to 2.0 and effectively delay the
> > problem.
> 
> Note that #34427 is still open.

We can probably drop it. We'll pick it back up again if/when it comes up
again.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#34427: guile-bootstrap@2.2 segfault?

[Efraim Flashner]

On Tue, Apr 12, 2022 at 06:01:39PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner  skribis:
> 
> > On Tue, Feb 12, 2019 at 03:27:37PM +0100, Ludovic Courtès wrote:
> >> Hello Efraim,
> >> 
> >> Efraim Flashner  skribis:
> >> 
> >> > I'm testing %bootstrap-guile from bootstrap.scm and I'm getting a
> >> > segfault when runing guile --version. I've attached an strace of the
> >> > process.
> >> 
> >> To be clear, I believe this is for a *cross-compiled* Guile, right?
> >
> > That's right, %bootstrap-guile is extracted from $(guix build
> > --target=powerpc-linux-gnu bootstrap-tarballs)
> 
> Cross-compilation to aarch64-linux-gnu works fine:
> 
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped 
> --target=aarch64-linux-gnu) /bin/guile
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> warning: failed to install locale: Invalid argument
> 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@(guile-user)> %host-type
> $1 = "aarch64-unknown-linux-gnu"
> scheme@(guile-user)> ,q
> $ guix describe
> Generation 210  Apr 11 2022 09:34:10(current)
>   guix 7da907f
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: 7da907f90e74a4edf96d76ee457ff958265ef8d4
> --8<---cut here---end--->8---
> 
> The problem has to do specifically with powerpc-linux-gnu (this is with
> transparent emulation via QEMU+binfmt_misc):
> 
> --8<---cut here---start->8---
> $ unshare -mrf chroot $(guix build guile-static-stripped 
> --target=powerpc-linux-gnu) /bin/guile
> guile: warning: failed to install locale
> GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
> GC Warning: Couldn't read /proc/stat
> Pre-boot error; key: wrong-type-arg, args: (#f "Wrong type to apply: ~S" (#f) 
> (#f))qemu: uncaught target signal 6 (Aborted) - core dumped
> Aborted
> --8<---cut here---end--->8---
> 
> Unfortunately I fail to get a backtrace from that core dump.
> 
> Efraim, could you get a backtrace on the bare metal?
> 
> Besides, if PPC32 is the only platform that has a problem, I think this
> bug should not be a blocker.
> 
> WDYT?
> 
> Ludo’.

Here's what I get from strace when running on bare metal. I agree, if
it's only affecting ppc32 we shouldn't have it be a blocker.
28071 
execve("/gnu/store/imbgn3if51jxi1nhwwdb5q9dpkhz9aff-guile-static-stripped-3.0.7/bin/guile",
 ["/gnu/store/imbgn3if51jxi1nhwwdb5"...], 0xaf88c21c /* 30 vars */) = 0
28071 brk(NULL) = 0x10849000
28071 brk(0x108498d8)   = 0x108498d8
28071 uname({sysname="Linux", nodename="g4", ...}) = 0
28071 set_tid_address(0x10849068)   = 28071
28071 set_robust_list(0x10849070, 12)   = 0
28071 rt_sigaction(SIGRTMIN, {sa_handler=0x101154ac, sa_mask=[], 
sa_flags=SA_SIGINFO}, NULL, 8) = 0
28071 rt_sigaction(SIGRT_1, {sa_handler=0x1011558c, sa_mask=[], 
sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
28071 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
28071 ugetrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
28071 readlink("/proc/self/exe", "/gnu/store/imbgn3if51jxi1nhwwdb5"..., 4096) = 
81
28071 brk(0x1086a8d8)   = 0x1086a8d8
28071 brk(0x1086b000)   = 0x1086b000
28071 mprotect(0x1037f000, 4096, PROT_READ) = 0
28071 openat(AT_FDCWD, "/run/current-system/locale/2.33/locale-archive", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/gnu/store/-glibc-cross-powerpc-linux-gnu-2.33/share/locale/locale.alias",
 O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en_US.UTF-8/LC_IDENTIFICATION", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en_US.utf8/LC_IDENTIFICATION", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
28071 openat(AT_FDCWD, 
"/run/current-system/locale/2.33/en_US/LC_IDENTIFICATION", O_RDONL