Plan for a release!

Plan for a release!

[Ludovic Courtès]

Hi Guix!

I’m going on vacation for a bit, but I think we should finally get that
release out!  Here’s the list of things to do I have in mind:

  • We need Guile 3.0.1 to fix ‘guix pull’ etc. on AArch64 and possibly
    JIT on ARMv7:

      https://issues.guix.gnu.org/issue/39266
      https://issues.guix.gnu.org/issue/39208

  • More testing of the guided installer and related issues:

     https://issues.guix.gnu.org/issue/39729
     https://issues.guix.gnu.org/issue/39712

  • Fix the weird default font in GNOME Terminal, as sirgazil reported
    on help-guix.

  • Ensure that the desktop environments provided by the installer
    actually work (GNOME, Xfce, MATE, etc.).  It’d be great to have
    automated tests for these!

  • (Optionally) have an automated test that installs the binary tarball
    on Debian or similar.

  • Address as many of the bugs marked “important” or “serious” as
    possible.  Should we organize a bug-squashing week?  :-)

  • We already have “make assert-binaries-available”, but at the Guix
    Days we came up with the idea of having ‘guix weather
    --release-critical’ or similar, which would ensure that all the
    relevant jobs pass (packages, cross-builds, system tests, etc.).
    I’ll see if I can do something in that area.

What’s missing from the list?

I don’t think we’ll wait for the ‘core-updates’ merge, but who knows.

As you see there’s a lot of testing in there, plus the need to keep
things on track!  If someone wants to be the “master of time” and make
sure we don’t enter and endless add-feature/break/fix loop, that’d be
welcome!

Thoughts?

Ludo’.

Re: Plan for a release!

[Vincent Legoll]

Hello,

On Mon, Feb 24, 2020 at 10:56 PM Ludovic Courtès <ludo@gnu.org> wrote:

> I’m going on vacation for a bit, but I think we should finally get that
> release out!  Here’s the list of things to do I have in mind:

Yes !

>   • (Optionally) have an automated test that installs the binary tarball
>     on Debian or similar.

I'm (slowly) working on this. I have some bash script doing the work, but
that cannot be run from guix itself because it requires libguestfs. So I'm
working on packaging that first, but it is not trivial. Another requirement
was tunctl, but that one is tackled already.

I've developed it under debian, and can easily test candidate tarballs on
a bunch of different OSes manually, until I've got something submittable
for inclusion... So I personally opt for the "Optionally" for this release and
will continue to work on it to have it ready for next one.

-- 
Vincent Legoll

Re: Plan for a release!

[Jonathan Brielmaier]

On 24.02.20 23:55, Vincent Legoll wrote:>>   • (Optionally) have an
automated test that installs the binary tarball
>>     on Debian or similar.
>
> I'm (slowly) working on this. I have some bash script doing the work, but
> that cannot be run from guix itself because it requires libguestfs. So I'm
> working on packaging that first, but it is not trivial. Another requirement
> was tunctl, but that one is tackled already.
>
> I've developed it under debian, and can easily test candidate tarballs on
> a bunch of different OSes manually, until I've got something submittable
> for inclusion... So I personally opt for the "Optionally" for this release and
> will continue to work on it to have it ready for next one.

Can you give us a link to your work (git or so). I'm very interested in
this stuff, to use it on openSUSE. tunctl and libguestfs are already
packaged for openSUSE. So it should be useable.

Re: Plan for a release!

[Vincent Legoll]

Hello,

On Tue, Feb 25, 2020 at 3:00 PM Jonathan Brielmaier
<jonathan.brielmaier@web.de> wrote:
> Can you give us a link to your work (git or so). I'm very interested in
> this stuff, to use it on openSUSE. tunctl and libguestfs are already
> packaged for openSUSE. So it should be useable.

OK, I'll post it to the ML when I'm back home, friday-ish...

-- 
Vincent Legoll

Re: Plan for a release!

[zimoun]

Hi Ludo,

On Mon, 24 Feb 2020 at 22:57, Ludovic Courtès <ludo@gnu.org> wrote:

> I’m going on vacation for a bit, but I think we should finally get that
> release out!  Here’s the list of things to do I have in mind:

Enjoy the vacations ! :-D


>   • Address as many of the bugs marked “important” or “serious” as
>     possible.  Should we organize a bug-squashing week?  :-)

Bug-squashing week sounds a good idea!

The tags "important" and "serious" are priority.
But close (or provide new information of) any bug is already nice;
especially old bugs and old patches.



Cheers,
simon

Re: Plan for a release!

[Joshua Branson]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Guix!
>
> I’m going on vacation for a bit, but I think we should finally get that
> release out!  Here’s the list of things to do I have in mind:
>
>   • We need Guile 3.0.1 to fix ‘guix pull’ etc. on AArch64 and possibly
>     JIT on ARMv7:
>
>       https://issues.guix.gnu.org/issue/39266
>       https://issues.guix.gnu.org/issue/39208
>
>   • More testing of the guided installer and related issues:
>
>      https://issues.guix.gnu.org/issue/39729
>      https://issues.guix.gnu.org/issue/39712

I'll volunteer to do this on Thursday.  I've got two Macbooks 7,1 and a
2008 Macbook Pro that I can test on.  

>
>   • Fix the weird default font in GNOME Terminal, as sirgazil reported
>     on help-guix.
>
>   • Ensure that the desktop environments provided by the installer
>     actually work (GNOME, Xfce, MATE, etc.).  It’d be great to have
>     automated tests for these!

I do that as well this Thursday.

>
>   • (Optionally) have an automated test that installs the binary tarball
>     on Debian or similar.
>
>   • Address as many of the bugs marked “important” or “serious” as
>     possible.  Should we organize a bug-squashing week?  :-)
>
>   • We already have “make assert-binaries-available”, but at the Guix
>     Days we came up with the idea of having ‘guix weather
>     --release-critical’ or similar, which would ensure that all the
>     relevant jobs pass (packages, cross-builds, system tests, etc.).
>     I’ll see if I can do something in that area.
>
> What’s missing from the list?
>
> I don’t think we’ll wait for the ‘core-updates’ merge, but who knows.
>
> As you see there’s a lot of testing in there, plus the need to keep
> things on track!  If someone wants to be the “master of time” and make
> sure we don’t enter and endless add-feature/break/fix loop, that’d be
> welcome!
>
> Thoughts?
>
> Ludo’.
>

-- 
Joshua Branson
Sent from Emacs and Gnus

Re: Plan for a release!

[jbranso]

Well I finally got around to doing some testing on my Macbook Pro circa 2008.  I built the installer image just today with 

     guix system disk-image --file-system-type=iso9660 \
       gnu/system/install.scm


joshua@dobby ~$ guix describe
Generation 45	Mar 03 2020 23:16:24	(current)
  jmacs 54f8408
    repository URL: https://notabug.org/jbranso/guix-packages.git
    branch: master
    commit: 54f84080d7459e74cd33cf434c1077c082ce6508
  guix 4b759d3
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 4b759d3c548270eba348521669bae15c9e5b72bc

In the past, I had to run open the grub command promt and run "configfile (hd0,msdos)/boot/grub/grub.cfg".  Guix's installer does now allow me to see the "EFI boot" option when I hold down the "option" key on start up.  That is an improvent.


I had to test the manual installation method.  The graphical installer does not work on my macbook.  It just flickers on and then off.  Shortly after grub boots into the installer, I briefly see a blue screen, then black, then blue, then black, etc.  I can switch to a virtual console and proceed with the installation that way.  Perhaps, we should try to start the graphical installer only 5 times.  If it fails, then just produce an error message and suggest the user switch to another virtual console and try the manual install.


Manual install worked.  I had a weird issue when I made the btrfs filesystems.  "mkfs.btrfs -L my-root /dev/sd3" gave me an error like "failed to execute /gnu/store/eudev/santsnthsnthau32psu/lib/udev ID_BTRFS_READY=0", and it repeated on every boot.   The error message on each bot looked like:

udevd failed to execute /gnu/store/eudev/santsnthsnthau32psu/lib/udev ID_BTRFS_READY=0

I configured EFI boot with 1 btrfs partition.  I enabled gnome, mate, xfce, and enlightenment services.  The install took about an hour.  In the past, I configured a minimal install with no desktop services or window manager services.  I have found that trying to install a desktop service fails halfway through.  However, this time,  the install worked just fine.

GDM started just fine.  It even recognized my dvorak layout.  It did not in the past.  Progress.

I first tested Gnome.  Gnome took a long time to fully load.  I had a mouse that could move around for 5+ minutes with no background image before the "Welcome to Gnome" screen popped up.  I navigated through the default gnome setup easily.  No issues.  Gnome appeared to be working just fine.

Next I tried testing Enlightenment, which started just fine.  The Enlightenment welcome dialog started first.  I clicked through a few screen, but it appeared to get stuck picking default mouse bindings.  The dialog box said,  "Enlightenment sets default mouse bindings for objects".  It hanged on that screen after I clicked "Alt" for 10+ minutes.  I did a hard reboot, which is what really screwed me.  I should have switched to a virtual console and tried to shut off that way.

Anyway, after hard rebooting, grub attempted to load my OS.  The grub screen went away, and the boot process showed a cursor, but no text.  I waited for 5 minutes before hard rebooting.  I got the same issue.  So my Macbook Pro currently has no OS on it.  :(  But my ThinkPad T400 works just fine!

Thanks,

Joshua

P.S.  If anyone has any suggestions of where I can look for errors, please let me know.  I would be happy to try installing again.

Re: Plan for a release!

[pelzflorian (Florian Pelz)]

On Thu, Mar 05, 2020 at 04:54:21AM +0000, jbranso@dismail.de wrote:
> I had to test the manual installation method.  The graphical installer does not work on my macbook.  It just flickers on and then off.  Shortly after grub boots into the installer, I briefly see a blue screen, then black, then blue, then black, etc.  I can switch to a virtual console and proceed with the installation that way.  Perhaps, we should try to start the graphical installer only 5 times.  If it fails, then just produce an error message and suggest the user switch to another virtual console and try the manual install.

Perhaps one should restart with mingetty-service if kmscon fails (but
not if installation was restarted by the user).  But I suppose this
was discussed before and I do not know if kmscon can be unloaded.

Regards,
Florian

kmscon not working on MacBook

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Thu, Mar 05, 2020 at 04:54:21AM +0000, jbranso@dismail.de wrote:
>> I had to test the manual installation method.  The graphical installer does not work on my macbook.  It just flickers on and then off.  Shortly after grub boots into the installer, I briefly see a blue screen, then black, then blue, then black, etc.  I can switch to a virtual console and proceed with the installation that way.  Perhaps, we should try to start the graphical installer only 5 times.  If it fails, then just produce an error message and suggest the user switch to another virtual console and try the manual install.
>
> Perhaps one should restart with mingetty-service if kmscon fails (but
> not if installation was restarted by the user).  But I suppose this
> was discussed before and I do not know if kmscon can be unloaded.

Joshua, do you know what graphics card this MacBook has?

In the past, Mathieu, Florian, and others looked at similar issues on
some graphics boards.  Perhaps there’s something we can do here to
special-case this hardware?

Ludo’.

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Sun, Mar 08, 2020 at 10:03:26PM +0100, Ludovic Courtès wrote:
> In the past, Mathieu, Florian, and others looked at similar issues on
> some graphics boards.  Perhaps there’s something we can do here to
> special-case this hardware?
> 
> Ludo’.

The affected hardware is diverse and I see no pattern.  I would favor
restarting with mingetty.  However, the installer runs but just has no
display, so I do not know how to detect it.

My Macbook using “NVIDIA Corporation MCP89 [GeForce 320M] (rev a2)”
runs the installer just fine.

A desktop PC using “NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev
a2)” runs it just fine too.

Another PC using “Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO
[Radeon R7 240/340]” runs the installer just fine (but not Xorg X).

A laptop Acer Aspire 5738 using “Advanced Micro Devices,
Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]” *fails*
with a black screen; manual installation is required (which I have not
tested but probably works).

Another laptop Uniwill U50SI1 using “Silicon Integrated Systems [SiS]
771/671 PCIE VGA Display Adapter (rev 10)” *fails* the same way.
Manual install works fine.  Note that I cannot boot non-Windows
install images (Debian or Guix) on this machine, only via DVD, and
Xorg X server only runs using uvesafb with a v86d helper.

None of these installers flicker; the screen is black or it runs fine.

Regards,
Florian

Re: kmscon not working on MacBook

[Vincent Legoll]

Hello,

On Mon, Mar 9, 2020 at 8:44 AM pelzflorian (Florian Pelz)
<pelzflorian@pelzflorian.de> wrote:
> None of these installers flicker; the screen is black or it runs fine.

I also tried the installer on an old laptop (AMD CPU + GPU) on which
the gui installer did not work, black screen. The manual installer run on
an alternate text console worked fine.

-- 
Vincent Legoll

Re: kmscon not working on MacBook

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Sun, Mar 08, 2020 at 10:03:26PM +0100, Ludovic Courtès wrote:
>> In the past, Mathieu, Florian, and others looked at similar issues on
>> some graphics boards.  Perhaps there’s something we can do here to
>> special-case this hardware?
>> 
>> Ludo’.
>
> The affected hardware is diverse and I see no pattern.  I would favor
> restarting with mingetty.  However, the installer runs but just has no
> display, so I do not know how to detect it.
>
> My Macbook using “NVIDIA Corporation MCP89 [GeForce 320M] (rev a2)”
> runs the installer just fine.
>
> A desktop PC using “NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev
> a2)” runs it just fine too.
>
> Another PC using “Advanced Micro Devices, Inc. [AMD/ATI] Oland PRO
> [Radeon R7 240/340]” runs the installer just fine (but not Xorg X).
>
> A laptop Acer Aspire 5738 using “Advanced Micro Devices,
> Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]” *fails*
> with a black screen; manual installation is required (which I have not
> tested but probably works).
>
> Another laptop Uniwill U50SI1 using “Silicon Integrated Systems [SiS]
> 771/671 PCIE VGA Display Adapter (rev 10)” *fails* the same way.
> Manual install works fine.  Note that I cannot boot non-Windows
> install images (Debian or Guix) on this machine, only via DVD, and
> Xorg X server only runs using uvesafb with a v86d helper.
>
> None of these installers flicker; the screen is black or it runs fine.

For the cases where kmscon actually fails (exit with a non-zero code),
a solution would be the following: instead of running kmscon directly,
we run a wrapper around it that spawn mingetty (as you suggested) when
kmscon exits with non-zero.

(Perhaps the flickering Joshua mentioned was actually due to kmscon
being continuously restarted by shepherd?)

However, in cases where kmscon does *not* exits and simply produces a
black screen, I don’t see what can be done.  In the cases you list
above, does kmscon simply sit there without exiting?

At any rate, thanks for the testing & detailed info!

Ludo’.

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

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

On Mon, Mar 09, 2020 at 05:45:45PM +0100, Ludovic Courtès wrote:
> However, in cases where kmscon does *not* exits and simply produces a
> black screen, I don’t see what can be done.  In the cases you list
> above, does kmscon simply sit there without exiting?
> 

When run with --debug, kmscon displays not quite helpful errors:

[0000.488942] DEBUG: pty: forking child 28378 (pty_spawn() in src/pty.c:422)
[0000.490819] DEBUG: pty: HUP on pty of child 28378 (pty_input() in src/pty.c:520)
[0000.490866] DEBUG: eloop: child 28378 exited with status 1 (sig_child() in src/eloop.c:350)
[0000.490883] INFO: pty: child exited: pid: 28378 status: 256 (sig_child() in src/pty.c:536)

over and over again.  (The errors are visible after killing kmscon.)

I’m not sure if that is a good means for detection.



"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:
> A laptop Acer Aspire 5738 using “Advanced Micro Devices,
> Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4530/4570/545v]” *fails*
> with a black screen; manual installation is required (which I have not
> tested but probably works).
>

I could get the installer to display properly by using my unfinished
package for the useful v86d helper (attached):

guix package -f v86d.scm
ln -s /gnu/store/yj9mxi0yr4ksg5v7031mdrc8fvb2wxrb-linux-libre-5.4.24/lib/ /lib
modprobe uvesafb v86d=/root/.guix-profile/sbin/v86d

Without the symbolic linking, kmscon displays a flickering Module
uvesafb not found in directory /lib/modules…

I will try to properly package v86d now (without bundled libraries).
uvesafb does not work on my Macbook though; I believe it conflicts
with modesetting.

Regards,
Florian

[-- Attachment #2: v86d.scm --]
[-- Type: application/vnd.lotus-screencam, Size: 1751 bytes --]

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Wed, Mar 11, 2020 at 08:14:37AM +0100, pelzflorian (Florian Pelz) wrote:
> I’m not sure if that is a good means for detection.
> 
> 
> 

Perhaps one could go by whether /dev/fb0 exists.  I wonder if /dev/fb0
is missing on all affected devices.  I will check mine later.

Regards,
Florian

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Wed, Mar 11, 2020 at 08:14:37AM +0100, pelzflorian (Florian Pelz) wrote:
> I could get the installer to display properly by using […]the useful v86d helper[…]
> 
> guix package -f v86d.scm
> ln -s /gnu/store/yj9mxi0yr4ksg5v7031mdrc8fvb2wxrb-linux-libre-5.4.24/lib/ /lib
> modprobe uvesafb v86d=/root/.guix-profile/sbin/v86d
> 
> Without the symbolic linking, kmscon displays a flickering Module
> uvesafb not found in directory /lib/modules…
> 
> I will try to properly package v86d now (without bundled libraries).
> uvesafb does not work on my Macbook though; I believe it conflicts
> with modesetting.
> 

Now that v86d is pushed as e2303e8e375ed2e07c1fd760c86a204eb51fbc6e
(see <https://lists.gnu.org/archive/html/guix-patches/2020-03/msg00681.html>):

The attached patch makes the graphical installer work on two old
computers I tested.  I do not know how to proceed with it.  I would
like something similar to be included in the next release.  Maybe
kmscon works everywhere then.  ('nomodeset' is not needed; I leave it
in only for testing on computers where the graphical installer works
anyway when not passing 'nomodeset'.)  The patch should not change
behavior on machines where /dev/fb0 is created via modesetting anyway.

Regards,
Florian

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

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

On Fri, Mar 20, 2020 at 09:48:50AM +0100, pelzflorian (Florian Pelz) wrote:
> The attached patch […]
Forgot attachment …

[-- Attachment #2: 0001-for-TESTING-only-works-for-some-machines-installer-R.patch --]
[-- Type: text/plain, Size: 2933 bytes --]

From 2dd61d18b88f197d8d6951fe1dc97bafdf4fe03f Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Thu, 19 Mar 2020 15:50:00 +0100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: [PATCH 3/3] [for TESTING, only works for some machines] installer:
 Run installer in uvesafb.

* gnu/system/install.scm (installation-os): Load uvesafb before installer.
---
 gnu/system/install.scm | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/gnu/system/install.scm b/gnu/system/install.scm
index c15c2c7814..88db4320b0 100644
--- a/gnu/system/install.scm
+++ b/gnu/system/install.scm
@@ -50,6 +50,7 @@
   #:use-module (gnu packages texinfo)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages nvi)
+  #:use-module (gnu packages xorg)
   #:use-module (ice-9 match)
   #:use-module (srfi srfi-26)
   #:export (installation-os
@@ -304,8 +305,34 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
     (define bare-bones-os
       (load "examples/bare-bones.tmpl"))
 
+    (define (insmod-uvesafb-activation value)
+      #~(begin
+          (use-modules (guix build utils))
+          (symlink #$(file-append linux-libre "/lib") "/lib")))
+
+    (define (insmod-uvesafb-shepherd-service _)
+      (list (shepherd-service
+             (provision '(insmod-uvesafb))
+             (requirement '(user-processes udev dbus-system))
+             (start #~(make-forkexec-constructor
+                       (list #+(file-append kmod "/bin/modprobe") "uvesafb"
+                             (string-append "v86d=" #$v86d "/sbin/v86d")
+                             "mode_option=1024x768")))
+             (stop #~(make-kill-destructor))
+             (one-shot? #t))))
+
     (list (service virtual-terminal-service-type)
 
+          (service
+           (service-type (name 'insmod-uvesafb)
+                         (extensions
+                          (list (service-extension activation-service-type
+                                                   insmod-uvesafb-activation)
+                                (service-extension shepherd-root-service-type
+                                                   insmod-uvesafb-shepherd-service)))
+                         (description "Start uvesafb."))
+           #t)
+
           (service kmscon-service-type
                    (kmscon-configuration
                     (virtual-terminal "tty1")
@@ -434,7 +461,7 @@ Access documentation at any time by pressing Alt-F2.\x1b[0m
     ;; non-functional:
     ;; <https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00441.html>.
     ;; Thus, blacklist it.
-    (kernel-arguments '("quiet" "modprobe.blacklist=radeon"))
+    (kernel-arguments '("quiet" "modprobe.blacklist=radeon" "nomodeset"))
 
     (file-systems
      ;; Note: the disk image build code overrides this root file system with
-- 
2.25.1

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Fri, Mar 20, 2020 at 09:48:50AM +0100, pelzflorian (Florian Pelz) wrote:
> I would
> like something similar to be included in the next release.  Maybe
> kmscon works everywhere then.

Of course the machines that need uvesafb to show the installer also
later have problems showing Xorg.  Maybe until Xorg on installed
systems without Kernel Mode Setting works fine without manually
fiddling with uvesafb or nonfree drivers, there is no use making the
installer work.

Perhaps uvesafb could somehow be made to work automatically, however
on one of my computers uvesafb can only be used after „chmmod o+rw
/dev/fb0“ which is a security issue, I suppose.


> ('nomodeset' is not needed; I leave it
> in only for testing on computers where the graphical installer works
> anyway when not passing 'nomodeset'.)

In fact nomodeset was needed on a friend’s AMD GPU system.  Probably
one could blacklist yet another AMD graphics module instead of passing
nomodeset.  But then the installer on AMD systems where the module is
working fine would be limited to uvesafb.

Regards,
Florian

Re: kmscon not working on MacBook

[Bengt Richter]

Hi,

On +2020-03-26 00:00:18 +0100, pelzflorian (Florian Pelz) wrote:
> On Fri, Mar 20, 2020 at 09:48:50AM +0100, pelzflorian (Florian Pelz) wrote:
> > I would
> > like something similar to be included in the next release.  Maybe
> > kmscon works everywhere then.
> 
> Of course the machines that need uvesafb to show the installer also
> later have problems showing Xorg.  Maybe until Xorg on installed
> systems without Kernel Mode Setting works fine without manually
> fiddling with uvesafb or nonfree drivers, there is no use making the
> installer work.
> 
> Perhaps uvesafb could somehow be made to work automatically, however
> on one of my computers uvesafb can only be used after „chmmod o+rw
> /dev/fb0“ which is a security issue, I suppose.
>

Are you a member of the video group?
What do you see typing
    stat /dev/fb0
? Maybe something to try?
Or not relevant to your context?

> 
> > ('nomodeset' is not needed; I leave it
> > in only for testing on computers where the graphical installer works
> > anyway when not passing 'nomodeset'.)
> 
> In fact nomodeset was needed on a friend’s AMD GPU system.  Probably
> one could blacklist yet another AMD graphics module instead of passing
> nomodeset.  But then the installer on AMD systems where the module is
> working fine would be limited to uvesafb.
> 
> Regards,
> Florian
> 

-- 
Regards,
Bengt Richter

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

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

On Thu, Mar 26, 2020 at 03:26:05AM +0100, Bengt Richter wrote:
> On +2020-03-26 00:00:18 +0100, pelzflorian (Florian Pelz) wrote:
> > on one of my computers uvesafb can only be used after „chmmod o+rw
> > /dev/fb0“ which is a security issue, I suppose.
> >
> 
> Are you a member of the video group?

Indeed the issue was that the gdm user was not a member of the video
group.  Thank you!

I have verified the attached patch makes it sufficient to run
`modprobe uvesafb v86d=$(guix build v86d | head -n1)/sbin/v86d
mode_option=1280x800-32` before `herd restart xorg-server` without any
additional chmod.  I will push if nobody objects.

I do however need to remove xf86-video-vesa via
set-xorg-configuration.  Perhaps xf86-video-vesa should not be among
the defaults if uvesafb is to be made a default.  Note that when not
running X as root, xf86-video-vesa does not work anyway.  That’s what
uvesafb is for.

If uvesafb should be made a default, v86d:testvbe could be used to
find a suitable resolution as a mode_option parameter.

However I still do not know how best to modprobe uvesafb
automatically.

Regards,
Florian

[-- Attachment #2: 0001-services-gdm-Add-gdm-user-to-video-supplementary-gro.patch --]
[-- Type: text/plain, Size: 888 bytes --]

From 419ec6f3866d223b88f195466d3e731090240a2a Mon Sep 17 00:00:00 2001
From: Florian Pelz <pelzflorian@pelzflorian.de>
Date: Thu, 26 Mar 2020 15:19:21 +0100
Subject: [PATCH] services: gdm: Add gdm user to 'video' supplementary group.

See <https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00351.html>.

* gnu/services/xorg.scm (%gdm-accounts): Set supplementary groups.
---
 gnu/services/xorg.scm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 09379d40c3..d0196a299e 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -798,6 +798,7 @@ the GNOME desktop environment.")
         (user-account
          (name "gdm")
          (group "gdm")
+         (supplementary-groups '("video"))
          (system? #t)
          (comment "GNOME Display Manager user")
          (home-directory "/var/lib/gdm")
-- 
2.25.1

Re: kmscon not working on MacBook

[pelzflorian (Florian Pelz)]

On Thu, Mar 26, 2020 at 05:53:11PM +0100, pelzflorian (Florian Pelz) wrote:
> On Thu, Mar 26, 2020 at 03:26:05AM +0100, Bengt Richter wrote:
> > Are you a member of the video group?
> 
> Indeed the issue was that the gdm user was not a member of the video
> group.  […]  I will push if nobody objects.

I pushed my change adding gdm to the video group in Guix.  I do not
think there is a downside.

Regards,
Florian

Gnome takes more than 5 minutes to start

[Ricardo Wurmus]

jbranso@dismail.de writes:

> I first tested Gnome.  Gnome took a long time to fully load.  I had a
> mouse that could move around for 5+ minutes with no background image
> before the "Welcome to Gnome" screen popped up.

This sounds unusual.  Can you reliably reproduce this behaviour?  Does
this only happen the first time you start Gnome or also on subsequent
logins?

--
Ricardo

Btrfs/udev issue

[Ludovic Courtès]

jbranso@dismail.de skribis:

> Manual install worked.  I had a weird issue when I made the btrfs filesystems.  "mkfs.btrfs -L my-root /dev/sd3" gave me an error like "failed to execute /gnu/store/eudev/santsnthsnthau32psu/lib/udev ID_BTRFS_READY=0", and it repeated on every boot.   The error message on each bot looked like:
>
> udevd failed to execute /gnu/store/eudev/santsnthsnthau32psu/lib/udev ID_BTRFS_READY=0

Good news!  This issue is now fixed:

  https://git.savannah.gnu.org/cgit/guix.git/commit/?id=24a4a635fd76a91463c75cfe615929ec482cc2f6

I don’t think it was critical, though.

Ludo’.

Re: Plan for a release!

[jbranso]

Well I re-installed guix again just now, so that I could test Xfce and MATE. (1) Since I knew that
gnome worked just fine, I decided not to include the gnome service in my config. I also decided not
to include the enlightenment environment.

tl;dr  Xfce worked fine, and MATE failed to launch any applications.

The first oddity, was GDM. It worked just smoothly, but the default drop down shows that by default
I am going to boot into Gnome. I don't even have the gnome service in the config. That's a bit odd.

Xfce worked just fine. It took about 15+ seconds for the desktop background to appear, but it
appears to be running smoothly. However, there does not appear to be a browser installed by
default. Clicking on the browser icon gives me a pop up message "Choose Preferred Application". The 
drop down does not list any programs. I manually installed icecat. Perhaps the manual should mention 
that we have not packaged firefox. Instead we have icecat. Also, I used to have problems with my mouse 
only moving up and down in guix when I use an apple laptop. This appears to be resolved. Nice work guys!

After Icecat was installed, clicking on the browser button allowed me to choose icecat as my default browser, and I was able to browse the internet just fine.  I logged out of Xfce.

Mate started just fine.  I did get a pop-up message 

"Authenticate".

Authentication is needed to run mat-power-backlight-helper.  I put in my password, and the dialog went away.  I did not seem to be able to launch icecat with the Application menu.  The Icecat logo was in the applications menu, but a popup said "Could not launch GNU Icecat Web Browser".  The error message is "Failed to execute child process "gio-launch-deskop" (No such file or directory).  I also could not launch mate terminal for the same reason.  Actually very few applications could launch.  I could get the file browser (thunar?) to open, but not much else.  Since MATE did not seem to work so well, I logged out.

Thanks,

Joshua

1. I wish I knew how I could have reconfigured my laptop instead of reinstalling everything. I
tried this.

chroot /mnt;
guix system reconfigure /mnt/etc/config.scm;

I got an error that said that guix could not access the build daemon inside the chroot. I wasn't
sure how to fix that.

Re: Plan for a release!

[sirgazil]

Hi Joshua,


 ---- On Thu, 05 Mar 2020 08:42:29 -0500  <jbranso@dismail.de> wrote ----
 > Well I re-installed guix again just now, so that I could test Xfce and MATE. (1) Since I knew that
 > gnome worked just fine, I decided not to include the gnome service in my config. I also decided not
 > to include the enlightenment environment.
 > 
 > tl;dr  Xfce worked fine, and MATE failed to launch any applications.
 > 
 > The first oddity, was GDM. It worked just smoothly, but the default drop down shows that by default
 > I am going to boot into Gnome. I don't even have the gnome service in the config. That's a bit odd.

This is a known issue (see https://issues.guix.gnu.org/issue/37831).


 > Mate started just fine.  I did get a pop-up message 
 > 
 > "Authenticate".
 > 
 > Authentication is needed to run mat-power-backlight-helper.  I put in my password, and the dialog went away.  I did not seem to be able to launch icecat with the Application menu.  The Icecat logo was in the applications menu, but a popup said "Could not launch GNU Icecat Web Browser".  The error message is "Failed to execute child process "gio-launch-deskop" (No such file or directory).  I also could not launch mate terminal for the same reason.  Actually very few applications could launch.  I could get the file browser (thunar?) to open, but not much else.  Since MATE did not seem to work so well, I logged out.

I got a different pop-up message on my first MATE session, but I haven't had the time to report it (see https://multimedialib.files.wordpress.com/2020/03/mate-error-applet-2020-02-28.png). The message did not appear again after logging out and back in.

I'm not sure, but the problem of launching applications from application menus  may be related to the issue of launching applications when double-clicking files in file managers (Thunar, Caja, etc.) when there is more than one Desktop Environment or Window Manager available. Could you please check https://issues.guix.gnu.org/issue/39843 and see if you get the same behavior? If so, it would be helpful if you could report your experience in that bug report as well.


 > Joshua
 > 
 > 1. I wish I knew how I could have reconfigured my laptop instead of reinstalling everything. I
 > tried this.
 > 
 > chroot /mnt;
 > guix system reconfigure /mnt/etc/config.scm;

I may be missing something from previous messages to the list, but to reconfigure the Guix System you can copy the system configuration file in "/etc/config.scm" save it wherever you want, modify it to your liking (e.g. adding or removing more packages or services), and then

$ guix pull
$ sudo guix system reconfigure /path/to/your/config.scm

Re: Plan for a release!

[Joshua Branson]

sirgazil <sirgazil@zoho.com> writes:

>
> I'm not sure, but the problem of launching applications from
> application menus may be related to the issue of launching
> applications when double-clicking files in file managers (Thunar,
> Caja, etc.) when there is more than one Desktop Environment or Window
> Manager available. Could you please check
> https://issues.guix.gnu.org/issue/39843 and see if you get the same
> behavior? If so, it would be helpful if you could report your
> experience in that bug report as well.

Sure.  I'll add it to my schedule.

>
>  > Joshua
>  > 
>  > 1. I wish I knew how I could have reconfigured my laptop instead of reinstalling everything. I
>  > tried this.
>  > 
>  > chroot /mnt;
>  > guix system reconfigure /mnt/etc/config.scm;
>
> I may be missing something from previous messages to the list, but to
> reconfigure the Guix System you can copy the system configuration file
> in "/etc/config.scm" save it wherever you want, modify it to your
> liking (e.g. adding or removing more packages or services), and then
>
> $ guix pull
> $ sudo guix system reconfigure /path/to/your/config.scm
>

My problem was that I could not do a guix pull, because I could not boot
into the laptop.  Grub would load, and display Guix System boot option,
but after that it would show a blank screen.  Essentially how do you fix
a laptop that will not boot guix, via a guix usb install image? 

-- 
Joshua Branson
Sent from Emacs and Gnus

Re: Plan for a release!

[Jan]

On Thu, 05 Mar 2020 13:42:29 +0000
jbranso@dismail.de wrote:

> tl;dr  Xfce worked fine, and MATE failed to launch any applications.
> 

Hello everyone,

actually Xfce has been broken for several months already, was too lazy
to report the issue and another one got 0 replies.

The first issue:
When right clicking at a file in Thunar and running "open with", an
error window appears telling it couldn't run "gio-launch-desktop" child
process, because it couldn't find such a file or directory.

The second issue:
When trying to run an application using xfce panel, it throws an error
"Couldn't run /gnu/store/<hash>-exo-0.12.6/bin/exo-open --launch
TerminalEmulator" It can't find the file/directory.

Hope this helps.


Jan Wielkiewicz

Re: Plan for a release!

[Joshua Branson]

Jan <tona_kosmicznego_smiecia@interia.pl> writes:

> On Thu, 05 Mar 2020 13:42:29 +0000
> jbranso@dismail.de wrote:
>
>> tl;dr  Xfce worked fine, and MATE failed to launch any applications.
>> 
>
> Hello everyone,
>
> actually Xfce has been broken for several months already, was too lazy
> to report the issue and another one got 0 replies.

Oh really?  I had no issue with Xfce.

>
> The first issue:
> When right clicking at a file in Thunar and running "open with", an
> error window appears telling it couldn't run "gio-launch-desktop" child
> process, because it couldn't find such a file or directory.
>
> The second issue:
> When trying to run an application using xfce panel, it throws an error
> "Couldn't run /gnu/store/<hash>-exo-0.12.6/bin/exo-open --launch
> TerminalEmulator" It can't find the file/directory.
>
> Hope this helps.
>
> Jan Wielkiewicz

-- 
Joshua Branson
Sent from Emacs and Gnus

Thunar cannot launch gio-launch-desktop

[Ricardo Wurmus]

Jan <tona_kosmicznego_smiecia@interia.pl> writes:

> The first issue:
> When right clicking at a file in Thunar and running "open with", an
> error window appears telling it couldn't run "gio-launch-desktop" child
> process, because it couldn't find such a file or directory.

Maybe Thunar needs to be wrapped with glib:bin, which provides
gio-launch-desktop.  Would you like to give this a try?

--
Ricardo

Re: Thunar cannot launch gio-launch-desktop

[Jan]

On Fri, 06 Mar 2020 17:51:46 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> 
> Maybe Thunar needs to be wrapped with glib:bin, which provides
> gio-launch-desktop.  Would you like to give this a try?

The only thing that comes to my mind when someone says "wrapper" is
tortilla with chicken, but I can try tinkering with it.

> --
> Ricardo


Jan Wielkiewicz

Re: Thunar cannot launch gio-launch-desktop

[Ricardo Wurmus]

Jan <tona_kosmicznego_smiecia@interia.pl> writes:

> On Fri, 06 Mar 2020 17:51:46 +0100
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>>
>> Maybe Thunar needs to be wrapped with glib:bin, which provides
>> gio-launch-desktop.  Would you like to give this a try?
>
> The only thing that comes to my mind when someone says "wrapper" is
> tortilla with chicken, but I can try tinkering with it.

In many packages we use “wrap-program” (and in a few we use
“wrap-script”) to create a shell script that sets environment variables
and then calls the actual program.

The Thunar executable could perhaps be wrapped with a shell script that
first sets the PATH environment variable to a value that includes the
“bin” directory of the “glib” package’s “bin” output.  The result is
that Thunar will be able to find gio-launch-desktop in the PATH.

--
Ricardo

Re: Thunar cannot launch gio-launch-desktop

[Jan]

On Fri, 06 Mar 2020 22:51:36 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> In many packages we use “wrap-program” (and in a few we use
> “wrap-script”) to create a shell script that sets environment
> variables and then calls the actual program.
> 
> The Thunar executable could perhaps be wrapped with a shell script
> that first sets the PATH environment variable to a value that
> includes the “bin” directory of the “glib” package’s “bin” output.
> The result is that Thunar will be able to find gio-launch-desktop in
> the PATH.
> 
> --
> Ricardo

Okay, I should be able to do this then. I guess there are many
examples, so this should be easy. 
Just give me a day, because it's night here now.


Jan Wielkiewicz

Re: Thunar cannot launch gio-launch-desktop

[Jan]

I managed to fix it by adding glib:bin to propagated inputs and
wrapping by adding gio-launch-desktop to PATH.
Is using PATH correct way of doing so?
If yes, should I send the patch to the patch mailing list?


Jan Wielkiewicz

Re: Thunar cannot launch gio-launch-desktop

[Ricardo Wurmus]

Jan <tona_kosmicznego_smiecia@interia.pl> writes:

> I managed to fix it by adding glib:bin to propagated inputs and
> wrapping by adding gio-launch-desktop to PATH.
> Is using PATH correct way of doing so?

You should only need one of these two things:

1. propagate glib:bin
2. wrap Thunar with PATH including gio-launch-desktop.

> If yes, should I send the patch to the patch mailing list?

Yes, then we can discuss it.  Thanks!

-- 
Ricardo

Re: Thunar cannot launch gio-launch-desktop

[Jan]

On Sun, 08 Mar 2020 10:08:03 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> You should only need one of these two things:
> 
> 1. propagate glib:bin
> 2. wrap Thunar with PATH including gio-launch-desktop.
> 
> > If yes, should I send the patch to the patch mailing list?  
> 
> Yes, then we can discuss it.  Thanks!
> 

I used just "inputs" instead of "propagated-inputs" and it works as
well. I guess I'll just send the patch now.


Jan Wielkiewicz

Re: Thunar cannot launch gio-launch-desktop

[Jan]

I sent the patch, the issue number is 39989.


Jan Wielkiewicz

Re: Thunar cannot launch gio-launch-desktop

[Jan]

Hello,

it seems the issue is not Thunar-specific as Diego pointed out 
https://lists.gnu.org/archive/html/guix-patches/2020-03/msg00291.html
I'm closing the issue then.
Cool wrapper exercise though :)


Jan Wielkiewicz

Re: Plan for a release!

[pelzflorian (Florian Pelz)]

On Thu, Mar 05, 2020 at 01:42:29PM +0000, jbranso@dismail.de wrote:
> Also, I used to have problems with my mouse 
> only moving up and down in guix when I use an apple laptop. This appears to be resolved. Nice work guys!

Sorry to say it is not resolved, mouse issues just happen much more
rarely for me (for some reason).

This is still-open bug <https://bugs.gnu.org/35574>.

Regards,
Florian

Re: Plan for a release!

[John Soo]

Hi Guix,

In addition I think issue #38544 (gparted segfaults) should be addressed before a release.  I would imagine that partitioning is an activity that happens a lot around new installs.

- John

Re: Plan for a release!

[Ricardo Wurmus]

jbranso@dismail.de writes:

> 1. I wish I knew how I could have reconfigured my laptop instead of reinstalling everything. I
> tried this.
>
> chroot /mnt;
> guix system reconfigure /mnt/etc/config.scm;
>
> I got an error that said that guix could not access the build daemon inside the chroot. I wasn't
> sure how to fix that.

Why chroot into /mnt?  You can just “guix system reconfigure
/my/config.scm” as root.

-- 
Ricardo

Re: Plan for a release!

[Ludovic Courtès]

Hey Joshua,

Thanks for the detailed testing reports, very valuable!

Do you think you could email remaining issues that are not already at
<https://issues.guix.gnu.org> to bug-guix@gnu.org?

To make sure we get sizable bites, please describe only one specific
issue in each report.  For graphical issues, you can attach screenshots.

(I’m sorry to ask for extra work, if we have a bug squashing week,
that’ll certainly make it easier to get things done.  :-))

Thanks,
Ludo’.

Re: Plan for a release!

[Ludovic Courtès]

Hi!

Ludovic Courtès <ludo@gnu.org> skribis:

> I’m going on vacation for a bit, but I think we should finally get that
> release out!  Here’s the list of things to do I have in mind:
>
>   • We need Guile 3.0.1 to fix ‘guix pull’ etc. on AArch64 and possibly
>     JIT on ARMv7:
>
>       https://issues.guix.gnu.org/issue/39266
>       https://issues.guix.gnu.org/issue/39208

Done!  Our current ‘guile-next’ package works fine, with JIT, on all 4
platforms.

(That also means we could switch to Guile 3.0 on core-updates.)

>   • More testing of the guided installer and related issues:
>
>      https://issues.guix.gnu.org/issue/39729
>      https://issues.guix.gnu.org/issue/39712
>
>   • Fix the weird default font in GNOME Terminal, as sirgazil reported
>     on help-guix.
>
>   • Ensure that the desktop environments provided by the installer
>     actually work (GNOME, Xfce, MATE, etc.).  It’d be great to have
>     automated tests for these!
>
>   • (Optionally) have an automated test that installs the binary tarball
>     on Debian or similar.
>
>   • Address as many of the bugs marked “important” or “serious” as
>     possible.  Should we organize a bug-squashing week?  :-)
>
>   • We already have “make assert-binaries-available”, but at the Guix
>     Days we came up with the idea of having ‘guix weather
>     --release-critical’ or similar, which would ensure that all the
>     relevant jobs pass (packages, cross-builds, system tests, etc.).
>     I’ll see if I can do something in that area.

I’m working on this last item.

We still have to make progress on the other issues though.

Should make next week (or next week-end?) a bug-squashing party where
we’d all join as time permits?  How does that sound?

Thanks,
Ludo’.

Re: Plan for a release!

[Ludovic Courtès]

Hi there!

Ludovic Courtès <ludo@gnu.org> skribis:

[...]

> (That also means we could switch to Guile 3.0 on core-updates.)

Done!  :-)

>>   • More testing of the guided installer and related issues:
>>
>>      https://issues.guix.gnu.org/issue/39729
>>      https://issues.guix.gnu.org/issue/39712

Done, but it’d be nice to add more test of the installer!

>>   • Fix the weird default font in GNOME Terminal, as sirgazil reported
>>     on help-guix.
>>
>>   • Ensure that the desktop environments provided by the installer
>>     actually work (GNOME, Xfce, MATE, etc.).  It’d be great to have
>>     automated tests for these!
>>
>>   • (Optionally) have an automated test that installs the binary tarball
>>     on Debian or similar.

Not much progress on these fronts.

>>   • Address as many of the bugs marked “important” or “serious” as
>>     possible.  Should we organize a bug-squashing week?  :-)

We should really do that!

You can view them here:

  https://issues.guix.gnu.org/search?query=is%3Aserious+is%3Aopen
  https://issues.guix.gnu.org/search?query=is%3Aimportant+is%3Aopen

There’s quite some bug triage to be done, in fact (some are probably
already fixed.)  Let’s synchronize on IRC!

>>   • We already have “make assert-binaries-available”, but at the Guix
>>     Days we came up with the idea of having ‘guix weather
>>     --release-critical’ or similar, which would ensure that all the
>>     relevant jobs pass (packages, cross-builds, system tests, etc.).
>>     I’ll see if I can do something in that area.

Now we can do:

--8<---------------cut here---------------start------------->8---
ludo@ribbon ~/src/guix$ ./pre-inst-env guix weather -m etc/release-manifest.scm
guix weather: warning: ambiguous package specification `guile@2.2'
guix weather: warning: choosing guile@2.2.7 from gnu/packages/guile.scm:256:2
computing 265 package derivations for x86_64-linux...
looking for 411 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  78.3% substitutes available (322 out of 411)
  at least 1,287.5 MiB of nars (compressed)
  2,720.0 MiB on disk (uncompressed)
  0.004 seconds per request (1.6 seconds in total)
  250.9 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

This one is telling us that we have substitutes for 78% of the
“release-critical” packages, for all architectures.

There are build failures to look at (e.g., vim on armhf-linux).  You can
run ‘guix weather’ with ‘--display-missing’ to view the list of failing
items, and then you can try building them with, say:

  guix build $(guix gc --derivers /gnu/store/…-thing-that-fails)

Help welcome!

Then, system tests:

--8<---------------cut here---------------start------------->8---
ludo@ribbon ~/src/guix$ ./pre-inst-env guix weather -m etc/system-tests.scm
random seed for tests: 1584533532
Selected 63 system tests...
computing 63 package derivations for x86_64-linux...
[############################                                                                                      ]Computing Guix derivation for 'x86_64-linux'... /
[###############################################################                                                   ]hint: gnu/tests/monitoring.scm:312:19: zabbix-front-end-configuration: Consider using `db-secret-file' instead of
`db-password' for better security.

looking for 63 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  68.3% substitutes available (43 out of 63)
  at least 0.1 MiB of nars (compressed)
  2.4 MiB on disk (uncompressed)
  0.007 seconds per request (0.5 seconds in total)
  135.1 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
ludo@ribbon ~/src/guix$ ./pre-inst-env guix weather -m etc/system-tests.scm -s i686-linux
random seed for tests: 1584533661
Selected 63 system tests...
computing 63 package derivations for i686-linux...
[############################                                                                                      ]Computing Guix derivation for 'x86_64-linux'... /
[#################################################################                                                 ]hint: gnu/tests/monitoring.scm:312:19: zabbix-front-end-configuration: Consider using `db-secret-file' instead of
`db-password' for better security.

looking for 63 store items on https://ci.guix.gnu.org...
https://ci.guix.gnu.org
  68.3% substitutes available (43 out of 63)
  at least 0.1 MiB of nars (compressed)
  2.4 MiB on disk (uncompressed)
  0.000 seconds per request (0.0 seconds in total)
  3,379.3 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
--8<---------------cut here---------------end--------------->8---

This suggests that there are (presumably) a bunch of system tests
failing.  Again, we can pass ‘--display-missing’ to see which ones.
I fixed a few tests recently.

If you’re confined at home anyway, that gives you plenty of ways to help
out!  :-)

How ’bout targeting a release next week?

Ludo’.

Re: Plan for a release!

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

>>>   • Address as many of the bugs marked “important” or “serious” as
>>>     possible.  Should we organize a bug-squashing week?  :-)
>
> We should really do that!
>
> You can view them here:
>
>   https://issues.guix.gnu.org/search?query=is%3Aserious+is%3Aopen
>   https://issues.guix.gnu.org/search?query=is%3Aimportant+is%3Aopen

Here are the correct URLs:

    https://issues.guix.gnu.org/search?query=severity%3Aserious+is%3Aopen
    https://issues.guix.gnu.org/search?query=severity%3Aimportant+is%3Aopen

(I should add more information to the search field to make this more obvious.)

--
Ricardo

Re: Plan for a release!

[Mathieu Othacehe]

Hey!

>>>   • More testing of the guided installer and related issues:
>>>
>>>      https://issues.guix.gnu.org/issue/39729
>>>      https://issues.guix.gnu.org/issue/39712
>
> Done, but it’d be nice to add more test of the installer!

I can help on that. Maybe adding:

* More partitioning patterns
* More DE & services

> How ’bout targeting a release next week?

Sounds great :)

Mathieu

Re: Plan for a release!

[Mathieu Othacehe]

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


Hey,

>> Done, but it’d be nice to add more test of the installer!
>
> I can help on that. Maybe adding:
>
> * More partitioning patterns
> * More DE & services

Turns out, when selecting GNOME in choose-services call of (gnu tests
install), it triggers downloads during "guix system init ..." call.

I guess it's normal because the installer image does not contain those
packages. However, as there's no connection, it fails.

Not sure, we can go further?

In the meantime, here's a patch that helps dealing with installation
failures.

Thanks,

Mathieu

[-- Attachment #2: 0001-tests-install-Abort-when-one-installation-step-fails.patch --]
[-- Type: text/x-diff, Size: 7730 bytes --]

From 11193c030fa64cc3e2f6505062b7aa4fa9b2a2f4 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe <m.othacehe@gmail.com>
Date: Fri, 20 Mar 2020 11:36:33 +0100
Subject: [PATCH] tests: install: Abort when one installation step fails.

When marionette-eval calls fail in gui-test-program, the installation
continues which results in two scenarios:

- hang forever at the next marionette-eval call,

- keep going and start a broken installation, which is annoying because it
clears the terminal and hides the error.

Make sure that gui-test-program is exited with #f return code when one of the
marionette-eval calls fail.

* gnu/tests/install.scm (gui-test-program): Add a new macro
"marionette-eval*". Use it to abort to prompt 'gui-test and return #f when one
on the marionette-eval calls fail.
---
 gnu/tests/install.scm | 139 ++++++++++++++++++++++++------------------
 1 file changed, 78 insertions(+), 61 deletions(-)

diff --git a/gnu/tests/install.scm b/gnu/tests/install.scm
index 4f650ffb34..4453b15e89 100644
--- a/gnu/tests/install.scm
+++ b/gnu/tests/install.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2016, 2017, 2018, 2019, 2020 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2020 Mathieu Othacehe <m.othacehe@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -946,70 +947,86 @@ build (current-guix) and then store a couple of full system images.")
         (marionette-control (string-append "screendump " file)
                             #$marionette))
 
+      (define-syntax-rule (marionette-eval* exp marionette)
+        (unless (marionette-eval exp marionette)
+          (abort-to-prompt 'gui-test)))
+
       (setvbuf (current-output-port) 'none)
       (setvbuf (current-error-port) 'none)
 
-      (marionette-eval '(use-modules (gnu installer tests))
-                       #$marionette)
-
-      ;; Arrange so that 'converse' prints debugging output to the console.
-      (marionette-eval '(let ((console (open-output-file "/dev/console")))
-                          (setvbuf console 'none)
-                          (conversation-log-port console))
-                       #$marionette)
-
-      ;; Tell the installer to not wait for the Connman "online" status.
-      (marionette-eval '(call-with-output-file "/tmp/installer-assume-online"
-                          (const #t))
-                       #$marionette)
-
-      ;; Run 'guix system init' with '--no-grafts', to cope with the lack of
-      ;; network access.
-      (marionette-eval '(call-with-output-file
-                            "/tmp/installer-system-init-options"
-                          (lambda (port)
-                            (write '("--no-grafts" "--no-substitutes")
-                                   port)))
-                       #$marionette)
-
-      (marionette-eval '(define installer-socket
-                          (open-installer-socket))
-                       #$marionette)
-      (screenshot "installer-start.ppm")
-
-      (marionette-eval '(choose-locale+keyboard installer-socket)
-                       #$marionette)
-      (screenshot "installer-locale.ppm")
-
-      ;; Choose the host name that the "basic" test expects.
-      (marionette-eval '(enter-host-name+passwords installer-socket
-                                                   #:host-name "liberigilo"
-                                                   #:root-password
-                                                   #$%root-password
-                                                   #:users
-                                                   '(("alice" "pass1")
-                                                     ("bob" "pass2")))
-                       #$marionette)
-      (screenshot "installer-services.ppm")
-
-      (marionette-eval '(choose-services installer-socket
-                                         #:desktop-environments '()
-                                         #:choose-network-service?
-                                         (const #f))
-                       #$marionette)
-      (screenshot "installer-partitioning.ppm")
-
-      (marionette-eval '(choose-partitioning installer-socket
-                                             #:encrypted? #$encrypted?
-                                             #:passphrase #$%luks-passphrase)
-                       #$marionette)
-      (screenshot "installer-run.ppm")
-
-      (marionette-eval '(conclude-installation installer-socket)
-                       #$marionette)
-
-      (sync)
-      #t))
+      (call-with-prompt 'gui-test
+        (lambda ()
+          (marionette-eval* '(use-modules (gnu installer tests))
+                           #$marionette)
+
+          ;; Arrange so that 'converse' prints debugging output to the
+          ;; console.
+          (marionette-eval*
+           '(let ((console (open-output-file "/dev/console")))
+              (setvbuf console 'none)
+              (conversation-log-port console))
+           #$marionette)
+
+          ;; Tell the installer to not wait for the Connman "online" status.
+          (marionette-eval*
+           '(call-with-output-file "/tmp/installer-assume-online"
+              (const #t))
+           #$marionette)
+
+          ;; Run 'guix system init' with '--no-grafts', to cope with the lack
+          ;; of network access.
+          (marionette-eval*
+           '(call-with-output-file
+                "/tmp/installer-system-init-options"
+              (lambda (port)
+                (write '("--no-grafts" "--no-substitutes")
+                       port)))
+           #$marionette)
+
+          (marionette-eval* '(define installer-socket
+                              (open-installer-socket))
+                           #$marionette)
+          (screenshot "installer-start.ppm")
+
+          (marionette-eval* '(choose-locale+keyboard installer-socket)
+                           #$marionette)
+          (screenshot "installer-locale.ppm")
+
+          ;; Choose the host name that the "basic" test expects.
+          (marionette-eval*
+           '(enter-host-name+passwords installer-socket
+                                       #:host-name "liberigilo"
+                                       #:root-password
+                                       #$%root-password
+                                       #:users
+                                       '(("alice" "pass1")
+                                         ("bob" "pass2")))
+           #$marionette)
+          (screenshot "installer-services.ppm")
+
+          (marionette-eval*
+           '(choose-services installer-socket
+                             #:desktop-environments
+                             '("GNOME")
+                             #:choose-network-service?
+                             (const #f))
+           #$marionette)
+          (screenshot "installer-partitioning.ppm")
+
+          (marionette-eval*
+           '(choose-partitioning installer-socket
+                                 #:encrypted? #$encrypted?
+                                 #:passphrase #$%luks-passphrase)
+           #$marionette)
+          (screenshot "installer-run.ppm")
+
+          (marionette-eval* '(conclude-installation installer-socket)
+            #$marionette)
+
+          (sync)
+          #t)
+        (lambda _
+          #f))))
 
 (define %extra-packages
   ;; Packages needed when installing with an encrypted root.
-- 
2.25.1

Re: Plan for a release!

[Gábor Boskovits]

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

Hello,

Mathieu Othacehe <m.othacehe@gmail.com> ezt írta (időpont: 2020. márc. 20.,
Pén 11:52):

>
> Hey,
>
> >> Done, but it’d be nice to add more test of the installer!
> >
> > I can help on that. Maybe adding:
> >
> > * More partitioning patterns
> > * More DE & services
>
> Turns out, when selecting GNOME in choose-services call of (gnu tests
> install), it triggers downloads during "guix system init ..." call.
>
> I guess it's normal because the installer image does not contain those
> packages. However, as there's no connection, it fails.
>
> Not sure, we can go further?
>

I believe what could be done is to create and extended installer image with
the packages need for testing available.
It could work similarly to how the barebones closure is included right now.
These images would be quite big, and impractical for anything but testing.
I believe that having a simple very big image is better than having
separate smaller ones for testing. This would also allow us to create a
selection of images with different de/service options for direct download
if the need arises, by expanding the list of configuration templates, and
the test image can be simply created by including the closure of all the
template configs. Wdyt?

>
> In the meantime, here's a patch that helps dealing with installation
> failures.
>
> Thanks,
>
> Mathieu
>
Best regards,
g_bor

>

[-- Attachment #2: Type: text/html, Size: 2222 bytes --]

Re: Plan for a release!

[Mathieu Othacehe]

Hello Gábor,

> I believe what could be done is to create and extended installer image with
> the packages need for testing available.
> It could work similarly to how the barebones closure is included right now.
> These images would be quite big, and impractical for anything but testing.
> I believe that having a simple very big image is better than having
> separate smaller ones for testing. This would also allow us to create a
> selection of images with different de/service options for direct download
> if the need arises, by expanding the list of configuration templates, and
> the test image can be simply created by including the closure of all the
> template configs. Wdyt?

Seems fair, that would be a very big image (10GiB only for GNOME), and
it gets duplicated when running installation tests. Better have some
free space :p

In my case, it would mean adding all DE/services to os definition in
"guided-installation-test" I guess.

Ludo, WDYT?

Thanks,

Mathieu

Re: Plan for a release!

[Ludovic Courtès]

Hi Mathieu!

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>>> Done, but it’d be nice to add more test of the installer!
>>
>> I can help on that. Maybe adding:
>>
>> * More partitioning patterns
>> * More DE & services
>
> Turns out, when selecting GNOME in choose-services call of (gnu tests
> install), it triggers downloads during "guix system init ..." call.
>
> I guess it's normal because the installer image does not contain those
> packages. However, as there's no connection, it fails.
>
> Not sure, we can go further?

Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a
variant thereof) include all the services/packages needed for the target
config.

In the manual installation tests we use ‘define-os-with-source’ to both
embed the target OS and its references in the installation image *and*
have the source of the target OS available in /etc/target-config.scm in
the installation image.

The 2nd step is not relevant here, but the first step remains necessary.

> From 11193c030fa64cc3e2f6505062b7aa4fa9b2a2f4 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe <m.othacehe@gmail.com>
> Date: Fri, 20 Mar 2020 11:36:33 +0100
> Subject: [PATCH] tests: install: Abort when one installation step fails.
>
> When marionette-eval calls fail in gui-test-program, the installation
> continues which results in two scenarios:
>
> - hang forever at the next marionette-eval call,
>
> - keep going and start a broken installation, which is annoying because it
> clears the terminal and hides the error.
>
> Make sure that gui-test-program is exited with #f return code when one of the
> marionette-eval calls fail.
>
> * gnu/tests/install.scm (gui-test-program): Add a new macro
> "marionette-eval*". Use it to abort to prompt 'gui-test and return #f when one
> on the marionette-eval calls fail.

[...]

> +      (define-syntax-rule (marionette-eval* exp marionette)
> +        (unless (marionette-eval exp marionette)
> +          (abort-to-prompt 'gui-test)))

It’d be IMO clearer, although technically equivalent, to make it:

  (or (marionette-eval exp marionette)
      (throw 'marionette-eval-failure 'exp))

Perhaps you don’t even need to catch it.

Thanks for working on this!

Ludo’.

Re: Plan for a release!

[Mathieu Othacehe]

Hello,

> Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a
> variant thereof) include all the services/packages needed for the target
> config.
>
> In the manual installation tests we use ‘define-os-with-source’ to both
> embed the target OS and its references in the installation image *and*
> have the source of the target OS available in /etc/target-config.scm in
> the installation image.

Ok! I'm testing with an installation image containing all desktop
environments. This represents 1200 store items (image around 6GiB).

The disk-image creation takes 2h45 on a powerful machine (with
KVM). I've seen your insights on this topic here:

--8<---------------cut here---------------start------------->8---
>   I'd like to propose an alternative mechanism which would be faster and
>   not involving virtual machines. Maybe producing the disk-image in a
>   container?

Unfortunately, I don’t think that’s possible.  The reason we resort to
VMs is that the Linux kernel doesn’t allow you, for instance, to mount a
file system without being root.  So doing things like running Parted,
mounting a file system, and populating it typically requires root
privileges.  (In some cases, there are tools like mksquashfs that can do
that from user-space, but it’s very ad-hoc.)
--8<---------------cut here---------------end--------------->8---

It makes sense and after some digging, I cannot propose something
better (nix is using the same mechanism). However, I feel very
frustrated by this disk-image thing, loosing a lot of time and
computation time for some copies.

> It’d be IMO clearer, although technically equivalent, to make it:
>
>   (or (marionette-eval exp marionette)
>       (throw 'marionette-eval-failure 'exp))
>
> Perhaps you don’t even need to catch it.

You are right :) I pushed this patch throwing exception as suggested.

Thanks,

Mathieu

Re: Plan for a release!

[Ludovic Courtès]

Hi,

Mathieu Othacehe <m.othacehe@gmail.com> skribis:

>> Yes: you need to have ‘installation-os-for-gui-tests’ (or preferably a
>> variant thereof) include all the services/packages needed for the target
>> config.
>>
>> In the manual installation tests we use ‘define-os-with-source’ to both
>> embed the target OS and its references in the installation image *and*
>> have the source of the target OS available in /etc/target-config.scm in
>> the installation image.
>
> Ok! I'm testing with an installation image containing all desktop
> environments. This represents 1200 store items (image around 6GiB).
>
> The disk-image creation takes 2h45 on a powerful machine (with
> KVM). I've seen your insights on this topic here:
>
>>   I'd like to propose an alternative mechanism which would be faster and
>>   not involving virtual machines. Maybe producing the disk-image in a
>>   container?
>
> Unfortunately, I don’t think that’s possible.  The reason we resort to
> VMs is that the Linux kernel doesn’t allow you, for instance, to mount a
> file system without being root.  So doing things like running Parted,
> mounting a file system, and populating it typically requires root
> privileges.  (In some cases, there are tools like mksquashfs that can do
> that from user-space, but it’s very ad-hoc.)
>
> It makes sense and after some digging, I cannot propose something
> better (nix is using the same mechanism). However, I feel very
> frustrated by this disk-image thing, loosing a lot of time and
> computation time for some copies.

Understood.  :-/

Another approach would be to do like ‘guix system vm’, which is to share
the store with the host.  But then we would need a way to be able to run
a daemon in the guest and have its build results overlaid on top of the
host-provided store.

Note that system tests other than the installation tests actually use
the equivalent of ‘guix system vm’ already, so they copy much less stuff
around.

Thanks,
Ludo’.

Re: Plan for a release!

[Vincent Legoll]

On Thu, Mar 26, 2020 at 12:55 PM Ludovic Courtès <ludo@gnu.org> wrote:
> Another approach would be to do like ‘guix system vm’, which is to share
> the store with the host.  But then we would need a way to be able to run
> a daemon in the guest and have its build results overlaid on top of the
> host-provided store.

Couldn't `guix copy` be used here to get built items back onto the host
easily ?

-- 
Vincent Legoll

Re: Plan for a release!

[Ludovic Courtès]

Vincent Legoll <vincent.legoll@gmail.com> skribis:

> On Thu, Mar 26, 2020 at 12:55 PM Ludovic Courtès <ludo@gnu.org> wrote:
>> Another approach would be to do like ‘guix system vm’, which is to share
>> the store with the host.  But then we would need a way to be able to run
>> a daemon in the guest and have its build results overlaid on top of the
>> host-provided store.
>
> Couldn't `guix copy` be used here to get built items back onto the host
> easily ?

No, ‘guix copy’ is only for copies over SSH between full-features stores
(each one running a daemon).

Ludo’.