Re: Plan for a release!

[Ludovic Courtès]

Vincent Legoll  skribis:

> On Thu, Mar 26, 2020 at 12:55 PM Ludovic Courtès  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’.

Re: Plan for a release!

[Vincent Legoll]

On Thu, Mar 26, 2020 at 12:55 PM Ludovic Courtès  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]

Hi,

Mathieu Othacehe  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!

[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!

Mathieu Othacehe  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 
> 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 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!

[Gábor Boskovits]

Hello,

Mathieu Othacehe  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

>

Re: Plan for a release!

[Mathieu Othacehe]

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
>From 11193c030fa64cc3e2f6505062b7aa4fa9b2a2f4 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
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 
 ;;; Copyright © 2017, 2019 Tobias Geerinckx-Rice 
+;;; Copyright © 2020 Mathieu Othacehe 
 ;;;
 ;;; 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-eva

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!

[Ricardo Wurmus]

Ludovic Courtès  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!

[Ludovic Courtès]

Hi there!

Ludovic Courtès  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

Re: Plan for a release!

[Ludovic Courtès]

Hi!

Ludovic Courtès  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]

Hey Joshua,

Thanks for the detailed testing reports, very valuable!

Do you think you could email remaining issues that are not already at
 to bug-g...@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!

[Ricardo Wurmus]

jbra...@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!

[pelzflorian (Florian Pelz)]

On Thu, Mar 05, 2020 at 04:54:21AM +, jbra...@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

Re: Plan for a release!

[Joshua Branson]

Jan  writes:

> On Thu, 05 Mar 2020 13:42:29 +
> jbra...@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/-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

Re: Plan for a release!

[Joshua Branson]

sirgazil  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!

[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!

[pelzflorian (Florian Pelz)]

On Thu, Mar 05, 2020 at 01:42:29PM +, jbra...@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 .

Regards,
Florian

Re: Plan for a release!

[Jan]

On Thu, 05 Mar 2020 13:42:29 +
jbra...@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/-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!

[sirgazil]

Hi Joshua,


  On Thu, 05 Mar 2020 08:42:29 -0500   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!

[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!

[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!

[Joshua Branson]

Ludovic Courtès  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!

[Vincent Legoll]

Hello,

On Tue, Feb 25, 2020 at 3:00 PM Jonathan Brielmaier
 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!

[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!

[zimoun]

Hi Ludo,

On Mon, 24 Feb 2020 at 22:57, Ludovic Courtès  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!

[Vincent Legoll]

Hello,

On Mon, Feb 24, 2020 at 10:56 PM Ludovic Courtès  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

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’.