Installation-Protocol for GuixSD x86_64 v0.15-preview

[Björn Höfling]

Hi people,

as Ludo "requested", today I freshly installed GuixSD in a QEMU
environment (x86_64 on both host and virtual env) to check the
installation process of the upcoming release.

Overall result: Yes, it worked, no big trouble! There are some things I
noticed I want to share here. I know you all do a good job here, so
take this just as observations. Whoever has the time might take one. And
I'm really picky when I should test something :-)

Starting point/environment Guix from git, being on commit:

6e65eb3cad1d1148eade9ed2228cdea90d531a94
From: Mon Jul 2 00:08:54 2018 +0200

Being on Ubuntu, having Qemu from Ubuntu.

Preparation of installation image went quick and without problems.
Booting it up was also no problem.

Here are my points :

1) Manual/Installing GuixSD in a VM:
https://www.gnu.org/software/guix/manual/guix.html#Installing-GuixSD-in-a-VM

It's telling to start the VM like:

qemu-system-x86_64 -m 1024 -smp 1 \
  -net user -net nic,model=virtio -boot menu=on \
  -drive file=guixsd-install-0.14.0.system.iso \
  -drive file=guixsd.img

I prefered writing the disk like this:

 -drive readonly,media=cdrom,\
file=/gnu/store/70p7140n5igrqsfl989cxfzx6q3czc9a-image.iso

In that way, I can use the RO store entry and QEMU will not complain
about not being able to write to. Should we update the manual?

2) The welcome screen with installation instructions is a bit
cluttered. I had in mind that Danny already worked on this? There might
be some interesting things in case of fatal errors. But this is not very
nice for new users who can't read the instructions between the lines:

It's something like that:

```
You have been warned ...
[8.47... ] shephard[1]: Service console-font-tty1 has been started.
... Service term-tty2 has been started.
..
PIO_UNIMAPCLR: Input/output error
root@gnu ~# [...]
error in finalization thread: Bad file descriptor
[49.] random: crng init done
[49]  random: 4 urandom warning(s) missed due to ratelimiting

```

3) PIO_UNIMAPCLR: Input/output error

Anything to worry about?

3a) POSITIVE: Colors work. GPM works. Alt-F2, Docu works.

4) Network setup. Then: `ping -c gnu.org`

That did not work. It took me a while to realize that DNS worked but
ping not. Probably due to QEMU NAT?

I tried instead wget or curl. But both are not there. Do we have
"HTTP client" tools in the installer package to test the network this
way? Or is this too heavy in size for the installer? Do we have
anything else to give the user at it's hand besides ping?

5) I think the partition part in the manual is quite confusing. For me,
it's not clear what's the difference between DOS and this other
partitioning scheme. Which one should I choose in which situation [OK,
is this something GuixSD has to care about? I think at least a bit]?

Anyway, I continued with a DOS, one partition, no swap.

6) Editors: When it comes about editing the standard config, there are
three editors mentioned: zile, nano, nvi. The first ones are fired up as
named, for "nvi" the command is "vi". This is not obvious for everyone.

7) Zile/Umlauts problem:
I wantet do write "Björn" as my user comment in the config but I
couldn't.
Althogh I did `loadkeys de-latin1` and could write umlauts on the
shell, within Zile I get this error:

 is undefined

7a) GOOD: guix system init took only 10 minutes. Where's my break?

8) No keymap in new system:

One of the first steps in the installation is to load the keymaps. But
when I reboot into the newly system, I'm left with the default
US-keyboard again. Luckily root has no password yet. Nobody mentioned I
should set that up in my configuration, no example in the configuration
file [I used the plain one].

8a) GOOD: That title 'label thing is no longer in the config, although
it is still mentioned on the homepage docs [Needs to be updated]

9) Old guix version:

Being in the newly booted system:

 which guix:
--> /run/current-system/profile/bin/guix
  -> /gnu/store/111i...-guix-0.14.0-12.77a1aac/bin/guix

That commit 77a1aac is from 2018-06-09. Why so old?

After guix pull [quite fast!], I get it correctly from ~/.config/...

Ah, whait, a `which guix` is correctly pointing to there, and that is finally 
pointing to `/gnu/store/496...guix-6e65eb3a/bin/guix` But guix --version 
reports still the old one ...

So why is there this guix-0.14.0-12.77a1aac from one month ago? After a
fresh installation, I want the newest Guix!

BTW: After reboot (I think a logout/in would have been sufficent), guix
--version reported the new commit-id.

10) Old kernel?

I'm pretty sure about that, but now a bit confused. Probably due to 9)?

Installation ISO welcomes with:

"GNU with Linux-Libre 4.17.3 (beta)"

After 'guix system init', I'm at 4.17.2 (Yes, I have this old generation in my 
GRUB startup screen).

Only after guix pull && guix system reconfigure I'm at 4.17.3 again.

So, if you start your system newly and don't do a guix pull directly ["This is 
so complicated, let's do that later..."], you are one kernel beh

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Tobias Geerinckx-Rice]

Hullo Bjrn,

Björn Höfling wrote:

Hi people,

as Ludo "requested", today I freshly installed GuixSD in a QEMU
environment (x86_64 on both host and virtual env) to check the
installation process of the upcoming release.


Wow. Thanks!

You've motivated me to try it on a headless server (if that 
works).



qemu-system-x86_64 -m 1024 -smp 1 \
  -net user -net nic,model=virtio -boot menu=on \
  -drive file=guixsd-install-0.14.0.system.iso \
  -drive file=guixsd.img

I prefered writing the disk like this:

 -drive readonly,media=cdrom,\
file=/gnu/store/70p7140n5igrqsfl989cxfzx6q3czc9a-image.iso

In that way, I can use the RO store entry and QEMU will not 
complain

about not being able to write to.


My QEMU-FU is, to say the least, rusty.

Do I parse this correctly as two separate (but related) 
suggestions: adding ‘readonly,media=cdrom’ to silence the 
complaint and ‘file=/gnu/store/...’ to use an image from the 
store?



Should we update the manual?


...if so: +1 to the first suggestion.

The second one seems to depend on your situation. The manual 
assumes you've downloaded the image (probably not using ‘guix 
download’) instead of building it from scratch, but we could 
document both. Especially since the latter can be written as one 
easy command:


 qemu-system-x86_64 [...] -drive readonly,media=cdrom,file=$(guix 
 ...)



2) The welcome screen with installation instructions is a bit
cluttered. I had in mind that Danny already worked on this? 
There might
be some interesting things in case of fatal errors. But this is 
not very
nice for new users who can't read the instructions between the 
lines:


It's something like that:

```
You have been warned ...
[8.47... ] shephard[1]: Service console-font-tty1 has been 
started.

... Service term-tty2 has been started.
..
PIO_UNIMAPCLR: Input/output error
root@gnu ~# [...]
error in finalization thread: Bad file descriptor
[49.] random: crng init done
[49]  random: 4 urandom warning(s) missed due to ratelimiting

```


Yeah. This is horrible.


3) PIO_UNIMAPCLR: Input/output error

Anything to worry about?


I can't find this in any logs on any box so I can't say.


3a) POSITIVE: Colors work. GPM works. Alt-F2, Docu works.

4) Network setup. Then: `ping -c gnu.org`

That did not work. It took me a while to realize that DNS worked 
but

ping not. Probably due to QEMU NAT?


Not NAT, but yes, it's due to QEMU's ‘user networking’ not 
actually emulating all OSI layers IIRC.



I tried instead wget or curl. But both are not there. Do we have
"HTTP client" tools in the installer package to test the network 
this

way? Or is this too heavy in size for the installer? Do we have
anything else to give the user at it's hand besides ping?


‘guix download’. (Hey, if we include a static example and its hash 
in the manual you'll even know when your being MITM'd by an 
incompetent!)


We *could* include our own simple CLI HTTP client in Guile, if one 
doesn't already exist. I don't think that it's a very good option, 
but it is one.


5) I think the partition part in the manual is quite 
confusing. For me,

it's not clear what's the difference between DOS and this other
partitioning scheme. Which one should I choose in which 
situation [OK,
is this something GuixSD has to care about? I think at least a 
bit]?


It's something the user has to care about, because their computer 
does and GRUB does. Unless we (again) write our own magic wrapper 
somehow. Then GRUB breaks, the user shows up in #guix, and it's 
even harder to help them.


I think it would be most helpful to add something like:

 If /sys/firmware/efi exist on your system, jump to Partitioning 
 under UEFI.
 Otherwise, see Partitioning with DOS or BIOS or whatever we 
 choose to call it.


Would this have been enough to help you through?

[I prefer this to a ‘Welcome to the installer! (UEFI mode)’ 
message as proposed elsewhere because it keeps all knowledge in 
the manual, doesn't scroll off the screen ;-), isn't 
GuixSD-specific, and allows the user to get started quickly 
without hiding anything, but that's obviously all in my opinion.]



Anyway, I continued with a DOS, one partition, no swap.

6) Editors: When it comes about editing the standard config, 
there are
three editors mentioned: zile, nano, nvi. The first ones are 
fired up as
named, for "nvi" the command is "vi". This is not obvious for 
everyone.


Thorough testing :-) Good catch! Do you have time to submit a 
patch?



7) Zile/Umlauts problem:
I wantet do write "Björn" as my user comment in the config but I
couldn't.
Althogh I did `loadkeys de-latin1` and could write umlauts on 
the

shell, within Zile I get this error:

 is undefined

7a) GOOD: guix system init took only 10 minutes. Where's my 
break?


8) No keymap in new system:

One of the first steps in the installation is to load the 
keymaps. But

when I reboot into the newly system, I'm left with the default
US-keyboard again. Luckily root has no password yet. Nobody 
mentioned I
shou

(Ab?)using aliases to set ls' and others' colours

[Tobias Geerinckx-Rice]

Tobias Geerinckx-Rice wrote:

Björn Höfling wrote:

ls has a colored output. Nice.
ls | less has ugly escape sequences. Only ls --color=no | less
works.


I'd be surprised if ‘ls | less -R’ didn't (and that would be a 
bug).


Otherwise, this is standard behaviour for both ‘ls’ and ‘less’.


Apologies, I made a reado.

‘ls | $foo’ should indeed detect a missing tty and stop spewing 
colour automatically. At least if ‘ls’ is properly aliased to ‘ls 
--color=auto’.


Instead, it is aliased[0] to use ‘--color’ — short for ‘ls 
--color=always’ — for reasons I cannot understand. We do the same 
for ‘grep’.


Perhaps it was assumed that ‘--color’ on its own implies ‘auto’ 
instead of ‘always’ (I could see how that could happen)? Or 
‘--color=auto’ is too cautious, and disables colour in a situation 
where the author expects it? In that case I don't think the 
trade-off is worth it.


On the other hand, what I consider an obvious bug has been around 
since literal forever[1], so maybe I'm missing something obvious 
here. I've CC'd the original author. If everyone agrees or nobody 
responds, I'd like to change it to something less aggressive 
before 0.15.[2]


What? Not sure yet. I'm not even sure this should be handled by 
aliases at all. Our default ‘ls’ alias also adds a ‘-p’, which is 
probably valid [although I find it useless and annoying and 
disable it], but colours for both commands can also be controlled 
through the {LS,GREP}_COLORS variables which seems like a better 
fit for distro defaults like these. We can even change the 
colours! But let's not.


Oh, I don't know.

This is the kind of trivial bug that would've put me off a distro, 
I guess.


Kind regards,

T G-R

[0]: in gnu/system/shadow.scm
[1]: 2013, at least: 0b86a82dc7e649e4ae551edefba445690a315b83
[2]: I'm already doing so in my own .bashrc, which has drifted 
away from Guix's current upstream version, which is its own little 
annoying gotcha.

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Marius Bakke]

Björn Höfling  writes:

> 9) Old guix version:
>
> Being in the newly booted system:
>
>  which guix:
> --> /run/current-system/profile/bin/guix
>   -> /gnu/store/111i...-guix-0.14.0-12.77a1aac/bin/guix
>
> That commit 77a1aac is from 2018-06-09. Why so old?
>
> After guix pull [quite fast!], I get it correctly from ~/.config/...
>
> Ah, whait, a `which guix` is correctly pointing to there, and that is finally 
> pointing to `/gnu/store/496...guix-6e65eb3a/bin/guix` But guix --version 
> reports still the old one ...
>
> So why is there this guix-0.14.0-12.77a1aac from one month ago? After a
> fresh installation, I want the newest Guix!

The issue here is that the installation media has no
~/.config/guix/current: it uses the "snapshot" Guix, from (gnu packages
package-management).  Which in turn installs an even older snapshot.

It is the same reason you got an older kernel than the installation
image: when building the image, you get the latest version (from your
~/.config/guix/current); but when installing, you get the version
contained in the snapshot.

So it's Guix all the way down.  A funny side effect is that if you never
`guix pull`, but keep reconfiguring, you'll gradually downgrade your
system one snapshot at a time.


signature.asc
Description: PGP signature

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Danny Milosavljevic]

Hi Björn,

thanks for testing it!

On Tue, 3 Jul 2018 10:15:53 +0200
Björn Höfling  wrote:

> 2) The welcome screen with installation instructions is a bit
> cluttered. I had in mind that Danny already worked on this? 

Only for the serial tty init.  But it might be similar here too, I don't know.

> PIO_UNIMAPCLR: Input/output error
> 3) PIO_UNIMAPCLR: Input/output error
> 
> Anything to worry about?

According to https://elixir.bootlin.com/linux/v3.2/source/include/linux/kd.h#L70
that's trying to clear the Unicode -> font map (that is, charmap).

In Linux, ./drivers/tty/vt/vt_ioctl.c implements it.

Can't see how that ever ends up in -EIO O_o

> The first line is written in English with a decimal point. The last line is 
> written in English, although the decimal separator is German [Furthermore, 
> It's more confusing to report the 0.00081 MiBs, i.e. about 80KiB saved space. 
> Rounding should be done after 3 places].

Please, anything *but* 3 fractional places.

Right now, it's still possible to disambiguate "," and "." errors--that would
not be possible with 3 fractional places.

>

After this release, let's integrate an installer.

wip-installer-2 works fine.  The architecture could be more generic (it has
peculiar ideas about how any installer screen MUST look), but it's not bad
or anything.  Also, the wizard leaves something to be desired (I didn't
find the place where it does that yet: You can select any future step, but
if it requires information in a dependent step, it will instead jump to
that one - that's jarring and not what you would expect - at least not
without good visualization).

I thought about doing fully generic Guile window management library a la
Turbo Vision but it's really overkill for what we need.  Nice, sure.

I think the technical holdup for merging wip-installer-2 to master was the
modularization of guix.

Also, I've packaged Anaconda, the Red Hat installer.  It still fails some
tests (and has a lot of dependencies).  I would need some help with Guix's
gi.repository handling.


pgpmsro7306zh.pgp
Description: OpenPGP digital signature

Re: guix package is slow

[swedebugia]

On July 2, 2018 10:28:01 PM GMT+02:00, Alex Kost  wrote:
>Maxim Cournoyer (2018-07-02 10:55 -0400) wrote:
>
>> Hi,
>>
>> Oleg Pykhalov  writes:
>>
>>> Hello,
>>>
>>> Pierre Neidhardt  writes:
>>>
 Maxim Cournoyer  writes:

>> - Perform transactions (install/remove) over multiple packages.
>
> To be fair, I think you can already accomplish this using
>emacs-guix by
> separating with commas multiple package names :).

 Can you explain?  I don't know how to do that.

 The point of the Helm interface is that it allows to "batch select"
 multiple packages.  I don't think that emacs-guix can do that.
>>>
>>> […]
>>>
>>> Another way in ‘M-x guix-all-packages’ or any ‘guix-search-by-*’:
>>>
>>>   • Hit ‘i’ on not installed packages.
>>>   • Hit ‘d’ on installed package.
>>>   • Hit ‘x’ to apply.
>>
>> Thanks Oleg! I keep forgetting about this interface;
>
>he-he, it is only one of about 10 different interfaces of this kind
>(for
>packages, profiles, generations, services, etc.).  If you use only "M-x
>guix", you miss most of Emacs-Guix features.
>
>> there doesn't seem
>> to be an entry point from M-x guix for easy discovery.
>
>"M-x guix" can't be an entry point for this or any other interface, it
>is only for "guix" *shell* commands.  Actually I'm very surprised
>someone uses "M-x guix", I find it unpractical.  I even plan to rename
>it to "M-x guix-command", and to make "M-x guix" a real entry point for
>the various Emacs-Guix commands (including "guix-command" and all the
>interfaces).
>
>-- 
>Alex

Good idea! 
-- 
Cheers Swedebugia 

Guix support in cachix

[Oleg Pykhalov]

Hello Guix,

Domen Kožar  recently was in #guix (IRC) 2 days ago asking
about support of Guix in cachix.  Also he opened an issue on GitHub:

> I'm opening this issue for interest around supporting Guix.

[1] https://github.com/cachix/cachix/issues/85


signature.asc
Description: PGP signature

[PATCH] profiles: Let canonicalize-profile return an absolute path.

[Roel Janssen]

Dear Guix,

I'd like to change the way the symlinks to custom profiles are created.
Here's what currently happens:

$ guixr package -i hello -p guix-profiles/test
$ ls -l guix-profiles
lrwxrwxrwx. 1 user group 25 Jul  3 19:53 test -> guix-profiles/test-1-link
lrwxrwxrwx. 1 user group 51 Jul  3 19:53 test-1-link -> 
/gnu/store/...6qbaps-profile

Now, that symlink is broken.
Instead, I'd like to have it always use absolute paths:

$ guixr package -i hello -p guix-profiles/test
$ ls -l guix-profiles
lrwxrwxrwx 1 roel users 36  3 jul 19:56 test -> 
/home/user/guix-profiles/test-1-link
lrwxrwxrwx 1 roel users 51  3 jul 19:56 test-1-link -> 
/gnu/store/...6qbaps-profile

This symlink isn't broken.

In this patch I implemented this behavior by modifying
canonicalize-profile to return an absolute path when it's not
“~/.guix-profile”.

I hope we can merge this, or a similar solution so that creating
profiles in custom locations is a little more robust.

Kind regards,
Roel Janssen

>From 95178018beb8c5458c154771ac9d1ff4866cc507 Mon Sep 17 00:00:00 2001
From: Roel Janssen 
Date: Tue, 3 Jul 2018 19:49:04 +0200
Subject: [PATCH] profiles: Let canonicalize-profile return an absolute path.

* guix/profiles.scm (canonicalize-profile): Return an absolute path.
---
 guix/profiles.scm | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index ebd7da2a2..4a6a0a80e 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1547,8 +1547,8 @@ because the NUMBER is zero.)"
 
 (define (canonicalize-profile profile)
   "If PROFILE is %USER-PROFILE-DIRECTORY, return %CURRENT-PROFILE.  Otherwise
-return PROFILE unchanged.  The goal is to treat '-p ~/.guix-profile' as if
-'-p' was omitted."   ; see 
+return PROFILE as an absolute path.  The goal is to treat '-p ~/.guix-profile'
+as if '-p' was omitted."   ; see 
 
   ;; Trim trailing slashes so that the basename comparison below works as
   ;; intended.
@@ -1558,7 +1558,10 @@ return PROFILE unchanged.  The goal is to treat '-p ~/.guix-profile' as if
(dirname %user-profile-directory))
  (string=? (basename profile) (basename %user-profile-directory)))
 %current-profile
-profile)))
+(string-append
+ (canonicalize-path (dirname profile))
+ file-name-separator-string
+ (basename profile)
 
 (define (user-friendly-profile profile)
   "Return either ~/.guix-profile if that's what PROFILE refers to, directly or
-- 
2.17.0

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

Hi Marius,

Marius Bakke  writes:

> Mark H Weaver  writes:
>
>> mba...@fastmail.com (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>>> Author: Marius Bakke 
>>> Date:   Mon Jul 2 12:07:58 2018 +0200
>>>
>>> build-system/meson: Really skip the 'fix-runpath' phase on armhf.
>>> 
>>> This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which 
>>> doesn't
>>> work because %current-system etc expands before the actual build.
>>
>> I'm disappointed by this workaround that simply removes the
>> 'fix-runpath' phase on armhf.  Is that phase needed, or is it truly
>> optional?  What does the phase accomplish, and how will armhf users be
>> disadvantaged by the removal of that phase?
>>
>> This feels like "sweeping the problem under the rug" to me.
>
> It *is* sweeping the problem under the rug, no doubt.  The only
> alternatives I can see is fixing patchelf on armhf, which is difficult
> for me without access to hardware; fixing Meson itself, which may be
> easier, but then we may not be able to merge staging in a long time; or
> implement patchelf functionality in Guix as Ludovic started with
>  and is currently in 'core-updates'.
>
> Do you have other suggestions?

None that I expect to be taken seriously by this community.  I'd just
like to point out that given the way things are going, I could only
recommend Guix to x86_64 users.  Almost all of our users are on x86_64,
and they are impatient to always have the latest software.  In practice,
when upgrades would break *any* other system, we move ahead anyway, just
like we did with the last 'core-updates' merge, and just like you wish
to do now with the 'staging' branch.

The end result is that the wishes of the x86_64-using majority are the
only ones that seem to matter in this community, and other users are
frequently left in a bad spot.  This makes it increasingly unlikely that
we'll ever gain a significant number of non-x86_64 users.

I'm very troubled by this, because I intend to move away from x86_64.
Unless there is a significant change in the priorities of the Guix
project, I don't think I will be able to continue using Guix.

>>> Fixes .
>>
>> I don't see the connection between that bug and this commit.
>> How does this commit fix that bug?
>
> Whoops, typo.  It should be .

In my view, this commit does not fix that bug.

   Mark

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Mark H Weaver]

Hi Marius,

Marius Bakke  writes:

> Mark H Weaver  writes:
>
>> mba...@fastmail.com (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit cb4b508cd68df89bfbd5255a0c5569f8318ad50f
>>> Author: Marius Bakke 
>>> Date:   Mon Jul 2 12:07:58 2018 +0200
>>>
>>> build-system/meson: Really skip the 'fix-runpath' phase on armhf.
>>> 
>>> This follows up commit d5b5a15a4046362377f1a45d466b43bb6e93d4f which 
>>> doesn't
>>> work because %current-system etc expands before the actual build.
>>
>> I'm disappointed by this workaround that simply removes the
>> 'fix-runpath' phase on armhf.  Is that phase needed, or is it truly
>> optional?  What does the phase accomplish, and how will armhf users be
>> disadvantaged by the removal of that phase?
>
> I'm sorry, I forgot to address your actual concerns.  The (buggy)
> workaround was put in place and discussed in
> .  The meat of it can be found in (guix
> build-system meson):
>
> ;; XXX PatchELF fails to build on armhf, so we skip
> ;; the 'fix-runpath' phase there for now.  It is used
> ;; to avoid superfluous entries in RUNPATH as described
> ;; in , so armhf may now
> ;; have different runtime dependencies from other arches.

Thanks for this, but I'd still like to know the answer to my questions:
"What does the [fix-runpath] phase accomplish, and how will armhf users
be disadvantaged by the removal of that phase?"

If the 'fix-runpath' phase is not strictly needed, then I would prefer
to remove it on _all_ systems.  If it _is_ needed, then I don't see how
we can simply remove it on 'armhf' systems.

  Thanks,
Mark

Re: guix package is slow

[Ludovic Courtès]

Alex Kost  skribis:

> "M-x guix" can't be an entry point for this or any other interface, it
> is only for "guix" *shell* commands.  Actually I'm very surprised
> someone uses "M-x guix", I find it unpractical.  I even plan to rename
> it to "M-x guix-command", and to make "M-x guix" a real entry point for
> the various Emacs-Guix commands (including "guix-command" and all the
> interfaces).

+1!

Ludo’.

Re: preparing the next release v0.15.0

[Ludovic Courtès]

Hello!

Efraim Flashner  skribis:

> make guix-binary.aarch64-linux.tar.xz works as exptected

Great, thanks for checking!

BTW, did “we” fix access to the OverDrive by berlin.guixsd.org?

In other news, these installation tests pass for me, as of
a51cf16031c974ffa238e5dd9ced32f0d68c9227, on x86_64:

  make check-system TESTS="installed-os iso-image-installer encrypted-root-os"

I think I’ll create the ‘version-0.15’ branch real soon, so we can have
some stability in the next few days.

Ludo’.

Re: preparing the next release v0.15.0

[Ricardo Wurmus]

Ludovic Courtès  writes:

> BTW, did “we” fix access to the OverDrive by berlin.guixsd.org?

I opened a ticket to have the firewall rules adjusted but the network
security person who usually does these things is currently out sick.
Looks like it’s going to take a little longer, unfortunately.

(I didn’t yet get around to reconfiguring some build nodes to use qemu
to build for other architectures, but it’s on my list.)

--
Ricardo

Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.

[Ludovic Courtès]

Marius Bakke  skribis:

> I'm sorry, I forgot to address your actual concerns.  The (buggy)
> workaround was put in place and discussed in
> .  The meat of it can be found in (guix
> build-system meson):
>
> ;; XXX PatchELF fails to build on armhf, so we skip
> ;; the 'fix-runpath' phase there for now.  It is used
> ;; to avoid superfluous entries in RUNPATH as described
> ;; in , so armhf may now
> ;; have different runtime dependencies from other arches.
>
> Now, I'm not proud of this "workaround", but it's not exactly new, so I
> don't see why we should rush to fix it now.  Given how late we are in
> this staging cycle, I would prefer delaying any proper fix until the
> next round.

I agree.  It’s terrible, but the priority here is to get ‘staging’ in
shape for merging.

Thanks for taking care of ‘staging’!

Ludo’.

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Ludovic Courtès]

Hey Danny,

Danny Milosavljevic  skribis:

> After this release, let's integrate an installer.
>
> wip-installer-2 works fine.  The architecture could be more generic (it has
> peculiar ideas about how any installer screen MUST look), but it's not bad
> or anything.  Also, the wizard leaves something to be desired (I didn't
> find the place where it does that yet: You can select any future step, but
> if it requires information in a dependent step, it will instead jump to
> that one - that's jarring and not what you would expect - at least not
> without good visualization).
>
> I thought about doing fully generic Guile window management library a la
> Turbo Vision but it's really overkill for what we need.  Nice, sure.
>
> I think the technical holdup for merging wip-installer-2 to master was the
> modularization of guix.

I agree, we should definitely do that!  And we can always improve it
incrementally afterwards.

Ludo’.

Re: Guix support in cachix

[Ludovic Courtès]

Hello!

Oleg Pykhalov  skribis:

> Domen Kožar  recently was in #guix (IRC) 2 days ago asking
> about support of Guix in cachix.  Also he opened an issue on GitHub:
>
>> I'm opening this issue for interest around supporting Guix.
>
> [1] https://github.com/cachix/cachix/issues/85

Cachix looks interesting!  It’s good to collaboratively provide
binaries.  It’s easier than having everyone set up ‘guix publish’, at
the cost of being more centralized.

The “cachix use ” example on https://cachix.org/ glosses over
security “details” though.  I wonder how one gets to authenticate a
particular user of Cachix and to authorize binaries coming from them.
There’s also the issue that said user could be publishing binaries they
themselves obtained from a source that you do not trust yourself.  Tough
issues!

Ludo’.

Re: Installation-Protocol for GuixSD x86_64 v0.15-preview

[Ludovic Courtès]

Hi Björn,

Björn Höfling  skribis:

> as Ludo "requested", today I freshly installed GuixSD in a QEMU
> environment (x86_64 on both host and virtual env) to check the
> installation process of the upcoming release.
>
> Overall result: Yes, it worked, no big trouble! There are some things I
> noticed I want to share here. I know you all do a good job here, so
> take this just as observations. Whoever has the time might take one. And
> I'm really picky when I should test something :-)

Thanks a lot for testing and providing detailed feedback!  I think
Tobias and Marius already commented on most issues; some can be fixed
for 0.15, others are unfortunately trickier to address.

> Starting point/environment Guix from git, being on commit:
>
> 6e65eb3cad1d1148eade9ed2228cdea90d531a94
> From: Mon Jul 2 00:08:54 2018 +0200

I made some adjustments to ‘guix system init’ later today, but it
shouldn’t make a big difference here.

Did you have troubles with substitutes?  In particular, did it hang as
described in ?  (I’m still experiencing it
occasionally and I can’t believe I’m the only one.)

> ...
> note: currently hard linking saves 206.08 MiB
> guix gc: freed 91,50781 MiBs
>
> The first line is written in English with a decimal point. The last line is 
> written in English, although the decimal separator is German [Furthermore, 
> It's more confusing to report the 0.00081 MiBs, i.e. about 80KiB saved space. 
> Rounding should be done after 3 places].

The English part comes from the C++ code base, which is not i18n’d,
whereas the other line comes from the Scheme part, which is i18n’d.

Here the Scheme code prints numbers according to your German locale;
however, there’s apparently no translation of the message itself, which
is why it still says “freed”.  Weird, I agree.

> 12) ls | less
>
> ls has a colored output. Nice.
> ls | less has ugly escape sequences. Only ls --color=no | less works.

As discussed on IRC with Tobias, that’s a mistake; we should use
--color=auto.  Tobias, are you committing this change?  :-)

Thanks!

Ludo’.