Re: Guix as a non-optional dependency in another project, and Guix resources requirements.

[Denis 'GNUtoo' Carikli]

On Mon, 25 Mar 2024 18:34:18 +0100
"pelzflorian (Florian Pelz)"  wrote:

> Hello, what you intend does sound very interesting.  As for “guix
> time-machine”, I do not see the problem [...]
Let's say a user install Guix 1.4.0 and GNU Boot use a guix commit after
v1.4.0, as I understand guix time-machine will fail.

Here we have code to detect that situation already, the issue is more
what to do when this situation happens.

A second problem is if a user install guix and runs guix pull right
after but doesn't run guix pull again, and that in the future we start
using commits/revisions newer than the ones the user had right after
running guix pull.

Especially in the second case, running an additional 'guix pull'
behind the back of the user can have some bad consequences if the user
is also using Guix for other things and for some reasons didn't plan to
update guix yet.

So my current plan is just to detect that the commit is not there and
tell the user to run guix pull and also give the user a way to restore
the old guix revision afterward if needed. It's not ideal but it could
work right now for all use cases.

> Simplifying install docs is being discussed and we would like more
> feedback:
> 
> https://issues.guix.gnu.org/69977
>
> At the same time, me citing the Arch Wiki’s negative stance on
> distros’ guix packages
> 
> and the dealing with the recent Guix local privilege escalation
> vulnerability
> 
> hopefully will not cost us our Debian package.
Thanks, I'll read all these threads.

> > As for supporting various guix build options (like '-c, --cores=N',
> > '--max-jobs=N'), we could probably make that configurable in GNU
> > Boot with the help of autotools.
> 
> I do not know, but maybe the Autotools of Guix itself use something
> like this to deal with “make -j4”.
My question was more about the user interface and if it was the right
thing to do. As for the code implementing it[1], it was pretty easy to
do for me and it integrates fine with the current GNU Boot structure: if
users run './autogen.sh && ./configure' they can still use the scripts
manually, so this avoids too much invasive changes.

I still need to do some cleanups though and complete that work (as some
things are still missing, like handling 'guix pull' to make sure that
guix-time-machine works).

[1]https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix-configure

> I’m looking forward to reading much of the info you gave in this mail
> on a GNU Boot website, or if the info is there already I just missed
> it.
The issue is that there is a chicken and egg issue as for the
code/documentation to be merged in GNU Boot, we need to figure out the
questions I asked in this thread.

And there is also a second chicken and egg: we don't want to add a
dependency on Guix without a real use case that really requires Guix in
some non-optional way (more on that below).

As for the code that is actually merged, building the GNU Boot website
can be done with guix shell but to do that the user needs to pass
--enable-guix to the ./configure in that directory:
https://git.savannah.gnu.org/cgit/gnuboot.git/tree/website-build

We used Guix shell here because it makes Guix optional, so we didn't
need to have the Guix part being ultra robust/polished/documented. If
it worked for users already familiar with Guix, it was good enough.

And we also already merged code to update Guix:
https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/dependencies/guix
https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/scripts/misc/guix.sh
but this is not run automatically, and not mentioned in the
documentation either. So users that know about it could run it manually
but that's pretty much it.

So in the meantime the code/documentation we have on Guix
non-optional integration in GNU Boot is available in various branches as
it is not ready yet.

And we don't want to make Guix non-optional for the website right now,
as it works fine in the way it is.

And the idea is to try to integrate Guix as a required dependency with
the least amount of changes. So it will probably be done to build some
tools first like with this branch:
https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix-configure

This kind of changes really makes sense as it would enable us to fix
some installation instructions for some devices which would make the
first release closer, and it limits the risk of breakages since it
doesn't modify in any way the binaries to install.

As for deeper integration that can build GRUB with Guix, it can be found
here: https://git.savannah.gnu.org/cgit/gnuboot.git/log/?h=GNUtoo/guix
Note that this branch is older and will probably be rebased / cleaned
up much later (probably after the release).

To get there we converted the Libreboot directory structures to
resemble more packages with tasks[2], and that

Re: packaging python-cyvcf2

[Simon Tournier]

Hi Alexis,

On ven., 22 mars 2024 at 12:38, Alexis Simon  wrote:

> I'm attaching the new version for reference.

Cool!  Well, maybe this package could be part of Guix Science channel or
another.  WDYT?

Cheers,
simon

Re: system hangs at boot - LUKS /home/ problem(?)

[Fulbert]

I forgot to mention : LUKS version 2 with PBKDF: argon2i. I remember reading
that guix supported LUKS2 except for /boot… but I might be wrong. At 
least it

has worked for month on my computer until guix d5f857a (22 mar 2024).

So, new question, do I have to convert to LUKS1 ?

Le 26.03.24 à 16:15, Fulbert a écrit :


Hello! Seeking some help/suggestions to solve a problem preventing
my system to boot up, which was working properly up to guix 9b84b36
(21 mar 2024) (note: I confess that my system is not totally pure).

Starting with guix d5f857a (22 mar 2024) up to my latest guix pull
with 1415ea7, the **system hangs during boot**, and it does before
anything is written to /var/log/messages. So, using a video capture
of the screen at boot, I was abble to catch :

#+begin_src boot
shepherd[1]: Exception caught while while starting device-mapping-luks-homes: 
(unbound-variable #f "Unbound variable: "S" (bytevector?) #f)
#+end_src

… which appears to be the culprit ?!

follows a long list of "shepherd[1]: Service XXX depends on YYY" and
then
#+begin_src boot
shepherd[1]: The following services could not be started in the background: 

#+end_src

 From there : a blinking cursor and the only way out I found is
CTRL-ALT-DEL, which triggers shepherd to stop some services. After
that I have to shutdown using hardware button.

My system and its config.scm have not changed and I see nothing
relevant, related to LUKS/dm-crypt, in `guix pull -l`.

My LUKS is configured like so :

   (mapped-devices
 (list
   (mapped-device
 (source (uuid ""))
 (target "luks-homes")
 (type luks-device-mapping

   (file-systems
 (append
   (list
 […]
 (file-system (mount-point "/home")
  (device (file-system-label "luks-homes"))
  (type "ext4")
  (dependencies mapped-devices))
 […]

Any help would be appreciated.

system hangs at boot - LUKS /home/ problem(?)

[Fulbert]

Hello! Seeking some help/suggestions to solve a problem preventing
my system to boot up, which was working properly up to guix 9b84b36
(21 mar 2024) (note: I confess that my system is not totally pure).

Starting with guix d5f857a (22 mar 2024) up to my latest guix pull
with 1415ea7, the **system hangs during boot**, and it does before
anything is written to /var/log/messages. So, using a video capture
of the screen at boot, I was abble to catch :

#+begin_src boot
shepherd[1]: Exception caught while while starting device-mapping-luks-homes: 
(unbound-variable #f "Unbound variable: "S" (bytevector?) #f)
#+end_src

… which appears to be the culprit ?!

follows a long list of "shepherd[1]: Service XXX depends on YYY" and
then
#+begin_src boot
shepherd[1]: The following services could not be started in the background: 

#+end_src

>From there : a blinking cursor and the only way out I found is
CTRL-ALT-DEL, which triggers shepherd to stop some services. After
that I have to shutdown using hardware button.

My system and its config.scm have not changed and I see nothing
relevant, related to LUKS/dm-crypt, in `guix pull -l`.

My LUKS is configured like so :

  (mapped-devices
(list
  (mapped-device
(source (uuid ""))
(target "luks-homes")
(type luks-device-mapping

  (file-systems
(append
  (list
[…]
(file-system (mount-point "/home")
 (device (file-system-label "luks-homes"))
 (type "ext4")
 (dependencies mapped-devices))
[…]

Any help would be appreciated.

Re: Cannot run texlive context: permission denied

[Taha Aziz Ben Ali]

I'm also experiencing this same issue on two different installations of
Guix.

Running `context` directly yields the same result as Reza's. However, I
was able to successfully run the `mtxrun` binary and to generate the
database files using `mtxrun --generate`.

While `context` is unable to execute, `mtxrun --script context` throws
the following error:

   unknown script 'context.lua' or 'mtx-context.lua'

Kind regards,
-- 
Aziz