Best base system for Guix

Best base system for Guix

[Alexander Asteroth]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

Dear all,

of course the optimum is probably a pure native Guix system. But if this
is not possible, what system forms the best base for Guix. I've tried
arch and debian 11 and noticed that the packages available in Guix under
arch are way more recent (e.g icecat 91 vs 6x) and more in general.

Also I'm asking myself how Guix deals with different
systems/kernels/base installations and how it decides which packages
will work? Isn't there any dependence? Is this documented somewhere?

Thanks for any help.

Cheers,
Alex

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

Re: Best base system for Guix

[Tobias Geerinckx-Rice]

Alexander,

I don't have personal experience but think it likely that 
Trisquel/Debian is used by more contributors than Arch, which means that 
integration bugs are more likely to be noticed and fixed.  The 
difference shouldn't be significant, and we're always open to bug 
reports from Guix on other GNU/Linux distributions.  Most contributors 
run Guix System.

However:

On 2021-11-11 11:59, Alexander Asteroth wrote:
> I've tried
> arch and debian 11 and noticed that the packages available in Guix 
> under
> arch are way more recent (e.g icecat 91 vs 6x) and more in general.

Something's wrong.  Guix provides a single rolling release across all 
Guix Systems and foreign distributions.

The 'guix' packages for foreign distributions install an older snapshot 
of Guix which sets up the daemon and puts a 'guix' command in the global 
$PATH.

Users are expected to run 'guix pull' (similar to 'pacman -S' but per 
user--never sudo!) to update it.  This will update both guix itself and 
the list of availabe packages.

> Also I'm asking myself how Guix deals with different
> systems/kernels/base installations and how it decides which packages
> will work?

It doesn't.  Either your Arch system isn't properly configured so that 
'command -v guix' returns ~/.config/guix/current/bin/guix, or you 
haven't run 'guix pull' to create or update that copy of guix.

If you have run 'guix pull' and still see outdated packages, let us 
know.  There's something wrong with the system then.

> Isn't there any dependence? Is this documented somewhere?

Once installed, Guix expects little more from the host system than a 
reasonably modern Linux kernel (supporting certain namespaces, syscalls 
& the like) and minimal configuration like a running Guix daemon, the 
guixbuild* users, mounted /dev, etc.  I don't think these are formally 
documented in a single place.

If available, the 'guix' package on a foreign distribution will set that 
up for you: it can depend on foreign packages, set up users/groups, 
support uninstallation, etc., in a cleaner way than the guix-install.sh 
shell script can.

Kind regards,

T G-R

Sent from a Web browser.  Excuse or enjoy my brevity.

Re: Best base system for Guix

[Alexander Asteroth]

[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]

Dear Tobias,

thank you for your fast and comprehensive answer.

On arch I never had any problem; it was on debian 11 that the packages
were outdated. However I did a guix pull and now icecat is recent.

Curious if I forgot to do so the last time I tried to install icecat 91
I looked at my bash history. And that's what I found:

 > 1157  guix pull
 > 1158  echo $PATH
 > 1159  source .bashrc
 > 1160  [...]
 > 1161  echo $PATH
 > 1162  [...] 
 > 1163  guix 
 > 1164  guix --help
 > 1165  guix pull
 > 1166  guix install icecat
 > 1167  guix search icecat

It looks as if guix first was not found but then it was found an I
definitively did a pull before trying to install icecat 91. But it was
only the older version that was found by guix. That was why I did the
search command later on.

Strange! Anyway, now it works.

Cheers,
Alex


On Do, Nov 11 2021, 12:45:58, Tobias Geerinckx-Rice wrote:

> Alexander,
>
> I don't have personal experience but think it likely that
> Trisquel/Debian is used by more contributors than Arch, which means
> that integration bugs are more likely to be noticed and fixed.  The 
> difference shouldn't be significant, and we're always open to bug
> reports from Guix on other GNU/Linux distributions.  Most contributors 
> run Guix System.
>
> However:
>
> On 2021-11-11 11:59, Alexander Asteroth wrote:
>> I've tried
>> arch and debian 11 and noticed that the packages available in Guix
>> under
>> arch are way more recent (e.g icecat 91 vs 6x) and more in general.
>
> Something's wrong.  Guix provides a single rolling release across all
> Guix Systems and foreign distributions.
>
> The 'guix' packages for foreign distributions install an older
> snapshot of Guix which sets up the daemon and puts a 'guix' command in
> the global $PATH.
>
> Users are expected to run 'guix pull' (similar to 'pacman -S' but per
> user--never sudo!) to update it.  This will update both guix itself
> and the list of availabe packages.
>
>> Also I'm asking myself how Guix deals with different
>> systems/kernels/base installations and how it decides which packages
>> will work?
>
> It doesn't.  Either your Arch system isn't properly configured so that
> 'command -v guix' returns ~/.config/guix/current/bin/guix, or you 
> haven't run 'guix pull' to create or update that copy of guix.
>
> If you have run 'guix pull' and still see outdated packages, let us
> know.  There's something wrong with the system then.
>
>> Isn't there any dependence? Is this documented somewhere?
>
> Once installed, Guix expects little more from the host system than a
> reasonably modern Linux kernel (supporting certain namespaces,
> syscalls & the like) and minimal configuration like a running Guix
> daemon, the guixbuild* users, mounted /dev, etc.  I don't think these
> are formally documented in a single place.
>
> If available, the 'guix' package on a foreign distribution will set
> that up for you: it can depend on foreign packages, set up
> users/groups, support uninstallation, etc., in a cleaner way than the
> guix-install.sh shell script can.
>
> Kind regards,
>
> T G-R
>
> Sent from a Web browser.  Excuse or enjoy my brevity.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

Re: Best base system for Guix

[André A. Gomes]

Alexander Asteroth <alexander.asteroth@h-brs.de> writes:

> of course the optimum is probably a pure native Guix system. But if this
> is not possible, what system forms the best base for Guix. I've tried
> arch and debian 11 and noticed that the packages available in Guix under
> arch are way more recent (e.g icecat 91 vs 6x) and more in general.

I don't see how the base system could influence Guix's package
availability.

Things that might differ from one base system to the other are some
default configurations (environment variables, etc).  For example, a
friend of mine tried to use Guix on top of Ubuntu and there was a big
mess concerning XDG_* environment variables and the X window system (I
don't remember the details).

If you're curious about Guix, I strongly advice using the whole system.
The community, afaik, doesn't put too much effort in making sure that it
works flawlessly out-of-the-box for all systems, since there other
priorities.  Regardless, the community would be happy to accommodate any
contribution in that direction.


--
André A. Gomes
"Free Thought, Free World"

Re: Best base system for Guix

[Alexander Asteroth]

Ok, you all convinced me to give Guix a third try (yes I already gave up
twice). Today I installed guix on a seperate partition aside the
Debian-11 install on the same HD. Everything went fine but for the
bootloader. I thought maybe it's best to not install it and let
os-prober on the Debian side discover the Guix system (which I mounted
on /mnt). Unfortunately it seems not to recognize the Guix-Install
(maybe because the kernel-image is hidden deep in the store?). Vice
versa I could add the Debian partition to the Guix config but if
something goes wrong ... ?

Any advice? I'd really like to switch to guix (particularly because I've
programmed a lot in guile in the late 90s and like the idea to configure
my system in scheme :-)

Bests,
Alex


On Thu, Nov 11 2021, 15:47:52, André A. Gomes <andremegafone@gmail.com> wrote:

> Alexander Asteroth <alexander.asteroth@h-brs.de> writes:
>
>> of course the optimum is probably a pure native Guix system. But if this
>> is not possible, what system forms the best base for Guix. I've tried
>> arch and debian 11 and noticed that the packages available in Guix under
>> arch are way more recent (e.g icecat 91 vs 6x) and more in general.
>
> I don't see how the base system could influence Guix's package
> availability.
>
> Things that might differ from one base system to the other are some
> default configurations (environment variables, etc).  For example, a
> friend of mine tried to use Guix on top of Ubuntu and there was a big
> mess concerning XDG_* environment variables and the X window system (I
> don't remember the details).
>
> If you're curious about Guix, I strongly advice using the whole system.
> The community, afaik, doesn't put too much effort in making sure that it
> works flawlessly out-of-the-box for all systems, since there other
> priorities.  Regardless, the community would be happy to accommodate any
> contribution in that direction.

Re: Best base system for Guix

[pelzflorian (Florian Pelz)]

Hello Alexander.

On Thu, Nov 11, 2021 at 06:48:37PM +0100, Alexander Asteroth wrote:
> Ok, you all convinced me to give Guix a third try (yes I already gave up
> twice).

The name of the operating system distribution that can be installed
with the Guix package manager is Guix System.


> Today I installed guix on a seperate partition aside the
> Debian-11 install on the same HD. Everything went fine but for the
> bootloader.

This sounds like a bug.  Does your computer boot with EFI?

When installing, do you configure a mount point such as /boot/efi for
your existing boot/EFI system partition?


> I thought maybe it's best to not install it and let
> os-prober on the Debian side discover the Guix system (which I mounted
> on /mnt). Unfortunately it seems not to recognize the Guix-Install
> (maybe because the kernel-image is hidden deep in the store?).

Yes, that is probably the reason.


> Vice
> versa I could add the Debian partition to the Guix config but if
> something goes wrong ... ?

However, if you boot from EFI, you maybe can use the EFI boot menu to
switch between Debian’s and Guix’s bootloader if both are installed.
This should be sufficient to dual boot.  For extras:

If both are installed, it is even possible to configure Debian’s grub
bootloader to chainload Guix, although I no longer know the commands
for chainloading.

For the opposite, to boot Debian from Guix’ GRUB EFI bootloader, do
this: After installing Guix to boot Guix, I used to change my
/etc/config.scm like this:

 (bootloader (bootloader-configuration
              (bootloader grub-efi-bootloader)
              (targets '("/boot/efi"))
              (keyboard-layout keyboard-layout)
              (menu-entries
               (list (menu-entry
                      (label "Debian")
                      (linux "(hd1,gpt4)/boot/vmlinuz-4.19.0-6-amd64")
                      (linux-arguments '("\
root=UUID=387b3930-178a-4f35-b89c-e77a2c25e686"))
                      (initrd "(hd1,gpt4)/boot/initrd.img-4.19.0-6-amd64"))))))

The initrd and root settings I took from Debian’s GRUB bootloader
configuration.

Regards,
Florian

Re: Best base system for Guix

[Alexander Asteroth]

[-- Attachment #1: Type: text/plain, Size: 3350 bytes --]

Dear Florian (and André),

I found the cause. It was my fault I created a second EFI partition for
the guix grub (to be sure it doesn't make my Debian installation
unbootable) and mounted the EFI partition on /mnt/boot (instead of
/mnt/boot/efi) This way the EFI directory was not top level an more
important the bootcode that was made known to the efi was at the wrong
location.

Now the guix system is woking fine.

Of course now the next issues arise, like "how do I configure postfix
under guix" and what is the right way to make my keyboard layout known
to the system (so far I have added a few lines (a variant) to the
/usr/share/X11/xkb/symbols/us file, wich is now hidden somewhere in the
guix-store)? Guix configuration is really very different from other
*ix'es. Are packages configurable at all without writing scheme-modules
for them? An where would this configuration go? Is everything hidden in
some directories in the gnu store? 

Cheers,
Alex

On Do, Nov 11 2021, 21:58:40, pelzflorian (Florian Pelz) wrote:

> Hello Alexander.
>
> On Thu, Nov 11, 2021 at 06:48:37PM +0100, Alexander Asteroth wrote:
>> Ok, you all convinced me to give Guix a third try (yes I already gave up
>> twice).
>
> The name of the operating system distribution that can be installed
> with the Guix package manager is Guix System.
>
>
>> Today I installed guix on a seperate partition aside the
>> Debian-11 install on the same HD. Everything went fine but for the
>> bootloader.
>
> This sounds like a bug.  Does your computer boot with EFI?
>
> When installing, do you configure a mount point such as /boot/efi for
> your existing boot/EFI system partition?
>
>
>> I thought maybe it's best to not install it and let
>> os-prober on the Debian side discover the Guix system (which I mounted
>> on /mnt). Unfortunately it seems not to recognize the Guix-Install
>> (maybe because the kernel-image is hidden deep in the store?).
>
> Yes, that is probably the reason.
>
>
>> Vice
>> versa I could add the Debian partition to the Guix config but if
>> something goes wrong ... ?
>
> However, if you boot from EFI, you maybe can use the EFI boot menu to
> switch between Debian’s and Guix’s bootloader if both are installed.
> This should be sufficient to dual boot.  For extras:
>
> If both are installed, it is even possible to configure Debian’s grub
> bootloader to chainload Guix, although I no longer know the commands
> for chainloading.
>
> For the opposite, to boot Debian from Guix’ GRUB EFI bootloader, do
> this: After installing Guix to boot Guix, I used to change my
> /etc/config.scm like this:
>
>  (bootloader (bootloader-configuration
>               (bootloader grub-efi-bootloader)
>               (targets '("/boot/efi"))
>               (keyboard-layout keyboard-layout)
>               (menu-entries
>                (list (menu-entry
>                       (label "Debian")
>                       (linux "(hd1,gpt4)/boot/vmlinuz-4.19.0-6-amd64")
>                       (linux-arguments '("\
> root=UUID=387b3930-178a-4f35-b89c-e77a2c25e686"))
>                       (initrd "(hd1,gpt4)/boot/initrd.img-4.19.0-6-amd64"))))))
>
> The initrd and root settings I took from Debian’s GRUB bootloader
> configuration.
>
> Regards,
> Florian


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

Re: Best base system for Guix

[pelzflorian (Florian Pelz)]

Hello Alexander.  I’m glad booting works.

On Fri, Nov 12, 2021 at 04:16:17PM +0100, Alexander Asteroth wrote:
> I created a second EFI partition for
> the guix grub (to be sure it doesn't make my Debian installation
> unbootable)

Debian and Guix can share an EFI system partition, otherwise I’m not
sure if dual boot is possible.  Except probably with (menu-entry …).


> Of course now the next issues arise, like "how do I configure postfix
> under guix"

If you want Postfix to run an e-mail server: Is this on a VPS, so you
have a static IP?

AFAIK there is not yet a postfix service for Guix, only Exim and
OpenSMTPd.  But maybe someone has written a Guix channel for Postfix
outside the main Guix repo.

I’m not sure, but maybe it would be better to configure Postfix with
traditional configuration files and only start it automatically on
boot with a custom Shepherd service (see the syslogd example at
`info "(guix) Shepherd Services"`).  Or imitate the Exim service in
the Guix repo.



> and what is the right way to make my keyboard layout known
> to the system (so far I have added a few lines (a variant) to the
> /usr/share/X11/xkb/symbols/us file, wich is now hidden somewhere in the
> guix-store)?

You need to change the value of (keyboard-layout …) in your operating
system configuration (by default /etc/config.scm).

See the examples at `info "(guix) Keyboard Layouts"`.



> Guix configuration is really very different from other
> *ix'es. Are packages configurable at all without writing scheme-modules
> for them? An where would this configuration go?

In Scheme code in your operating system configuration
(/etc/config.scm) or in your package manifest, you can add your own
package records in-place or you can use a module in which you defined
them.  It is probably best to look at the packages in the Guix repo.
For example you can use the command `guix edit hello` to look at GNU
Hello’s package.  The Guix cookbook contains a packaging tutorial.



> Is everything hidden in
> some directories in the gnu store?

Yes, kind of.  Guix manages the directories /gnu, /var/guix,
~/.config/guix and on Guix System a few more like /run/current-system.

Regards,
Florian

Re: Best base system for Guix

[Alexander Asteroth]

Hi Florian,

On Fri, Nov 12 2021, 17:48:36, "pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> Hello Alexander.  I’m glad booting works.
>
> On Fri, Nov 12, 2021 at 04:16:17PM +0100, Alexander Asteroth wrote:
>> I created a second EFI partition for
>> the guix grub (to be sure it doesn't make my Debian installation
>> unbootable)
>
> Debian and Guix can share an EFI system partition, otherwise I’m not
> sure if dual boot is possible.  Except probably with (menu-entry …).

of course dual boot is not possible this way. But the idea was to make
sure nothing unplanned happens to the system I currently use everyday.

>> Of course now the next issues arise, like "how do I configure postfix
>> under guix"
>
> If you want Postfix to run an e-mail server: Is this on a VPS, so you
> have a static IP?
>
> AFAIK there is not yet a postfix service for Guix, only Exim and
> OpenSMTPd.  But maybe someone has written a Guix channel for Postfix
> outside the main Guix repo.
>
> I’m not sure, but maybe it would be better to configure Postfix with
> traditional configuration files and only start it automatically on
> boot with a custom Shepherd service (see the syslogd example at
> `info "(guix) Shepherd Services"`).  Or imitate the Exim service in
> the Guix repo.
>

I can probably live with nullmailer. I'll have a look at it.

>> and what is the right way to make my keyboard layout known
>> to the system (so far I have added a few lines (a variant) to the
>> /usr/share/X11/xkb/symbols/us file, wich is now hidden somewhere in the
>> guix-store)?
>
> You need to change the value of (keyboard-layout …) in your operating
> system configuration (by default /etc/config.scm).
>
> See the examples at `info "(guix) Keyboard Layouts"`.

I'm not using a predifined layout from /usr/share/X11/xkb/symbols but
some self-defined variant based on us. This means I have to edit a file
under /usr/share but that was the way it was done since I work with X11
(back in the 90s) and so far I haven't found a replacement for it that
allows to fully define own keyboardlayouts.

>> Guix configuration is really very different from other
>> *ix'es. Are packages configurable at all without writing scheme-modules
>> for them? An where would this configuration go?
>
> In Scheme code in your operating system configuration
> (/etc/config.scm) or in your package manifest, you can add your own
> package records in-place or you can use a module in which you defined

But in the end the applications depend on configurartion files that need
to be placed somewhere (even if generated or parameterized) by some
scheme code.

> them.  It is probably best to look at the packages in the Guix repo.
> For example you can use the command `guix edit hello` to look at GNU
> Hello’s package.  The Guix cookbook contains a packaging tutorial.

I'll have a look at that. Before I encountered these issues I saw it but
didn't understand it's importance.

Cheers,
Alex

Re: Best base system for Guix

[pelzflorian (Florian Pelz)]

Hello Alexander.

On Fri, Nov 12, 2021 at 07:21:38PM +0100, Alexander Asteroth wrote:
> I'm not using a predifined layout from /usr/share/X11/xkb/symbols but
> some self-defined variant based on us. This means I have to edit a file
> under /usr/share but that was the way it was done since I work with X11
> (back in the 90s) and so far I haven't found a replacement for it that
> allows to fully define own keyboardlayouts.

You really need to change the Xorg service (if you use X11) and / or
packages.  Guix hard-codes using the xkeyboard-config.

You can set up guix pull to pull from a Git repo in your file system.
See `info "(guix)Using a Custom Guix Channel"`.

guix pull’ing will take longer only for the part you change,
i.e. packages or services will need to be recompiled on guix pull.

Alternatively copy the Xorg X11 service from gnu/services/xorg.scm
from the Guix repo to your own operating system configuration
(/etc/config.scm) or to a file you refer to therein.


> >> Guix configuration is really very different from other
> >> *ix'es. Are packages configurable at all without writing scheme-modules
> >> for them? An where would this configuration go?
> >
> > In Scheme code in your operating system configuration
> > (/etc/config.scm) or in your package manifest, you can add your own
> > package records in-place or you can use a module in which you defined
> 
> But in the end the applications depend on configurartion files that need
> to be placed somewhere (even if generated or parameterized) by some
> scheme code.

Yes, they are built from Scheme code.  That is a good thing though.

Regards,
Florian

Re: Best base system for Guix

[zimoun]

Hi,

On Thu, 11 Nov 2021 at 11:59, Alexander Asteroth <alexander.asteroth@h-brs.de> wrote:

> Also I'm asking myself how Guix deals with different
> systems/kernels/base installations and how it decides which packages
> will work? Isn't there any dependence? Is this documented somewhere?

Guix-the-package-manager works on the top of any Linux distro and the
packages from Guix are defined by the Guix revision (guix describe).
For one specific Guix revision, build and run the packages on the top of
Arch should be exactly the same as build and run the packages on the top
of Debian.  Well, that what others had answered. :-)

I just want to add that the assumption to make it happen is about kind
of “stability” of Linux kernel.  The machine using Arch runs one Linux
kernel, not necessary at the same version and/or compiled with the same
tools as the other machine using Debian.  The assumption is that this
variation of the Linux kernel does not have any influence – bit-to-bit
reproducibility speaking – on building the packages.

Well, the corner cases are really really really rare that I do not
remember such reproducibility issue or even just know one case. :-)


Cheers,
simon