Hi,
Let try to build the Haskell package ghc-lucid.
--8<---cut here---start->8---
$ guix build ghc-lucid
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
/gnu/store/9m71fs1i0anv89f5zq44hbh2wn2l
Hi,
Using Guix 65cabb0, I do not understand why ‘guix copy’ fails.
Well, I have some items in the store of my remote desktop machine.
--8<---cut here---start->8---
$ ssh desktop -t guix build hledger ghc-lucid
/gnu/store/f23gh2padz9xwsjgz5znfk9azn5l101z-ghc-l
Hello,
I hope my question makes sense. It concerns Guix grub UEFI bootloaders.
I would like to understand in which extent Guix functional approach
helps to secure the computer with regards to an early boot malicious
code/malware infection.
As far as I understand, Guix doesn't provide means to au
That would be interesting, even on a Talos II, which has owner
controlled secure boot. There will be no need to sign with a Microsoft
key as most UEFI implementations do. There are two Microsoft keys, one
for Windows and one for all other OSes.
On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Pad
Hi zimoun,
> Is it a manual in-place replacement? Or is it an automatic in-place
> update by Hackage infrastructure? Or do I miss a point?
>
> In all cases, these revised Cabal files are not archived elsewhere than
> in Hackage, right? The question is thus, where could we archive them?
>
> No
Hi Antonio,
On Sat, 2022-08-20 at 13:23 +0200, Antonio Carlos Padoan Junior wrote:
> As far as I understand, Guix doesn't provide means to automatically
> sign
> bootloaders and kernels in order to use UEFI secure boot after each
> system
> reconfigure (assuming a PKI is properly implemented). He
