bug#53406: union-build incorrectly handles grafts

[John Kehayias via Bug reports for GNU Guix]

Hi Ludo’,

Thanks for explaining!

‐‐‐ Original Message ‐‐‐

On Monday, January 24th, 2022 at 9:18 AM, Ludovic Courtès wrote:

>
> Grafting is a pretty basic process: in this case it replaces occurrences
> of /gnu/store/…-expat-2.4.1 with /gnu/store/…-expat-2.4.3, nothing more.
> It cannot guess that libexpat.so.1.8.1 was renamed to libexpat.so.1.8.3
> or anything like that.
>
> Is it a problem? Normally no, because users of shared libraries don’t
> refer to libraries by their fully-qualified name:
>
> --8<---cut here---start->8---
> $ objdump -x $(guix build dbus-glib)/bin/dbus-binding-tool|grep NEED.*expat
> NEEDED libexpat.so.1
> $ objdump -x $(guix build dbus-glib)/bin/dbus-binding-tool|grep RUNPATH
> RUNPATH 
> /gnu/store/wwmxxlmlhwljn39z0gsj6iai3zk67a2g-dbus-glib-0.110/lib:/gnu/store/5s6iz5f777rh23q4kv8gvqrsyy61cbjh-dbus-1.12.20/lib:/gnu/store/s0w7szfsajdy6cnrz2w7z4h5spyl4aaj-expat-2.4.1/lib:/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33/lib:/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gcc-10.3.0-lib/lib:/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/lib:/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/../../..
> --8<---cut here---end--->8---
>
> Likewise, ‘etc/ld.so.cache’ contains a reference to ‘libexpat.so.1’, not
> to ‘libexpat.so.1.8.1’.
>

(Your example output was not of a grafted libexpat in the RUNPATH, but point 
taken; I see the newer expat version on my (grafted) dbus-glib).

> Does that make sense? Or am I overlooking something?
>

Yes, that makes sense, thank you for clarifying. So this is the currently 
expected behavior. Ideally grafting would be smarter to maybe avoid this 
(missing changes in e.g. version number)? But I would guess this is not 
something that would be expected to cause a problem for the vast majority of 
cases, as you explain, and adds complexity to the process.

I'm glad to hear it all works! But...

Perhaps I was too hasty in noting this "problem" which like I said was not the 
error I originally encountered. I was using a package that constructs both the 
64- and 32-bit libraries to put in a container (say, a /lib32 and /lib64 or 
something similar to an FHS environment). A collision was happening between a 
file and directory, one being a good symlink and the other broken, rather than 
a "real" mismatch in file vs directory. Anyway, going back to that what I see 
is that one link is broken for the above reasons, but the good one is good 
because it is to the *ungrafted* library store path. I don't know now if these 
2 things are connected other than one led me to the other, but I turn now to 
what demonstrates my original problem.

I don't know why this happens or if it is something in this building process 
that is not correct, but I did come up with a minimal example (attached). The 
code is a bit odd in its stripped down form, though hopefully is clear in what 
way this would be used to do something useful (again, like an FHS environment 
or other container). Apologies for the old style and lack of gexps which I'm 
finally getting used to. The example package just tries to make a dummy package 
that has, for illustration, a "/lib64" and "/lib32" which link to the 
respective union-build inputs (of a single library for simplicity). I don't 
think the actual package being made matters so much, or how it is constructed, 
but that two inputs are union-builds of the same library (x86_64 and i686) 
which should have a graft of expat. Just my guess though.

Doing:

ls -la $(guix build -f graft-test.scm)/lib64/lib/libexpat*
lrwxrwxrwx 1 root root 71 Dec 31  1969 
/gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.la 
-> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
lrwxrwxrwx 1 root root 71 Dec 31  1969 
/gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so 
-> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so*
lrwxrwxrwx 1 root root 73 Dec 31  1969 
/gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1
 -> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1*
lrwxrwxrwx 1 root root 77 Dec 31  1969 
/gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1.8.1
 -> 
/gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1

is what we saw already: libexpat is the newer (replacement, 2.4.3) version, 
with the full version symlink broken since the version number is wrong. 
Likewise in other pieces that have the version number, like share/doc. Okay, 
that's expected. But now, in the i686-linux union-build input:

ls -la $(guix build -f graft-test.scm)/lib32/lib/libexpat*
lrwxrwxrwx 1 root root 71 Dec 31  1969 
/gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.la 
-> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-

bug#55111: CONFIG_HSA_AMD unset in recent kernels

[John Kehayias via Bug reports for GNU Guix]

Hi Guix,

In trying to update AMD's OpenCL stuff (ROCm) in Guix to the latest version, I 
found that CONFIG_HSA_AMD is not set in our kernel config which I think might 
be needed (for HSA, most visibly having a /dev/kfd if I'm understanding). I see 
it was set to 'm' in previous versions, like 4.19, but at some point has been 
unset.

Does anyone know why this was changed or have any reason not to set it in our 
kernel config?

I've tried building the kernel with this configuration change and it went fine, 
but haven't been able to properly test it just yet.

John

bug#55111: CONFIG_HSA_AMD unset in recent kernels

[John Kehayias via Bug reports for GNU Guix]

I can confirm setting CONFIG_HSA_AMD=y (setting it to 'm' didn't seem to work 
for me) made /dev/kfd available and the OpenCL ROCm work, including making 
OpenCL available to Darktable. Note that I tested this on a non linux-libre 
kernel (what I use) which may or may not be required for OpenCL on some 
hardware. This is on x86-64.

Are there any objections to enabling this option in our kernel config?

bug#55987: guix refresh -u doesn't output anything on updater failure

[John Kehayias via Bug reports for GNU Guix]

Hello,

$ guix refresh wayland-protocols
gnu/packages/freedesktop.scm:1029:2: warning: 'generic-html' updater failed to 
determine available releases for wayland-protocols

but

$ guix refresh wayland-protocols -u

outputs nothing (and exit code is not an error as that would show up in my 
prompt setup).

John

bug#55111: CONFIG_HSA_AMD unset in recent kernels

[John Kehayias via Bug reports for GNU Guix]

Hello,

--- Original Message ---
On Tuesday, April 26th, 2022 at 1:07 PM, John Kehayias 
 wrote:
>
> I can confirm setting CONFIG_HSA_AMD=y (setting it to 'm' didn't seem to work 
> for me) made /dev/kfd available and the OpenCL ROCm work, including making 
> OpenCL available to Darktable. Note that I tested this on a non linux-libre 
> kernel (what I use) which may or may not be required for OpenCL on some 
> hardware. This is on x86-64.
>
> Are there any objections to enabling this option in our kernel config?

Now that ROCm has been updated in #55948, I tested again if I needed this 
kernel config change. Indeed, without CONFIG_HSA_AMD I do not get OpenCL with 
ROCm (darktable-cltest fails, as does rocminfo). I again set this configuration 
option and it works.

Any obstacles to (re)enabling this configuration option?

Thanks!
John

bug#55443: [PATCH] gnu: emacs: Fix source snippet.

[John Kehayias via Bug reports for GNU Guix]

Hello,

I believe this bug is due to a change in emacs to where the 
tramp-default-remote-path was moved from tramp-sh.el to tramp.el: 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=695f6792f1524a446d276bf5c5e53bbb4c200909

Due to this the source snippet in emacs that adds guix paths did not work, as 
you should see by examining the variable: C-h v tramp-remote-path

I've tested this patch builds, sets tramp-remote-path, and alleviates the sudo 
problem I also experienced (for local tramp). Please test if this fixes it for 
you. And maybe someone can relay this to the guix-devel thread mentioned in 
case there is more to be done as per the discussion there.

Thanks,
John

From 9cf58b23bc169e173c363a8c9107caa90d2a8f71 Mon Sep 17 00:00:00 2001
From: John Kehayias 
Date: Tue, 21 Jun 2022 21:22:26 -0400
Subject: [PATCH] gnu: emacs: Fix source snippet.

Fixes .

* gnu/packages/emacs.scm (emacs)[source](snippet): Patch tramp.el rather than
tramp-sh.el as the code to be patched moved.
---
 gnu/packages/emacs.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 31b5c04324..0de4b7a5d5 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -106,7 +106,7 @@ (define-public emacs
   ;; Make sure Tramp looks for binaries in the right places on
   ;; remote Guix System machines, where 'getconf PATH' returns
   ;; something bogus.
-  (substitute* "net/tramp-sh.el"
+  (substitute* "net/tramp.el"
 ;; Patch the line after "(defcustom tramp-remote-path".
 (("\\(tramp-default-remote-path")
  (format #f "(tramp-default-remote-path ~s ~s ~s ~s "
-- 
2.36.1

bug#55443: [PATCH] gnu: emacs: Fix source snippet.

[John Kehayias via Bug reports for GNU Guix]

I forgot to CC other users on the bug, so I'm sending the message again. 
Apologies if you got this twice.


--- Original Message ---
On Tuesday, June 21st, 2022 at 9:53 PM, John Kehayias 
 wrote:


> Hello,
>
> I believe this bug is due to a change in emacs to where the 
> tramp-default-remote-path was moved from tramp-sh.el to tramp.el: 
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=695f6792f1524a446d276bf5c5e53bbb4c200909
>
> Due to this the source snippet in emacs that adds guix paths did not work, as 
> you should see by examining the variable: C-h v tramp-remote-path
>
> I've tested this patch builds, sets tramp-remote-path, and alleviates the 
> sudo problem I also experienced (for local tramp). Please test if this fixes 
> it for you. And maybe someone can relay this to the guix-devel thread 
> mentioned in case there is more to be done as per the discussion there.
>
> Thanks,
> JohnFrom 9cf58b23bc169e173c363a8c9107caa90d2a8f71 Mon Sep 17 00:00:00 2001
From: John Kehayias 
Date: Tue, 21 Jun 2022 21:22:26 -0400
Subject: [PATCH] gnu: emacs: Fix source snippet.

Fixes .

* gnu/packages/emacs.scm (emacs)[source](snippet): Patch tramp.el rather than
tramp-sh.el as the code to be patched moved.
---
 gnu/packages/emacs.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 31b5c04324..0de4b7a5d5 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -106,7 +106,7 @@ (define-public emacs
   ;; Make sure Tramp looks for binaries in the right places on
   ;; remote Guix System machines, where 'getconf PATH' returns
   ;; something bogus.
-  (substitute* "net/tramp-sh.el"
+  (substitute* "net/tramp.el"
 ;; Patch the line after "(defcustom tramp-remote-path".
 (("\\(tramp-default-remote-path")
  (format #f "(tramp-default-remote-path ~s ~s ~s ~s "
-- 
2.36.1

bug#55443: [PATCH] gnu: emacs: Fix source snippet.

[John Kehayias via Bug reports for GNU Guix]

Hello!

--- Original Message ---
On Wednesday, June 22nd, 2022 at 3:47 PM, Liliana Marie Prikler wrote:

> I saw, I reworded slightly, I pushed.
>

Thanks!

> > Maybe someone can relay this to the guix-devel thread mentioned in
> > case there is more to be done as per the discussion there.
>
> I don't think a discussion that is several months old has weight in
> deciding what to do with relatively newer bugs. In any case, I think
> our tramp fixes should at some point also end up in the actual tramp
> package, not just emacs itself :)
>

I didn't follow the discussion thread but thought it might be the same (or in 
addition to) this bug. In any event, sure let's leave that to the actual bug 
tracking.

And yes, we should see about getting this in emacs proper, they should have 
GNU's own Guix taken care of as well :)

> That being said, thanks for the fix and have a nice evening

Thanks for the quick review and push, have a great day too!

bug#50665: Docker 19.03 is no longer receiving updates.

[John Kehayias via Bug reports for GNU Guix]

Hello,

I believe this can be closed with Docker having been updated to the latest 
version in this patch series: https://issues.guix.gnu.org/52790

However, on the Go front, this leaves docker-compose to be updated to v2 which 
moves to Go. I tried to import the go package definition but it fails if using 
recursive to get the (many many) dependencies:

guix import go github.com/docker/compose/v2 -r
...
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Git error: reference 'refs/tags/v0.30.0' not found

In just doing the base package and finding what dependencies are missing, I hit 
this again with

guix import go k8s.io/client-go -r
...
ice-9/boot-9.scm:1683:16: In procedure raise-exception:
Git error: reference 'refs/tags/v0.9.20' not found

Anyway, I should open (after searching for any relevant issues) an issue for 
the Go importer and/or docker-compose updates. Just thought I capture what I've 
seen so far in trying to complete the Docker update.

John

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hello,

I currently use the flatwhatson channel (cc'ed on this email, hope that is okay 
Andrew!) and it has worked well for Emacs, though never tried anything else 
with libgccjit. It would be great to get this upstreamed in Guix, especially 
since libgccjit is a beast to build (more than emacs if I remember correctly).

Happy to help test and work on this, let me know anything I can do.

Thanks,
John

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hi,

--- Original Message ---
On Tuesday, June 28th, 2022 at 12:17 AM, Liliana Marie Prikler wrote:

> Keyword here is "has worked for emacs". I've tried porting the logic
> from flatwhatson's channel over, but regardless of what I do, it
> already fails in the configure step of Emacs (in a manner that's
> reproducible outside as well). Thus, I think this is a bug in
> libgccjit (or perhaps our packaging of it) that simply happened to be
> ignored during development of Emacs 28, but no longer in the release.
>

Sorry, I should be extra clear that I mean has in the past and continues to 
work for Emacs. I've been using emacs-pgtk-native-comp through the flatwhatson 
channel from well before v28 was released. Currently I'm using 
emacs-pgtk-native-comp-28.1.50-223.3ddccb5. Everything has built, installed, 
and run fine for as long as I have been using it. Just in case that was in 
question, and as a point of reference.

Anyway, I'll try to reproduce when I can (tomorrow likely) what you reported in 
the first message using this setup, if that is of use.

Appreciate the efforts from everyone working on this!
John

bug#55111: CONFIG_HSA_AMD unset in recent kernels

[John Kehayias via Bug reports for GNU Guix]

Addressed in #56200, pushed by Leo as 44f2c7c2ca5d0a275c61d5bfd9dde1205590504b

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

Found out some useful info and a work around for the original reported issue of 
the simple "hello world" of gccjit not working.


--- Original Message ---
On Tuesday, June 28th, 2022 at 1:16 AM, John Kehayias wrote:

> Hi,
>
> --- Original Message ---
> On Tuesday, June 28th, 2022 at 12:17 AM, Liliana Marie Prikler wrote:
>
> > Keyword here is "has worked for emacs". I've tried porting the logic
> > from flatwhatson's channel over, but regardless of what I do, it
> > already fails in the configure step of Emacs (in a manner that's
> > reproducible outside as well). Thus, I think this is a bug in
> > libgccjit (or perhaps our packaging of it) that simply happened to be
> > ignored during development of Emacs 28, but no longer in the release.
>
>
> Sorry, I should be extra clear that I mean has in the past and continues to 
> work for Emacs. I've been using emacs-pgtk-native-comp through the 
> flatwhatson channel from well before v28 was released. Currently I'm using 
> emacs-pgtk-native-comp-28.1.50-223.3ddccb5. Everything has built, installed, 
> and run fine for as long as I have been using it. Just in case that was in 
> question, and as a point of reference.
>
> Anyway, I'll try to reproduce when I can (tomorrow likely) what you reported 
> in the first message using this setup, if that is of use.
>

I was able to reproduce the original error, though I used the libgccjit package 
from the flatwhatson channel, at v11.3.0 (along with GCC at that version). For 
good measure, I also used the tutorial at that version, just in case 
https://gcc.gnu.org/onlinedocs/gcc-11.3.0/jit/intro/tutorial01.html  I chose 
this version since that is what emacs-native-comp from that channel is built 
with.

Searching for these error messages of missing libraries/files, I found

https://ref.strikr.io/jit/internals/index.html#environment-variables

and a bug report at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87808

I didn't dive into the details and I'm not expert here, but it gave me the 
clues to work around it. Seems that where gccjit looks for things has some 
assumptions (bugs?) which we can fix at runtime with:

LIBRARY_PATH=$GUIX_ENVIRONMENT/lib/gcc/x86_64-unknown-linux-gnu/11.3.0:$LIBRARY_PATH
 ./gccjittest

The errors reported before were solved with this LIBRARY_PATH addition of the 
lib/gcc subdirectory. So, the test program runs in

guix shell gcc-toolchain@11 libgccjit@11 --pure

where I compiled to gccjittest following the tutorial directions (no change to 
LIBRARY_PATH).

So, looking at the emacs-native-comp definition in flatwhatson, we can see that 
a phase is used to set LIBRARY_PATH before configure just as I did here: 
https://github.com/flatwhatson/guix-channel/blob/master/flat/packages/emacs.scm#L65

Hope this is helpful and unblocks libgccjit and emacs-native-comp for Guix!

John

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hi,

Looks like the code you sent got line wrapped and I couldn't easily untangle 
it. The difference that pops out to me is how you are locating the lib/gcc 
directory, is it maybe picking up from the build system rather than libgccjit? 
(though I think gcc:lib should be the same here, but not gcc-toolchain)

In any event, I just want to reiterate that the libgccjit and emacs-native-comp 
from Andrew's channel does indeed work: it compiles, runs, and does native 
compilations successfully. So hopefully we've narrowed down now that there is 
some difference in the code you tried and from Andrew's that is leading to 
different behavior.

John

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hello,

--- Original Message ---
On Friday, August 5th, 2022 at 5:31 PM, Liliana Marie Prikler wrote:

> The style changes are not the only thing at play here, though. In
> particular, I am trying to build Emacs 28.1, whereas Andrew builds
> other versions, though notably the newest one ought to include the
> smoke test. You could also try other combinations for libgccjit and
> gcc to see if those make a difference – last time I tried it did not.
>

I'm seeing the same version, 28.1.90, in yours and from Andrew's channel. And 
just checking that indeed it is 28.1.90 that I've been running locally from 
that channel, with libgccjit@11.3.0. I have not tried with v29.

> Attached the definitions as a file this time.
>

Thanks, will play around with it this weekend to see if I have anything useful 
to add.

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Hi,

--- Original Message ---
On Saturday, August 6th, 2022 at 1:53 AM, Liliana Marie Prikler 
 wrote:

> Pardon that, it's an artifact from trying to fetch 28.1.90 via url-
> fetch and failing. Note that the hash is the one for 28.1.

On Andrew's channel I can change the version/commit/hash to 28.1 and it builds 
fine. Though this is using a git checkout at the 28.1 tag commit, but I don't 
think that matters here? (Emacs runs too, but only tried in guix shell and just 
to see it opens, didn't see if it compiles anything.)

And yet with your code I cannot. I tried using the phase from Andrew instead of 
your code, tried adding gcc to the native-inputs to match Andrew, used gcc-11 
with libgccjit-11, ...still the same configure failure on the libgccjit test 
program: can't find libgccjit.so

Weird.

Adding just the libgccjit library path to LD_LIBRARY_PATH makes configure find 
libgccjit, but then fails to find libx11 in that same libgccjit test program. 
Instead, making LD_LIBRARY_PATH=LIBRARY_PATH fixes the configure and it finally 
fails on the runpath validation. Maybe cause of messing with LD_LIBRARY_PATH or 
could use the patch Andrew has? Anyway, wasn't looking into this.

I thought I had a similar problem with the test program you had started with, 
but in the end just the LIBRARY_PATH tweak was needed. I wish I could remember 
the combination of things I tried that also had it failing to find libgccjit. 
Or perhaps it was something libgccjit was linked to, but I hadn't explored?

So. I tried to see what was different between your and Andrew's code and I'm 
not seeing what it could be. There must be some subtle difference we're 
missing? Seems we have all the ingredients and a known working example.

John

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

--- Original Message ---
On Sunday, August 7th, 2022 at 9:59 AM, Liliana Marie Prikler wrote:

> It's a really stupid one. Basically, the tests and really any
> executable you try to build fails to execute without LD_LIBRARY_PATH
> set. Now obviously, that's an issue with ld and you know which package
> has ld? That's right, it's binutils!
>

Ah! That LD_LIBRARY_PATH was needed was the clue.

> In Andrew's recipe, he sneakily snarfed out binutils from inputs using
> assoc-ref, but I'm using the new package style with (this-package-
> input) to achieve the same thing, so I had to add binutils. But this
> now shadows ld-wrapper. So we have to add ld-wrapper as well. Now
> this makes me question whether the driver options are actually sane or
> whether we'd have to prepend ld-wrapper to those as well.
>

Is the assoc-ref for binutils (implicit input?) equivalent to just using 
#$binutils directly? e.g. (string-append "-B" #$binutils "/bin/") with no added 
binutils to the inputs. Is that not a good idea? As a test, that does indeed 
work, everything configures, builds, and runs (only tested opening with no 
configuration).

> WDYT, Andrew?

bug#55657: libgccjit is unusable

[John Kehayias via Bug reports for GNU Guix]

Thanks for the new patchset Lily, very excited to have emacs with native 
compiliation in upstream Guix! (At the very least so I don't have to compile 
libgccjit and emacs)

For everyone following along at home, please see 
https://issues.guix.gnu.org/57086

As for the original issue here, I guess the LIBRARY_PATH and ld shadowing is 
the workaround. I don't know if that is something that can/should be 
incorporated into the libgccjit package definition or should just be handled by 
any package using it. Currently, that will just be emacs anyway and hopefully 
the discussion here is useful to anyone trying to use libgccjit.

Thanks again Lily and Andrew for your work here!

bug#57480: Wrong Type To Apply on Reconfigure

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Tue, Aug 30, 2022 at 02:49 PM, 宋文武 wrote:

> Julien Lepiller  writes:
>
>> I don't know how to fix it, but here is what I think is the issue:
>>
>> in guix/scripts/system/reconfigure.scm:
>>
>> #:autoload   (guix describe) (current-channels)
>> ...
>> (define* (check-forward-update ...
>>(current-channels ...))
>>   (define new (current-channels)) ; this is supposed to be the
>>  ; autoloaded procedure, but it's the keyword argument
>>  ; which is a list
>>   ... ; uses of current-channels, the keyword argument
>>
>> Le Mon, 29 Aug 2022 23:01:46 -0400,
>> Christopher Rodriguez  a écrit :
>>
>>> Hello All,
>>>
>>> A change made in b084398 is preventing both my system and home
>>> configurations from building with a Wrong Type to Apply error. Did the
>>> channel spec format change with the changes in that commit?
>
> Hello, I revert the commit b084398 for now.

Thanks, I was able to reconfigure after a guix pull to
466038b2e552f5550252afb1a22e3936bc455cfc

John

bug#58861: guix shell emulate-fhs option can have wrong glibc package

[John Kehayias via Bug reports for GNU Guix]

Hi Guixers,

(cc'ing Ludo’ as author of the commit referenced below)

After commit 

 I noticed a changed in behavior of guix shell with the emulate-fhs option for 
a container. I tracked it down to the wrong glibc package appearing in the 
container, i.e. the standard Guix version rather than glibc-for-fhs (which 
reads a global ld cache).

The cause I believe is related to , namely 
that package input order for a profile can matter. But it is slightly different 
here since the glibc-for-fhs package is added internally.

We can see this demonstrated by comparing the FHS container with a -D input so 
that a glibc package is implicitly included (here from the gnu-build-system):

--8<---cut here---start->8---
❯ guix shell -CFD hello coreutils
john@narya ~/Files/UPenn/canvasgrading [env]$ ls /lib/ld* -la
lrwxrwxrwx 1 65534 overflow 69 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 79 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2
--8<---cut here---end--->8---

Note that the loader comes from the standard glibc package. This means it won't 
read from the global cache.

However, if we change the order, placing the FHS option after the (implicit) 
glibc input, we do get the glibc-for-fhs package. This is similar to #58859 
which I just reported:

--8<---cut here---start->8---
❯ guix shell -CD hello -F coreutils
The following derivation will be built:
  /gnu/store/1hvdkgp68nak827qx6vhmrixdixnl6yl-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
building directory of Info manuals...
building profile with 23 packages...

[env]$ ls /lib/ld* -la
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2
--8<---cut here---end--->8---

Here the ld loader is as it should be for the FHS container.

This was not the behavior before 8b192c5550213911f930594f4fd7386f36618237, 
where the option handling was moved to shell rather than environment for 
emulate-fhs. Reverting this commit and doing the same thing, I get

--8<---cut here---start->8---
❯ ./pre-inst-env guix shell -CFD hello coreutils

[env]$ ls -la /lib/ld*
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2

[env]$ exit

❯ ./pre-inst-env guix shell -CD hello -F coreutils

[env]$ ls -la /lib/ld*
lrwxrwxrwx 1 65534 overflow 77 Jan  1  1970 /lib/ld-2.33.so -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-2.33.so
lrwxrwxrwx 1 65534 overflow 87 Jan  1  1970 /lib/ld-linux-x86-64.so.2 -> 
/gnu/store/dhd4a04vxs6nzz0kqnhp0f2sm1q1xbkq-glibc-for-fhs-2.33/lib/ld-linux-x86-64.so.2
--8<---cut here---end--->8---

Both cases have the expected behavior. The glibc-for-fhs package being added to 
the profile is done last, when creating the manifest, so I think it is the last 
package in the list and thus "wins out" over the glibc from the --development 
input (in keeping with the behavior noted in #58859).

Further, I don't reproduce the bug that the commit above was supposed to fix: 
running the same FHS container shell multiple times (so the profile is cached) 
does not give me any errors. Although I didn't test for this specifically 
before the final FHS patches, I did (and do) use the same cached profiles 
repeatedly.

Was the bug in using the --profile option in combination with --emulate-fhs? I 
haven't tested that, but I could see that being the problem instead.

Assuming there is a problem with profiles and emulate-fhs, what is the best fix 
here? My guess is to put the glibc-for-fhs package always last to make sure it 
is the glibc of the profile in this case to always have the same (expected) 
behavior.

Thanks!
John

bug#58859: profile contents depends on package order

[John Kehayias via Bug reports for GNU Guix]

Hi Guix,

(I'm cc'ing the devel list for this bug report as I think some wider input and 
commentary would be worthwhile.)

While investigating a bug with the --emulate-fhs option (bug report 
forthcoming) I noticed that the profile contents can depend on the order of 
packages given as input to guix shell. The FHS bug is also due to argument 
order, but I think is clearly a bug and not expected behavior (wrong glibc 
included in the container). Though maybe we want to look around for other 
argument order problems or have some tests?

Actually, this is true for profiles more generally, as I just quickly tested 
the first example with "guix install" rather than just shell. My examples are 
all with shell, but I guess it comes down to the same thing. I think this is 
trickier with shell and the -D option, as we'll see in the second example.

First example, where we might expect something to happen, though personally I 
expected a profile collision error:

--8<---cut here---start->8---
❯ guix shell ffmpeg@4 ffmpeg@5

❯ ls -la $(which ffmpeg)
lrwxrwxrwx 1 root root 67 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/bin/ffmpeg -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/bin/ffmpeg*

❯ ls -la $GUIX_ENVIRONMENT/lib/libavdevice.so*
lrwxrwxrwx 1 root root 75 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.58 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58*
lrwxrwxrwx 1 root root 85 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.58.13.100
 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58.13.100*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.59 -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59*
lrwxrwxrwx 1 root root 84 Dec 31  1969 
/gnu/store/ivfa3mjhqiqc91m5h27sr9gfyzwnv1d0-profile/lib/libavdevice.so.59.7.100 
-> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59.7.100*
--8<---cut here---end--->8---

Note that the last specified package, ffmpeg@5, takes precedence here for bin, 
and the lib directory contains a mixture (as there are some unique filenames as 
well).

To compare, we do the same thing with the order of ffmpeg versions switched. As 
we might guess, the profile was not cached; this is a different profile.

--8<---cut here---start->8---
❯ guix shell ffmpeg@5 ffmpeg@4
The following derivation will be built:
  /gnu/store/2273cnn0wpgid93na7wbhzijrz0r0hlx-profile.drv

building CA certificate bundle...
listing Emacs sub-directories...
building fonts directory...
generating GLib schema cache...
building directory of Info manuals...
building XDG desktop file cache...
building XDG MIME database...
building profile with 2 packages...

❯ ls -la $(which ffmpeg)
lrwxrwxrwx 1 root root 67 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/bin/ffmpeg -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/bin/ffmpeg*

❯ ls -la $GUIX_ENVIRONMENT/lib/libavdevice.so*
lrwxrwxrwx 1 root root 75 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.58 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58*
lrwxrwxrwx 1 root root 85 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.58.13.100
 -> 
/gnu/store/hx4xf70yjgycx0asv1k1h33p7xms15m8-ffmpeg-4.4.2/lib/libavdevice.so.58.13.100*
lrwxrwxrwx 1 root root 78 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.59 -> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59*
lrwxrwxrwx 1 root root 84 Dec 31  1969 
/gnu/store/c3r3n5fxjs5r4lbjvz1x6rdlgbi8bv8a-profile/lib/libavdevice.so.59.7.100 
-> 
/gnu/store/51gal8hjxilk1f26f3m3ggdhg9rykz6s-ffmpeg-5.1.2/lib/libavdevice.so.59.7.100*
--8<---cut here---end--->8---

This confirms the ordering of inputs to guix shell matters.

As a rather contrived example we might expect the user is paying attention with 
this explicit package input conflict. However, this also happens when that is 
not clear from the package names without inspecting package definitions.

See this second example, where the sdl2 package given to guix shell does not 
match the sdl2-2.0 input of ffmpeg@4 (with the -D argument):

--8<---cut here---start---

bug#58861: guix shell emulate-fhs option can have wrong glibc package

[John Kehayias via Bug reports for GNU Guix]

Hi simon and Ludo’,

Before I forget, nckx helpfully pointed out that I linked to the wrong commit, 
which made this all the more confusing. The correct commit is

<https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8b192c5550213911f930594f4fd7386f36618237>

On Wed, Nov 02, 2022 at 01:47 PM, zimoun wrote:

> Hi,
>
> On sam., 29 oct. 2022 at 05:31, John Kehayias via Bug reports for GNU Guix
>  wrote:
>
>> --8<---cut here---start->8---
>> ❯ guix shell -CFD hello coreutils
>
>> ❯ guix shell -CD hello -F coreutils
>> --8<---cut here---end--->8---
>
> Unrelated, “guix package” provides some ’%actions’ and as reported in
> [1], the command-line order matters – when it should not be.  Maybe, as
> proposed in [1], “guix shell” could process a « plan » with always the
> same order, whatever the command-line order is.
>
> 1: <http://issues.guix.gnu.org/issue/50473>
>

Thanks, I'll take a look. Seems like we may want to have a more systematic 
method here.

bug#58861: [PATCH] shell: Fix '--emulate-fhs' sometimes not including 'glibc-for-fhs'.

[John Kehayias via Bug reports for GNU Guix]

Hi Ludo’,

On Wed, Nov 02, 2022 at 04:50 PM, Ludovic Courtès wrote:

> Hi John,
>
> John Kehayias  skribis:
>
>> After commit
>> 
>> I noticed a changed in behavior of guix shell with the emulate-fhs option 
>> for a
>> container. I tracked it down to the wrong glibc package appearing in the 
>> container, i.e.
>> the standard Guix version rather than glibc-for-fhs (which reads a global ld 
>> cache).
>>
>> The cause I believe is related to , 
>> namely that
>> package input order for a profile can matter. But it is slightly different 
>> here since
>> the glibc-for-fhs package is added internally.
>>
>> We can see this demonstrated by comparing the FHS container with a -D input 
>> so that a
>> glibc package is implicitly included (here from the gnu-build-system):
>>
>> ❯ guix shell -CFD hello coreutils
>> john@narya ~/Files/UPenn/canvasgrading [env]$ ls /lib/ld* -la
>> lrwxrwxrwx 1 65534 overflow 69 Jan 1 1970 /lib/ld-2.33.so ->
>> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-2.33.so
>> lrwxrwxrwx 1 65534 overflow 79 Jan 1 1970 /lib/ld-linux-x86-64.so.2 ->
>> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ld-linux-x86-64.so.2
>
> How about fixing it by moving the (alist-cons 'expression …) thing right
> before the ‘options-with-caching’ call in ‘parse-args’?
>
> That way it would no longer be sensitive to the position of ‘-F’ on the
> command line.
>

Good idea, that worked! I didn't think right away of an easier way of doing 
this, so I added another let binding to easily check for '--emulate-fhs' in the 
parsed arguments.

> Could you give it a try and add a test?
>

I added a test that explicitly includes 'glibc' in the 'guix shell' invocation 
and checked the link to '/lib/libc.so' was from 'glibc-for-fhs'. Again, not 
sure if there is a better way here, but the test does pass now and fails 
without the change you proposed. I also checked against the examples I gave 
originally and looked good there too.

Patch attached. I included an explanation (and link) of this bug and the fix in 
the commit message.

Thanks and let me know if there is anything to improve here!

John
From 72be4a15a10916ae8d51dfb2998d6179bc57be59 Mon Sep 17 00:00:00 2001
From: John Kehayias 
Date: Thu, 3 Nov 2022 14:25:09 -0400
Subject: [PATCH] shell: Fix '--emulate-fhs' sometimes not including
 'glibc-for-fhs'.

Fixes .

Previously the order of the options giving to 'guix shell' could mean that the
'glibc-for-fhs' package included with the '--emulate-fhs' option would not
appear in the container.  For example, using the development option with a
package using the 'gnu-build-system', e.g. 'guix shell -CFD hello', would
include the regular 'glibc' package.  The option ordered mattered: 'guix shell
-CD hello -F' would include the expected 'glibc-for-fhs'.  We fix this by
having 'glibc-for-fhs' added to the package list just before calling
'options-with-caching' so the option order given by the user does not matter.

* guix/scripts/shell.scm (%options): Move the '--emulate-fhs' (expression
. ...) component from here...
(parse-args): ... to here.
* tests/guix-environment-container.sh: Add a test to check that
'glibc-for-fhs' is in the container even when 'glibc' is included in the 'guix
shell' package list.
---
 guix/scripts/shell.scm  | 26 ++
 tests/guix-environment-container.sh | 10 ++
 2 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/guix/scripts/shell.scm b/guix/scripts/shell.scm
index a2836629ad..f334bd57ae 100644
--- a/guix/scripts/shell.scm
+++ b/guix/scripts/shell.scm
@@ -143,16 +143,7 @@ (define %options
 
   (option '(#\F "emulate-fhs") #f #f
   (lambda (opt name arg result)
-(let ((result
-   ;; For an FHS-container, add the (hidden)
-   ;; package glibc-for-fhs which uses the global
-   ;; cache at /etc/ld.so.cache.
-   (alist-cons
-'expression
-'(ad-hoc-package
-  "(@@ (gnu packages base) glibc-for-fhs)")
-result)))
- (alist-cons 'emulate-fhs? #t result)
+(alist-cons 'emulate-fhs? #t result
 (filter-map (lambda (opt)
   (and (not (any (lambda (name)
(member name to-remove))
@@ -173,8 +164,19 @@ (define (parse-args args)
   ;; The '--' token is used to separate the command to run from the rest of
   ;; the operands.
   (let ((args command (break (cut string=? "--" <>) args)))
-(let ((opts (parse-command-line args %options (list %default-options)
-  

bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?

[John Kehayias via Bug reports for GNU Guix]

On Tue, Dec 06, 2022 at 09:07 AM, Marek Paśnikowski wrote:

Hello!

(resending as it seems debbugs in Emacs doesn't automatically add the
bug number email in the To/CC list.)

> I recently started attempting to execute an AppImage with
> guix shell --container --emulate-fhs .

Great! You may want to see this recent mailing list thread and draft
blog post which also covers exactly this in an example:

specifically: https://lists.gnu.org/r/guix-devel/2022-12/msg00156.html

and: https://issues.guix.gnu.org/60112

> I found a workflow, where I set LD_LIBRARY_PATH=$LIBRARY_PATH
> and trace the executable with strace -ffZ ./Program.AppImage .

In the FHS container you shouldn't need to set LD_LIBRARY_PATH. There
was a bug in the first weeks after it was merged (where this would work
around it), but assuming you have updated somewhat recently this
shouldn't be needed in genera.

> Its concept is that I want to turn each failing call to a successful
> one, until the program runs flawlessly.

I think this way lies madness. There will always be a ton of failing
calls, by nature of how things work. In particular, if you haven't see
this blog post, which covers exactly this (library loading), it was
enlightening for me at least:

https://guix.gnu.org/blog/2021/taming-the-stat-storm-with-a-loader-cache/

> I program as a hobby, and have no way of knowing if any of the
> trace calls can be safely ignored.
>
> I would like to encourage development of such an implementation,
> where strace -ffZ output is reduced as much as possible by default.

But in general I agree, I also use strace to find out what is breaking.
Often you want to see the last set of calls, but not always.

> Here is the head of the current trace I am stuck at:
>
>> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file
>> or directory)
>>
>> openat(AT_FDCWD, "/gnu/store/c8ndz685xbqm29r9zwlwsbjqj4ylh4m4-
>> profile/lib/tls/x86_64/x86_64/libdl.so.2", O_RDONLY|O_CLOEXEC) =
>> -1 ENOENT (No such file or directory)
>
> The second line is the interesting one.

Yes, the first one should be ignored as far as I know and is not
important.

The second one could be a failure, if that is where it stops looking for
libdl and errors out. So a more complete log, or at least the end where
an actual failure happens, would be helpful. As well as the exact
command you are running and the AppImage (if it is free software, of
course) would be good. Usually you'll see lots of these ENOENT errors
until it finds it in one of the search paths, or else an actual error
that the library could not be found and loaded.

> According to an ancient post on the Linux Questions forum[1],

This link didn't show for me.

> $PATH/lib/tls is the directory for glibc with thread support (NPTL).
> I do not know if the glibc in Guix has the thread support or not.
> However, it is the next two subdirectories that baffle me.
> x86_64/x86_64?  I have never seen anything like this.
> I thought, that maybe having a tls->. link in the lib directory
> would suppress the failure, but lib also does not have
> an x86_64 directory.
>
> I have spent a couple of hours chasing the libdl libry,
> only to realise that it is supplied by glibc, and it is
> the AppImage program trying to reach it in a different place.
> I strongly believe that solving this mode of failure will save
> countless hours of futile struggle for future users of Guix Shell.
> For the same purpose, the first error can be permanently silenced
> by creating an empty file at /etc/ld.so.preload .

I'm not certain you are actually failing at libdl. The FHS container
will show this library in /lib and in the ld cache, which should cover
just about everything trying to find it. More details would be helpful.

Hope this helps in the meantime!
John

bug#60566: [PATCH] environment: Fix '--emulate-fhs' option overriding $PATH.

[John Kehayias via Bug reports for GNU Guix]

On Wed, Jan 04, 2023 at 11:33 PM, jman wrote:

> Hello,
>
> When emulating a FHS I observe that env vars seems to be not preserved. 
> Example,
> the following command will not preserve $PATH:
>
> guix shell --container --emulate-fhs --preserve='^PATH$'
>
> When creating a container *without* emulating a FHS, env vars are available,
> example:
>
> guix shell --container --preserve='^PATH$'
>
> Pastebin log of a sample of this behaviour:
> https://paste.sr.ht/~jman/65e7f96c445504e11f55595b237280e0c1e3ad34
>
> ref: https://lists.gnu.org/archive/html/help-guix/2023-01/msg2.html
>
> Thanks for an opinion on this

Thanks for reporting, I can confirm this behavior.

Here is a patch for this where the FHS directories are added to the
current value of $PATH. I believe this should in general be fine since
this is the last step before actually calling the command given to 'guix
shell' and thus $PATH has been set or preserved as needed already.

CC'ing Ludo as most familiar with this code. Anything we should be aware
of here? This change to $PATH in the first place wasn't strictly needed
('guix shell' already has the profile bin directory) but I thought made
sense to make it look most like FHS.

Thanks!
John

From 57cdc3a8f9c6451aaf17f1fafae0bcf29faeea03 Mon Sep 17 00:00:00 2001
From: John Kehayias 
Date: Thu, 5 Jan 2023 16:06:19 -0500
Subject: [PATCH] * environment: Fix '--emulate-fhs' option overriding $PATH.

Fixes  where even if "--preserve='^PATH$'"
was passed to 'guix shell' it would be replaced by just the FHS directories
when '--emulate-fhs' was also set.

* gnu/scripts/environment.scm (launch-environment): Add the FHS directories to
$PATH rather than overriding $PATH completely.
---
 guix/scripts/environment.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index c7fd8fd340..20fa5850c4 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -475,10 +475,11 @@ (define* (launch-environment command profile manifest
  (catch 'system-error
(lambda ()
  (when emulate-fhs?
-   ;; When running in a container with EMULATE-FHS?, override $PATH
+   ;; When running in a container with EMULATE-FHS?, augment $PATH
;; (optional, but to better match FHS expectations), and generate
;; /etc/ld.so.cache.
-   (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin")
+   (setenv "PATH" (string-append "/bin:/usr/bin:/sbin:/usr/sbin:"
+ (getenv "PATH")))
(invoke "ldconfig" "-X"))
  (apply execlp program program args))
(lambda _
-- 
2.38.1

bug#60566: [PATCH] environment: Fix '--emulate-fhs' option overriding $PATH.

[John Kehayias via Bug reports for GNU Guix]

Hi Ludo’,

On Sat, Jan 07, 2023 at 12:03 AM, Ludovic Courtès wrote:

> To be safe, you need to account for (getenv "PATH") returning #f, and
> not add a trailing colon in that case.
>

Ah, right. I think this would only happen if somehow unsetting PATH and 
preserving it? As 'guix shell' already sets PATH. Anyway, better to be safe 
here.

I tweaked this, though not sure if there is a more elegant way to construct the 
string than what I did (suggestions always welcome!).

> Other than that, I agree this is a valid change because that would be
> consistent with:
>
> $ PATH=/foo $(type -P guix) shell -E ^PATH$ -C coreutils -- env |grep ^PATH
> PATH=/gnu/store/pfl0lyqbs557khv7rw90bzp24qp2lqsn-profile/bin:/foo
>
> Perhaps you can add a line to test it in
> ‘tests/guix-environment-container.sh’?
>

I added two tests while I was at it: one to check that PATH has the FHS 
modification in the container and a second for this particular bug. For the 
second one I just used a test string added to PATH as the entire thing will 
differ already from inside/outside the container, FHS or not. I checked the 
tests pass here and removing '--emulate-fhs' causes the first to fail while 
removing the '--preserve' argument causes the second test to fail. I could 
separate the first out as a separate commit if that makes more sense, but I do 
think the current behavior is just wrong in overwriting all of PATH when 
'--emuate-fhs' is given.

New version attached, thanks for the suggestions!

John
From beb6f9255fc62fe52e237f82c7e953a21b7f82f4 Mon Sep 17 00:00:00 2001
From: John Kehayias 
Date: Thu, 5 Jan 2023 16:06:19 -0500
Subject: [PATCH] * environment: Fix '--emulate-fhs' option overriding $PATH.

Fixes  where even if "--preserve='^PATH$'"
was passed to 'guix shell' it would be replaced by just the FHS directories
when '--emulate-fhs' was also set.

* gnu/scripts/environment.scm (launch-environment): Add the FHS directories to
$PATH rather than overriding $PATH completely.
* tests/guix-environment-container.sh: Test that FHS directories are in $PATH
in the container and that $PATH can be preserved.
---
 guix/scripts/environment.scm|  8 +---
 tests/guix-environment-container.sh | 18 +-
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index c7fd8fd340..19ba2f7bee 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -2,7 +2,7 @@
 ;;; Copyright © 2014, 2015, 2018 David Thompson 
 ;;; Copyright © 2015-2022 Ludovic Courtès 
 ;;; Copyright © 2018 Mike Gerwitz 
-;;; Copyright © 2022 John Kehayias 
+;;; Copyright © 2022, 2023 John Kehayias 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -475,10 +475,12 @@ (define* (launch-environment command profile manifest
  (catch 'system-error
(lambda ()
  (when emulate-fhs?
-   ;; When running in a container with EMULATE-FHS?, override $PATH
+   ;; When running in a container with EMULATE-FHS?, augment $PATH
;; (optional, but to better match FHS expectations), and generate
;; /etc/ld.so.cache.
-   (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin")
+   (setenv "PATH" (string-append "/bin:/usr/bin:/sbin:/usr/sbin"
+ (when (getenv "PATH")
+   (string-append ":" (getenv "PATH")
(invoke "ldconfig" "-X"))
  (apply execlp program program args))
(lambda _
diff --git a/tests/guix-environment-container.sh b/tests/guix-environment-container.sh
index 0306fc1744..198352c1e2 100644
--- a/tests/guix-environment-container.sh
+++ b/tests/guix-environment-container.sh
@@ -1,6 +1,6 @@
 # GNU Guix --- Functional package management for GNU
 # Copyright © 2015 David Thompson 
-# Copyright © 2022 John Kehayias 
+# Copyright © 2022, 2023 John Kehayias 
 #
 # This file is part of GNU Guix.
 #
@@ -242,6 +242,22 @@ guix shell -CF --bootstrap guile-bootstrap glibc \
0
1))'
 
+# Test that $PATH inside the container has FHS directories.
+guix shell -CF --bootstrap guile-bootstrap \
+ -- guile -c '(exit (if (string-contains (getenv "PATH")
+"/bin:/usr/bin:/sbin:/usr/sbin")
+   0
+   1))'
+
+# Make sure '--preserve' is honored for $PATH, which the '--emulate-fhs'
+# option will modify.  We can't (easily) check the whole $PATH as it will
+# differ inside and outside the container, so just check for an added string.
+PATH=this-is-a-test:$PATH guix shell -CF --bootstrap guile-bootstrap -E PATH \
+ -- guile -c '(exit (if (string-contains (getenv "PATH")
+"this-is-a-test")
+   0
+   1))'
+
 # '--symlink' works.
 echo "TESTING SYMLINK IN CONTAINER"
 guix shell --boots

bug#60566: [PATCH] environment: Fix '--emulate-fhs' option overriding $PATH.

[John Kehayias via Bug reports for GNU Guix]

Hi Ludo’,


On Sat, Jan 14, 2023 at 03:41 PM, Ludovic Courtès wrote:

> Hi John,
>
> John Kehayias  skribis:
>
> [...]
>
>> -   (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin")
>> +   (setenv "PATH" (string-append "/bin:/usr/bin:/sbin:/usr/sbin"
>> + (when (getenv "PATH")
>> +   (string-append ":" (getenv 
>> "PATH")
>
> Remember that ‘when’ returns *unspecified* when the condition is false,
> so you’d get a type error here when PATH is undefined.
>
> Instead write: (if (getenv "PATH") … "").
>

Ah yes, my Common Lisp showing through and relying on nil instead. Fixed and 
thanks!

>> +# Test that $PATH inside the container has FHS directories.
>> +guix shell -CF --bootstrap guile-bootstrap \
>> + -- guile -c '(exit (if (string-contains (getenv "PATH")
>> +"/bin:/usr/bin:/sbin:/usr/sbin")
>> +   0
>> +   1))'
>
> Even (exit (string=? (getenv "PATH") "/bin:/usr/bin:/sbin:/usr/sbin")).
>

With this patch PATH now gets the FHS directories in addition to what it 
normally has (like the profile's bin directory). While slightly redundant, this 
seems to be better than clobbering it. Anyway, so we can't check that the PATH 
is completely equal here.

>> +# Make sure '--preserve' is honored for $PATH, which the '--emulate-fhs'
>> +# option will modify.  We can't (easily) check the whole $PATH as it will
>> +# differ inside and outside the container, so just check for an added 
>> string.
>> +PATH=this-is-a-test:$PATH guix shell -CF --bootstrap guile-bootstrap -E 
>> PATH \
>> + -- guile -c '(exit (if (string-contains (getenv "PATH")
>> +"this-is-a-test")
>> +   0
>> +   1))'
>
> It might be slightly more concise with ‘env’:
>
>   PATH=/foo $(type -P guix) shell -E ^PATH$ -C coreutils -- env |grep 
> ^PATH=.*:/foo
>
> (I think ‘--bootstrap’ doesn’t buy us much here because we have to
> download/build ‘glibc-for-fhs’ anyway.  ‘--bootstrap’ and
> ‘guile-bootstrap’ are particularly useful for testse that can run
> without network access and without building tons of stuff, as in
> ‘tests/guix-environment.sh’ for instance.)
>

Ah, thanks, that is nicer if we can just use coreutils. I rewrote the previous 
test to use that as well. Probably some other tests here could use that 
simplification, but outside of the scope here.

(Side note that 'type' in zsh works differently, one could use 'whence' there 
or even the built-in 'which'. For the tests we are running with bash or bash 
compliant here, so it is not a problem.)

> Otherwise LGTM, thanks!
>
> Ludo’.

Thanks again for your careful review! Pushed as 
3bfbfa2946aebb7f68c8027ae80f272f6915c94f and closing this issue.

Thanks also for jman for reporting.

John

bug#59855: Emacs Debbugs reply (was Re: bug#59855: Guix Shell with FHS Feedback: lib/tls/x86_64/x86_64?)

[John Kehayias via Bug reports for GNU Guix]

Hi simon,

On Thu, Jan 05, 2023 at 12:31 PM, Simon Tournier wrote:

> Hi John,
>
> On Fri, 23 Dec 2022 at 05:39, John Kehayias via Bug reports for GNU
> Guix  wrote:
>
>> (resending as it seems debbugs in Emacs doesn't automatically add
>> the
>> bug number email in the To/CC list.)
>
> Well, I think it is about Gnus and not Debbugs.  There is bunch of
> option to reply with Gnus. :-)
>
> 9 candidates:
> gnus-summary-reply
> gnus-summary-wide-reply
> gnus-summary-very-wide-reply
> gnus-summary-reply-with-original
> gnus-summary-reply-broken-reply-to
> gnus-summary-wide-reply-with-original
> gnus-summary-reply-to-list-with-original
> gnus-summary-very-wide-reply-with-original
> gnus-summary-reply-broken-reply-to-with-original
>
>
> Personally, I have this config (the only Gnus keybinding I use ;-))
>
>   (define-key gnus-summary-mode-map "R" 
> 'gnus-summary-wide-reply-with-original)
>   (define-key gnus-article-mode-map "R" 
> 'gnus-summary-wide-reply-with-original)
>
> which is consistent with Emacs Notmuch key binding.
>
>
> Hope that helps,
> simon

Yes that helps, exactly what I would have expected, thanks! It is now also my 
only Gnus keybindings, matching my others (mu4e in my case).

Much appreciated,
John

bug#62313: VDPAU can't find backends

[John Kehayias via Bug reports for GNU Guix]

Hi Guix,

Currently VDPAU, through libvdpau, can't find backends as they are not part of 
where it will search:



Namely, it will search where it is configured to at build time via pkg-config, 
but for us our backends will be somewhere in the store unknown unless we 
include e.g. mesa as an input. Rather than increasing the closure to include 
any VDPAU backends (I know of mesa and libvdpau-va-gl), an environment variable 
can be specified at runtime, VDPAU_DRIVER_PATH.

However, I'm not sure how we can use that as a search path unless we require 
users to install libvdpau and a backend, like mesa, in their profile. This 
doesn't seem like the cleanest option.

Any other options?

For testing, here is mpv not finding a VDPAU backend (trying with vaapi or 
hwdec auto will use vaapi successfully):

--8<---cut here---start->8---
❯ guix shell mpv -- mpv -vo=vdpau ~/test.mkv
 (+) Video --vid=1 (*) (h264 1920x1080 30.000fps)
 (+) Audio --aid=1 (*) 'Track1' (aac 2ch 48000Hz)
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
file: No such file or directory
[vo/vdpau] Error when calling vdp_device_create_x11: 1
Error opening/initializing the selected video_out (--vo) device.
Video: no video

Exiting... (Errors when loading file)
--8<---cut here---end--->8---

but we can specify mesa explicitly:

--8<---cut here---start->8---
❯ VDPAU_DRIVER_PATH=$(guix build mesa | tail -n1)/lib/vdpau guix shell mpv -- 
mpv -vo=vdpau ~/test.mkv
 (+) Video --vid=1 (*) (h264 1920x1080 30.000fps)
 (+) Audio --aid=1 (*) 'Track1' (aac 2ch 48000Hz)
[vo/vdpau] Warning: this compatibility VO is low quality and may have issues 
with OSD, scaling, screenshots and more.
[vo/vdpau] vo=gpu is the preferred choice in any case and includes VDPAU 
support via hwdec=vdpau or vdpau-copy.
AO: [pulse] 48000Hz stereo 2ch float
VO: [vdpau] 1920x1080 yuv420p
[vo/vdpau] Compositing window manager detected. Assuming timing info is 
inaccurate.
AV: 00:00:00 / 00:20:25 (0%) A-V:  0.005 DS: 2.067/0

Exiting... (Quit)
--8<---cut here---end--->8---

Or, of course, using vdpauinfo:

--8<---cut here---start->8---
❯ guix shell vdpauinfo -- vdpauinfo
display: :0.0   screen: 0
Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
file: No such file or directory
Error creating VDPAU device: 1
❯ VDPAU_DRIVER_PATH=$(guix build mesa | tail -n1)/lib/vdpau guix shell 
vdpauinfo -- vdpauinfo
display: :0.0   screen: 0
API version: 1
Information string: G3DVL VDPAU Driver Shared Library version 1.0

Video surface:

name   width height types

42016384 16384  NV12 YV12
42216384 16384  UYVY YUYV
44416384 16384  Y8U8V8A8 V8U8Y8A8
420_16 16384 16384
422_16 16384 16384
444_16 16384 16384

[...]
--8<---cut here---end--->8---

John

PS: I didn't check in detail, but I would guess 
 is related; though there at least mesa is 
an input for VLC (including libvdpau-va-gl wouldn't be much for a 1.6 gig 
package already).

bug#62493: xelatex won't render fonts correctly without full texlive

[John Kehayias via Bug reports for GNU Guix]

Hi TeX Guixers,

Ran into a curious problem today of xelatex not properly rendering what I think 
is a mapping/ligature issue: the usual TeX ``something'' quote syntax should 
become proper double quotes (for English at least) but don't.

Here is a simple test tex file:

--8<---cut here---start->8---
\documentclass{article}
\begin{document}
``test quote''
\end{document}
--8<---cut here---end--->8---

If you compile it with

--8<---cut here---start->8---
guix shell texlive-base texlive-fontspec -- xelatex test.tex
--8<---cut here---end--->8---

you'll see the same quotes as in the tex file. Full log (test-bad.log) attached 
but the relevant line looks to me like

--8<---cut here---start->8---
Document Class: article 2020/04/10 v1.4m Standard LaTeX document class
(/gnu/store/npkjqvkgzj3pfhqwbcc504kgp1z6fj8s-profile/share/texmf-dist/tex/latex/base/size10.clo
File: size10.clo 2020/04/10 v1.4m Standard LaTeX file (size option)
Font mapping `tex-text.tec' for font `[lmroman10-regular]:mapping=tex-text;' 
not found.
)
--8<---cut here---end--->8---

I did try adding various packages, changing fonts and font settings, but to no 
avail.

Meanwhile, using

--8<---cut here---start->8---
guix shell texlive -- xelatex test.tex
--8<---cut here---end--->8---

gives a nicely rendered double quote mark. The log (also attached as test.log) 
shows no such similar message.

Some searching the most succinct and relevant summary I think is here 


Anyway, seems like something is missing when we use the minimal packages, but I 
can't seem to find what to add to guix shell to change the output of the pdf. 
Probably it is not captured in a package or is otherwise lost?

Any ideas?

Thanks!
John

PS: I don't think it is related, but xelatex will complain about not finding a 
fontspec.cfg either. I made one locally from what it used to be, but didn't 
change the output for me. I think it went missing here:




test.log
Description: Binary data


test-bad.log
Description: Binary data

bug#62513: network-manager updated to unstable version?

[John Kehayias via Bug reports for GNU Guix]

Hi Guix,

(cc'ing Maxim as author of last few network-manager version updates.)

I noticed a recent up date to network-manager to 1.43.4 (previously 1.41.2 and 
1.40.0) but can't find a record of that release. In their docs there is no 
mention of anything newer than the 1.42 release [0, 1] and they mention the 
even-numbered releases being the stable series [2]. Indeed, Arch only has 
1.42.4 in their repos [3]. I only see "dev" tags for these 1.43 versions in 
their gitlab.

Should we be on a 1.42.y version instead?

I noticed this because the update to 1.43.4 has an issue with my (wired) 
connection not resuming from sleep when previously it did. I have to restart 
the service. I had some logs I can dig up, but in discussing on IRC (no logs 
that day it seems) there was nothing out of the ordinary and the shepherd 
service seemed normal.

I've since reconfigured to a commit before the most recent version change, 
namely 5174820753be045ba4fc7cc93da33f4e0b730bc3 and cannot reproduce the issue 
so seems due to newer versions of network-manager after 1.41.2 at least.

Note that this may have been reported upstream [4], but I haven't tested with 
the current stable release. So this may be a separate (upstream) issue.

Anyway, the first question is what version we should have of network-manager?

Thanks!
John


[0 
]

[1] 

[2] 

[3] 

[4] 

bug#62493: xelatex won't render fonts correctly without full texlive

[John Kehayias via Bug reports for GNU Guix]

Hi Ricardo,

Note that I didn't get your replies as it was sent just to the debbugs
email (I always find it strange that the bug email alias doesn't send to
the submitter by default). This message from Simon was helpful for me,
at least via Emacs: https://issues.guix.gnu.org/59855#2 (perhaps you
already know or have some other method, but thought I'd mention it and
I'm open to more such tricks!)

Ricardo Wurmus  writes:

> We seem to be missing the xetex package that provides files for font mapping:
>
> $ info tex-text.tec
> tlmgr.pl: cannot find package tex-text.tec, searching for other matches:
>
> Packages containing `tex-text.tec' in their title/description:
>
> Packages containing files matching `tex-text.tec':
> xepersian:
>   texmf-dist/fonts/misc/xetex/fontmapping/xepersian/persian-tex-text.tec
> xetex:
>   texmf-dist/fonts/misc/xetex/fontmapping/base/tex-text.tec
>

Ah, that's good to know, thanks for figuring that out.

> I was under the impression that we did have a xetex package, but I can’t
> find it now.

I also don't see any record of such a package. Trying

--8<---cut here---start->8---
guix shell subversion -- guix import texlive xetex
[...]
Exported revision 59745.
A/tmp/guix-directory.cKaqWd/doc/xetex/base
A/tmp/guix-directory.cKaqWd/doc/xetex/base/NEWS
A/tmp/guix-directory.cKaqWd/doc/xetex/base/README
A/tmp/guix-directory.cKaqWd/doc/xetex/base/XeTeX-notes.pdf
A/tmp/guix-directory.cKaqWd/doc/xetex/base/XeTeX-notes.tex
Exported revision 59745.
A/tmp/guix-directory.cKaqWd/fonts/misc/xetex/fontmapping/base
A/tmp/guix-directory.cKaqWd/fonts/misc/xetex/fontmapping/base/qx-unicode.map
A/tmp/guix-directory.cKaqWd/fonts/misc/xetex/fontmapping/base/qx-unicode.tec
A/tmp/guix-directory.cKaqWd/fonts/misc/xetex/fontmapping/base/tex-text.map
A/tmp/guix-directory.cKaqWd/fonts/misc/xetex/fontmapping/base/tex-text.tec
Exported revision 59745.
svn: E160013: File not found: revision 66702, path 
'/tags/texlive-2021.3/Master/texmf-dist/tcode'
command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" 
"svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/tcode/" 
"/tmp/guix-directory.cKaqWd/tcode/" failed with status 1
guix import: error: failed to download description for package 'xetex'
--8<---cut here---end--->8---

or with a -r as well:

--8<---cut here---start->8---
Exported revision 59745.
A/tmp/guix-directory.XcAtR6/doc/xetex/base
A/tmp/guix-directory.XcAtR6/doc/xetex/base/NEWS
A/tmp/guix-directory.XcAtR6/doc/xetex/base/README
A/tmp/guix-directory.XcAtR6/doc/xetex/base/XeTeX-notes.pdf
A/tmp/guix-directory.XcAtR6/doc/xetex/base/XeTeX-notes.tex
Exported revision 59745.
A/tmp/guix-directory.XcAtR6/fonts/misc/xetex/fontmapping/base
A/tmp/guix-directory.XcAtR6/fonts/misc/xetex/fontmapping/base/qx-unicode.map
A/tmp/guix-directory.XcAtR6/fonts/misc/xetex/fontmapping/base/qx-unicode.tec
A/tmp/guix-directory.XcAtR6/fonts/misc/xetex/fontmapping/base/tex-text.map
A/tmp/guix-directory.XcAtR6/fonts/misc/xetex/fontmapping/base/tex-text.tec
Exported revision 59745.
svn: E160013: File not found: revision 66702, path 
'/tags/texlive-2021.3/Master/texmf-dist/tcode'
command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" "59745" 
"svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/tcode/" 
"/tmp/guix-directory.XcAtR6/tcode/" failed with status 1
Backtrace:
   8 (primitive-load "/home/john/.config/guix/current/bin/gu…")
In guix/ui.scm:
   2300:7  7 (run-guix . _)
  2263:10  6 (run-guix-command _ . _)
In guix/scripts/import.scm:
89:11  5 (guix-import . _)
In ice-9/boot-9.scm:
  1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/import/texlive.scm:
92:38  3 (_)
In guix/import/utils.scm:
   638:27  2 (recursive-import _ #:repo->guix-package _ #:guix-name . #)
   630:33  1 (lookup-node "xetex" #f)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong number of values returned to continuation (expected 2)
--8<---cut here---end--->8---

I'm not up to with texlive packaging, any tips? Or perhaps someone we
can ask for input here?

Thanks!
John

bug#62493: xelatex won't render fonts correctly without full texlive

[John Kehayias via Bug reports for GNU Guix]

"Ricardo Wurmus"  writes:

> John Kehayias  writes:
>
>> Exported revision 59745.
>> svn: E160013: File not found: revision 66702, path
>> '/tags/texlive-2021.3/Master/texmf-dist/tcode'
>> command "svn" "export" "--non-interactive" "--trust-server-cert"
>> "-r" "59745"
>> "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/tcode/"
>> "/tmp/guix-directory.XcAtR6/tcode/" failed with status 1
>
> The importer is naive and assumes that any file in tlpdb starts with
> “texmf-dist/”.  For the xetex package there’s a file
> “tlpkg/tlpostcode/xetex.pl” and if you drop the same number of
> characters that you would for “texmf-dist/” you end up with
> “tcode/xetex.pl”.
>
> Oops!

Unfortunately that leaves me at a bit of a loss for making a
texlive-xetex package as I'm not understanding the whole texlive package
structure at first glance. I've tried something similar to other
packages I see but haven't gotten anywhere.

Any pointers or similar package to look at?

Thanks!

bug#62493: xelatex won't render fonts correctly without full texlive

[John Kehayias via Bug reports for GNU Guix]

Hi Ricardo,

On Wed, Mar 29, 2023 at 05:32 PM, Ricardo Wurmus wrote:

> John Kehayias  writes:
>
>> Exported revision 59745.
>> svn: E160013: File not found: revision 66702, path
>> '/tags/texlive-2021.3/Master/texmf-dist/tcode'
>> command "svn" "export" "--non-interactive" "--trust-server-cert"
>> "-r" "59745"
>> "svn://www.tug.org/texlive/tags/texlive-2021.3/Master/texmf-dist/tcode/"
>> "/tmp/guix-directory.XcAtR6/tcode/" failed with status 1
>
> The importer is naive and assumes that any file in tlpdb starts with
> “texmf-dist/”.  For the xetex package there’s a file
> “tlpkg/tlpostcode/xetex.pl” and if you drop the same number of
> characters that you would for “texmf-dist/” you end up with
> “tcode/xetex.pl”.
>
> Oops!

I see you pushed some fixes for this (I didn't try with -r as that kept running 
for a while and might have tried to generate a whole lot of the dependency 
tree), thanks! I do get an import for xetex now.

And on that note I see cbf731ae481b434e657b05c80b4a32282e5d112b which adds 
texlive-xetex.

I can confirm with guix shell texlive-base texlive-fontspec texlive-xetex -- 
xelatex test.tex the output pdf has proper quotation marks and the log looks 
clean.

Many thanks!
John

bug#62672: Unexpected interaction between gobject-introspection and grafts

[John Kehayias via Bug reports for GNU Guix]

Hi Collin and Josselin,

I haven't fully read this thread but wanted to chime in with work I did
but never finalized to upstream here. In short, I did get taffybar to
build and run if I recall. There was a lot of fussing with versions,
some Haskell packages that were broken/undergoing some breaking changes
at the time...I don't remember the details, sorry.

https://gitlab.com/podiki/guix-pod/-/blob/main/taffybar.scm

Checking now taffybar does not build (some dependent package failing,
looks like needs an input change) but ghc-gi-gdk does. This should be
the bulk of the work you need beyond polishing (linting, license checks,
all that). It is a lot of packages, many are the autogenerated
haskell-gi packages as I'm sure you are familiar.

On the gobject-introspection front, I do remember needing some tinkering
there for cairo, and ended up using what was suggested here:
https://issues.guix.gnu.org/49122#4

I haven't used Taffybar much since I went back to my lisp land (StumpWM)
but hopefully this is helpful. Some Haskell experts can chime in with
other details or polishing once it builds.

Let me know if you need help parsing this early and rough packaging I
did, though I think it shouldn't take much to get it to build again
(famous last words, I know).

John

bug#62956: Fail to update gajim: [PATCH] Updates for python-k5test and python-gssapi

[John Kehayias via Bug reports for GNU Guix]

Thanks for the ping, I missed this message in time before the merge.

On Mon, Apr 24, 2023 at 11:52 AM, Andreas Enge wrote:

> Am Mon, Apr 24, 2023 at 10:51:31AM +0200 schrieb Simon Tournier:
>> Please note #62956 reporting the failure and proposing a patch.
>
> Thanks for the notice! On core-updates, the current gajim requires
> python-gssapi, which fails to build; so this would have to be repaired
> additionally to the above patch.
>

I will send the two patches for the needed updates and then gajim
builds for me locally (I only built and checked that it ran, though it
wouldn't open a window in my pure environment at least). I'll attempt
with the new mumi updates, so it may take a bit for me to get it set
up.

Notes:

1. For python-k5tests I removed all inputs (guix refresh -u suggested
   some) and everything built and seemed to work fine for
   python-gssapi. I'm not familiar with these packages though.

2. gajim built for me with only the addition of python-idna, but again
   did not test extensively.

If they look good feel free to push to master (after QA if it sees
these patches?) or I can later if no complaints.

John

bug#62956: [PATCH 1/2] gnu: python-k5test: Update to 0.10.3.

[John Kehayias via Bug reports for GNU Guix]

* gnu/packages/python-xyz.scm (python-k5test): Update to 0.10.3.
[propagated-inputs]: Remove.
[native-inputs]: Remove.
[arguments]{phases}: Remove.
---
 gnu/packages/python-xyz.scm | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 0abfa226f4..849b75ead2 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -26096,30 +26096,15 @@ (define-public python-forbiddenfruit
 (define-public python-k5test
   (package
 (name "python-k5test")
-(version "0.9.2")
+(version "0.10.3")
 (source
  (origin
(method url-fetch)
(uri (pypi-uri "k5test" version))
(sha256
 (base32
- "1lqp3jgfngyhaxjgj3n230hn90wsylwilh120yjf62h7b1s02mh8"
+ "07sp9hc6nkbgzywvr2ivcik03wibs6gmxm1k33l1b8v3mnyfx7cw"
 (build-system python-build-system)
-(propagated-inputs
- (list python-six
-   ;; `which`, `kadmin.local` binaries called inside library
-   which mit-krb5))
-(native-inputs (list mit-krb5))
-(arguments
- '(#:phases
-   (modify-phases %standard-phases
- (add-after 'unpack 'apply-upstream-fixes
-   (lambda* _
- (substitute* "k5test/realm.py"
-   ;; Upstream commit f6b302d94dbdce37a1b81cc3faeeac4dc637b0e9.
-   (("'kadmin_local'") "'kadmin.local'")
-   ;; Upstream commit 3aef84515cf3d1a171c66856c898d0a5cbbd03ea.
-   (("\\.stop_daemon") "._stop_daemon")))
 (home-page "https://github.com/pythongssapi/k5test";)
 (synopsis "Library for setting up self-contained Kerberos 5 environments")
 (description
--
2.39.2

bug#62956: [PATCH 2/2] gnu: python-gssapi: Update to 1.8.2.

[John Kehayias via Bug reports for GNU Guix]

* gnu/packages/python-xyz.scm (python-gssapi): Update to 1.8.2.
[native-inputs]: Add python-cython.  Order alphabetically.
---
 gnu/packages/python-xyz.scm | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 849b75ead2..247a842a3e 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -26117,22 +26117,25 @@ (define-public python-k5test
 (define-public python-gssapi
   (package
 (name "python-gssapi")
-(version "1.6.12")
+(version "1.8.2")
 (source
  (origin
(method url-fetch)
(uri (pypi-uri "gssapi" version))
(sha256
 (base32
- "1j2idrbrbczykzlb56q1bn0ivc9c0rjjljpk4yz86xn3gxfkpv8n"
+ "16n86nr19s95czvc1a9mdhs1kiq77qkcjp2c1rk5h4f93h10m3mp"
 (build-system python-build-system)
 (propagated-inputs
  (list python-decorator python-six))
 (inputs
  (list mit-krb5))
-;; for tests
 (native-inputs
- (list python-parameterized python-k5test python-nose))
+ (list python-cython
+   ;; for tests
+   python-k5test
+   python-nose
+   python-parameterized))
 (home-page "https://github.com/pythongssapi/python-gssapi";)
 (synopsis "Python GSSAPI Wrapper")
 (description
--
2.39.2

bug#62956: Fail to update gajim: [PATCH] Updates for python-k5test and python-gssapi

[John Kehayias via Bug reports for GNU Guix]

> I will send the two patches for the needed updates and then gajim
> builds for me locally (I only built and checked that it ran, though it
> wouldn't open a window in my pure environment at least). I'll attempt
> with the new mumi updates, so it may take a bit for me to get it set
> up.
>

Ah, when sending via mumi it was sent directly to the bug address and
didn't CC anyone else. Please see the patches starting at


> Notes:
>
> 1. For python-k5tests I removed all inputs (guix refresh -u suggested
>some) and everything built and seemed to work fine for
>python-gssapi. I'm not familiar with these packages though.
>
> 2. gajim built for me with only the addition of python-idna, but again
>did not test extensively.
>
> If they look good feel free to push to master (after QA if it sees
> these patches?) or I can later if no complaints.
>
> John

bug#63267: gcc-toolchain is missing libstdc++.so

[John Kehayias via Bug reports for GNU Guix]

Hi Christopher,

On Thu, May 04, 2023 at 11:05 AM, Christopher Rodriguez wrote:
>
> Sorry for the spam; Resending this without the bugs address, but with
> the issue's address.
>
> Christopher Rodriguez  writes:
>
>>
>> Hello All,
>>
>> I noticed today that libstdc++.so.1 (and some others), which used to be
>> part of gcc:lib, are not included in any of the outputs of the
>> superceding `gcc-toolchain` package.
>>
>> Is there another method for getting these needed shared libraries in a
>> guix system at this point? It's entirely possible I'm missing something.
>>
>> I am CCing guix-de...@gnu.org per podiki[m]'s request.
>>
>> Thanks!

Thanks for opening this and cc'ing; this has come up with some
frequency on IRC, especially recently. In discussing there today, the
current reasoning is that usually one will just call g++ which knows
how to find libstdc++. So, gcc-toolchain does not include gcc:lib as
part of what it makes available.

I think what we (and when this comes up, others) are getting at are
some edge cases or different use cases where one wants to directly get
at libstdc++. Previously it was more direct to use gcc:lib; of course
one still can in code and/or cli with the proper call. For example,
guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show
the lib output of the (hidden) gcc package. Though I'm not sure how to
select just the lib output here.

My use case currently is in the FHS container where a binary wants to
find some libraries directly. Previously one would include the gcc:lib
package output in the guix shell call. Now some of those libraries can
be found elsewhere, like libgccjit, but libstdc++ seems to be the
trickier one. Open to other suggestions/workarounds, or thoughts on if
it is worthwhile to include gcc:lib in the gcc-toolchain package (or
make a gcc-toolchain:lib output?).

Thanks all!
John

bug#63267: gcc-toolchain is missing libstdc++.so

[John Kehayias via Bug reports for GNU Guix]

Hi again,

On Thu, May 04, 2023 at 11:19 AM, John Kehayias wrote:

> Thanks for opening this and cc'ing; this has come up with some
> frequency on IRC, especially recently. In discussing there today, the
> current reasoning is that usually one will just call g++ which knows
> how to find libstdc++. So, gcc-toolchain does not include gcc:lib as
> part of what it makes available.
>

I tried locally just adding gcc:lib as an input for gcc-toolchain and
that does the trick. And since it is just a union-build, very quick to
try out :)

guix size reports an increase in gcc-toolchain as 0.1 MiB with gcc:lib
included.

> I think what we (and when this comes up, others) are getting at are
> some edge cases or different use cases where one wants to directly get
> at libstdc++. Previously it was more direct to use gcc:lib; of course
> one still can in code and/or cli with the proper call. For example,
> guix build -e "(@@ (gnu packages gcc) gcc)" will download/build/show
> the lib output of the (hidden) gcc package. Though I'm not sure how to
> select just the lib output here.
>
> My use case currently is in the FHS container where a binary wants to
> find some libraries directly. Previously one would include the gcc:lib
> package output in the guix shell call. Now some of those libraries can
> be found elsewhere, like libgccjit, but libstdc++ seems to be the
> trickier one. Open to other suggestions/workarounds, or thoughts on if
> it is worthwhile to include gcc:lib in the gcc-toolchain package (or
> make a gcc-toolchain:lib output?).
>

I tried with my local gcc-toolchain modification and this gets me what
I wanted.

On that note, I forgot to bring up the problem I had with using
make-libstdc++: it does not seem to build the same libstdc++ as
included in the gcc package. The doc string for that procedure notes
that this is meant to be used when using non-gcc toolchains, but we
also have the libstdc++ variable which seems to suggest that
(make-libstdc++ gcc) should be the same library as in gcc.

I'm not sure the difference in looking at the package definitions, but
I don't really know this stuff. Here's an example of the difference I
was finding:

I was running something and it complained that

--8<---cut here---start->8---
 symbol lookup error: : undefined symbol: 
_ZNSt18condition_variableD1Ev, version GLIBCXX_3.4.11
--8<---cut here---end--->8---

Indeed, looking at the libstdc++ I used via (or could have used
libstdc++ here directly since I used the default gcc):

--8<---cut here---start->8---
guix shell -e "(begin (use-modules (gnu packages gcc)) (make-libstdc++ gcc))"
--8<---cut here---end--->8---

I see

--8<---cut here---start->8---
$strings 
/gnu/store/6897bpw5858bdng744ddqw8rrqjb4frr-libstdc++-11.3.0/lib/libstdc++.so | 
grep "_ZNSt18condition_variableD1Ev"
--8<---cut here---end--->8---

while for gcc:lib it is defined

--8<---cut here---start->8---
$ strings 
/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-lib/lib/libstdc++.so | 
grep "_ZNSt18condition_variableD1Ev"
_ZNSt18condition_variableD1Ev
--8<---cut here---end--->8---

and using that libstdc++ does not result in that error.

Is make-libstdc++ not meant to be used/mixed with e.g. gcc-toolchain?
Is this expected that it is a different library produced or is this a
bug?

Thanks!
John

bug#63267: gcc-toolchain is missing libstdc++.so

[John Kehayias via Bug reports for GNU Guix]

Hi all,

> I have similar use cases of FHS containers to run binaries (primarily
> games). I recently ran into the issue of gcc:lib going away and no
> output from a visible package providing libstdc++. My current
> workaround was to implement a replacement for specifications->manifest
> that could handle packages and '(package "output") pairs in addition
> to strings, so that I could include `(,(@@ (gnu packages gcc) gcc)
> "lib") in place of "gcc:lib". Internally it resolves package strings
> to packages with specification->package, then passes the package and
> optional output specifier to package->manifest-entry. But I digress a
> little...

Nice little hack Kaelyn, would you mind sharing somewhere? I wonder if
this should be something we should have more easily anyway.

On Thu, May 04, 2023 at 12:14 PM, Katherine Cox-Buday wrote:

> On 5/4/23 11:33 AM, Kaelyn wrote:
>
>> Regarding solutions, I would prefer to have libstdc++ in it's own
>> package or output rather than bundled into gcc-toolchain:out; it
>> feels messy and against the grain of isolating programs in
>> containers if I have to make the gcc and g++ compilers available in
>> the container in order to run a program that needs libstdc++.
>
> +1. I recently ran into this as well and went looking for it.
>
> I think a good reason to give libstdc++ its own output is that this
> question continually gets asked.

That sounds reasonable to me as well. I would think the make-libstdc++
procedure would work for this, but as I detailed in my other message,
I'm not sure why it seems to be missing symbols. We would have just
what we need there and could just expose some public package versions
through that or leave it similar to how it is and document (so it is
more of an advanced or edge case scenario and not have more people
going that way when what they really want is the actual gcc-toolchain
package).

John

bug#63267: gcc-toolchain is missing libstdc++.so

[John Kehayias via Bug reports for GNU Guix]

Hi Kaelyn,

On Thu, May 04, 2023 at 11:45 PM, Kaelyn wrote:

> --- Original Message ---
> I wasn't sure the best place to share it, so I've attached my "run"
> script for running the binary download of PolyMC in a container. It is
> both a shell script and a guix package manifest, and is the one place
> so far I've worked around the removal of gcc:lib. The main
> program-specific bits are what CMD defaults to and which packages need
> to be included (most of the various shares are to get things like
> hardware 3D, pulseaudio, and dbus working and aren't all always
> needed). It also contains the original manifest commented-out for
> comparison. Hope it can be of help to folks!
>

Thanks, that's a nice little hack! Just something very minor I
noticed, but you don't need to specify glibc directly for the -F (FHS)
option in guix shell, as it will automatically include the (modified)
glibc.

This topic came up again on IRC today and GNUtoo had the correct cli
invocation for getting at gcc:lib. I thought I had tried something
similar but must have missed something, or else didn't notice that
this will only work for guix shell, as guix build doesn't take outputs
in the package list:

--8<---cut here---start->8---
guix shell  -e $'(list (@@ (gnu packages gcc) gcc) "lib")'
--8<---cut here---end--->8---

Thanks to both of you I have some options for workarounds currently,
but based on how this topic keeps coming up I still think we should
have a more straightforward option.

John

bug#62313: VDPAU can't find backends

[John Kehayias via Bug reports for GNU Guix]

Fixed with 02995444dbe9861c32b6e2cdbfb7a7b2affe2c2b

bug#48868: VLC cant find libvdpau_radeonsi.so when playing video

[John Kehayias via Bug reports for GNU Guix]

Hi Brendan,

On Sun, Jun 06, 2021 at 12:22 PM, Brendan Tildesley wrote:

> The file exists at
> /gnu/store/mwcgqw9ggi02p8mhzac8cg0x671j7wd1-mesa-20.2.4/lib/vdpau/libvdpau_radeonsi.so
> but it doesn't seem to be found (by libva?).
> Videos still play. Probably requires a Radeon card to reproduce.
> I got confused trying to figure out where exactly its loaded.
>
> libva info: VA-API version 1.10.0
> libva info: Trying to open 
> /gnu/store/gvncg7gzdzjx0gvyi4sm02m7qgnsmx5q-mesa-20.2.4/lib/dri/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_1_10
> libva info: va_openDriver() returns 0
> [7f6928001f80] glconv_vaapi_x11 gl error: vaDeriveImage: operation failed
> [7f69240ba3a0] main video output error: video output creation failed
> [7f69e8c929f0] main decoder error: failed to create video output
> Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
> file: No such file or directory
> Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
> file: No such file or directory

This has been fixed with 02995444dbe9861c32b6e2cdbfb7a7b2affe2c2b

bug#48868: VLC cant find libvdpau_radeonsi.so when playing video

[John Kehayias via Bug reports for GNU Guix]

Hi Brendan,

On Sun, Jun 06, 2021 at 12:22 PM, Brendan Tildesley wrote:

> The file exists at
> /gnu/store/mwcgqw9ggi02p8mhzac8cg0x671j7wd1-mesa-20.2.4/lib/vdpau/libvdpau_radeonsi.so
> but it doesn't seem to be found (by libva?).
> Videos still play. Probably requires a Radeon card to reproduce.
> I got confused trying to figure out where exactly its loaded.
>
> libva info: VA-API version 1.10.0
> libva info: Trying to open 
> /gnu/store/gvncg7gzdzjx0gvyi4sm02m7qgnsmx5q-mesa-20.2.4/lib/dri/radeonsi_drv_video.so
> libva info: Found init function __vaDriverInit_1_10
> libva info: va_openDriver() returns 0
> [7f6928001f80] glconv_vaapi_x11 gl error: vaDeriveImage: operation failed
> [7f69240ba3a0] main video output error: video output creation failed
> [7f69e8c929f0] main decoder error: failed to create video output
> Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
> file: No such file or directory
> Failed to open VDPAU backend libvdpau_radeonsi.so: cannot open shared object 
> file: No such file or directory

This has been fixed with 02995444dbe9861c32b6e2cdbfb7a7b2affe2c2b

bug#64200: Netsurf very frequently freezes when editing text (Harfbuzz issue?)

[John Kehayias via Bug reports for GNU Guix]

Hi Josselin and Csepp,

On Wed, Jun 21, 2023 at 11:08 AM, Josselin Poiret wrote:

> Hi Csepp,
>
> Csepp  writes:
>
>> Like the title says.  It never happens when just browsing, but happens
>> very frequently (like a minute after starting to type) when editing
>> text, at least on Brutaldon, but maybe on other sites too.
>>
>> I noticed that our Harfbuzz package is two entire major releases behind.
>> Maybe there are bugfixes in the latest one that we could use?
>>
>> I tried building it but it froze up my laptop for some reason (rather
>> strange, even if it runs out of memory it should just be killed by
>> earlyoom) so I haven't attempted to test this theory yet.
>>
>> Is there any particular reason Harfbuzz wasn't covered by the last
>> core-updates?  If it turns out to be a bug in it, what would be the best
>> way to proceed?
>
> core-updates was lagging behind, and while merging you don't want to
> introduce potential sources of issues.  This could maybe go into the
> graphics updates along with mesa, if John thinks it's appropriate.
>

Likely that it was just overlooked, these things happen. Despite being
two major releases behind, our version is less than a year old at
least, so it wasn't completely forgotten :)

I just tried a guix build harfbuzz --with-latest=harfbuzz and it
worked, but I only built once and didn't try dependents. A quick look
at the changelog shows mostly fixes and new API, doesn't look like
anything immediately obvious as breaking, but this will affect ~9000
packages.

I do think this could be a more impactful change than the Mesa update
but I say we put them all on a feature branch and see how the builds
work out. If harfbuzz needs more work than it seems, we can just hold
off on it and group it with the inevitable next Mesa update or some
other related packages.

How does that sound? I'll give it some days for comments on my
previous message about a Mesa branch but the patches here are all
trivial (so far...) so it would be nice to get builds started soon. My
thoughts for Mesa were hopefully just a few days of checking builds
and then merging, to keep it simple and straightforward. But we should
group builds together rather than wasting resources.

John

PS: Csepp if you can reproduce the build failure and attach a log
somewhere, that would be helpful. If newer harfbuzz is helpful but too
drastic of a change everywhere, we could have a 'harfbuzz-next' to
ease the transition.

PPS: I'll bring this up elsewhere, but on a similar vein I noticed our
freetype package is built without brotli support (anyone know why?).
It is needed for the update to Godot 4. I'll raise the details on a
forthcoming Godot patch.

bug#64200: Netsurf very frequently freezes when editing text (Harfbuzz issue?)

[John Kehayias via Bug reports for GNU Guix]

Dear Csepp,

On Thu, Jun 22, 2023 at 12:00 AM, Csepp wrote:

>
> So, I built Netsurf with --with-latest=harfbuzz, which also affected
> GTK+ and a bunch of other packages along the way, and it worked on my
> first attempt, just needed a stronger machine.
> I copied over the resulting Netsurf to my laptop and have been using it
> all day today, it seems to have shooed that bug away.
> (Don't squash bugs, bugs are good for the ecosystem. They are only a
> problem when they get inside your mainframe and cause a short. UwU)
> BTW there was no log when it caused my system to hang.  I had to reboot
> it with sysrq.  Probably a kernel bug?
>
> So it looks like Harfbuzz can be updated without any problem.

Great, that's good to hear and a nontrivial test too! I'll await
comments on this mesa+friends update branch and plan on including the
harfbuzz update there. Stay tuned...

John

bug#64200: Netsurf very frequently freezes when editing text (Harfbuzz issue?)

[John Kehayias via Bug reports for GNU Guix]

On Mon, Jun 26, 2023 at 04:16 AM, Csepp wrote:

> John Kehayias  writes:
>
>> Dear Csepp,
>>
>> On Thu, Jun 22, 2023 at 12:00 AM, Csepp wrote:
>>
>>> So, I built Netsurf with --with-latest=harfbuzz, which also affected
>>> GTK+ and a bunch of other packages along the way, and it worked on my
>>> first attempt, just needed a stronger machine.
>>> I copied over the resulting Netsurf to my laptop and have been using it
>>> all day today, it seems to have shooed that bug away.
>>> (Don't squash bugs, bugs are good for the ecosystem. They are only a
>>> problem when they get inside your mainframe and cause a short. UwU)
>>> BTW there was no log when it caused my system to hang.  I had to reboot
>>> it with sysrq.  Probably a kernel bug?
>>>
>>> So it looks like Harfbuzz can be updated without any problem.
>>
>> Great, that's good to hear and a nontrivial test too! I'll await
>> comments on this mesa+friends update branch and plan on including the
>> harfbuzz update there. Stay tuned...
>>
>> John
>
> Well, now the bug is back somehow???  I haven't updated anything since
> then.  Didn't change fonts either.
> Still happens in a Harfbuzz call.

Ah, sorry to hear that, that's annoying! I'll be making the mesa
branch today, but not sure if I'll include harfbuzz. I have another
font related big change, so maybe best to have a separate branch for
those. In either case, guess this doesn't help your bug, sorry!

John

bug#64369: Request for merging "mesa-updates" branch

[John Kehayias via Bug reports for GNU Guix]

Hello all,

This is a request to merge the recently created "mesa-updates" branch. 
Currently there are just 2 patches on there, fixing/updating mesa only. The 
main thing to see is how substitute building goes in case anything breaks, but 
I'm hoping there isn't anything caused by this update.

I believe the "ruby-team" and "tex-team-next" [1] are ahead in the queue, not 
sure the timing of where those are. In addition/alternatively, would it make 
sense to have this branch as a separate build job on Cuirass directly as the 
"kernel-updates" branch? This would need a build roughly every month or so when 
mesa puts out a new update, we check for breakages, and then merge to master 
with substitutes available already.

I wasn't sure if this needs formal blockers in debbugs for the other branch 
merge requests, let me know!

Thanks,
John

[0] 

[1] 

bug#66319: Incorrect code snippet in manual

[John Kehayias via Bug reports for GNU Guix]

Hi Gabriel,

On Mon, Oct 02, 2023 at 06:38 PM, Gabriel Hondet wrote:

> Hello,
>
> The code snippets of the page 'Sending a patch series' look incorrect to
> me: the snippets mention the email address
> "guix-patc...@debbugs.gnu.org" but the text mentions
> "guix-patc...@gnu.org".
>

It is possible that one is an alias for the other (I'm not sure), but as
far as I know I always use the guix-patc...@gnu.org address to start a
patch submission. After the initial email, as noted in the manual, you
get a bug number @debbugs.gnu.org to use.

> For instance,
>> We can now send just the cover letter to the guix-patc...@gnu.org
>> address, which will create an issue that we can send the rest of the
>> patches to.
>>
>> > $ git send-email outgoing/-cover-letter.patch -a \
>> >   --to=guix-patc...@debbugs.gnu.org \
>> >   $(etc/teams.scm cc-members ...)
>> > $ rm outgoing/-cover-letter.patch # we don't want to resend it!
>
> The documentation I'm looking at is the one accessible at
> https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches
> on the Monday, 2nd of October at 6pm (CEST) (a.k.a. 2023-10-02T18+02:00
> if you prefer ISO dates).
>

Ah, so this is the "1.4.0" manual rather than the current one:
.
This is a long standing confusion that needs to be sorted out, but in
short I would say the 1.4.0 manual is just to match the 1.4.0 installer,
but once installed and updated you should always use the manual that
matches your guix version. You can use "info guix" for instance, or the
web "devel" manual for the latest version.

So, yes, this is a potential error in the 1.4.0 manual but is corrected
in the current version. I don't think we can easily correct the old
version (it is already tagged and released) but we do have to clarify
the manual online for what version is what. This has been reported
before and there are some proposals, not sure why it hasn't been done
yet. Sorry about that!

> Cheers,
> Gabriel

Hope that is helpful! I'm going to close this in light of the above, but
feel free (or someone else) to reopen if needed.

Thanks for the close reading, doc errors and suggestions always welcome!

John

bug#59364: gnome clocks does not start due to missing libGLES.so

[John Kehayias via Bug reports for GNU Guix]

Hi all,

On Wed, Nov 30, 2022 at 09:47 PM, Simon Streit wrote:

> Csepp  writes:
>> It does work with LIBGL_ALWAYS_SOFTWARE=1, but it would be pretty messed
>> up if that had to be enabled globally.
>
> Thanks for that tip!
>
> I fired up a recent Fedora live image to see that these applications do
> work in wayland on this old machine.  Which they do.
>
> Gnome in Ferdora is already at 43.

Is this the same issue as in ? With
potential fix ? I'm looking to
include this on the next mesa-updates round coming up soon.

Thanks!
John

bug#64981: GTK4 applications broken (missing libGLESv2)

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

Not sure if people saw this patch, has anyone tested if it fixes the
problem for them? I can include it in an upcoming mesa-updates branch
with other related updates/rebuilds.



Hope I got everyone from the original bug thread (seems many replies
didn't go directly to everyone) and cc'ed the patch number as well.

Thanks!
John

On Sat, Aug 19, 2023 at 10:59 AM, iyzs...@envs.net wrote:

> From: 宋文武 
>
> Fixes .
>
> * gnu/packages/gl.scm (libepoxy)[arguments]<#:phases>:
> Hardcode paths to libGLESv1_CM.so.1 and libGLESv2.so.2.
> ---
>  gnu/packages/gl.scm | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
> index b53b42a9ba..f662f0f7da 100644
> --- a/gnu/packages/gl.scm
> +++ b/gnu/packages/gl.scm
> @@ -742,10 +742,14 @@ (define-public libepoxy
>#~(modify-phases %standard-phases
>(add-before 'configure 'patch-paths
>  (lambda* (#:key inputs #:allow-other-keys)
> -  (let ((mesa (dirname (search-input-file inputs 
> "lib/libGL.so"
> +  (let ((mesa-lib
> + (lambda (file)
> +   (search-input-file inputs (string-append "lib/" 
> file)
>  (substitute* (find-files "." "\\.[ch]$")
> -  (("libGL.so.1") (string-append mesa "/libGL.so.1"))
> -  (("libEGL.so.1") (string-append mesa 
> "/libEGL.so.1")
> +  (("libGL.so.1") (mesa-lib "libGL.so.1"))
> +  (("libEGL.so.1") (mesa-lib "libEGL.so.1"))
> +  (("libGLESv1_CM.so.1") (mesa-lib "libGLESv1_CM.so.1"))
> +  (("libGLESv2.so.2") (mesa-lib "libGLESv2.so.2")
>  (build-system meson-build-system)
>  (native-inputs
>   (list pkg-config python))
>
> base-commit: 597af70fd24eb85a85fa8c45008c9cfa241f4d0b

bug#66304: exim vulnearable to CVE-2023-42115 et al

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Thu, Oct 05, 2023 at 05:25 PM, Wilko Meyer wrote:

> * gnu/packages/mail.scm (exim): Update to 4.96.1.
> ---
>  gnu/packages/mail.scm | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
> index 72d971eb77..e6923627f4 100644
> --- a/gnu/packages/mail.scm
> +++ b/gnu/packages/mail.scm
> @@ -52,6 +52,7 @@
>  ;;; Copyright © 2022 jgart 
>  ;;; Copyright © 2022 ( 
>  ;;; Copyright © 2023 Timo Wilken 
> +;;; Copyright © 2023 Wilko Meyer 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1895,7 +1896,7 @@ (define-public msmtp
>  (define-public exim
>(package
>  (name "exim")
> -(version "4.96")
> +(version "4.96.1")
>  (source
>   (origin
> (method url-fetch)
> @@ -1909,7 +1910,7 @@ (define-public exim
>  (string-append "https://ftp.exim.org/pub/exim/exim4/old/";
> file-name
> (sha256
> -(base32 "18ziihkpa23lybm7m2l9wp2farxw0bd5ng7xm9ylgcrfgf95d6i9"
> +(base32 "0g83cxkq3znh5b3r2a3990qxysw7d2l71jwcxaxzvq8pqdahgb4k"
>  (build-system gnu-build-system)
>  (arguments
>   (list #:phases
>
> base-commit: ad5e4fe54a66c725dc03dedebf8e5c65723ccb74
> prerequisite-patch-id: 5bde835de1e0f7e9cd752986da0585463713d745
> prerequisite-patch-id: cda50d13de497f5c74c87b2def4ae6a7d5807305
> prerequisite-patch-id: 7024afc52961b5947429f925c55265f29607c801
> prerequisite-patch-id: 10a4f92340880065a5210c983cc878c98c075855
> prerequisite-patch-id: e6610085f98fb881bada0bb27b59def23c3d7cc3

Thanks for the patch and quickly noticing the security issues!

Pushed as add2a22ad7bcca2521432e3f486460138401d5a5 with some added
detail to the commit message. I tested that exim and a dependent builds.

John

bug#59364: gnome clocks does not start due to missing libGLES.so

[John Kehayias via Bug reports for GNU Guix]

On Sat, Oct 07, 2023 at 09:32 PM, Simon Streit wrote:

> John Kehayias  writes:
>
>> Is this the same issue as in ? With
>> potential fix ? I'm looking to
>> include this on the next mesa-updates round coming up soon.
>
> Yes, it is!  I can only confirm this error on older Machines with older
> graphics cards.  The newer ones are okay.

Thanks for confirming, hope to have the fix on mesa-updates and merged
soon. Soon depending on the next mesa point release and building the
branch.

bug#66033: Package name conflict for "helm"

[John Kehayias via Bug reports for GNU Guix]

Hi Panos,

On Sat, Sep 16, 2023 at 05:39 PM, Panos Alevropoulos wrote:

> Hi,
>
> There seems to be a recently introduced package name conflict.
> There are two packages named "helm". One is is the package manager for
> Kubernetes and the other is a synthesizer. I noticed after upgrading
> and helm suddenly jumped from 0.9.0 to 3.12.3. `guix install
> helm@0.9.0` restores helm-lv2 as a temp fix.
>
> I suggest the latter be renamed "helm-lv2" to fix the issue.
>
> Panos

Turns out this is due to another channel adding a package by the same
name. It should now be fixed in that channel. Thanks for reporting!

John

bug#53406: union-build incorrectly handles grafts

[John Kehayias via Bug reports for GNU Guix]

Hi Ludo’,

Long time since I've thought about this bug, but with all the recent
grafts I thought to return to it. I'll have to make a new example to
dig again, but wanted to think through where we might look to see
what's happening first.

On Tue, Jan 25, 2022 at 02:47 PM, Ludovic Courtès wrote:

> Hi John,
>
> John Kehayias  skribis:
>
[...]
>> Perhaps I was too hasty in noting this "problem" which like I said
>> was not the error I originally encountered. I was using a package
>> that constructs both the 64- and 32-bit libraries to put in a
>> container (say, a /lib32 and /lib64 or something similar to an FHS
>> environment). A collision was happening between a file and
>> directory, one being a good symlink and the other broken, rather
>> than a "real" mismatch in file vs directory. Anyway, going back to
>> that what I see is that one link is broken for the above reasons,
>> but the good one is good because it is to the *ungrafted* library
>> store path. I don't know now if these 2 things are connected other
>> than one led me to the other, but I turn now to what demonstrates my
>> original problem.
>>
>> I don't know why this happens or if it is something in this building
>> process that is not correct, but I did come up with a minimal
>> example (attached). The code is a bit odd in its stripped down form,
>> though hopefully is clear in what way this would be used to do
>> something useful (again, like an FHS environment or other
>> container). Apologies for the old style and lack of gexps which I'm
>> finally getting used to. The example package just tries to make a
>> dummy package that has, for illustration, a "/lib64" and "/lib32"
>> which link to the respective union-build inputs (of a single library
>> for simplicity). I don't think the actual package being made matters
>> so much, or how it is constructed, but that two inputs are
>> union-builds of the same library (x86_64 and i686) which should have
>> a graft of expat. Just my guess though.
>>
>> Doing:
>>
>> ls -la $(guix build -f graft-test.scm)/lib64/lib/libexpat*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.la
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.la*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so*
>> lrwxrwxrwx 1 root root 73 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1*
>> lrwxrwxrwx 1 root root 77 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib64/lib/libexpat.so.1.8.1
>> ->
>> /gnu/store/2q8wwhd3prib0swky68rbx9hl0xxs6hf-expat-2.4.3/lib/libexpat.so.1.8.1
>>
>> is what we saw already: libexpat is the newer (replacement, 2.4.3)
>> version, with the full version symlink broken since the version
>> number is wrong. Likewise in other pieces that have the version
>> number, like share/doc. Okay, that's expected. But now, in the
>> i686-linux union-build input:
>>
>> ls -la $(guix build -f graft-test.scm)/lib32/lib/libexpat*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.la
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.la*
>> lrwxrwxrwx 1 root root 71 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so*
>> lrwxrwxrwx 1 root root 73 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1*
>> lrwxrwxrwx 1 root root 77 Dec 31 1969
>> /gnu/store/qbh16hfdv8pnfw01k6izbs3jkji6i978-test-pkg-0.0/lib32/lib/libexpat.so.1.8.1
>> ->
>> /gnu/store/b0jns3vzhhpna7lim8bc3dr0payzx5yy-expat-2.4.1/lib/libexpat.so.1.8.1*
>>
>> all the links are good and to the original (version 2.4.1) expat. In
>> other words, the constructed union64 and union32 inputs (in the
>> sample code) do not both get grafted, even though doing just the
>> fhs-union command on it's own (not building both for another
>> package) does graft for either architecture. At least that seems
>> like the most obvious difference between the earlier example and
>> this new one.
>>
>> Why? Does the grafting just happen "once" somehow and misses the
>> "same" input again (but built for different system)? Is this
>> expected or just a weird/wrong way to do this kind of build which is
>> causing this? I'm not sure if this is just with union-build or if it
>> would happen just with inputs of the same library but different
>> architectures. I didn't know how to do that quickly off hand, so I
>> haven't tried it yet.
>
> Woow, it’s a sophi

bug#66757: missing INFOPATH for some packages (Git, Coreutils)

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Thu, Oct 26, 2023 at 10:11 AM, Simon Tournier wrote:

> Hi,
>
> Is it expected
>
> $ guix shell -C git coreutils
> [env]$ ls $GUIX_ENVIRONMENT/share/info
> coreutils.info.gz  dirgit.info.gz  gitman.info.gz
>
> /tmp/some-dir [env]$ exit

Well there's no info-reader right? So doing "info git" errors with no
"info" found.

> $ guix shell -C git coreutils --search-paths
> export 
> PATH="/gnu/store/jigy78ai2asmgwhxpxzq2dhqhqi8c4p6-profile/bin${PATH:+:}$PATH"
> export 
> GIT_EXEC_PATH="/gnu/store/jigy78ai2asmgwhxpxzq2dhqhqi8c4p6-profile/libexec/git-core"
>
> ?  I was expecting an INFOPATH in the search path.
>

If you add info-reader to the packages I get an INFOPATH search-path
(and of course then an info command is available and works).

> Well, it appears to me a bug but if I am missing something, feel free to
> point me what :-) and then close.
>
>
> Cheers,
> simon

So I think it is just that you didn't have the "consumer" of the
search-path, the package info-reader, in the profile. That seems like
the expected functionality of search-path but maybe I'm missing
something? Not closing in case it is me not you :)

(as an aside, I never remember the package for the same thing with
man...)

John

bug#66703: Broken link to Debbugs User Guide

[John Kehayias via Bug reports for GNU Guix]

merge 66703 58415
thanks

On Mon, Oct 23, 2023 at 10:39 PM, Maxim Cournoyer wrote:

> Hi Greg,
>
> Greg Hogan  writes:
>
>> The page 
>> https://guix.gnu.org/devel/manual/en/html_node/Debbugs-User-Interfaces.html
>> has a broken link "Debbugs User Guide" to the page
>> https://guix.gnu.org/devel/manual/en/debbugs-ug/index.html#Top.
>
> There doesn't seem to be an online HTML version of this manual, so the
> bug doesn't appear actionable.
>
> It works when using 'info', provided the 'emacs-debbugs' package is
> installed.

I noticed the broken html link before but never tracked down the correct
link to patch it. But just now a search gave me
 which looks helpful?

John

bug#64981: GTK4 applications broken (missing libGLESv2)

[John Kehayias via Bug reports for GNU Guix]

On Fri, Oct 06, 2023 at 03:47 PM, John Kehayias wrote:

> Hi everyone,
>
> Not sure if people saw this patch, has anyone tested if it fixes the
> problem for them? I can include it in an upcoming mesa-updates branch
> with other related updates/rebuilds.
>
> 
>
> Hope I got everyone from the original bug thread (seems many replies
> didn't go directly to everyone) and cc'ed the patch number as well.
>

Pushed as 37fc2c99e0067dfd669526c61dc10d014b89c08b (on mesa-updates
first and then merged to master).

Thanks!

bug#67608: qtbase fails to build on i686

[John Kehayias via Bug reports for GNU Guix]

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
> .

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.

>
> [ 59%] Building CXX object 
> src/gui/CMakeFiles/Gui.dir/text/freetype/qfreetypefontdatabase.cpp.o
> cd /tmp/guix-build-qtbase-6.5.2.drv-0/build/src/gui && 
> /gnu/store/isbd8adggnzdprcd7fxxlck2f5iqamg5-gcc-11.3.0/bin/c++ 
> -DENABLE_PIXMAN_DRAWHELPERS -DGui_EXPORTS -DQT_ASCII_CAST_WARNINGS 
> -DQT_BUILDING_QT -DQT_BUILD_GUI_LIB -DQT_CORE_LIB -DQT_DBUS_LIB 
> -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x05 
> -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 
> -DQT_MOC_COMPAT -DQT_NO_AS_CONST=1 -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG 
> -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS 
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_USING_NAMESPACE 
> -DQT_QPA_DEFAULT_PLATFORM_NAME=\"xcb\" -DQT_USE_QSTRINGBUILDER 
> -DQT_WARN_DEPRECATED_UP_TO=0x07 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/src/gui/Gui_autogen/include 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtGui 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/qtbase-everywhere-src-6.5.2/src/gui 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/src/gui 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/qtbase-everywhere-src-6.5.2/src/gui/../3rdparty/VulkanMemoryAllocator
>  -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtGui/6.5.2 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtGui/6.5.2/QtGui 
> -I/gnu/store/nq8q5cnzhymc79c09z3a90qhg9l9aiy5-at-spi2-core-2.45.90/include/at-spi-2.0
>  -I/gnu/store/gc967whfn0l9h11k3smzvd32i1w9dvw9-dbus-1.14.0/include/dbus-1.0 
> -I/gnu/store/gc967whfn0l9h11k3smzvd32i1w9dvw9-dbus-1.14.0/lib/dbus-1.0/include
>  -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtCore 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/qtbase-everywhere-src-6.5.2/mkspecs/linux-g++
>  -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/src/corelib 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtCore/6.5.2 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtCore/6.5.2/QtCore 
> -I/tmp/guix-build-qtbase-6.5.2.drv-0/build/include/QtDBus -isystem 
> /gnu/store/3zs0f4vcbfl2f89jk90x6gpy6wjapv1n-glib-2.72.3/include/glib-2.0 
> -isystem 
> /gnu/store/3zs0f4vcbfl2f89jk90x6gpy6wjapv1n-glib-2.72.3/lib/glib-2.0/include 
> -isystem 
> /gnu/store/wjzil5rwysjdgldg48lvy3m93fnffpzv-freetype-2.13.0/include/freetype2 
> -isystem 
> /gnu/store/g4scmdws4ax4343k5cxj6bz8v86r3b6a-harfbuzz-5.3.1/include/harfbuzz 
> -isystem 
> /gnu/store/s5n48zg43qdqb4qinbngzbcsg0nkw52q-libpng-1.6.37/include/libpng16 -g 
> -DNDEBUG -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall 
> -Wextra -fno-exceptions -fPIC -Wsuggest-override -std=c++17 -MD -MT 
> src/gui/CMakeFiles/Gui.dir/text/freetype/qfreetypefontdatabase.cpp.o -MF 
> CMakeFiles/Gui.dir/text/freetype/qfreetypefontdatabase.cpp.o.d -o 
> CMakeFiles/Gui.dir/text/freetype/qfreetypefontdatabase.cpp.o -c 
> /tmp/guix-build-qtbase-6.5.2.drv-0/qtbase-everywhere-src-6.5.2/src/gui/text/freetype/qfreetypefontdatabase.cpp
> /tmp/guix-build-qtbase-6.5.2.drv-0/qtbase-everywhere-src-6.5.2/src/gui/painting/qdrawhelper_avx2.cpp:
>  In function ‘const QRgba64* fetchRGBA64ToRGBA64PM_avx2(QRgba64*, const 
> uchar*, int, int, const QList*, QDitherInfo*)’:
> /tmp/guix-build-qtbase-6.5.2.drv-0/qtbase-everywhere-src-6.5.2/src/gui/painting/qdrawhelper_avx2.cpp:1353:33:
>  error: could not convert ‘vs’ from ‘__m128i’ to ‘QRgba64’
>  1353 | vs = multiplyAlpha65535(vs, va);
>   | ^~
>   | |
>   | __m128i
> [ 59%] Building CXX object 
> src/gui/CMakeFiles/Gui.dir/text/unix/qfontconfigdatabase.cpp.o
> cd /tmp/guix-build-qtbase-6.5.2.drv-0/build/src/gui && 
> /gnu/store/isbd8adggnzdprcd7fxxlck2f5iqamg5-gcc-11.3.0/bin/c++ 
> -DENABLE_PIXMAN_DRAWHELPERS -DGui_EXPORTS -DQT_ASCII_CAST_WARNINGS 
> -DQT_BUILDING_QT -DQT_BUILD_GUI_LIB -DQT_CORE_LIB -DQT_DBUS_LIB 
> -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x05 
> -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 
> -DQT_MOC_COMPAT -DQT_NO_AS_CONST=1 -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG 
> -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS 
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_USING_NAMESPACE 
> -DQT_QPA_DEFAULT_PLATFORM_NAME=\"xcb\" -DQT_USE_QSTRINGBUILDER 
> -DQT_WARN_DEPRECATED_UP_TO=0x07 -D_LARGEFILE64_SOURCE -D_LAR

bug#67829: qtwebengine new failure on i686

[John Kehayias via Bug reports for GNU Guix]

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
> .
>
> 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:  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...

John

bug#68429: Catch2-3.5.1 tests fails on i686-linux, SSE extension

[John Kehayias via Bug reports for GNU Guix]

Hi,

On Sat, Jan 13, 2024 at 11:43 AM, Richard Sent wrote:

> Opening a ticket so discussions a bit more organized. Hope this
> doesn't step on anybody's toes.
>
> Catch2-3.5.1 fails to build with system=i686-linux, log attached. This
> is due to a test added upstream that assumes the SSE extension is
> present,
> SelfTest/IntrospectiveTests/RandomNumberGeneration.tests.cpp:570.
>
> One fix was proposed that replaces GCC with Clang, attached. This
> works because Clang assumes the SSE extension by default. If we add
> "-DCMAKE_CXX_FLAGS=-mno-sse", the test fails again.
>
> Another solution is to add "-DCMAKE_CXX_FLAGS=-msse -mfpmath=sse" to
> the existing package definition.
>
> Of the two, the second is more explicit in how the problem is
> resolved, but I don't know if we should assume SSE is present on i686.
>

Thanks! Looking at other packages, seems it is find to enable SSE, just
for x86_64 and i686. Other times we explicitly disable SSE2 more
generally, but in this case it makes sense to match upstream (unless
they change this) and enable in these cases.

So, I used that configure flag just for those systems in
18393fcdddf5c3d834fa89ebf5f3925fc5b166ed which I've pushed. I added you
and another (Jo Gay, from the other channel) as co-authors for finding
the fix(es).

> An issue was opened upstream at
> https://github.com/catchorg/Catch2/issues/2796
>

And thanks for this too!

John

> Richard Sent
>
> diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
> index 449340f331..e09a7bd82a 100644
> --- a/gnu/packages/check.scm
> +++ b/gnu/packages/check.scm
> @@ -621,9 +621,14 @@ (define-public catch2-3
>  (arguments
>   (list
>#:configure-flags
> -  #~(list "-DCATCH_DEVELOPMENT_BUILD=ON"
> +  #~(list "-DCMAKE_CXX_COMPILER=clang++" ; tests fail with gcc-11 on i686
> +  "-DCMAKE_CXX_STANDARD=14"
> +  "-DCMAKE_CXX_STANDARD_REQUIRED=ON"
> +  "-DCMAKE_CXX_EXTENSIONS=OFF"
> +  "-DCATCH_DEVELOPMENT_BUILD=ON"
>"-DCATCH_ENABLE_WERROR=OFF"
>"-DBUILD_SHARED_LIBS=ON")))
> +(native-inputs (list clang-10))
>  (inputs (list python-wrapper))
>  (synopsis "Automated test framework for C++ and Objective-C")
>  (description "Catch2 stands for C++ Automated Test Cases in Headers and 
> is

bug#68429: Catch2-3.5.1 tests fails on i686-linux, SSE extension

[John Kehayias via Bug reports for GNU Guix]

Hi,

On Sat, Jan 13, 2024 at 11:43 AM, Richard Sent wrote:

> Opening a ticket so discussions a bit more organized. Hope this
> doesn't step on anybody's toes.
>
> Catch2-3.5.1 fails to build with system=i686-linux, log attached. This
> is due to a test added upstream that assumes the SSE extension is
> present,
> SelfTest/IntrospectiveTests/RandomNumberGeneration.tests.cpp:570.
>
> One fix was proposed that replaces GCC with Clang, attached. This
> works because Clang assumes the SSE extension by default. If we add
> "-DCMAKE_CXX_FLAGS=-mno-sse", the test fails again.
>
> Another solution is to add "-DCMAKE_CXX_FLAGS=-msse -mfpmath=sse" to
> the existing package definition.
>
> Of the two, the second is more explicit in how the problem is
> resolved, but I don't know if we should assume SSE is present on i686.
>

Thanks! Looking at other packages, seems it is find to enable SSE, just
for x86_64 and i686. Other times we explicitly disable SSE2 more
generally, but in this case it makes sense to match upstream (unless
they change this) and enable in these cases.

So, I used that configure flag just for those systems in
18393fcdddf5c3d834fa89ebf5f3925fc5b166ed which I've pushed. I added you
and another (Jo Gay, from the other channel) as co-authors for finding
the fix(es).

> An issue was opened upstream at
> https://github.com/catchorg/Catch2/issues/2796
>

And thanks for this too!

John

> Richard Sent
>
> diff --git a/gnu/packages/check.scm b/gnu/packages/check.scm
> index 449340f331..e09a7bd82a 100644
> --- a/gnu/packages/check.scm
> +++ b/gnu/packages/check.scm
> @@ -621,9 +621,14 @@ (define-public catch2-3
>  (arguments
>   (list
>#:configure-flags
> -  #~(list "-DCATCH_DEVELOPMENT_BUILD=ON"
> +  #~(list "-DCMAKE_CXX_COMPILER=clang++" ; tests fail with gcc-11 on i686
> +  "-DCMAKE_CXX_STANDARD=14"
> +  "-DCMAKE_CXX_STANDARD_REQUIRED=ON"
> +  "-DCMAKE_CXX_EXTENSIONS=OFF"
> +  "-DCATCH_DEVELOPMENT_BUILD=ON"
>"-DCATCH_ENABLE_WERROR=OFF"
>"-DBUILD_SHARED_LIBS=ON")))
> +(native-inputs (list clang-10))
>  (inputs (list python-wrapper))
>  (synopsis "Automated test framework for C++ and Objective-C")
>  (description "Catch2 stands for C++ Automated Test Cases in Headers and 
> is

bug#68764: ASDF can't load sbcl-clx-truetype installed through Guix

[John Kehayias via Bug reports for GNU Guix]

Hi Lars,

On Sat, Jan 27, 2024 at 04:57 PM, Lars Rustand wrote:

> Trying to load clx-truetype with ASDF in SBCL fails because of read-only
> filesystem. This is caused by the store being read-only and ASDF is
> trying to save the compiled file there. I read somewhere that Guix
> already supplies precompiled files for all Common Lisp libraries, so
> ASDF should just be able to load this one instead of compiling it, but
> this doesn't seem to work in this case.
>
> I'm able to load other packages just fine, like sbcl-slynk and
> sbcl-alexandria. Using cl-clx-truetype instead of sbcl-clx-truetype also
> works fine, even though this one obviously also needs compilation.
>
> I'm not sure what the exact cause is, but it seems that there are at
> least two things wrong.
> 1. ASDF/SBCL doesn't find the precompiled file(s) for clx-truetype.
> 2. The path to where the compiled files are saved is wrong.
>
>
> Steps to reproduce:
> 1. Install sbcl and sbcl-clx-truetype
> 2. Run `sbcl --eval '(require :asdf)' --eval '(asdf:load-system 
> :clx-truetype)'`
> 2a. Or start sbcl and manually run the commands
>

I can't reproduce this, at least on Guix at commit
da3e6aea0a750246e8a9120d62441c3df65faff0

I ran your command in one line with guix shell (and set --pure just in
case; I have SBCL_HOME set, not sure if anything else relevant):

--8<---cut here---start->8---
❯ guix shell --pure sbcl sbcl-clx-truetype -- sbcl --eval '(require :asdf)' 
--eval '(asdf:load-system :clx-truetype)'
This is SBCL 2.4.0, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
WARNING: System definition file 
#P"/gnu/store/qwb8qyjn615icrgxkjwqjwlwkwzxcc7y-sbcl-clx-truetype-0.0.1-1.c6e10a9/share/common-lisp/sbcl/clx-truetype/clx-truetype.asd"
 contains definition for system "clx-truetype-test". Please only define 
"clx-truetype" and secondary systems with a name starting with "clx-truetype/" 
(e.g. "clx-truetype/test") in that file.
WARNING: System definition file 
#P"/gnu/store/bqfsbh15lpnf9i9f5qf6ya6yhcdk8nw3-sbcl-cl-store-0.8.11-1.c787337/share/common-lisp/sbcl/cl-store/cl-store.asd"
 contains definition for system "cl-store-tests". Please only define "cl-store" 
and secondary systems with a name starting with "cl-store/" (e.g. 
"cl-store/test") in that file.
WARNING: redefining ZPB-TTF::LOCATION in DEFGENERIC
* (quit)
--8<---cut here---end--->8---

Perhaps try with 'guix shell --pure' as well, in case it is an
environment setting?

John

> This is SBCL 2.4.0, an implementation of ANSI Common Lisp.
> More information about SBCL is available at .
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> WARNING: System definition file 
> #P"/gnu/store/qwb8qyjn615icrgxkjwqjwlwkwzxcc7y-sbcl-clx-truetype-0.0.1-1.c6e10a9/share/common-lisp/sbcl/clx-truetype/clx-truetype.asd"
>  contains definition for system "clx-truetype-test". Please only define 
> "clx-truetype" and secondary systems with a name starting with 
> "clx-truetype/" (e.g. "clx-truetype/test") in that file.
> WARNING: System definition file 
> #P"/gnu/store/bqfsbh15lpnf9i9f5qf6ya6yhcdk8nw3-sbcl-cl-store-0.8.11-1.c787337/share/common-lisp/sbcl/cl-store/cl-store.asd"
>  contains definition for system "cl-store-tests". Please only define 
> "cl-store" and secondary systems with a name starting with "cl-store/" (e.g. 
> "cl-store/test") in that file.
> WARNING: redefining ZPB-TTF::LOCATION in DEFGENERIC
>
> debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread
> #:
>   Error opening 
> #P"/gnu/store/qwb8qyjn615icrgxkjwqjwlwkwzxcc7y-sbcl-clx-truetype-0.0.1-1.c6e10a9/lib/common-lisp/sbcl/clx-truetype/package-tmpGHU3ALSV.fasl":
>
> Read-only file system
>
> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>   0: [CONTINUE ] Retry opening.
>   1: [USE-VALUE] Try opening a different file.
>   2: [RETRY] Retry
>  compiling # "clx-truetype" "package">.
>   3: [ACCEPT   ] Continue, treating
>  compiling # "clx-truetype" "package">
>  as having been successful.
>   4: Retry ASDF operation.
>   5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
>  configuration.
>   6:

bug#59364: gnome clocks does not start due to missing libGLES.so

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Mon, Oct 09, 2023 at 01:31 AM, John Kehayias wrote:

> On Sat, Oct 07, 2023 at 09:32 PM, Simon Streit wrote:
>
>> John Kehayias  writes:
>>
>>> Is this the same issue as in ? With
>>> potential fix ? I'm looking to
>>> include this on the next mesa-updates round coming up soon.
>>
>> Yes, it is!  I can only confirm this error on older Machines with older
>> graphics cards.  The newer ones are okay.
>
> Thanks for confirming, hope to have the fix on mesa-updates and merged
> soon. Soon depending on the next mesa point release and building the
> branch.

And forgot to update/close this bug after mesa-updates was merged, with
37fc2c99e0067dfd669526c61dc10d014b89c08b the relevant commit.

John

bug#69735: [BUG] Error running any docker-composse command

[John Kehayias via Bug reports for GNU Guix]

Hi Edison and CC'ing Arun (commit in question),

On Mon, Mar 11, 2024 at 04:52 PM, Edison Ibáñez wrote:

> Greetings, with the last Commit, Python-Docker was updated, apparently this 
> causes errors with Docker-Compose, the apparent solution is to update the 
> Docker-Composse version, but changes the installation method of Python to Go, 
> so I can't Generate the patch to update the package.
>

Indeed, we are behind with docker compose because it requires some new
effort in packaging.

> Give the error:
>
> /gnu/store/v2sr2wqfjnnlf4cr6fbaadslrlz9cdj4-python-paramiko-2.7.2/lib/python3.10/site-packages/paramiko/transport.py:219:
>  CryptographyDeprecationWarning: Blowfish has been deprecated
>   "class": algorithms.Blowfish,
> Traceback (most recent call last):
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/bin/.docker-compose-real",
>  line 33, in 
> sys.exit(load_entry_point('docker-compose==1.29.2', 'console_scripts', 
> 'docker-compose')())
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/lib/python3.10/site-packages/compose/cli/main.py",
>  line 81, in main
> command_func()
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/lib/python3.10/site-packages/compose/cli/main.py",
>  line 200, in perform_command
> project = project_from_options('.', options)
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/lib/python3.10/site-packages/compose/cli/command.py",
>  line 60, in project_from_options
> return get_project(
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/lib/python3.10/site-packages/compose/cli/command.py",
>  line 152, in get_project
> client = get_client(
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/lib/python3.10/site-packages/compose/cli/docker_client.py",
>  line 41, in get_client
> client = docker_client(
>   File 
> "/gnu/store/fh9sgccvjx86f168qvh7rvan3rnbydlg-docker-compose-1.29.2/lib/python3.10/site-packages/compose/cli/docker_client.py",
>  line 124, in docker_client
> kwargs = kwargs_from_env(environment=environment, ssl_version=tls_version)
> TypeError: kwargs_from_env() got an unexpected keyword argument 'ssl_version'
>
> Thanks

I also get this error trying to use 'docker-compose'. This is because
this argument was removed in 7.0.0, see
. Even more,
support for the compose v1 (which is what we are stuck I think until we
can upgrade docker/docker compose) was removed completely. A summary and
link to upstream issue: .

I would suggest we revert commit
d084fb4b04a1cebb59959633660013fff495cd0d and/or use the previous version
6.1.3 until we can have docker compose with v2 support. As it is, this
makes docker-compose unusable on Guix without some manual downgrade.

Arun, what do you think?

Thanks,
John

bug#69735: [BUG] Error running any docker-composse command

[John Kehayias via Bug reports for GNU Guix]

Hi Arun,

On Sat, Mar 16, 2024 at 08:59 PM, Arun Isaac wrote:

> Hi John,
>
>> I would suggest we revert commit
>> d084fb4b04a1cebb59959633660013fff495cd0d and/or use the previous version
>> 6.1.3 until we can have docker compose with v2 support. As it is, this
>> makes docker-compose unusable on Guix without some manual downgrade.
>>
>> Arun, what do you think?
>
> Reverted, thanks for reporting!
>
> Regards,
> Arun

Thanks! I can confirm things work again. I suppose we can update it to
6.1.3, but I haven't tried yet. More importantly would be to finally
tackle the docker upgrade...

Closing.

John

bug#70174: OpenEXR is vulnerable to CVE-2023-5841 and CVE-2021-45942

[John Kehayias via Bug reports for GNU Guix]

Hello,

On Thu, Apr 04, 2024 at 01:07 AM, Vinicius Monego wrote:

> OpenEXR suffers from these vulnerabilities which were fixed in version
> 3.2.2 [1] and 3.1.4 [2], respectively, while our version is currently
> 3.1.3.
>
> The package contains 448 dependents, and a change in derivation
> shouldn't be pushed to master, at least according to the patch
> submission guidelines.
>
> [1] https://nvd.nist.gov/vuln/detail/CVE-2023-5841
>
> [2] https://nvd.nist.gov/vuln/detail/CVE-2021-45942

Thanks for passing this along.

I've applied a patch, attached, locally to the mesa-updates branch which
 updates openexr to the latest version, 3.2.4. It required a few minor
 changes (fix a phase, an input) but it builds.

I may wait to queue up some more fixes for that branch, but don't
currently have anything pending. Either way, it will be there soon and
hopefully merged to master (just need to wait for everything to build
and look good).

Thanks!
John
From 870359351e80a3d14304a4f6a1b734f67c1ea167 Mon Sep 17 00:00:00 2001
Message-ID: <870359351e80a3d14304a4f6a1b734f67c1ea167.1712198858.git.john.kehay...@protonmail.com>
From: John Kehayias 
Date: Wed, 3 Apr 2024 22:45:50 -0400
Subject: [PATCH] gnu: openexr: Update to 3.2.4 [security fixes].

Previous versions, 3.2.2 and 3.1.4, fixed CVE-2023-5841 and CVE-2021-45942,
respectively.

* gnu/packages/graphics.scm (openexr): Update to 3.2.4.

Reported-by: Vinicius Monego 
Change-Id: I72f82e623c9b8988cae433947117cd81f40cdbc3
---
 gnu/packages/graphics.scm | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/gnu/packages/graphics.scm b/gnu/packages/graphics.scm
index ad08141c96..188e066766 100644
--- a/gnu/packages/graphics.scm
+++ b/gnu/packages/graphics.scm
@@ -1200,7 +1200,7 @@ (define-public ogre
 (define-public openexr
   (package
 (name "openexr")
-(version "3.1.3")
+(version "3.2.4")
 (source (origin
   (method git-fetch)
   (uri (git-reference
@@ -1210,7 +1210,7 @@ (define-public openexr
   (file-name (git-file-name name version))
   (sha256
(base32
-"0c9vla0kbsbbhkk42jlbf94nzfb1anqh7dy9b0b3nna1qr6v4bh6"
+"00s1a05kggk71vfbnsvykyjc2j7y6yyzgl63sy4yiddshz2k2mcr"
 (build-system cmake-build-system)
 (arguments
  (list #:phases
@@ -1218,8 +1218,6 @@ (define-public openexr
(add-after 'unpack 'patch-test-directory
  (lambda _
(substitute* (list
- "src/test/OpenEXRUtilTest/tmpDir.h"
- "src/test/OpenEXRFuzzTest/tmpDir.h"
  "src/test/OpenEXRTest/tmpDir.h"
  "src/test/OpenEXRCoreTest/main.cpp")
  (("/var/tmp")
@@ -1247,7 +1245,7 @@ (define-public openexr
 "")
(("TEST \\(testOptimizedInterleavePatterns, \"basic\"\\);")
 "")
-(inputs (list imath zlib))
+(inputs (list imath libdeflate zlib))
 (home-page "https://www.openexr.com/";)
 (synopsis "High-dynamic-range file format library")
 (description

base-commit: 1cba1f8ce6f84c4737650401c0eb0473a45f9ff7
prerequisite-patch-id: fa1f23e1340a3eeb9f347ed719b9b0fa0558fb3f
prerequisite-patch-id: a1eb5f0955b9988d3bfe3be8403c75999a1cae5f
prerequisite-patch-id: 2889be19c4a046760f2f608cefff987b11b65a31
prerequisite-patch-id: ea93b6662275aeec1e014a9bc9fe7a96f26ac600
prerequisite-patch-id: 177440a12b7c797d22f8bb1253db133d2fbad348
prerequisite-patch-id: 3a5189c1e8e4612ceb6f1b70cc3c83e39a977eb9
prerequisite-patch-id: 7ddfa796914f078615724949db7c1ac6c148d09f
prerequisite-patch-id: 3037b56c731bc0a62c6b4a2cfecbadc8ead38453
prerequisite-patch-id: 163581597c141e701fc8089a6337683abce82894
prerequisite-patch-id: f2f116d9fedadb3443bc61ff3824c479cda5fcf0
prerequisite-patch-id: 57807814fe98a68ffc68fb9ebdb92a7115959e0b
prerequisite-patch-id: 95f518cd6bd40014a2cb1b83f5af807b069a84cf
prerequisite-patch-id: 040ecf8f843498b7bcedac335cff1b84af17fad9
prerequisite-patch-id: 06b54c27f5ecd182574be222a50f592c5fb3fa4d
prerequisite-patch-id: 50f1bd0ac736d175116893d79869780070a2ea59
prerequisite-patch-id: 03be0e6d28cd6c11eaaf7b9784ba032fa72be4ff
prerequisite-patch-id: dce4ebc8c7dc26df87b1a91f676f660a87379c8a
prerequisite-patch-id: e3f21290baa6ec82b673387974ae2561caad7e64
prerequisite-patch-id: 15f266f43c1918cc8526406283af83369c4dc80e
prerequisite-patch-id: 78eedd30786c77e0e0a06f1d959ee9b687902d8f
prerequisite-patch-id: 3ad571d4975f17216c7ab008f3e81c5e038ec65b
prerequisite-patch-id: 8bcf03f489b2f139d277d0e46552ac0211b061b2
prerequisite-patch-id: 0e92576d6b767e75d64accf5b5d38eda08dae78e
-- 
2.41.0

bug#70174: OpenEXR is vulnerable to CVE-2023-5841 and CVE-2021-45942

[John Kehayias via Bug reports for GNU Guix]

On Thu, Apr 04, 2024 at 02:50 AM, John Kehayias wrote:

> Hello,
>
> On Thu, Apr 04, 2024 at 01:07 AM, Vinicius Monego wrote:
>
>> OpenEXR suffers from these vulnerabilities which were fixed in version
>> 3.2.2 [1] and 3.1.4 [2], respectively, while our version is currently
>> 3.1.3.
>>
>> The package contains 448 dependents, and a change in derivation
>> shouldn't be pushed to master, at least according to the patch
>> submission guidelines.
>>
>> [1] https://nvd.nist.gov/vuln/detail/CVE-2023-5841
>>
>> [2] https://nvd.nist.gov/vuln/detail/CVE-2021-45942
>
> Thanks for passing this along.
>
> I've applied a patch, attached, locally to the mesa-updates branch which
>  updates openexr to the latest version, 3.2.4. It required a few minor
>  changes (fix a phase, an input) but it builds.
>
> I may wait to queue up some more fixes for that branch, but don't
> currently have anything pending. Either way, it will be there soon and
> hopefully merged to master (just need to wait for everything to build
> and look good).
>
> Thanks!
> John

Forgot to note the change in [inputs] in the changelog, fixed locally.

bug#54447: cuirass: missing derivation error

[John Kehayias via Bug reports for GNU Guix]

Hi all,

On Thu, Apr 04, 2024 at 11:33 PM, Ludovic Courtès wrote:

> Hello!
>
> News from the everlasting bug!
>
>   cannot build missing derivation
> ‘/gnu/store/dfgc46q3l8wlnymv49a1wjnxypin8p0y-plink-1.07.drv’
>
> (From .)
>
> Why was it missing this time?  /var/log/nginx/error.log:
>
> 2024/04/04 17:15:03 [error] 98751#0: *152293778 upstream timed out (110: 
> Connection timed out) while reading response header from upstream, client: 
> 141.80.167.169, server: ci.guix.gnu.org, request: "GET 
> /dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo HTTP/1.1", upstream: 
> "http://127.0.0.1:3000/dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo";, host: 
> "141.80.167.131"
>
>
> Oops!  (There are dozens of upstream timeouts logged on that minute.)
>
> /var/log/guix-publish.log:
>
> 2024-04-04 17:14:51 GET 
> /nar/lzip/pz39bkq7pd1hgy5rwiynqa33gyjvpgs5-python-pygments-2.12.0
> 2024-04-04 17:14:51 GET /z2xxwwxswdd4b8c8iwmxhqnqbp5nwz09.narinfo
> 2024-04-04 17:14:51 GET /lgyck285bsxzwrnh3x5ix5dwzd3n3wga.narinfo
> 2024-04-04 17:14:51 GET 
> /nar/zstd/jxkglr445f215m2faqz1i2lgmbans4rf-texlive-amsmath-66594-doc
> 2024-04-04 17:15:33 GET /qg5cxb869i42jn7x2dm6k5l41ikkz21w.narinfo
> 2024-04-04 17:15:33 GET 
> /nar/zstd/i2hp3q2pfhsyl0al7z38am7cqpddi4qr-texlive-capt-of-66594-doc
> 2024-04-04 17:15:33 GET /hh0gdbljj3cjdnjbr88kfm21mhys5sy7.narinfo
> 2024-04-04 17:15:33 GET /dfgc46q3l8wlnymv49a1wjnxypin8p0y.narinfo
> 2024-04-04 17:15:33 GET /yj63wifalfr6sla42h7mkqg011qrl5d0.narinfo
> 2024-04-04 17:15:33 GET /h2s2g2adxbnd67g34mnjnpcr6p3nhr69.narinfo
> 2024-04-04 17:15:33 -> GET /h2s2g2adxbnd67g34mnjnpcr6p3nhr69.narinfo: 404
> 2024-04-04 17:15:33 GET 
> /nar/lzip/6zxlrw15b9dsv73s7v5fqabl7iv5v5il-python-exceptiongroup-1.1.1
> 2024-04-04 17:15:33 GET 
> /nar/zstd/pychjd114abscbqlzcr3s7myf1497vw2-julia-compilersupportlibraries-jll-0.4.0%2B1
>
> ‘guix publish’ replied, but 40s too late (nginx has
> “proxy_connect_timeout 10s;” for .narinfo URLs¹).
>
> Notice the 40s pause time between 17:14:51 and 17:15:33.  Stop-the-world
> GC?  Unlikely, because ‘guix publish’ had been running for ~3h, so even
> with a leak², it’s hard to believe GC could take this long.
>
> Ludo’.
>
> ¹
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/berlin.scm#n103
> ² https://issues.guix.gnu.org/69596

I don't have any insight, but if anyone wants to see this in action at a
large scale, take look at pretty much any red dot on
https://ci.guix.gnu.org/eval/1238471/dashboard?system=i686-linux

>From my quick look all the CL and texlive failures were all missing
derivation. I've tried restarting a bunch to get i686 coverage going, so
hopefully some will disappear. But I can't/won't manually restart the
thousands(?) of failed builds. I didn't see such issues on x86_64, while
other architectures take a really long time to build on Berlin so I
haven't looked.

I don't know if this is helpful, but thought I would chime in if anyone
wants potentially a bunch of data. And if there are good ideas to
recover (just restart all builds?) that would be great so mesa-updates
will be build on i686 since otherwise it looks good.

Thanks!
John

bug#63267: gcc-toolchain is missing libstdc++.so

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

Apologies for the long delay on this.

On Tue, May 09, 2023 at 07:07 PM, Simon Tournier wrote:

> Hi,
>
> I am proposing patch#63393 [1] which adds the output lib to
> gcc-toolchain.  Well, quoting the comment:
>
>   ;; The main raison d'être of this "meta-package" is (1) to conveniently
>   ;; install everything that we need, and (2) to make sure ld-wrapper 
> comes
>   ;; before Binutils' ld in the user's profile.
>
> I think, this package gcc-toolchain should be the visible package and
> battery included.
>
> WDYT?
>
> 1: https://issues.guix.gnu.org/issue/63393
>
> Cheers,
> simon

I've just pushed, as b47ae1ecc43baaf726701ab2d2f810ecfaa75428, the
patches from that issue (the first from simon, the second my simplified
one just adding gcc:lib to gcc-toolchain).

This should fix the original bug here, so I am closing. However, it was
raised here and in 63393 about alternatives in how we use gcc-toolchain
outputs. As well as the issue I ran into about make-libstdc++.

So, if anyone would like to change anything from the new status quo,
please open a new issue. At least now we are working from a better
default I would say, with gcc-toolchain including the libraries from
gcc:lib.

Thanks all,
John

bug#47543: “Repeated allocation of very large block” during ‘guix pull’

[John Kehayias via Bug reports for GNU Guix]

Hello,

Just hit this warning and went searching to find this report.

On Thu, Nov 23, 2023 at 12:42 PM, Ludovic Courtès wrote:

> Ludovic Courtès  skribis:
>
>> While running ‘guix pull’, sometime between the actual ‘git pull’ (via
>> Guile-Git) and channel authentication, I saw the dreaded libgc warning:
>>
>>   Repeated allocation of very large block
>
> [...]
>
>> So it might rather be ‘update-cached-checkout’ that triggers it.
>
> I wonder if this was due to the big checkouts we ended up with so far:
>
>   https://issues.guix.gnu.org/65720
>
> Ludo’.

In my case, just did a guix pull so I am on
2126dab4cd81db4cbde4566d8c638e45a4c0077c.

Pull was fine, but this warning was repeatable on a system reconfigure:

--8<---cut here---start->8---
❯ sudo guix system reconfigure ~/.config/guix/config.scm --max-jobs=4 -n
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 135168):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 131072):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 102400):
May lead to memory leak and poor performance
substitute: updating substitutes from 
'https://bordeaux-us-east-mirror.cbaines.net/'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://substitutes.nonguix.org'... 
100.0%
The following derivation would be built:
  /gnu/store/r9n8vz4s1n7v3551cphrqy0pqyl8wcv0-corectrl-1.3.5.drv

340.3 MB would be downloaded
❯ sudo guix system reconfigure ~/.config/guix/config.scm -n
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 122880):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
The following derivation would be built:
  /gnu/store/r9n8vz4s1n7v3551cphrqy0pqyl8wcv0-corectrl-1.3.5.drv

340.3 MB would be downloaded
❯ sudo guix system reconfigure ~/.config/guix/config.scm --max-jobs=4
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 69632):
May lead to memory leak and poor performance
GC Warning: Repeated allocation of very large block (appr. size 131072):
May lead to memory leak and poor performance
The following derivation will be built:
  /gnu/store/r9n8vz4s1n7v3551cphrqy0pqyl8wcv0-corectrl-1.3.5.drv

340.3 MB will be downloaded
 adwaita-icon-theme-44.0  904KiB
108.0MiB/s 00:00 ▕██▏ 100.0%
guix substitute: warning: download from 
'https://bordeaux-us-east-mirror.cbaines.net/nar/lzip/c2brbsvn75866l81rswb7z8sdpw2dvjr-font-abattis-cantarell-0.303-0.e049149'
 failed: 404, "Not Found"
retrying download of 
'/gnu/store/c2brbsvn75866l81rswb7z8sdpw2dvjr-font-abattis-cantarell-0.303-0.e049149'
 with other substitute URLs...

substitution of
/gnu/store/5in68ily7wjj8jy67kyj8sikwmci894j-ath9k-htc-ar7010-firmware-1.4.0
complete
--8<---cut here---end--->8---

this last one continued until I killed it to send capture the previous
output and send it.

--8<---cut here---start->8---
❯ free -h
   totalusedfree  shared  buff/cache   available
Mem:15Gi10Gi   3.4Gi   706Mi   2.4Gi   4.8Gi
Swap:   15Gi   4.1Gi11Gi
--8<---cut here---end--->8---

But since interrupting the reconfigure, it doesn't give the warning
again. So something happened by actually starting the reconfigure
process...?

I don't think I've ever see

bug#70174: OpenEXR is vulnerable to CVE-2023-5841 and CVE-2021-45942

[John Kehayias via Bug reports for GNU Guix]

On Thu, Apr 04, 2024 at 03:47 AM, John Kehayias wrote:

> On Thu, Apr 04, 2024 at 02:50 AM, John Kehayias wrote:
>
>> Hello,
>>
>> On Thu, Apr 04, 2024 at 01:07 AM, Vinicius Monego wrote:
>>
>>> OpenEXR suffers from these vulnerabilities which were fixed in version
>>> 3.2.2 [1] and 3.1.4 [2], respectively, while our version is currently
>>> 3.1.3.
>>>
>>> The package contains 448 dependents, and a change in derivation
>>> shouldn't be pushed to master, at least according to the patch
>>> submission guidelines.
>>>
>>> [1] https://nvd.nist.gov/vuln/detail/CVE-2023-5841
>>>
>>> [2] https://nvd.nist.gov/vuln/detail/CVE-2021-45942
>>
>> Thanks for passing this along.
>>
>> I've applied a patch, attached, locally to the mesa-updates branch which
>>  updates openexr to the latest version, 3.2.4. It required a few minor
>>  changes (fix a phase, an input) but it builds.
>>
>> I may wait to queue up some more fixes for that branch, but don't
>> currently have anything pending. Either way, it will be there soon and
>> hopefully merged to master (just need to wait for everything to build
>> and look good).
>>
>> Thanks!
>> John
>
> Forgot to note the change in [inputs] in the changelog, fixed locally.

Pushed as 410e699e0933653e69d03a4cdadf11854c6723f4 (and fixed some build
issues with 2718616f77aace28b3962fef29b4e38b87a512ce) and merged with
2d5736cc3e869fadd2592cc13a8d332fac63b144.

Thanks!
John

bug#49122: gobject-introspection and not finding cairo

[John Kehayias via Bug reports for GNU Guix]

Hello,

I'm trying to build some new packages, one of which is ghc-gi-cairo (from 
ghc-haskell-gi: https://github.com/haskell-gi/haskell-gi). These depend on 
gobject-introspection and finding library information from gir. However, it 
appears the typelib for cairo does not include the absolute path for cairo 
(though gobject-introspection right now does not depend on cairo, so that makes 
sense?) and the library cannot be found from this info.

Perhaps the name exposed in the typelib should be something else? I know there 
are patches for paths in gobject-introspection, and this issue of library path 
from gobject-introspection is not just in guix (e.g. 
https://github.com/Cimbali/pympress/issues/58). In building I do see 
LIBRARY_PATH includes the correct gobject-introspection (it does find the 
girepository in configure) and cairo, but as far as I can tell the path to 
cairo must be found via the typelib when using gobject-introspection?

I've tried building gobject-introspection with cairo enabled in meson, which 
didn't help. I also tried patching the cairo.gir file (as in 
https://github.com/Cimbali/pympress/issues/58#issuecomment-503174954), but 
haven't figured out what needs to go in there to make it work. Probably 
gobject-introspection needs to be build with cairo as an input and correctly 
get the full path to the library in generating the typelib? But what goes in 
the gir/cairo-1.0.gir.in file exactly?

>From the gobject-introspection package running:

strings 
/gnu/store/irmw6agiw3adqphw8c3m19g31fw1yf34-gobject-introspection-1.62.0/lib/girepository-1.0/cairo-1.0.typelib
 | grep lib

has output:

libcairo-gobject.so.2
xlib


End of building ghc-gi-cairo has the following message:

starting phase `configure'
running "runhaskell Setup.hs" with command "configure" and parameters 
("--prefix=/gnu/store/w95yciqs7i7aqm6v7qa6fiy6m6f25czb-ghc-gi-cairo-1.0.25" 
"--libdir=/gnu/store/w95yciqs7i7aqm6v7qa6fiy6m6f25czb-ghc-gi-cairo-1.0.25/lib" 
"--docdir=/gnu/store/w95yciqs7i7aqm6v7qa6fiy6m6f25czb-ghc-gi-cairo-1.0.25/share/doc/ghc-gi-cairo-1.0.25"
 "--libsubdir=$compiler/$pkg-$version" 
"--package-db=/tmp/guix-build-ghc-gi-cairo-1.0.25.drv-0/package.conf.d" 
"--global" "--enable-tests" "--enable-shared" "--enable-executable-dynamic" 
"--ghc-option=-fPIC" 
"--ghc-option=-optl=-Wl,-rpath=/gnu/store/w95yciqs7i7aqm6v7qa6fiy6m6f25czb-ghc-gi-cairo-1.0.25/lib/$compiler/$pkg-$version")

** (process:19): WARNING **: 17:28:36.142: Failed to load shared library 
'libcairo-gobject.so.2' referenced by the typelib: libcairo-gobject.so.2: 
cannot open shared object file: No such file or directory
Could not resolve symbol "cairo_gobject_context_get_type" in namespace 
"cairo-1.0"

Appreciate any tips, help, or things to try!

John

bug#49122: (No Subject)

[John Kehayias via Bug reports for GNU Guix]

I've managed to fix the initial problem I noted, but this would depend on 
having cairo as an input so that gobject-introspection can find the library to 
patch the typelib. Unfortunately, this would be a circular dependency. This is 
a long standing issue with how cairo is handled here (see, e.g., 
https://gitlab.freedesktop.org/cairo/cairo/-/issues/141).

I don't know how circular dependencies are solved in guix, so I'm not sure what 
to do to fix this. gobject-introspection doesn't need cairo to build or 
function, so the build depends is not really needed other than to fix this bug. 
So this could be done with a separate package or in two steps?

bug#49122: (No Subject)

[John Kehayias via Bug reports for GNU Guix]

Of course, saw right after my last message that the dependency cycle here is 
through poppler, and cairo-sans-poppler exists. So I think I've solved this 
problem and will submit a patch.

I've attached the current changes I've been working on and testing for now.

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 206222b578..fb3dbdecb5 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -496,6 +496,13 @@ dynamic loading, and an object system.")
 (arguments
  `(#:phases
(modify-phases %standard-phases
+ (add-after 'unpack 'patch
+   ;; Patch for cairo library location
+   (lambda* (#:key inputs #:allow-other-keys)
+  (substitute* "gir/cairo-1.0.gir.in"
+   (("shared-library=\"@CAIRO_SHARED_LIBRARY@\"")
+(string-append "shared-library=\""
+   (assoc-ref inputs "cairo") "/lib/@CAIRO_SHARED_LIBRARY@\"")
  (add-after 'unpack 'do-not-use-/usr/bin/env
(lambda _
  (substitute* "tools/g-ir-tool-template.in"
@@ -507,6 +514,7 @@ dynamic loading, and an object system.")
("pkg-config" ,pkg-config)))
 (inputs
  `(("bison" ,bison)
+   ("cairo" ,cairo-sans-poppler) ; break dependency loop via poppler
("flex" ,flex)
("glib" ,glib)
("python" ,python-wrapper)

bug#48944: haskell build-system cannot build pcg-random

[John Kehayias via Bug reports for GNU Guix]

Hello,

I also see this error for building packages that need cabal-doctest, as the 
configure step needs the package database. There's actually some packages in 
guix that already modify the configure step to do this, like ghc-cairo: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell-xyz.scm#n1465

As noted there, the package database should be passed to runhaskell itself, not 
just what it runs. This would allow other packages that need a module for 
configuring to work. Attached is a patch to modify haskell-build-system to do 
this, though not only for the configure command (seemed easiest to just do that 
for now). I'm submitting the patch with comments there about possible 
modifications.

I can confirm with this that pcg-random builds, as well as packages I've been 
trying that need cabal-doctest (note, I tested using guix's package of 
cabal-doctest, no need to add that as well).

Comments welcome here, especially as I'm pretty new to Haskell still and guix 
completely, or on patch submission (sending shortly).

Johndiff --git a/guix/build/haskell-build-system.scm b/guix/build/haskell-build-system.scm
index 28253ce2f0..be20f13e10 100644
--- a/guix/build/haskell-build-system.scm
+++ b/guix/build/haskell-build-system.scm
@@ -63,13 +63,14 @@
  ((file-exists? "Setup.lhs")
   "Setup.lhs")
  (else
-  #f
+  #f)))
+(pkgdb (string-append "-package-db=" %tmp-db-dir)))
 (if setup-file
 (begin
   (format #t "running \"runhaskell Setup.hs\" with command ~s \
 and parameters ~s~%"
   command params)
-  (apply invoke "runhaskell" setup-file command params))
+  (apply invoke "runhaskell" pkgdb setup-file command params))
 (error "no Setup.hs nor Setup.lhs found"
 
 (define* (configure #:key outputs inputs tests? (configure-flags '())
-- 
2.32.0

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

[John Kehayias via Bug reports for GNU Guix]

I've run into the same problem, seems like fetching the revised cabal file 
would be the best bet. (In the meantime I've modified package definitions to 
make the metadata changes, but that is manual and certainly should be automated 
by import.)

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

[John Kehayias via Bug reports for GNU Guix]

Actually, this does exist in the Haskell build system in Guix, but seems to be 
undocumented and not used by the importer. You can add the following to the 
arguments (in the bootstrap package in this case) to use a metadata revision:

#:cabal-revision ("2" "0a6j3313vz7n7dn8abddyib4jggblaq89f87ib4imdwjxjajbm33")

The hash is from running guix hash file (where file = 2.cabal in this case, 
downloaded from Hackage). This should be part of the importer, to specify a 
revision or by default grab the latest, I would say.

(and I'm guessing you know this is packaged in guix as integer-logarithms, 
without the "ghc-" prefix for some reason; not the only package like that I've 
noticed)

bug#49418: Importing haskell packages from hackage doesn't apply metadata revisions

[John Kehayias via Bug reports for GNU Guix]

Yes, I noticed that later too on some packages I'm working on. Glad you got it 
sorted out.

Still should be documented somewhere, I guess under the build systems.

bug#49477: [core-updates] python-pyyaml fails on sanity-check

[John Kehayias via Bug reports for GNU Guix]

Perhaps due to recent addition/changes for python sanity-check?

Here is the relevant portion of the log from running ./pre-inst-env guix build 
python-pyyaml on core-updates:

warning: build_py: byte-compiling is disabled, skipping.

running build_ext
building 'yaml._yaml' extension
creating build/temp.linux-x86_64-3.9
creating build/temp.linux-x86_64-3.9/yaml
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
-fno-semantic-interposition -fPIC 
-I/gnu/store/4nrih35yjsz2kwhr4pwxnkdzjmkgxxfq-python-3.9.5/include/python3.9 -c 
yaml/_yaml.c -o build/temp.linux-x86_64-3.9/yaml/_yaml.o
gcc: error: yaml/_yaml.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
Error compiling module, falling back to pure Python
phase `build' succeeded after 0.3 seconds
starting phase `install'
running "python setup.py" with command "install" and parameters 
("--prefix=/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1" 
"--no-compile" "--single-version-externally-managed" "--root=/")
running install
running build
running build_py
warning: build_py: byte-compiling is disabled, skipping.

running build_ext
building 'yaml._yaml' extension
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall 
-fno-semantic-interposition -fPIC 
-I/gnu/store/4nrih35yjsz2kwhr4pwxnkdzjmkgxxfq-python-3.9.5/include/python3.9 -c 
yaml/_yaml.c -o build/temp.linux-x86_64-3.9/yaml/_yaml.o
gcc: error: yaml/_yaml.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
Error compiling module, falling back to pure Python
running install_lib
creating /gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1
creating /gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib
creating 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9
creating 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages
creating 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/_yaml
copying build/lib.linux-x86_64-3.9/_yaml/__init__.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/_yaml
creating 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/__init__.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/composer.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/constructor.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/cyaml.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/dumper.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/emitter.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/error.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/events.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/loader.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/nodes.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/parser.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/reader.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/representer.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/resolver.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/scanner.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/serializer.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
copying build/lib.linux-x86_64-3.9/yaml/tokens.py -> 
/gnu/store/i9aqd2hcrfc68ykd24nnjw1nzrdyazrs-python-pyyaml-5.4.1/lib/python3.9/site-packages/yaml
warning: install_lib: byte-compiling is disabled, skipping.

runni

bug#49968: Fwd: issue website creates invalid comment expectations

[John Kehayias via Bug reports for GNU Guix]

(I think the bug title should be "comments sent via issues.guix.gnu.org 
disappear" as they seem to get swallowed by the server)

I sent a comment just a few minutes ago via the webform, that got the message 
that was successful. I'll check back to see if it appears later, but have not 
had it work in the past.

Hope this helps if anyone is checking some logs for what is happening with the 
web comment suggestion.

bug#49968: Fwd: issue website creates invalid comment expectations

[John Kehayias via Bug reports for GNU Guix]

Hi Maxime,

I took a quick look, but I'm not seeing how the proposed fix works: there is 
already that line for defining mu-debug in the only file that uses 
mu-message-send...? (Perhaps this should be sent to that original issue, I can 
send it again there if that is helpful.)

If there is not a relatively quick fix, I would vote for disabling the comment 
submission until it can be fixed. Otherwise, we're losing comments with no 
indication to the submitter.

John

bug#36900: key-mon crashes on launch

[John Kehayias via Bug reports for GNU Guix]

Are there any updates on this, did anyone get it to work? I just tried with the 
same issue on opening display for me too.

I'm seeing the same thing in trying to package autokey, but with the error 
displayed in a graphical window on the X server (and yet it says it doesn't 
know the protocol). This also uses python-xlib, gtk, etc.

Thanks,
John

bug#36900: key-mon crashes on launch

[John Kehayias via Bug reports for GNU Guix]

‐‐‐ Original Message ‐‐‐

On Saturday, August 14th, 2021 at 4:34 PM, John Kehayias wrote:

> Are there any updates on this, did anyone get it to work? I just tried with 
> the same issue on opening display for me too.
>
> I'm seeing the same thing in trying to package autokey, but with the error 
> displayed in a graphical window on the X server (and yet it says it doesn't 
> know the protocol). This also uses python-xlib, gtk, etc.
>

Of course immediatly after I found a workaround, for key-mon and my case: allow 
all to connect to X with `xhost +`. Certainly not the ideal thing to do as it 
disables authentication with X, but show the problem.

Does anyone know the proper way to deal with this for these python packages?

bug#48538: D-Bus services not working on foreign distributions/non-user profiles

[John Kehayias via Bug reports for GNU Guix]

Hi everyone,

I also ran into this issue, where I've put all my packages in various profiles, 
with the default one being empty (outside of short-lived packages for trying 
out). This is a setup is mentioned in the cookbook, on profiles and manifests.

Since the dbus files are not in the default profile, I was running into issues 
with dbus seeing them with the default system daemon (from %desktop-services). 
As suggested above, one workaround is to use dbus-run-session to launch a 
program (no problems).

I found a better one for me, which may be due to how I run my desktop session. 
I use the default gdm but just an .xsession file (which is just my .xinitrc, 
like a plain startx setup). If I modify my WM start in the final line from just 
`exec WM` to `dbus-launch --exit-with-session WM` that works for me. Seems to 
be an issue of how the dbus daemon is run. Could also be a side effect from not 
adding the xsession properly to gdm, but I haven't tried with .desktop files 
yet. (Another work around suggested on IRC was to start a user daemon from the 
login profile; this didn't work for me.) Also note that I did have glib in the 
profile, so that XDG_DATA_DIRS was properly in the profile, and all profiles 
loaded at login.

Hope this is helpful and that we can find a proper solution, as I think this is 
a tricky bug to encounter for a user.

John

bug#44997: Flatpaks are invisible to application launchers

[John Kehayias via Bug reports for GNU Guix]

I agree this should be exported by the flatpak package. I haven't hit any other 
packages putting anything in /etc/profile.d, though that does happen I know (so 
perhaps Guix should incorporate or patch such things?). Flatpak is also due for 
an update soon I think, so that would be a good time to make the modification 
perhaps.

bug#50004: got exception while creating partitions

[John Kehayias via Bug reports for GNU Guix]

Hi,

Thanks for filing this, I actually hit I think the same error when using the 
installer a week or 2 ago (built fresh from the main branch, not 1.3.0 which I 
found even flakier). This was on a nvme drive, also trying to just do the 
default ext4 partitions.

In general, it seems the partitioner is brittle: it didn't like some partially 
created partitions from a previous run, once made /boot an ext4 partition 
(rather than fat32), didn't like my messing with manual configuration.

In the end, I made sure to start with a clean (no partitions drive) and then it 
worked. I wish I had more detailed info, but for obvious reasons can't 
reproduce it now. I think I have some photos available, but looked like the 
same error I remember seeing.

Oh, and when there is a problem with partitions the installer kicks you back to 
the very beginning, which makes for a more tedious process in figuring out how 
to make it work.

Hope this is helpful!

John

bug#48538: D-Bus services not working on foreign distributions/non-user profiles

[John Kehayias via Bug reports for GNU Guix]

It looks like dbus-daemon-wrapper tries to take care of this by finding the 
user's profile, but this would just be the default one: 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/xorg.scm#n851

Not sure if it is easy for the service to find a non-standard profile, or if 
this should be exposed some other way.

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

Hello,

A minor bug: I think Pulseaudio should have XDG_CONFIG_DIRS as an exported 
search path, as it includes a desktop file in /etc/xdg/autostart. This would be 
used by e.g. starting just a window manager and using something like dex to run 
autostart programs. Of course there are other ways to do this, but especially 
if pulseaudio is not in the default user or system profile then XDG_CONFIG_DIRS 
will not include pulseaudio.

Are there any downsides to including XDG_CONFIG_DIRS in the pulseaudio package? 
I haven't run across any other packages falling into this case as well, but I 
wouldn't be surprised for anything that supplies an autostart .desktop file.

Thanks,
John

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

Hi Leo and Maxime,

Thanks for discussing this. A few questions/clarifications (perhaps mostly 
because I'm still new here) below. I'm not familiar enough with the internals 
of guix search-paths, so my perspective is mostly from the end-user standpoint.

‐‐‐ Original Message ‐‐‐

On Wednesday, August 18th, 2021 at 5:45 AM, Leo Prikler wrote:

> Hi,
>
> Am Mittwoch, den 18.08.2021, 11:28 +0200 schrieb Maxime Devos:
>
> > Leo Prikler schreef op wo 18-08-2021 om 10:03 [+0200]:
> >
> > > Hi John,
> > >
> > > a lot of packages would do much better if they exported
> > >
> > > XDG_CONFIG_DIRS. However, there is currently no way of doing so
> > >
> > > other
> > >
> > > than copypasting the same snippet over and over and over and
> > >
> > > over. A
> > >
> > > workaround -- if you need this in an environment -- is to also
> > >
> > > include
> > >
> > > a package, that already has a search path on XDG_CONFIG_DIRS, like
> > >
> > > glib
> > >
> > > (I think glib:bin works too).
> > >

I'm slightly confused here: I only see XDG_DATA_DIRS in the glib package. I 
include glib to get that export actually (I have everything in profiles, 
nothing in the default user). Autostart files are in 
$XDG_CONFIG_DIRS/autostart. XDG_DATA_DIRS seems to come up the most and more 
needed it seems to me (based on what I have there in a desktop environment).

> > > I recently tried exporting XDG_CONFIG_DIRS as a variable from one
> > >
> > > module, so that it can be referenced in others, but that led to a
> > >
> > > weird
> > >
> > > recursive errors. It would be nice to find a good way of doing
> > >
> > > that,
> > >
> > > though.
> >
> > What do you think of defining the 
> >
> > $XDG_CONFIG_DIR in (guix search-paths) itself, next to $PATH? That
> >
> > seems
> >
> > unlikely to lead to recursive errors.
> >
> > Alternatively, I would guess that making 'search-paths' and
> >
> > 'native-search-paths' a ‘thunked’ field would resolve the errors,
> >
> > at cost of making  objects use a bit more memory.
>
> Both sound like interesting proposals. Obviously, adding
>
> $XDG_CONFIG_DIRS to (guix search-paths) would work in the short term,
>
> but I think defining all interesting environment variables there is
>
> probably not the best solution for the future. There's a few variables
>
> that are used widely FSVO widely, but using them also implies having
>
> some package as input, e.g. the cURL-related ones. XDG_CONFIG_DIRS
>
> technically also falls in there, because you will have either xorg or
>
> xdisorg imported. Therefore, I think I'd prefer a solution where
>
> variables can be exported (and re-exported) from any module in the (gnu
>
> packages) subtree.
>

Is the case here that glib should have XDG_CONFIG_DIRS in it? Or does that only 
make sense in some other package that could then be included in a profile to 
get XDG_CONFIG_DIRS, similar to XDG_DATA_DIRS now?

I didn't see many references to XDG_CONFIG_DIRS in our current packages, mostly 
in some Lisp compilers and a few other random places. Slightly surprised it is 
not in more, but maybe packages that would normally put something in /etc/xdg 
(default for XDG_CONFIG_DIRS) have been configured otherwise.

I feel like my setup, from the cookbook, of having everything in profiles with 
the default user one being empty other than testing, has exposed a few related 
issues. What we are discussing might also have relevance to dbus files (see 
#48538), and perhaps to an older issue about paths and /etc/profile (#20255). 
(Not to bring up an old issue, but it was one that came up when searching for 
related issues in the past, which I skimmed.)

John

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

Hi Leo,

‐‐‐ Original Message ‐‐‐

On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler  wrote:
[...]
> > > >
> > > > > Hi John,
> > > > >
> > > > > a lot of packages would do much better if they exported
> > > > >
> > > > > XDG_CONFIG_DIRS. However, there is currently no way of doing so
> > > > >
> > > > > other than copypasting the same snippet over and over and over
> > > > >
> > > > > and over. A workaround -- if you need this in an environment --
> > > > >
> > > > > is to also include a package, that already has a search path on
> > > > >
> > > > > XDG_CONFIG_DIRS, like glib (I think glib:bin works too).
> >
> > I'm slightly confused here: I only see XDG_DATA_DIRS in the glib
> >
> > package. I include glib to get that export actually (I have
> >
> > everything in profiles, nothing in the default user). Autostart files
> >
> > are in $XDG_CONFIG_DIRS/autostart. XDG_DATA_DIRS seems to come up the
> >
> > most and more needed it seems to me (based on what I have there in a
> >
> > desktop environment).
>
> Haha, my bad, yeah glib only provides XDG_DATA_DIRS. In that case I'm
>
> not sure which one would be the canonical workaround package.
>

Okay, just checking! I didn't see any workaround package, very few references 
to XDG_CONFIG_DIRS in our packages.

> > > > > I recently tried exporting XDG_CONFIG_DIRS as a variable from
> > > > >
> > > > > one module, so that it can be referenced in others, but that
> > > > >
> > > > > led to a weird recursive errors. It would be nice to find a
> > > > >
> > > > > good way of doing that, though.
> > > >
> > > > What do you think of defining the 
> > > >
> > > > $XDG_CONFIG_DIR in (guix search-paths) itself, next to $PATH?
> > > >
> > > > That seems unlikely to lead to recursive errors. Alternatively, I
> > > >
> > > > would guess that making 'search-paths' and 'native-search-paths'
> > > >
> > > > a ‘thunked’ field would resolve the errors, at cost of making
> > > >
> > > >  objects use a bit more memory.
> > > >
> > > > Both sound like interesting proposals. Obviously, adding
> > > >
> > > > $XDG_CONFIG_DIRS to (guix search-paths) would work in the short
> > > >
> > > > term, but I think defining all interesting environment variables
> > > >
> > > > there is probably not the best solution for the future. There's a
> > > >
> > > > few variables that are used widely FSVO widely, but using them also
> > > >
> > > > implies having some package as input, e.g. the cURL-related ones.
> > > >
> > > > XDG_CONFIG_DIRS technically also falls in there, because you will
> > > >
> > > > have either xorg or xdisorg imported. Therefore, I think I'd prefer
> > > >
> > > > a solution where variables can be exported (and re-exported) from
> > > >
> > > > any module in the (gnu packages) subtree.
> >
> > Is the case here that glib should have XDG_CONFIG_DIRS in it? Or does
> >
> > that only make sense in some other package that could then be
> >
> > included in a profile to get XDG_CONFIG_DIRS, similar to
> >
> > XDG_DATA_DIRS now?
>
> I'm not sure about that myself but the answer is probably no.
>
> > I didn't see many references to XDG_CONFIG_DIRS in our current
> >
> > packages, mostly in some Lisp compilers and a few other random
> >
> > places. Slightly surprised it is not in more, but maybe packages that
> >
> > would normally put something in /etc/xdg (default for
> >
> > XDG_CONFIG_DIRS) have been configured otherwise.
>
> I think the likelier explanation is that XDG_CONFIG_DIRS is possibly
>
> underused when compared to XDG_DATA_DIRS. Most packages store their
>
> configuration -- if any -- in /etc/foo rather than /etc/xdg/foo. I'm
>
> pretty certain that using /etc/xdg rather than /etc was an error on
>
> XDG's part as XDG_CONFIG_HOME, which defaults to ~/.config makes much
>
> more sense from an application writer's POV.
>

It does seem less universal. On a non-Guix system I see a handful of programs 
that keep default configurations there, things like ICC profiles, and of course 
autostart .desktop files.

> > I feel like my setup, from the cookbook, of having everything in
> >
> > profiles with the default user one being empty other than testing,
> >
> > has exposed a few related issues. What we are discussing might also
> >
> > have relevance to dbus files (see #48538), and perhaps to an older
> >
> > issue about paths and /etc/profile (#20255). (Not to bring up an old
> >
> > issue, but it was one that came up when searching for related issues
> >
> > in the past, which I skimmed.)
>
> You are indeed right, multiple profiles are very badly supported by
>
> Guix. Needing to jump through the hoops described in the cookbook in
>
> the first place is in my eyes a clear enough indicator to support my
>
> point.
>

And I think that is a shame, as profiles and manifests are such a great feature 
of Guix. The ability to compartmentalize package groups is very nice just on 
the organizational level, but does seem less than fully incorporated at this 
point. It is 

bug#50103: Pulseaudio doesn't export XDG_CONFIG_DIRS

[John Kehayias via Bug reports for GNU Guix]

Hi Leo,

‐‐‐ Original Message ‐‐‐

On Wednesday, August 18th, 2021 at 12:35 PM, Leo Prikler wrote:

> Hi John,
>
> For the record, you should try to cite in a way, that lines don't get
> broken. I have no idea why this is happening
>

I just noticed that too, sorry. Seems protonmail likes to wrap at a shorter 
length and introduces these blank lines. Guess it is about time I get this 
account into mu4e.

> Am Mittwoch, den 18.08.2021, 16:06 + schrieb John Kehayias:
>
> > Hi Leo,
> >
> > On Wednesday, August 18th, 2021 at 11:19 AM, Leo Prikler wrote:
> >
> > [...]
> >
> > .config/guix is hardcoded in a few places already isn't it? (or is
> > that just for root? took just a quick look) Personally, I prefer
> > everything in .config to keep the home folder cleaner, but we all
> > know there's a strong mix of things like $HOME/.something and
> > $HOME/.config/something.
>
> $(HOME)/.config is particularly hard-coded in the current /etc/profile,
> which is why I dub it "fake XDG conformance". I personally disagree
> with the use for $(HOME)/.config for software packages.
>

Well, it is all a bit of a mess. Off topic, but I try to use literate org files 
and stow to wrangle everything.

> > [...]
> >
> > I suppose that still leaves the question of search paths. I don't
> > think I know enough of the internals to have a helpful input here so
> > far. Handling multiple profiles together would help pull in some
> > search-paths and maybe alleviate #48538 (dbus)? Would then /etc be
> > constructed from all the profiles together (by passing this
> > XDG_CONFIG_DIRS issue)? If it is still /etc in each profile relying
> > on env to find things, then at least in this case XDG_CONFG_DIRS
> > still has to appear somewhere. Search paths in profiles could be
> > good, conceptually works for how profiles are used, to me.
>
> For context, `guix package --search-paths' would implement the merged
> approach IIUC, but then you would have to invoke guix from
> /etc/profile, which reportedly is not every person's tea. You could
> still manually source $GUIX_PROFILE/etc/profile, but would then get an
> incomplete view depending on what your profiles look like.
>

That was the discussion in #20255 that was never resolved.

In this case, I don't think any combination of `guix package --search-paths` 
will update XDG_CONFIG_DIRS since it is not in the native-search-paths of any 
of my included packages, as far as I can tell. I do see it included in qtbase, 
but I'd rather avoid pulling that in unless I actually have qt packages (which 
I probably will at some point). Just checking, and installing qtbase would 
indeed add XDG_CONFIG_DIRS to the /etc/profile as expected.

Is there a reason qtbase has it but nothing on the glib/gtk/xorg side?

> As for the XDG_CONFIG_DIRS, I don't think your scenario is the only
> possible one, but with things being as they are currently, it is among
> the likeliest outcomes. Another approach would be to define "precious"
> search paths, which would be considered even if not explicitly
> mentioned by any package/profile. (I think this somewhat overlaps
> with/complements search paths as a first-class manifest citizen). I'm
> just throwing out ideas here, so you shouldn't necessarily take any of
> them as the solution to all our problems or something that can be
> easily implemented given the status quo, but if you want, you can take
> some inspiration from them or try out your own (thought) experiments.
>

I understand, this is a longer-term direction to discuss (I can certainly work 
around this issue in many ways). I think the related dbus issue #48538 is more 
noticeable, but all point towards better sorting out how we treat profiles and 
search-paths. My process as a new Guix user is to get everything working as I 
like it, and then try to reduce the edge case workarounds I've had to put in (a 
related one is #44997, for packages that may put things in /etc/profile.d).

I think it would be good to get some overall input and direction for what 
people would like as the next steps in how we manage profiles (and 
search-paths).

Thanks for the discussion so far, hopefully we can get some broad design 
choices and end goals in mind to then work out details.

John

bug#50788: Swapfile on Btrfs does not start at boot

[John Kehayias via Bug reports for GNU Guix]

Hi all,

This has been discussed a few times on #guix, with some having success, but 
mostly it seems not. The issue is having a swapfile (maybe also for partition?) 
on Btrfs and swap not being activated on boot. In my case, I can manually start 
with `sudo herd start swap-/swap/swapfile` and it will work fine. There might 
be an issue with when different filesystems are loaded with Btrfs subvolumes? I 
have my swap as a file on a subvolume.

>From syslog, just before and after the only "swap" related message:

Sep 23 13:09:31 localhost vmunix: [9.424364] shepherd[1]: Service udev has 
been started.
Sep 23 13:09:31 localhost vmunix: [9.424466] Unable to find swap-space 
signature
Sep 23 13:09:31 localhost vmunix: [9.424912] shepherd[1]: Service 
user-file-systems has been started.
Sep 23 13:09:31 localhost vmunix: [9.443245] shepherd[1]: Service 
file-system-/swap has been started.
Sep 23 13:09:31 localhost vmunix: [9.454002] shepherd[1]: Service 
file-system-/var/log has been started.
Sep 23 13:09:31 localhost vmunix: [9.464911] shepherd[1]: Service 
file-system-/home has been started.

Checking the status of the service shows:

  It is stopped.
  It is enabled.
  Provides (swap-/swap/swapfile).
  Requires (udev).
  Conflicts with ().
  Will not be respawned.

This is the file-systems and swap part of my system configuration:

  (file-systems (append
 (list (file-system
 (device (file-system-label "system"))
 (mount-point "/")
 (type "btrfs")
 (flags '(no-atime))
 (options "subvol=root,compress=lzo,ssd"))
   (file-system
 (device (file-system-label "system"))
 (mount-point "/swap")
 (type "btrfs")
 (flags '(no-atime))
 (options "subvol=swap,ssd"))
   (file-system
 (device (file-system-label "system"))
 (mount-point "/gnu/store")
 (type "btrfs")
 (flags '(no-atime))
 (options "subvol=gnu-store,compress=lzo,ssd"))
   (file-system
 (device (file-system-label "system"))
 (mount-point "/var/log")
 (type "btrfs")
 (flags '(no-atime))
 (options "subvol=var-log,compress=lzo,ssd"))
   (file-system
 (device (file-system-label "system"))
 (mount-point "/home")
 (type "btrfs")
 (flags '(no-atime))
 (options "subvol=home,compress=lzo,ssd"))
   (file-system
 (device (uuid "5989-F926" 'fat))
 (mount-point "/boot/efi")
 (type "vfat")))
 %base-file-systems))
  (swap-devices (list "/swap/swapfile"))

Hope this is helpful in tracking down what is happening, I know I'm not alone 
in this issue.

John

bug#50789: syncthing-gtk creates autostart file with wrong bin

[John Kehayias via Bug reports for GNU Guix]

Hello,

syncthing-gtk has an option to enable autostart, which it does by creating the 
.desktop file in ~/.config/autostart However, this has the wrong exec line, 
getting the -real script instead of syncthing-gtk. This won't work as it needs 
to be run as syncthing-gtk. Namely, it produces:

Exec=/gnu/store/vf5h9jqhq40x8r46afaa0jgw7awg1361-syncthing-gtk-0.9.4.4-1.c46fbd8/bin/.syncthing-gtk-real

Instead of

Exec=/gnu/store/vf5h9jqhq40x8r46afaa0jgw7awg1361-syncthing-gtk-0.9.4.4-1.c46fbd8/bin/syncthing-gtk

This is due to syncthing-gtk getting its executable name to write to the 
.desktop file in get_executable(): 
https://salsa.debian.org/debian/syncthing-gtk/-/blob/master/syncthing_gtk/tools.py#L409
 where due to wrapping it will find something that won't work when run directly.

How should this be solved in Guix? Should we patch this part of the code to 
explicitly rewrite the path to have "syncthing-gtk" instead of 
".syncthing-gtk-real"? Related would be the discussion at 
https://lists.gnu.org/r/guix-devel/2021-09/msg00088.html which I will message 
separately.

Thanks,
John

bug#50789: syncthing-gtk creates autostart file with wrong bin

[John Kehayias via Bug reports for GNU Guix]

Hi Leo, Liliana, et al,

‐‐‐ Original Message ‐‐‐

On Friday, September 24th, 2021 at 7:15 PM, Leo Famulari wrote:

> Maybe we could make the desktop file execute a path like
>
> "$HOME/.guix-profile/bin/syncthing-gtk"?

Hmm...these are both good points. And I think I may have run into stale files 
produced by some programs due to this. Actually, checking now, I see the same 
for redshift-gtk in the autostart .desktop file it makes (a /gnu/store link). 
So this is perhaps more common when programs create files like this.

I think there are a few possibilities and assumptions that go with them.

1. Rely on $PATH so that it can just be Exec=syncthing-gtk This is pretty 
common (non-Guix, at least) I think, but is an assumption. Seems safe for a 
program like this, but ambiguous, especially with Guix allowing multiple of the 
same-named bin to be installed at the same time.

2. Something like what was suggested by Leo, but we have to consider different 
profiles. Is that easy to account for in a build time patch? In my case it ends 
up $HOME/.config/guix/profiles/desktop/desktop/bin/syncthing-gtk Though I guess 
this happens at install. Perhaps the Python code can be patched to make 
something like this, based on its runtime path.

3. Remove the ability for these types of files to be created, as Liliana 
suggested. I think this is drastic though, changing the expected behavior in 
programs and difficult to enforce evenly. The point raised is important though, 
that direct /gnu/store links shouldn't be used in such a way.

Perhaps there are others. What do we currently do in Guix, or what would be 
preferred? From a user standpoint, I'd expect creating an autostart file (for 
instance) to work as created and to continue to do so.

John

bug#50827: [core-updates-frozen] python-graphql-relay fails on sanity-check

[John Kehayias via Bug reports for GNU Guix]

I'm not familiar with this package, perhaps some graphql related input missing? 
Last time I saw a sanity-check failure it was missing cython, see #49477. 
Haven't had a chance to try that here or investigate further, maybe someone 
familiar with this package know?

Thanks, and log below:

starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to 
`/gnu/store/nc8ip460g4lxg7nrsbmixsball4q7iki-python-wrapper-3.9.6/bin:/gnu/store/bd4gc7c1iaxp01ny9sz0vyfqkbrw810i-tar-1.34/bin:/gnu/store/9lg89igqqirv4kjmmz7vdzpq03gqrnmp-gzip-1.10/bin:/gnu/store/zyxdj13lwzlyskciggkkvdawk8s02ixn-bzip2-1.0.8/bin:/gnu/store/dw0d06h96hj9bm0h53m4x76wzwarrijg-xz-5.2.5/bin:/gnu/store/3f38x5psqk4i5zr4f6ah6rn6mh8ddzx6-file-5.39/bin:/gnu/store/rdbdmlhqgil54s4zq4awgadikfvdyan0-diffutils-3.7/bin:/gnu/store/vpdi8s1ssf5i1hxywflwjghk7xhx9z71-patch-2.7.6/bin:/gnu/store/ws9f4il05xjzyn9fmqyfglxjjy8jn8m9-findutils-4.8.0/bin:/gnu/store/s9rizbsiib3yqpncyf3802492rsnc3f6-gawk-5.1.0/bin:/gnu/store/0f86j2693pb29b028hbw1bab21i7w8mk-sed-4.8/bin:/gnu/store/i7wy4i022wwzywphxaf8nkchimnpy3fz-grep-3.6/bin:/gnu/store/w38rjighbdrysw9jdk7jv0fcxlrsg541-coreutils-8.32/bin:/gnu/store/9r929ilzl2kx2b1f7xnmqrbppn8gxhl7-make-4.3/bin:/gnu/store/p83y2lk39h7pbakr4mgmfnwcr832xxq2-bash-minimal-5.1.8/bin:/gnu/store/zglh8w9pj8hi40dpx0r6m8k9cmyvam84-ld-wrapper-0/bin:/gnu/store/nzvk9jc1sfw5637r10b3zs43hhqgwkv9-binutils-2.37/bin:/gnu/store/n33lh3szhvzc4ykdd42ii94khan0p9y5-gcc-10.3.0/bin:/gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/bin:/gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/sbin:/gnu/store/9ippfada78x436nmvg7hiv19005ngavm-python-3.9.6/bin'
environment variable `GUIX_PYTHONPATH' set to 
`/gnu/store/9cdm1v9d04cfk2iyq2sn47lg3bqpks9n-python-graphql-core-3.1.2/lib/python3.9/site-packages:/gnu/store/2a9cqqqph51cqmb052ssbwas0wk6480h-python-promise-0.4.2/lib/python3.9/site-packages:/gnu/store/g98qvf4rbsjpb2pi60si4jaqv99xa6p2-python-six-1.15.0/lib/python3.9/site-packages:/gnu/store/9ippfada78x436nmvg7hiv19005ngavm-python-3.9.6/lib/python3.9/site-packages'
environment variable `PYTHONTZPATH' unset
environment variable `BASH_LOADABLES_PATH' unset
environment variable `C_INCLUDE_PATH' set to 
`/gnu/store/zyxdj13lwzlyskciggkkvdawk8s02ixn-bzip2-1.0.8/include:/gnu/store/dw0d06h96hj9bm0h53m4x76wzwarrijg-xz-5.2.5/include:/gnu/store/3f38x5psqk4i5zr4f6ah6rn6mh8ddzx6-file-5.39/include:/gnu/store/s9rizbsiib3yqpncyf3802492rsnc3f6-gawk-5.1.0/include:/gnu/store/9r929ilzl2kx2b1f7xnmqrbppn8gxhl7-make-4.3/include:/gnu/store/nzvk9jc1sfw5637r10b3zs43hhqgwkv9-binutils-2.37/include:/gnu/store/n33lh3szhvzc4ykdd42ii94khan0p9y5-gcc-10.3.0/include:/gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/include:/gnu/store/9ippfada78x436nmvg7hiv19005ngavm-python-3.9.6/include:/gnu/store/lxdk5i48czjw2i8k86dvb7wqy2rlg4ql-linux-libre-headers-5.10.35/include'
environment variable `CPLUS_INCLUDE_PATH' set to 
`/gnu/store/zyxdj13lwzlyskciggkkvdawk8s02ixn-bzip2-1.0.8/include:/gnu/store/dw0d06h96hj9bm0h53m4x76wzwarrijg-xz-5.2.5/include:/gnu/store/3f38x5psqk4i5zr4f6ah6rn6mh8ddzx6-file-5.39/include:/gnu/store/s9rizbsiib3yqpncyf3802492rsnc3f6-gawk-5.1.0/include:/gnu/store/9r929ilzl2kx2b1f7xnmqrbppn8gxhl7-make-4.3/include:/gnu/store/nzvk9jc1sfw5637r10b3zs43hhqgwkv9-binutils-2.37/include:/gnu/store/n33lh3szhvzc4ykdd42ii94khan0p9y5-gcc-10.3.0/include/c++:/gnu/store/n33lh3szhvzc4ykdd42ii94khan0p9y5-gcc-10.3.0/include:/gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/include:/gnu/store/9ippfada78x436nmvg7hiv19005ngavm-python-3.9.6/include:/gnu/store/lxdk5i48czjw2i8k86dvb7wqy2rlg4ql-linux-libre-headers-5.10.35/include'
environment variable `LIBRARY_PATH' set to 
`/gnu/store/9cdm1v9d04cfk2iyq2sn47lg3bqpks9n-python-graphql-core-3.1.2/lib:/gnu/store/2a9cqqqph51cqmb052ssbwas0wk6480h-python-promise-0.4.2/lib:/gnu/store/g98qvf4rbsjpb2pi60si4jaqv99xa6p2-python-six-1.15.0/lib:/gnu/store/zyxdj13lwzlyskciggkkvdawk8s02ixn-bzip2-1.0.8/lib:/gnu/store/dw0d06h96hj9bm0h53m4x76wzwarrijg-xz-5.2.5/lib:/gnu/store/3f38x5psqk4i5zr4f6ah6rn6mh8ddzx6-file-5.39/lib:/gnu/store/s9rizbsiib3yqpncyf3802492rsnc3f6-gawk-5.1.0/lib:/gnu/store/nzvk9jc1sfw5637r10b3zs43hhqgwkv9-binutils-2.37/lib:/gnu/store/wvj3sz513h0zjc3fxnlm01pbnc92m59r-glibc-2.33/lib:/gnu/store/35inmjfw430awcvcsp6i1k4jcr3y5wg9-glibc-2.33-static/lib:/gnu/store/v7xnak2svydi4jdjpmqcwxgbxa73am6d-glibc-utf8-locales-2.33/lib:/gnu/store/9ippfada78x436nmvg7hiv19005ngavm-python-3.9.6/lib'
environment variable `GUIX_LOCPATH' set to 
`/gnu/store/v7xnak2svydi4jdjpmqcwxgbxa73am6d-glibc-utf8-locales-2.33/lib/locale'
phase `set-paths' succeeded after 0.0 seconds
starting phase `install-locale'
using 'en_US.utf8' locale for category "LC_ALL"
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
graphql-relay-0.4.5/
graphql-relay-0.4.5/graphql_relay/
graphql-relay-0.4.5/graphql_relay/__init__.py
graphql-relay-0.4.5/graphql_relay/connection/
graphql-relay-0.4.5/graphql_

bug#50830: [core-updates-frozen] glibc looks for $sysconfdir/etc/localtime rather than /etc/localtime

[John Kehayias via Bug reports for GNU Guix]

Just to followup, here is the relevant part of my `guix describe`:

  guix c6a8d6d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: core-updates-frozen
commit: c6a8d6db77520097bd0b2df99bfab659bfcfd64c

On a side note, nearly everything else seems to work well for me on 
core-updates-frozen. Will be happy to test a post-world-rebuild when that comes.

bug#50827: [core-updates-frozen] python-graphql-relay fails on sanity-check

[John Kehayias via Bug reports for GNU Guix]

Hi Efraim,

‐‐‐ Original Message ‐‐‐

On Monday, September 27th, 2021 at 2:23 AM, Efraim Flashner wrote:

> Fixed by updating the package to 3.1.0.
>

Thanks, that did it. Following the chain from there, python-graphene is failing 
at sanity-check. And now I see our version is super old; probably we should 
update the related libraries? Looks like that is blocking python-nautilus and 
dependents (like syncthing-gtk, gnome-shell-extension-gsconnect).

I can submit another bug report if that helps.

Thanks again!