bug#56437: Reduce closure size of gsettings-desktop-schemas

[Pierre Neidhardt]

Sounds good!


signature.asc
Description: PGP signature

bug#56681: Guix error report

[Kevin Morris]

Good afternoon! I received this error when trying to run "guix pull" today, and 
the report told me to send the output to this address.

Computing Guix derivation for 'x86_64-linux'... -Backtrace:
  13 (primitive-load 
"/gnu/store/lm4i0rd29gxfahw904gndpwpii7q2qj7-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2168:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1996:8  7 (_ _)
In ./guix/gexp.scm:
   300:22  6 (_ _)
   1181:2  5 (_ _)
   1047:2  4 (_ _)
893:4  3 (_ _)
In ./guix/store.scm:
  2053:12  2 (_ #)
   1401:5  1 (map/accumulate-builds # 
# ?)
  1417:15  0 (_ # _ _)

./guix/store.scm:1417:15: ERROR:
  1. :
  message: 
"`/gnu/store/0iii8i1lc4wg3wccs1db7y7d8lg80i04-guix-1.3.0/bin/guix substitute' 
died unexpectedly"
  status: 1
guix pull: error: You found a bug: the program 
'/gnu/store/lm4i0rd29gxfahw904gndpwpii7q2qj7-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"3f171587bc6a47bb056f3e699e17e05f5832aea5"; system: "x86_64-linux";
host version: "1.3.0"; pull-version: 1).
Please report the COMPLETE output above by email to .

bug#56669: enhancement: Link guix system and guix home

[Maxime Devos]

On 21-07-2022 19:13, Andrew Tropin wrote:


The source code is here:
https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9


What's the 'guix-home-gc-roots' for? I would expect the reference 
#$(file-append he "/activate") to be sufficient to keep things from 
being gc'ed.


+ 
 
(start #~(make-forkexec-constructor + 
 
'(#$(file-append he "/activate")) + 
 
#:user #$user + 
 
#:environment-variables + 
 
(list (string-append "HOME=" (passwd:dir (getpw #$user + 
 
#:group (group:name (getgrgid (passwd:gid (getpw #$user))
I'm wondering if GUIX_LOCPATH is needed as well. Anyway, if not done 
already internally by /activate, you could consider doing it in a 
container to reduce potential irreproducibility, or insecurity on 
multi-user systems (I'd assume the #:user + #:group to be sufficient for 
security, especially if it appears sufficient for other system services, 
but I'm not some expert on what things need to be set).


+ 
 
(provision (list (symbol-append 'guix-home- (string->symbol user + 
 
(one-shot? #t) + 
 
(auto-start? #f)
Wouldn't it then be possible for the user to login via the login manager 
before initialisation has completed, as gdm etc don't wait for 
guix-home-... currently?


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56669: enhancement: Link guix system and guix home

[Andrew Tropin]

On 2022-07-20 20:57, Andrew Tropin wrote:

> On 2022-07-20 11:47, Dale Mellor wrote:
>
>> I would like to be able to create a rescue disk for my system in which
>> the admin user's home directory contains a copy of an encrypted key,
>> for manually unlocking encrypted disk drives.
>>
>> Following a short discussion in IRC, it appears the best route to
>> achieve this would be to link *guix system* and *guix home* together,
>> so that the system configuration file can specify
>>
>> (user-account
>>...
>>(configuration (local-file "my-home-config.scm")))
>>
>> for example (it should be possible to use either (home-configuration)
>> or a file-like object here).
>>
>> Hopefully this is an easy thing to accomplish, but I don't know...
>>
>
> Hi Dale,
>
> it's not easy, but doable.
>
> This topic popups from time to time, but this feature is not implemented
> yet.
>
> https://yhetil.org/guix-devel/20220706112011.77c71...@marvid.fr/
>
> I have spare time tomorrow and can try to implement it, however Idk how
> much time will it take and if I don't finish tomorrow, there is no
> guarantee that I'll finish it anytime soon.

I built home environment baked in operating system and sucessfully
deployed it with guix deploy.  I face some issues with the similiar
setup on livecd, but I think I will figure out it soon and will publish
results in a few days.

The source code is here:
https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9

It's drafty and will be rewritten, also there are a few local commits
that I haven't sent to guix yet, but it should work without them if
elogind is enabled.

The usage example:


config.scm
Description: Binary data

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#56667: test failures tests/channels.scm and tests/texlive.scm

[Chris Keschnat via Bug reports for GNU Guix]

Ludovic Courtès  writes:

> Hi,
>
> Chris Keschnat  skribis:
>
>> test-name: channel-news, one entry
>> location: /home/ck/tmp/guix/tests/channels.scm:323
>> source:
>> + (test-assert
>> +   "channel-news, one entry"
>
> [...]
>
>> +  (entry (tag "tag-for-first-news-entry")
>> + (title (en "Old news.") (eo "Malnova?oj."))
>
> The question mark above suggests you were not running the test in a
> Unicode-capable locale.  I think you may need to first run:
>
>   export LC_ALL=en_US.UTF-8
>
> or something similar.
>
> Could you check whether that helps?

Hi Ludovic,
thank you, that does indeed make the test pass.

> [...]

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

[Marcel van der Boom]

During the check phase of building go-1.16.15 (as dependency of 
ungoogled-chromium) a failure occurs:



https://dpaste.org/ib5CZ :

--- FAIL: TestTrivialExecutable (3.43s)
   shared_test.go:484: file too large: got 202752, want <= 10
--- FAIL: TestTrivialExecutablePIE (0.61s)
   shared_test.go:484: file too large: got 202824, want <= 10


Full build log: https://dpaste.org/iWfL0

bug#56030: The guix pull profile is too big

[Maxime Devos]

On 21-07-2022 18:29, ( wrote:

Not all linkers support linker scripts, e.g. mold doesn't from what I've
read because they make the linker slower.

Would we really need to support anything other than ld, gold, and lld,
though?

 -- (



We can choose to not package mold of course, but I think it would be a 
good idea to support mold, because it appears to be much faster than the 
others. Furthermore, I'd like to eventually switch to mold by default, 
because it's much faster.  From the README:


mold is so fast that it is only 2x /slower/ than |cp| on the same 
machine. Feel free to file a bug  
if you find mold is not faster than other linkers.


Program (linker output size)GNU goldLLVM lldmold
Chrome 96 (1.89 GiB)53.86s  11.74s  2.21s
Clang 13 (3.18 GiB) 64.12s  5.82s   2.90s
Firefox 89 libxul (1.64 GiB)32.95s  6.80s   1.42s



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

> We could compile a '__guix_shell_path = "/..."' during the compilation 
> of the package (as a .o) and wrap gcc to insert it to the CLI arguments, 
> no linker scripts required.
Alas, for some reason I couldn't find any documentation on how to define
strings in a linker script. But never mind that, since that's a far
better idea :)

> Not all linkers support linker scripts, e.g. mold doesn't from what I've
> read because they make the linker slower.
Would we really need to support anything other than ld, gold, and lld,
though?

-- (

bug#56030: The guix pull profile is too big

[Maxime Devos]

On 21-07-2022 18:13, ( wrote:

Okay, another (hopefully more coherent) proposal: Patch in a

```
extern char *__guix_shell_path;
```

And then, we use a linker script to provide the definition of
__guix_shell_path at linking time. (Unfortunately there's no way to do
this with a flag, afaik...)


We could compile a '__guix_shell_path = "/..."' during the compilation 
of the package (as a .o) and wrap gcc to insert it to the CLI arguments, 
no linker scripts required.  Not all linkers support linker scripts, 
e.g. mold doesn't from what I've read because they make the linker slower.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56572: failed install on partition, backtrace attached

[Josselin Poiret via Bug reports for GNU Guix]

Hello everyone,

Ludovic Courtès  writes:
> That suggests that this formatting bug was fixed in the meantime, which
> is plausible because a lot of work has gone in the installer since
> 1.3.0.
>
> Josselin, Mathieu, does that ring a bell?

None for me, but it could come from improvements in (gnu build
file-systems) and friends too, not just the installer.  I can't pinpoint
a specific commit that would do that, but there are some general reworks
that might have helped with this.

Best,
-- 
Josselin Poiret

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

Okay, another (hopefully more coherent) proposal: Patch in a

```
extern char *__guix_shell_path;
```

And then, we use a linker script to provide the definition of
__guix_shell_path at linking time. (Unfortunately there's no way to do
this with a flag, afaik...)

-- (

bug#56582: Installer does not detect or allow detection of other bootable partitions

[Josselin Poiret via Bug reports for GNU Guix]

Hi Peter,

Peter  writes:
> To expand on this, Guix installs GRUB. This is undeniable, and this is
> where the problem begins.. over many years users are accustomed to GRUB
> working in a certain way with specific tools.. when they encounter a grub
> installation without grub-mkconfig, etc. they are at a loss, because it's a
> binary they expected to find and it's just not present. I think an argument
> could be made here that this behaviour breaks user space because it's
> established software, but changed to function differently as opposed to
> being something entirely new. It's like wearing your shoes on the opposite
> foot. You can do it, but it feels wrong.

Those tools are unfortunately stateful, like grub-mkconfig using
osprober, so wouldn't be a good fit for Guix.  You could also argue that
the majority of people using GRUB don't even know how to use the grub
tools, or what they actually do.  I personally think that our GRUB
interface is elegant, while a bit incomplete.

> The way Debian and other distros manage Grub is via mkconfig, and the boot
> menu presented is very similar to Guix's, the only difference is that
> there's an extra row entry in the grub menu for the Windows bootloader to
> be launched.

If we had a way to add menu entries that chainload another bootloader,
then that would result in the same exact menu.  It shouldn't even be too
hard to add.

> Personally, I dislike Grub because I feel it complicates things. I would
> love to use only UEFI and use only the bios boot menu to switch, but for
> whatever reason in a single internal drive system, this isn't easily done.
> Giving an example, awhile back, I tried installing a distro to an external
> usb drive.. it worked.. but the problem is that it installed grub to the
> internal drive.. and if you removed the usb drive from the pc, things would
> break because now a device it was expecting to see wasn't there. A
> workaround suggested was to disconnect the internal drive, do the setup,
> this way Grub would be on the external drive, then reconnect the internal
> drive and then I guess use the bios uefi menu to switch between, a lot of
> bother for a tightly sealed unit.

You can (and should) specify which EFI partition you'd like to install
GRUB to.  You'd simply need to create a EFI partition on the removable
media, and add the --removable option as well so that GRUB is installed
in the default boot location (/EFI/BOOT/bootx64.efi) so that booting
from the drive actually boots that bootloader.

If you want to get rid of GRUB, you can also compile Linux with the EFI
stub, so that it can be started as a EFI application directly, and then
add a EFI boot entry for it.

> The way MS's bootloader works is nice because one of the menu options it
> has is to pick a physical device so you can actually boot from a valid
> bootable USB flash drive device and it launches that device directly.

Your UEFI boot menu should already do that, no need for that in a
bootloader IMO.

> Maybe the solution is just to create an EFI partition at the front of all
> drives including external as Apple does and then it doesn't matter what
> bootloader you use or do not use, because you could always just use the
> UEFI menu to point to a device. Not using a bootloader would reduce
> complexity of maintenance.. if MS's bootloader is there, people can use it
> if they want to point to the device, and if it is not there, then they can
> use the uefi bios menu. In theory.

Without the EFI stub, Linux needs a bootloader to load, and the windows
bootloader surely won't support booting Linux.

Best,
-- 
Josselin Poiret

bug#56030: The guix pull profile is too big

[Julien Lepiller]

I must have misunderstood, I thought you wanted to pass it during the build of 
glibc.

Le 21 juillet 2022 17:49:36 GMT+02:00, "("  a écrit :
>On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
>> it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
>> appropriately.
>Why would we need to change it? The glibc definition already uses that
>macro for the shell path, it's just hard-coded to /bin/sh by default.

bug#56030: The guix pull profile is too big

[Maxime Devos]

On 21-07-2022 17:49, ( wrote:

On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:

Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But
it's not 'just use -DSHELL_PATH=', we still need to change 'system'
appropriately.

Why would we need to change it? The glibc definition already uses that
macro for the shell path, it's just hard-coded to /bin/sh by default.


If we modify the SHELL_PATH to point to 
/gnu/store/...-bash-minimal-.../bin/sh, then glibc has a reference to 
bash-minimal. But bash-minimal uses glibc, so bash-minimal would have a 
reference to glibc. So you would have to end up with a cycle, which is 
impossible in Guix.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

Oh! I understand now! The __guix_bin_sh macro would actually be included
in the expansion, not defined during the glibc build. Sorry (again) for
the noise!

-- (

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
> it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
> appropriately.
Why would we need to change it? The glibc definition already uses that
macro for the shell path, it's just hard-coded to /bin/sh by default.

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 4:42 PM BST, Julien Lepiller wrote:
> We're trying to avoid hard-coding bash-static in glibc, instead letting the 
> build-system fill the value in dependents. So that can't be it, right?
How would it be any different from -D__guix_bin_sh=...? That argument
would simply be filled in by the build system.

bug#56030: The guix pull profile is too big

[Maxime Devos]

On 21-07-2022 17:11, ( wrote:

couldn't we just use `-DSHELL_PATH=/gnu/store/...`?


Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes.  But 
it's not 'just use -DSHELL_PATH=', we still need to change 'system' 
appropriately.



Would this not violate POSIX? Since, as far as I can see,

does not give the implementation license to implement system(3) as a
macro.
Probably. But does that really matter?  The standard exists for a 
reason, but we aren't aiming for POSIX certifications and it isn't the 
law or something ... seems rather inconvenient for development outside a 
build environment though, so perhaps SHELL_PATH could somehow fallback 
to /bin/sh when outside a build environment.

  We could do

```
int system(const char *command) {
return __guix_run_in_shell(command, __guix_bin_sh);
}


Needs a 'static' to avoid multiple definitions on the same thing, but 
yes, that would avoid the macro problem (though not sufficient for some 
FFI).


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56030: The guix pull profile is too big

[Julien Lepiller]

We're trying to avoid hard-coding bash-static in glibc, instead letting the 
build-system fill the value in dependents. So that can't be it, right?

Le 21 juillet 2022 17:11:56 GMT+02:00, "("  a écrit :
>
>And considering the definition of system(3) in glibc:
>
>@ sysdeps/posix/system.c (took me way too long to find this; glibc's
>source code is a maze ;))
>```
>#define SHELL_PATH "/bin/sh"   /* Path of the shell.  */
>#define SHELL_NAME "sh"/* Name to give it.  */
>```
>
>couldn't we just use `-DSHELL_PATH=/gnu/store/...`?
>
>-- (

bug#56674: [Shepherd] Use of ‘waitpid’, ‘system*’, etc. in service code can cause deadlocks

[Ludovic Courtès]

Maxime Devos  skribis:

> Why Shepherd and not guile fibers? Is this a Shepherd-specific problem?

Blocking calls are a problem for Fibers in general, and ‘waitpid’ is no
exception.

The problem here is Shepherd-specific in the sense that we’re more
likely to use ‘system*’ and ‘waitpid’ in this context.  It’s also
Shepherd-specific because shepherd already runs an event loop that
tracks signal FDs and will thus “see” SIGCHLD events.

> 3. Make waitpid (or a variant that does what we need) interact well
> with guile-fibers, like how 'accept' is doesn't inhibit switching to
> another fiber. There some Linux API with signal handlers or pid fds or
> such that might be useful here, though I don't recall the
> name. Presumably something similar can be done for the Hurd, though
> some C glue may be needed to access the right Hurd APIs if the signal
> handler API isn't portable.

Yes, that’s roughly what I had in mind when I mentioned providing a
replacement for ‘system*’ (but you’re right, it’s a replacement for
‘waitpid’ at its core).

> Alternatively:
>
> 4. Do the waitpid in a separate thread (needs work-around for the
> multi-threaded fork problem, probably C things? Or modifying Guile and
> maybe glibc to avoid async-unsafe things or make more things
> async-safe or whatever the appropriate ...-safe is here.)

For shepherd, multithreading is not an option due to the semantics of
fork in the presence of threads.

Ludo’.

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 4:03 PM BST, paren--- via Bug reports for GNU Guix wrote:
> Would this not violate POSIX?
Correction: system(3) is ISO C, not POSIX.

But:

@ C11 7.1.4p1
```
... it is permitted to take the address of a library function even if it
is also defined as a macro ^185 ...

185) This means that an implementation shall provide an actual function
for each library function, even if it also provides a macro for that
function.
```

Note the footnote. So this technically would be a violation of ISO C,
but trivially fixed. Apologies for the noise! (Though the SHELL_PATH
solution still applies, of course.)

-- (

bug#40641: Building from git breaks when /bin/sh isn't bash

[Maxim Cournoyer]

Hi,

elaexuo...@wilsonb.com writes:

> Maxim Cournoyer  wrote:
>> I'll see if these Bashisms can be easily switched to POSIX variants,
>> else I'll experiment with setting the shebang of the test scripts to
>> bash.
>
> Is there any particular reason to go this route?

I can think of at least two:

1. GNU Autotools is designed to work across as many systems as possible,
and produces POSIX-compliant shell scripts such as configure; thus
keeping things in our build system (including the tests authored in
shell scripts) POSIX allows to build and test Guix from source in many
environments, not only in 'guix shell -D guix'.

2. Messing with Autotools-managed variables such as 'SHELL' may end up
causing confusions for those relying on Autotools documented behavior.

> Writing portable scripts is full of all sorts of pitfalls and ill-meaning
> dragons:
>
> - What if SHELL=tcsh?
> - What about incompatible behaviour between bash versions?
> - Do we want to write tests to future-proof fixes for the above?

You actually don't need to care about Bash incompatible behavior when
targetting POSIX shell script.  If the user goes out of their way to use
a non-POSIX shell... well they are on their own.

> In this case, since the build is running inside a guix shell, I don't really
> see any reason to *not* effectively pin the scripts to use the bash available
> in that environment.

That's true for the specific use case where someone tries to build Guix
inside a 'guix shell -D guix' environment, but there are also people
attempting to build Guix using they system provided dependencies and
shell, where the fix wouldn't help.

My previous experiment showed that the Bashisms used seem limited to
perhaps 2 tests; it doesn't seem too difficult to fix them using the
'shellcheck' tool to spot what syntax used is problematic and needs to
be adjusted.

Thanks,

Maxim

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

And considering the definition of system(3) in glibc:

@ sysdeps/posix/system.c (took me way too long to find this; glibc's
source code is a maze ;))
```
#define SHELL_PATH  "/bin/sh"   /* Path of the shell.  */
#define SHELL_NAME  "sh"/* Name to give it.  */
```

couldn't we just use `-DSHELL_PATH=/gnu/store/...`?

-- (

bug#56030: The guix pull profile is too big

[paren--- via Bug reports for GNU Guix]

On Thu Jul 21, 2022 at 3:52 PM BST, Maxime Devos wrote:
>   * Add a macro '#define system ...' that calls this variant and inserts
> __guix_bin_sh as the shell executable

Would this not violate POSIX? Since, as far as I can see,

does not give the implementation license to implement system(3) as a
macro. We could do

```
int system(const char *command) {
return __guix_run_in_shell(command, __guix_bin_sh);
}
```

though.

-- (

bug#56030: The guix pull profile is too big

[Maxime Devos]

On 17-06-2022 07:48, Julien Lepiller wrote:
We have bash-minimal and bash-static. The latter is a bit bigger than 
the former. Maybe we can keep only bash-minimal? 


bash-static is used by glibc (for the 'system' function), it's not 
something that can simply be replaced with bash-minimal (due to the 
cycle bash-minimal -> glibc -> bash-minimal that would result). I do 
have a proposal eliminating the bash-static reference though:


 * replace the 'system' function from glibc by a variant that accepts
   the file name of the shell executable
 * Add a macro '#define system ...' that calls this variant and inserts
   __guix_bin_sh as the shell executable
 * In the build system, look for bin/sh in the inputs.  If it exists,
   add -D__guix_bin_sh=/gnu/store/.../bin/sh to
   CFLAGS or such.

Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#54469: home-environment-variables-service-type does not quote things

[Maxime Devos]

On 14-07-2022 01:13, Ludovic Courtès wrote:

[...]
Fixed in af4c103595a725194318f40fc5aba110772ff417… except for checking
the name of the variable.

I guess we should stick to the grammar for “names” that Bash defines
(info "(bash) Definitions") and error out if the variable name doesn’t
comply?


Yes -- supporting arbitrary variable names would be nice but that just 
sticking to those (and erroring out) should be good enough in practice.


FWIW, (guix search-paths) also does export this="that", so it looks like 
the quoting and name checking could be generalised a little to also 
extend to etc/profile.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56678: certbot mcron job fails

[Ludovic Courtès]

Hello,

‘certbot-service-type’ defines an mcron job that invokes ‘certbot’ with
a fairly long list of arguments.  However, that command line appears
to be incorrect, or at least it is on bayfront.guix where I tested it:

--8<---cut here---start->8---
ludo@bayfront ~/src/maintenance/hydra$ sudo herd schedule mcron 100|grep -B1 
certbot
Thu Jul 21 12:51:00 2022 +0200
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
--
Fri Jul 22 00:45:00 2022 +0200
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
--
Fri Jul 22 12:36:00 2022 +0200
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
ludo@bayfront ~/src/maintenance/hydra$ ls -l 
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
-r-xr-xr-x 1 root root 789 Jan  1  1970 
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
ludo@bayfront ~/src/maintenance/hydra$ sudo less 
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
#!/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guile 
--no-auto-compile
!#
(begin (use-modules (ice-9 match)) (let ((code 0)) (for-each (match-lambda 
((name . command) (begin (format #t "Acquiring or renewing certificate: ~a~%" 
name) (set! code (or (apply system* command) code) (quote 
(("bayfront.guix.gnu.org" 
"/gnu/store/y2n10m4qkyb6vgx980c6jkjd132ln8xx-certbot-1.18.0/bin/certbot" 
"certonly" "-n" "--agree-tos" "--webroot" "-w" "/var/www" "--cert-name" 
"bayfront.guix.gnu.org" "-d" 
"bayfront.guix.gnu.org,bordeaux.guix.gnu.org,logs.guix.gnu.org,bayfront.guix.info,hpc.guix.info,guix-hpc.bordeaux.inria.fr,coordinator.bayfront.guix.gnu.org"
 "--email" "ludovic.cour...@inria.fr" "--deploy-hook" 
"/gnu/store/1wj7gy7n8r0nfx2i79afpr7n7xyhyzjx-nginx-deploy-hook" code))
ludo@bayfront ~/src/maintenance/hydra$ sudo su -c 
/gnu/store/r8hx1sdy3hkw9xpgsb92lh1kjs558876-certbot-command
Acquiring or renewing certificate: bayfront.guix.gnu.org
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['guix-hpc.bordeaux.inria.fr@2017-09-04T08:51:13Z (48c5)', 
'localhost@2016-12-03T21:08:38Z (00bc)']
Ask for help or search for solutions at https://community.letsencrypt.org. See 
the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for 
more details.
--8<---cut here---end--->8---

What should we do about “Please choose an account”?

Thanks,
Ludo’.