bug#70897: Guix system hangs on boot with LUKS root partition
Hi Ludo', I wanted to let you know that I have figured out what the failure is, and it turned out to be a customization buried within some shared operating-system configuration that I had forgotten about (and wasn't finding because it was due to a missing import, and simply grepping for "system*/tty" didn't match the file that was missing the import). Thank you for your time and help, and sorry about the red herring of a bug report! Cheers, Kaelyn
bug#70954: No 'guix pull' substitutes for foreign distros?
Hello Florian, From testing old Guix System system generations, I believe September 2023’s new daemon feature “builtin:git-download” has caused the change in hashes As far as I remember, approximately at that time, in the late autumn, I have started to experience very long 'guix pull'. I’m closing this bug. No objections. But I would like to know, does \ work in systemd by now Yes, \ works in systemd service files. I didn't know that \ was forbidden in the past. Regards, Nigko
bug#67250: builtin:git-download capability detection not working for the bordeaux build farm
Simon Tournier writes:
> On Wed, 22 Nov 2023 at 11:19, Ludovic Courtès wrote:
>
>> As in:
>>
>> (open-connection
>> #:assume-available-builtin-builders '("download"))
>
> Instead, why not check in ’git-fetch’? Currently, the test is done
> against the local daemon, right?
>
> --8<---cut here---start->8---
> (define* (git-fetch ref hash-algo hash
> #:optional name
> #:key (system (%current-system))
> guile git)
> "Return a fixed-output derivation that fetches REF, a
> object. The output is expected to have recursive hash HASH of type
> HASH-ALGO (a symbol). Use NAME as the file name, or a generic name if #f."
> (mlet %store-monad ((builtins (built-in-builders*)))
> (if (member "git-download" builtins)
> (git-fetch/built-in ref hash-algo hash name
> #:system system)
> (git-fetch/in-band ref hash-algo hash name
>#:system system
>#:guile guile
>#:git git
> --8<---cut here---end--->8---
>
> For example, why not a test as:
>
> (if (and SOMETHING
> (member "git-download" builtins))
>
> And this SOMETHING could be a global variable, as
> %assume-builtin-builder, set to true by default and turn to false with
> an environment variable, as GUIX_ASSUME_BUILTIN.
I can think of a couple of reasons not to do this via an environment
variable.
Having the logic in git-fetch via an environment variable would mean
that if other builtins are added, the code generating derivations using
them would also have to check the environment variable. Specifying the
builtin's that are available on a store connection would work
automatically in the case of new builtins being added..
There's also trade-offs in control when using environment variables, or
deciding when to take the value from an environment variable and switch
to passing the value around through arguments or other means. Consider
the case where you have a single process which has multiple store
connections open and it wants to specify different available builtin's
on particular store connections. This would become quite difficult when
using an environment variable, but work easily when specifying the
builtins available on the store connection.
signature.asc
Description: PGP signature
bug#67250: builtin:git-download capability detection not working for the bordeaux build farm
Christopher Baines writes:
> Ludovic Courtès writes:
>
>> Hi,
>>
>> Christopher Baines skribis:
>>
>>> The bordeaux build farm depends on computing the derivations on one
>>> machine, then potentially building them on a different machine.
>>>
>>> Some of the build machines don't have a new enough guix-daemon that
>>> understands builtin:git-download, so derivations that use this are
>>> sometimes failing (e.g. [1])
>>>
>>> 1: https://bordeaux.guix.gnu.org/build/10cc5622-6b1f-4f28-ad9a-41cf796d7a15
>>>
>>> One potential approach to address this is somehow have the data service
>>> indicate that it wants compatible derivations when computing them,
>>> rather than to have guix do feature detection against the guix-daemon
>>> that is being used at the point the derivations are being computed.
>>
>> Would it work for you if we added a keyword argument to
>> ‘open-connection’ in (guix store) that would let you select which
>> builtins to use?
>>
>> As in:
>>
>> (open-connection
>> #:assume-available-builtin-builders '("download"))
>
> Yep, that would at least allow freezing the available builtins going
> forward and separating it from the running daemon.
I've now sent some patches which add this option to #71038.
signature.asc
Description: PGP signature
bug#70954: No 'guix pull' substitutes for foreign distros?
Hello Nigko, I’m glad the problem is solved for you. >From testing old Guix System system generations, I believe September 2023’s new daemon feature “builtin:git-download” has caused the change in hashes, but no further action is advisable. I’m closing this bug. But I would like to know, does \ work in systemd by now: Nigko Yerden writes: > ~guix-daemon.service > ... > [Service] > ExecStart=/home/USER/.config/guix/current/bin/guix-daemon \ > --build-users-group=_guixbuild --discover=no \ > --substitute-urls='.' > > Environment='GUIX_LOCPATH=/home/USER/.guix-profile/lib/locale' > ... > ~ or have you changed the ExecStart line for the e-mail? The way I know, \ cannot be used. If this has changed, it could solve problems with overlong lines in the cookbook PDF. Regards, Florian
