bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

2020-11-12 Thread Mathieu Othacehe


Hello Maxim,

> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
> (%default-options): Set its default value to #f.
> (show-help): Add help doc.
> * guix/scripts/system.scm (perform-action): Propagate option...
> (system-derivation-for-action): ...here.  Use it to set the volatile-root?
> field of the image object passed to SYSTEM-IMAGE.
> * doc/guix.texi (Invoking guix system): Document it.

This is a nice addition and it looks good to me.

Thanks,

Mathieu





bug#44353: [PATCH version-1.2.0 v2 1/3] image: Remove conflicting user-provided EFI file system.

2020-11-12 Thread Mathieu Othacehe


Hey Maxim,

> When the bootloader used is grub-efi-bootloader, an ESP partition and file
> system is already added by the image generator.  If a conflicting
> user-provided EFI file system is provided, it will (likely) cause the boot to
> fail, as happens for the lightweight-desktop.tmpl and desktop.tmpl templates
> under gnu/system/examples.

Nice one. I would just clarify in the commit message that the ESP
partition is added only when the selected image type is "raw".

Otherwise, it looks fine!

Thanks,

Mathieu





bug#44353: [PATCH version-1.2.0 v2 2/3] bootloader: grub: Skip install-grub-efi when producing a disk image.

2020-11-12 Thread Mathieu Othacehe


Hello Maxim,

> As introducing bootloader knowledge at the level of the image code is
> undesirable, every bootloader should be adapted to support this fall-back for
> their installation procedure (TODO).

Or maybe find a way to remove the need to call "bootloader-installer"
when producing a disk-image as we discussed on IRC.

Looks fine!

Thanks,

Mathieu





bug#44353: [PATCH version-1.2.0 v2 3/3] doc: Detail which bootloader get used with disk-image or vm-image.

2020-11-12 Thread Mathieu Othacehe


Hey,

> +@example
> +image=$(guix system disk-image --image-type=qcow2 \
> + gnu/system/examples/lightweight-desktop.tmpl)
> +cp $image /tmp/my-image.qcow2
> +chmod +rw /tmp/my-image.qcow2
> +qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000
> +   -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin
> +@end example

This looks good! Note that I plan to remove the "vm-image" command and
rename "disk-image" command to "image" once the 1.2.0 is out.

Thanks,

Mathieu





bug#44593: (guix git) doesn’t honor HTTP/HTTPS proxy settings for submodules

2020-11-12 Thread Ludovic Courtès
(guix git) does not honor proxy settings when fetching submodules.

In fact, Guile-Git 0.4.0 doesn’t allow us to pass fetch options to
‘submodule-update’, which is what needs to be fixed first.





bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

2020-11-12 Thread Maxim Cournoyer
Hello Mathieu,

Mathieu Othacehe  writes:

> Hello Maxim,
>
>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>> (%default-options): Set its default value to #f.
>> (show-help): Add help doc.
>> * guix/scripts/system.scm (perform-action): Propagate option...
>> (system-derivation-for-action): ...here.  Use it to set the volatile-root?
>> field of the image object passed to SYSTEM-IMAGE.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> This is a nice addition and it looks good to me.
>
> Thanks,
>
> Mathieu

One thing I wasn't sure was if it'd be better to implicitly derive
volatile-root? #f when image-type was specified (not (eq? 'guess)).  The
rationale being that users specifying the image-size themselves probably
want to make use of extra space (assumption) but can't unless
volatile-root? is #t on the image.

If we choose the above it'd lead to less code and one less switch; on
the other hand it is not as explicit.

What do you think?

Maxim





bug#35594: bug#36376: Application menu of desktop environment not automatically updated

2020-11-12 Thread Ludovic Courtès
Hi!

Ludovic Courtès  skribis:

> So I went further to test the initial GLib patch I posted in “real
> conditions”.

I did some more testing using a similar workflow: this time I repeatedly
changed the profile (installing/removing packages), which showed that
the first patch was buggy (it would only notice the creation of
~/.guix-profile and nothing beyond that).

This is in part due to the fact that ‘GFileMonitor’ follows symlinks (it
doesn’t pass the ‘IN_DONT_FOLLOW’ inotify flag).  Thus, when it monitors
~/.guix-profile, it’s really monitoring /gnu/store/…-profile, which
never changes.

So with this new patch it’s monitoring /var/guix/profiles/per-user/USER
and /var/guix/profiles instead, which correctly detects changes.  It
detects a bit “too much” (for instance, running ‘guix pull’ triggers the
inotify hook because it changes
/var/guix/profiles/per-user/USER/current-guix) but that’s probably OK.

If you’re using GNOME, Xfce, or another GLib-based desktop environment,
I’d welcome tests on the bare metal!  Just apply the patch on a checkout
of ‘master’ and run:

  sudo -E ./pre-inst-env guix system reconfigure …

If there are no objections, I’d like to apply this patch shortly so we
can go ahead with a last round of pre-release tests.

Ludo’.

>From 7d03b2b823951219ece46c7f34e25ae36a8ba12c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Thu, 12 Nov 2020 16:35:24 +0100
Subject: [PATCH] gnu: glib: Graft patch to detect changes to the installed
 applications.

Fixes .
Reported by sirgazil  and others.

* gnu/packages/patches/glib-appinfo-watch.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/glib.scm (glib)[replacement]: New field.
(glib-with-gio-patch): New variable.
(glib-with-documentation): Use 'package/inherit'.
---
 gnu/local.mk  |  1 +
 gnu/packages/glib.scm | 14 ++-
 gnu/packages/patches/glib-appinfo-watch.patch | 92 +++
 3 files changed, 105 insertions(+), 2 deletions(-)
 create mode 100644 gnu/packages/patches/glib-appinfo-watch.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index d5a13cbdbd..2301a04d2f 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1050,6 +1050,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/ghostscript-no-header-id.patch		\
   %D%/packages/patches/ghostscript-no-header-uuid.patch		\
   %D%/packages/patches/ghostscript-no-header-creationdate.patch \
+  %D%/packages/patches/glib-appinfo-watch.patch			\
   %D%/packages/patches/glib-tests-timer.patch			\
   %D%/packages/patches/glibc-CVE-2018-11236.patch		\
   %D%/packages/patches/glibc-CVE-2018-11237.patch		\
diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 901222476a..43523e516d 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -181,6 +181,7 @@ shared NFS home directories.")
   (package
(name "glib")
(version "2.62.6")
+   (replacement glib-with-gio-patch)
(source (origin
 (method url-fetch)
 (uri (string-append "mirror://gnome/sources/"
@@ -387,11 +388,20 @@ dynamic loading, and an object system.")
(home-page "https://developer.gnome.org/glib/";)
(license license:lgpl2.1+)))
 
+(define glib-with-gio-patch
+  ;; GLib with a fix for .
+  ;; TODO: Fold into 'glib' above in the next rebuild cycle.
+  (package
+(inherit glib)
+(source (origin
+  (inherit (package-source glib))
+  (patches (cons (search-patch "glib-appinfo-watch.patch")
+ (origin-patches (package-source glib
+
 (define-public glib-with-documentation
   ;; glib's doc must be built in a separate package since it requires gtk-doc,
   ;; which in turn depends on glib.
-  (package
-(inherit glib)
+  (package/inherit glib
 (properties (alist-delete 'hidden? (package-properties glib)))
 (outputs (cons "doc" (package-outputs glib))) ; 20 MiB of GTK-Doc reference
 (native-inputs
diff --git a/gnu/packages/patches/glib-appinfo-watch.patch b/gnu/packages/patches/glib-appinfo-watch.patch
new file mode 100644
index 00..638a5e0949
--- /dev/null
+++ b/gnu/packages/patches/glib-appinfo-watch.patch
@@ -0,0 +1,92 @@
+This patch lets GLib's GDesktopAppInfo API watch and notice changes
+to the Guix user and system profiles.  That way, the list of available
+applications shown by the desktop environment is immediately updated
+when the user runs "guix install", "guix remove", or "guix system
+reconfigure" (see ).
+
+It does so by monitoring /var/guix/profiles (for changes to the system
+profile) and /var/guix/profiles/per-user/USER (for changes to the user
+profile) and crawling their share/applications sub-directory when
+changes happen.
+
+diff --git a/gio/gdesktopappinfo.c b/gio/gdesktopappinfo.c
+index f1e2fdd..095c110 100644
+--- a/gio/gdesktopappinfo.c
 b/gio/gdesktopappinfo.c
+@@ -148,6 +148,7 @@

bug#44558: Mesa isn't update to date

2020-11-12 Thread Guillaume Le Vaillant

Tobias Geerinckx-Rice via Bug reports for GNU Guix  skribis:

> Romulasry, are you suffering from specific Mesa 20.0.7 problems that 20.2.2
> might fix?  Please let us know.  An otherwise working package not being at the
> latest upstream version isn't a bug.
>
> romulasry via Bug reports for GNU Guix 写道:
>> Mesa 20.2.2 is released
>
> The core-updates branch updates Mesa to 20.1.9.  Would you like to submit
> a (tested) core-updates patch updating it to 20.2.2?

Hi,

Mesa 20.2 brings direct OpenGL rendering support for Nvidia RTX 20xx
graphic cards with the nouveau driver, whereas with our current version
these cards have to use LLVMpipe.
I tested the update quickly on my local staging branch using glxgears
and vlc, and it worked fine. When reading a video the CPU usage dropped
from 30% to 2%, which is nice.


signature.asc
Description: PGP signature


bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

2020-11-12 Thread Mathieu Othacehe


Hello Maxim,

> One thing I wasn't sure was if it'd be better to implicitly derive
> volatile-root? #f when image-type was specified (not (eq? 'guess)).  The
> rationale being that users specifying the image-size themselves probably
> want to make use of extra space (assumption) but can't unless
> volatile-root? is #t on the image.
>
> If we choose the above it'd lead to less code and one less switch; on
> the other hand it is not as explicit.
>
> What do you think?

When developing the image API, I hesitated keeping the default of using
volatile root file systems by default.

In most cases, I think that the user may prefer to have non volatile
images. They already have to copy the image from the store and make it
writable so that QEMU can use it with "-hda" argument.

Switching the default to non volatile could be an option I think. Doing
what you are proposing: setting volatile to false when image-size is
passed could also be a first step.

Thanks,

Mathieu





bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

2020-11-12 Thread Ludovic Courtès
Hi,

Christopher Baines  skribis:

> I found this when trying to build guile3.0-gnutls:
>
>   guix time-machine --commit=94585fffb23079fe71110e2bf99782eb4ccfa12b -- 
> build --no-grafts --check guile3.0-gnutls
>   
>
> FAIL: status-request-revoked
> 
>
> trying NORMAL:-VERS-ALL:+VERS-TLS1.2
> received status request
> received status request
> cert_verify_callback:263: certificate verify status doesn't match: 100402 != 
> 22FAIL status-request-revoked (exit status: 1)

This was fixed upstream between 3.6.12 and 3.6.14 with this patch by
Bernhard (it’s a small world!):

--8<---cut here---start->8---
commit ed208fe55f31478732fd6cc394f9576b315a42cd
Author: Bernhard M. Wiedemann 
Date:   Sun Apr 5 15:09:57 2020 +0200

tests: Fix status-request-revoked after 2020-10-24

included certs expire 2020-10-24 so this test fails after that date.

Fixes #967

This patch was done while working on reproducible builds for openSUSE.

Signed-off-by: Bernhard M. Wiedemann 
--8<---cut here---end--->8---

The question for us becomes how to ensure long-term reproducibility in
the presence of such bugs.

In this case, I think the only solution would be to change the system
clock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, but
you end up with different derivations, which is not necessarily
desirable).

Thoughts?

Ludo’.





bug#44353: [PATCH version-1.2.0 v2 3/3] doc: Detail which bootloader get used with disk-image or vm-image.

2020-11-12 Thread Ludovic Courtès
Hi,

Mathieu Othacehe  skribis:

>> +@example
>> +image=$(guix system disk-image --image-type=qcow2 \
>> + gnu/system/examples/lightweight-desktop.tmpl)
>> +cp $image /tmp/my-image.qcow2
>> +chmod +rw /tmp/my-image.qcow2
>> +qemu-system-x86_64 -enable-kvm -hda /tmp/my-image.qcow2 -m 1000
>> +   -bios $(guix build ovmf)/share/firmware/ovmf_x64.bin
>> +@end example
>
> This looks good! Note that I plan to remove the "vm-image" command and
> rename "disk-image" command to "image" once the 1.2.0 is out.

However note that the manual should not be change on ‘version-1.2.0’ at
this point, “the strings are frozen”, they say.

Ludo’.





bug#44353: [PATCH version-1.2.0 v2] guix: system: Add a new '--non-volatile' option for disk-image.

2020-11-12 Thread Ludovic Courtès
Mathieu Othacehe  skribis:

>> * guix/scripts/system.scm (%options)[volatile-root?]: New boolean option.
>> (%default-options): Set its default value to #f.
>> (show-help): Add help doc.
>> * guix/scripts/system.scm (perform-action): Propagate option...
>> (system-derivation-for-action): ...here.  Use it to set the volatile-root?
>> field of the image object passed to SYSTEM-IMAGE.
>> * doc/guix.texi (Invoking guix system): Document it.
>
> This is a nice addition and it looks good to me.

Can we keep it for ‘master’ only, notably because of the “string
freeze”?

Ludo’.





bug#44559: gnutls 3.6.12 fails to build: FAIL: status-request-revoked

2020-11-12 Thread Marius Bakke
Ludovic Courtès  writes:

> The question for us becomes how to ensure long-term reproducibility in
> the presence of such bugs.
>
> In this case, I think the only solution would be to change the system
> clock when one rebuilds GnuTLS (or to use ‘--without-tests=gnutls’, but
> you end up with different derivations, which is not necessarily
> desirable).
>
> Thoughts?

There is a related bug report here:

  https://issues.guix.gnu.org/39310

Perhaps we could make a "--with-system-clock" option for 'guix build'
that instructs the daemon to fake the system time?


signature.asc
Description: PGP signature


bug#44558: Mesa isn't update to date

2020-11-12 Thread Marius Bakke
Guillaume Le Vaillant  writes:

> Tobias Geerinckx-Rice via Bug reports for GNU Guix  skribis:
>
>> Romulasry, are you suffering from specific Mesa 20.0.7 problems that 20.2.2
>> might fix?  Please let us know.  An otherwise working package not being at 
>> the
>> latest upstream version isn't a bug.
>>
>> romulasry via Bug reports for GNU Guix 写道:
>>> Mesa 20.2.2 is released
>>
>> The core-updates branch updates Mesa to 20.1.9.  Would you like to submit
>> a (tested) core-updates patch updating it to 20.2.2?
>
> Hi,
>
> Mesa 20.2 brings direct OpenGL rendering support for Nvidia RTX 20xx
> graphic cards with the nouveau driver, whereas with our current version
> these cards have to use LLVMpipe.
> I tested the update quickly on my local staging branch using glxgears
> and vlc, and it worked fine. When reading a video the CPU usage dropped
> from 30% to 2%, which is nice.

That is great news.

The current 'staging' branch is just about ready for merge[*], so a Mesa
update will have to wait until the next round.

However, I think libGL is fairly ABI-stable, so you may be able to
"graft" this version in the mean time, like in commit
fdd883509301845ddb4dc90e70e58b469afb5441.

[*] gst-plugins-good fails on armhf and i686, not sure what to do about
it yet: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/803


signature.asc
Description: PGP signature


bug#44606: Error with `guix-start-repl', No prompt found

2020-11-12 Thread Michael Pagan
Guix works just fine; however, the `emacs-guix' interface does not
connect to the REPL (it creates one, but won't connect to it).

When I enter `M-x guix', the Magit-like interface appears.  Pressing the
`c' key should bring me straight into the REPL, but it doesn't.

The first time I execute the command, I receive this error:
Debugger entered--Lisp error: (error "No Geiser REPL for this buffer (try M-x 
run-geiser...")
  (signal error ("No Geiser REPL for this buffer (try M-x run-geiser..."))
  (error "No Geiser REPL for this buffer (try M-x run-geiser...")
  (geiser-repl--connection)
  (geiser-eval--send/wait ",use (geiser emacs)\n'done")
  (geiser-guile--startup nil)
  (apply geiser-guile--startup nil)
  (geiser-impl--call-method repl-startup guile nil)
  (geiser-repl--startup guile nil)
  (guix-start-repl # nil)
  (guix-start-repl-maybe nil "Starting Guix REPL ..." nil)
  (guix-start-process-maybe)
  (guix-get-repl-buffer internal)
  (guix-eval-read "(help-string )")
  (guix-help-string nil)
  (guix-command-parse-arguments nil)
  (guix-command--all-arguments nil)
  (guix-command-all-arguments nil)
  (guix-command-generate-popup guix-command-popup nil)
  (guix-command nil)
  (funcall-interactively guix-command nil)
  (call-interactively guix-command)
  (magit-invoke-popup-action 99)
  (funcall-interactively magit-invoke-popup-action 99)
  (call-interactively magit-invoke-popup-action nil nil)
  (command-execute magit-invoke-popup-action)

The second time I execute the command, I receive this error:
Debugger entered--Lisp error: (error "No prompt found!")
  (signal error ("No prompt found!"))
  (error "%s" "No prompt found!")
  (geiser-repl--wait-for-prompt 1)
  (geiser-repl--start-scheme guile nil "\\([^@()]+@([^)]*?)> 
\\|[^@()]+@([^)]*?) \\[[0-9]+\\]>...")
  (guix-start-repl # nil)
  (guix-start-repl-maybe nil "Starting Guix REPL ..." nil)
  (guix-start-process-maybe)
  (guix-get-repl-buffer internal)
  (guix-eval-read "(help-string )")
  (guix-help-string nil)
  (guix-command-parse-arguments nil)
  (guix-command--all-arguments nil)
  (guix-command-all-arguments nil)
  (guix-command-generate-popup guix-command-popup nil)
  (guix-command nil)
  (funcall-interactively guix-command nil)
  (call-interactively guix-command)
  (magit-invoke-popup-action 99)
  (funcall-interactively magit-invoke-popup-action 99)
  (call-interactively magit-invoke-popup-action nil nil)
  (command-execute magit-invoke-popup-action)

I noticed that Guix recommended me to run `M-x run-geiser', so I did:
(run-geiser 'guile).  This created a REPL with a buffer name of
"* Guile REPL *", whilst Guix created one named "*Guix REPL*".

Essentially, it was as if Guix did not recognize the REPL that it
recommended to be used and hence created another REPL with a different
name. I tried evaluating (setq guix-repl-buffer-name "* Guile REPL *"),
so that Guix would not create a new REPL and try the existing one, but
this did not change anything.

Not sure what to do to fix this.  I've tried the interface before, when
GuixSD was at around version 0.8, and it worked like a charm.  Now, this
is my preferred operating system of choice and it would be nice to have
this interface working again.

Thanks in advance for your support!

Guix version: guix (GNU Guix) 5f799dd119f8b2396ed35add58affc301cf563db
Guile version: guile (GNU Guile) 2.2.6

Kind regards
--
Michael Pagan (pegzmasta) | Casual GNU Emacs user
GPG Key ID: A99A 235B 599C 0894 20AF  2937 D675 7575 27CD F56D


pgpM9vL1cJi6q.pgp
Description: OpenPGP Digital Signature


bug#44606: Error with `guix-start-repl', No prompt found

2020-11-12 Thread Michael Rohleder
Hello Michael,

Thank you for reporting!

I think, we already have #44062 for this, so I merged them.


signature.asc
Description: PGP signature