bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

Building the new Podman package fails because building a depdency 
(gvisor-tap-vsock) fails:
 
The following derivation will be built:
/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv
building 
/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv...
WARNING: (guile-user): imported module (guix build utils) overrides core 
binding `delete'
Backtrace:
16 (primitive-load "/gnu/store/2a9k7v2qhydivh63xv921gr6kp9?")
In ice-9/eval.scm:
214:21 15 (_ #f)
217:50 14 (lp (# ?))
217:50 13 (lp (# ?))
217:50 12 (lp (# ?))
217:50 11 (lp (# ?))
217:50 10 (lp (# ?))
217:50 9 (lp (# ?))
217:50 8 (lp (# ?))
217:50 7 (lp (# ?))
217:50 6 (lp (# ?))
217:50 5 (lp (# ?))
217:33 4 (lp (# ?))
293:34 3 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
173:55 2 (_ #(#(#(#(#(# ?) ?) ?) ?) ?))
223:20 1 (proc #(#(#(#(#(# ?) ?) ?) ?) ?))
In unknown file:
0 (%resolve-variable (5 (guix build go-build-system) . #) #)
ERROR: In procedure %resolve-variable:
In procedure module-lookup: Unbound variable: remove-go-references
builder for 
`/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv' failed 
with exit code 1
build of /gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv 
failed
View build log at 
'/var/log/guix/drvs/4l/zcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv.gz'.
guix build: error: build of 
`/gnu/store/4lzcddslib984s8mlf854ig2lpgmnv3k-gvisor-tap-vsock-0.7.3.drv' failed
error: Recipe `guix` failed on line 13 with exit code 1
 
It looks to me like 0df957eecc536e1d0a5722b47dda1563439bbe04 removed 
remove-go-references, but it is still used by podman, gvisor-tap-vsock, and 
buildah.
 
--
Nils Landt

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

> jgart  hat am 01.07.2024 16:35 CEST geschrieben:
> 
>  
> > Building the new Podman package fails because building a depdency
> > (gvisor-tap-vsock) fails:
> 
> Hi Nils,
> 
> Would you be interested in sending patches to fix these failures?

No, the patch submission process is too annoying for me.

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

> jgart  hat am 01.07.2024 19:04 CEST geschrieben:
> 
>  
> > No, the patch submission process is too annoying for me.
> >
> 
> Hi Nils,
> 
> Sorry to hear that. I can relate to that as I've also been annoyed by aspects 
> of the process.
> 
> Can you share some of the pain points that you've experienced with the patch 
> submission process?
> 
> This will help us potentially address that and open discussion around it.
>
> How do you think that the patch submission process can be improved?
 
Nothing that hasn't been talked about for years, really.

- Patch submission workflow without email
- Code review tool with threaded at-code conversations
- Code formatter that I can make work for vim (i.e. guix style for non-packages)
- Useful commit messages instead of GNU ChangeLog

My previous attempt at contribution (https://issues.guix.gnu.org/66557) was 
quite unpleasant.
I don't know how to phrase my critique of the reviewers in a constructive 
manner, given that I respect we're all human beings volunteering time for this 
hobby.
 
> I'm going to give a talk in August at the Guix London meetup on patch review, 
> the mumi CLI tool, and my current personal workflow.

I will be watching the recording, but I don't see how it would address my 
wishlist :)

bug#71870: Some broken Go packages (including Podman)

[Nils Landt]

> Jean-Pierre De Jesus Diaz  hat am 03.07.2024 18:40 CEST 
> geschrieben:
> 
>  
> Hello,
> 
> I've sent a few patches in  to fix
> the build of these
> packages and also updates podman to latest version.
> 
> Cheers,

Thank you very much Jean-Pierre.

bug#66659: (home-)on-first-login script broken when no gexps are added

[Nils Landt]

Error message:

ice-9/psyntax.scm:2824:12: In procedure syntax-violation:
Syntax error:
/home/nl/.guix-home/on-first-login:3:1233: source expression failed to match 
any pattern in form (when (claim-first-run flag-file-path))

As you can see, there is no body in the "when" expression.

Code in gnu/home/services.scm:438 :

  (if (file-exists? xdg-runtime-dir)
  (when (claim-first-run flag-file-path)
#$@gexps)

In my case, it appears that gexps is empty, resulting in the invalid syntax.

Broken by b92235ea8b06e304072bad55ae006593ea673568

bug#66659: closed (Re: bug#66659: (home-)on-first-login script broken when no gexps are added)

[Nils Landt]

> help-debb...@gnu.org hat am 21.10.2023 16:16 CEST geschrieben:
> 
>  
> Your bug report
> 
> #66659: (home-)on-first-login script broken when no gexps are added
> 
> which was filed against the guix package, has been closed.
> 
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 66...@debbugs.gnu.org.
> 
> -- 
> 66659: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66659
> GNU Bug Tracking System
> Contact help-debb...@gnu.org with problems
> Hi Carlo & Nils,
> 

> I’ve just pushed something similar to what you provided, Carlo, in
> commit e098ba2f499bbddfea50c85058e4077e39b85513.
> 
> We should be good now.

I'm afraid this did not fix the issue. It results in
(when (claim-first-run flag-file-path) (begin))

which leads to the new error message "Syntax error:
/home/nl/.guix-home/on-first-login:3:1272: sequence of zero expressions in form 
(begin)"

bug#65471: home mcron service overwrites PATH with a GuixSD-only directory

[Nils Landt]

> Ludovic Courtès  hat am 20.11.2023 23:10 CET geschrieben:

> nils@landt.email skribis:
> 
> > when using the home-mcron-service, PATH is set to 
> > /run/current-system/profile/bin . This directory is empty when using guix 
> > home on a foreign distro, meaning all executable paths would need to be 
> > absolute. This includes stuff like /usr/bin/ssh, /usr/bin/nice etc..
> >  
> > My guess for the culprit was 1c30d5a6bfc5d48137f4bdcc271189a06fdc6ed3 , 
> > which replaced the custom home-mcron-service-type with mapping it to 
> > mcron-service-type. 
> > The mcron shepherd service in old service type did not mess with the 
> > environment variables, the inherited one does:
> > #:environment-variables
> > (cons* "GUILE_AUTO_COMPILE=0"
> > "PATH=/run/current-system/profile/bin"
> > (remove (cut string-prefix? "PATH=" <>)
> > (environ)))
> 
> As a rule of thumb, I personally always provide absolute file names, as
> in #~(job … #$(file-append coreutils "/bin/ls") …).

I do the same, but occasionally a program I call expects something to be 
available in PATH. For me (guix home in Debian 12), this includes Guix itself.
Running 
/home/nl/.config/guix/current/bin/guix pull 
in a terminal works perfectly fine, but
unset PATH
/home/nl/.config/guix/current/bin/guix pull 
results in a stacktrace that ends in:
In guix/scripts/pull.scm:
453:4  4 (_)
In guix/build/utils.scm:
625:6  3 (which "guix")
In unknown file:
   2 (string-tokenize #f # …)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure string-tokenize: Wrong type argument in position 1 (expecting 
string): #f

> I wonder what the preferred behavior would be.  Restore PATH to whatever
> value it had when the user ‘shepherd’ process was started, at the
> expense of making things harder to track/less reproducible?  Should we
> leave it unset, possibly breaking programs that expect it to be set?
> Should we set it to “/run/current-system/profile/bin:/usr/bin” or
> similar?

I think the previous behaviour was fine for a user level service. I'm guessing 
this was inheriting the environment variables from the shepherd process that 
started mcron?

Otherwise, adding /usr/local/bin:/usr/bin:/bin should be a good default I think.

I'm not emotionally invested either way, I have moved away from shepherd / 
mcron.

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Nils Landt]

Hello,

I use guix home for almost everything, but I have installed glibc-locales in my 
"regular" guix (just by running guix package install glibc-locales).
Now, running guix package --upgrade fails with:
guix package: error: package glibc-locales@2.37 does not support x86_64-linux

But from my reading of (gnu packages base), glibc-locales version should be the 
same as glibc version. This is not the case for me though:
guix repl
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use (gnu packages)
scheme@(guix-user)> (specification->package "glibc-locales")
$1 = #
scheme@(guix-user)> (specification->package "glibc")
$2 = #

In my home profile, I was able to fix it by using (make-glibc-locales glibc) 
instead of (specification->package "glibc-locales").

bug#67586: guix package: error: package glibc-locales@2.37 does not support x86_64-linux

[Nils Landt]

> Ludovic Courtès  hat am 06.12.2023 23:58 CET geschrieben:
> 
>  
> Hi,
> 
> Nils Landt  skribis:
> 
> > I use guix home for almost everything, but I have installed glibc-locales 
> > in my "regular" guix (just by running guix package install glibc-locales).
> > Now, running guix package --upgrade fails with:
> > guix package: error: package glibc-locales@2.37 does not support 
> > x86_64-linux
> 
> Fixed with 4a6cef9d66ff26e96d63f2f1f886b8212154ca00.
> 
> The problem was that glibc-locales@2.37 is marked as supported for
> i586-gnu only (that’s GNU/Hurd).

Thank you for the quick fix! 
But isn't the the real bug that guix package (--install, --upgrade) consider an 
unsupported package as the version to install / upgrade to? Expected behaviour 
for me would be that it checks for the newest version that can actually be 
installed on the architecture.

> The workaround on GNU/Linux would have been to run:
> 
>   guix install glibc-locales@2.35

Is this version pin persisted anywhere? Because I executed that, and --upgrade 
still tried tried to install 2.37.