bug#52680: installer error

[Mathieu Othacehe]

Hello Florian,

> I did burn a fresh installer qcow2 image and then ran the installer at 
> digital ocean.

Thanks for the report. You mean that you ran the following command?

--8<---cut here---start->8---
guix system image -t qcow2 gnu/system/install.scm
--8<---cut here---end--->8---

I'll try to reproduce it.

Thanks,

Mathieu

bug#52266: [Installer] ESP/EFI Partition not being reformatted (if exists) during graphical install by default.

[Mathieu Othacehe]

Hey,

> Probably best to close this as I won't be able to get back around to
> testing. I'm running into sof-firmware issues so I gotta tackle that. 
> Thank you for your time!

Closing, then. Thanks!

Mathieu

bug#52662: vte-ng build failure (termite dependency)

[Efraim Flashner]

Fixed with 4b56f5c86944d1c607e3ff3af474b9ca1baddc44

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#52807: Guix home executables are not executable

[Maxime Devos]

Hi,

Nick Zalutskiy schreef op zo 26-12-2021 om 17:25 [-0500]:
> [...]
> I was trying to figure out how to close this... no luck.

https://debbugs.gnu.org/Developer.html has instructions on how to
close, reopen and tag bugs.

Greetings (and closing),
Maxime.

bug#52680: installer error

[Mathieu Othacehe]

Hey,

> guix system image -t qcow2 gnu/system/install.scm

So, I produced a qcow2 installation image this way, imported it in
DigitalOcean, then created a droplet out of it.

The qcow2 image is resized to the droplet disk image size, 25GiB in my
case, and appears as vda disk. There is also an empty vdb disk. In the
installer partitioning page, vda is hidden as this is the installation
device but vdb appears.

Trying to proceed with vdb fails and leads to the backtrace you sent
us. Two things here:

1. We should hide vdb as it is an empty drive, maybe by requiring a
minimal available space. Josselin, what do you think about it?

2. As the qcow2 installation image is also the main VM drive, it will be
hard to install Guix System this way. You might prefer to generate a
complete disk-image that suit your needs and use it directly on
DigitalOcean, as described here:
https://othacehe.org/hosting-a-blog-using-only-scheme.html.

Thanks,

Mathieu

bug#52559: guix pull fails with `Unknown command: nix fish: nix show-derivation "~/.fr-sqOEpp/....-module-import-compiled.drv"

[Grigory Shepelev]

After the last letter my laptop's motherboard broke. It was replaced
recently but all the data was lost from the SSD due to encryption...
TLDR: I made a backup and reinstalled the system.
But the problem still persists. How can I safely move root's profile into
the user's one?  Tinkering with any root-related things is a danger zone
for me, so I won't do anything on my own until there are any clear
instructions.
As previously: from root "guix pull" works perfectly. From users it has the
same problem (nix-related error).


пт, 17 дек. 2021 г. в 09:59, Maxime Devos :

> Grigory Shepelev schreef op vr 17-12-2021 om 09:21 [+0300]:
> > Although I was able to "guix pull" with "sudo", as root user
> > normally. As far as I know guix pull updates only per-user when
> > called.
> > Can I use the result from root somehow?
>
> Determine the full store path of root's guix & run that.
>
> Greetings,
> Maxime
>
>

bug#52559: guix pull fails with `Unknown command: nix fish: nix show-derivation "~/.fr-sqOEpp/....-module-import-compiled.drv"

[Maxime Devos]

Hi,

Grigory Shepelev schreef op ma 27-12-2021 om 17:27 [+0300]:
> After the last letter my laptop's motherboard broke. It was replaced
> recently but all the data was lost from the SSD due to encryption...
> TLDR: I made a backup and reinstalled the system. 
> But the problem still persists. How can I safely move root's profile
> into the user's one?  Tinkering with any root-related things is a
> danger zone for me, so I won't do anything on my own until there are
> any clear instructions.

You could try deleting /var/guix/profiles/per-user/$USER and running
"$THE_GUIX_OF_ROOT pull" and "$guix install ...". I don't see why that
wouldn't work, but I've never tried it and 0 warranty.

> As previously: from root "guix pull" works perfectly. From users it
> has the same problem (nix-related error).

Could you search for "show-derivation" in the back-up? E.g. with grep -
rF show-derivation. Maybe there's a leftover from when you used nix
somewhere ...

Greetings,
Maxime.

bug#52680: installer error

[Josselin Poiret via Bug reports for GNU Guix]

Hello Matthieu and Florian,
Mathieu Othacehe  writes:

> 1. We should hide vdb as it is an empty drive, maybe by requiring a
> minimal available space. Josselin, what do you think about it?

Looks good to me.
I think we should also gracefully handle formatting commands (and maybe
others) failures, as mkfs should properly report why it's failing (and
this would have been a great hint here).  I'll try looking into it.

-- 
Josselin Poiret

bug#52823: 3 gx*lv2 packages fail to build in the same manner

[Thorsten Wilms]

Hi!

gx-saturator-lv2-0-3m, gx-slow-gear-lv2-0-3, gx-vbass-preamp-lv2-0-2
all fail in the same way, with many repetitons of `error: template 
with C linkage` and warnings for deprecated ‘GTypeDebugFlags’ and
‘GTimeVal’.Using gx-saturator as example:

```
In file included from gui/paintbox.cpp:20:
gui/paintbox.h:24:1: note: ‘extern "C"’ linkage started here
   24 | extern "C" {
  | ^~
In file included from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/glib-typeof.h:39,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gatomic.h:28,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gthread.h:32,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib/gasyncqueue.h:32,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib.h:32,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gobject/gbinding.h:28,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib-object.h:22,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gio/gioenums.h:28,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gio/giotypes.h:28,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gio/gio.h:26,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gdk/gdk.h:32,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtk.h:32,
 from gui/paintbox.h:27,
 from gui/paintbox.cpp:20:
/gnu/store/vakvgvrb839igv16jkif4lmx11d25jqb-gcc-10.3.0/include/c++/type_traits:2930:3:
 error: template with C linkage
 2930 |   template
  |   ^~~~
In file included from gui/paintbox.cpp:20:
gui/paintbox.h:24:1: note: ‘extern "C"’ linkage started here
   24 | extern "C" {
  | ^~
In file included from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkobject.h:37,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkwidget.h:36,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkcontainer.h:35,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkbin.h:35,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkwindow.h:36,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkdialog.h:35,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtk.h:33,
 from gui/paintbox.h:27,
 from gui/paintbox.cpp:20:
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtktypeutils.h:236:64:
 warning: ‘GTypeDebugFlags’ is deprecated [-Wdeprecated-declarations]
  236 | voidgtk_type_init   (GTypeDebugFlagsdebug_flags);
  |^
In file included from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gobject/gobject.h:24,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gobject/gbinding.h:29,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/glib-object.h:22,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gio/gioenums.h:28,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gio/giotypes.h:28,
 from 
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gio/gio.h:26,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gdk/gdkapplaunchcontext.h:30,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gdk/gdk.h:32,
 from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2.24.33/include/gtk-2.0/gtk/gtk.h:32,
 from gui/paintbox.h:27,
 from gui/paintbox.cpp:20:
/gnu/store/qqs98rxwjrji6aaf6dqwp7q4m545g2sn-glib-2.70.0/include/glib-2.0/gobject/gtype.h:704:3:
 note: declared here
  704 | } GTypeDebugFlags GLIB_DEPRECATED_TYPE_IN_2_36;
  |   ^~~
In file included from 
/gnu/store/2sw8v141r6hjsv0mq7cwxxp6m2499y4v-gtk+-2

bug#52559: guix pull fails with `Unknown command: nix fish: nix show-derivation "~/.fr-sqOEpp/....-module-import-compiled.drv"

[Grigory Shepelev]

Created new user. Tested from it. Guix pull works great. Now will move the
stuff.
Thanks a lot.

пн, 27 дек. 2021 г., 18:53 Maxime Devos :

> Hi,
>
> Grigory Shepelev schreef op ma 27-12-2021 om 17:27 [+0300]:
> > After the last letter my laptop's motherboard broke. It was replaced
> > recently but all the data was lost from the SSD due to encryption...
> > TLDR: I made a backup and reinstalled the system.
> > But the problem still persists. How can I safely move root's profile
> > into the user's one?  Tinkering with any root-related things is a
> > danger zone for me, so I won't do anything on my own until there are
> > any clear instructions.
>
> You could try deleting /var/guix/profiles/per-user/$USER and running
> "$THE_GUIX_OF_ROOT pull" and "$guix install ...". I don't see why that
> wouldn't work, but I've never tried it and 0 warranty.
>
> > As previously: from root "guix pull" works perfectly. From users it
> > has the same problem (nix-related error).
>
> Could you search for "show-derivation" in the back-up? E.g. with grep -
> rF show-derivation. Maybe there's a leftover from when you used nix
> somewhere ...
>
> Greetings,
> Maxime.
>
>

bug#52680: installer error

[Mathieu Othacehe]

Hey,

>> 1. We should hide vdb as it is an empty drive, maybe by requiring a
>> minimal available space. Josselin, what do you think about it?
>
> Looks good to me.

Here's an attached patch. It seems to work fine, but I am still running
the system tests.

WDYT?

Thanks,

Mathieu
>From d7cc04a71b477d8527b901a66704b28b4e618e04 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Mon, 27 Dec 2021 19:12:54 +0100
Subject: [PATCH 1/1] installer: Ignore small devices.

Filter the devices that are smaller than 10GiB in the device selection list.

* gnu/installer/parted.scm (%min-device-size): New variable.
(non-install-devices): Rename it ...
(eligible-devices): ... this way. Filter the install device as well as the
small devices.
* gnu/installer/newt/partition.scm (run-partitioning-page): Adapt it.
---
 gnu/installer/newt/partition.scm |  9 +++---
 gnu/installer/parted.scm | 47 +++-
 2 files changed, 39 insertions(+), 17 deletions(-)

diff --git a/gnu/installer/newt/partition.scm b/gnu/installer/newt/partition.scm
index 70c11ed8ad..ccc7686906 100644
--- a/gnu/installer/newt/partition.scm
+++ b/gnu/installer/newt/partition.scm
@@ -83,7 +83,8 @@ (define (device-items)
  devices))
 
   (let* ((result (run-listbox-selection-page
-  #:info-text (G_ "Please select a disk.")
+  #:info-text (G_ "Please select a \
+disk.  The installation device as well as the small devices are filtered.")
   #:title (G_ "Disk")
   #:listbox-items (device-items)
   #:listbox-item->text cdr
@@ -792,13 +793,13 @@ (define (run-page devices)
result-user-partitions)
 
   (init-parted)
-  (let* ((non-install-devices (non-install-devices))
- (user-partitions (run-page non-install-devices))
+  (let* ((eligible-devices (eligible-devices))
+ (user-partitions (run-page eligible-devices))
  (user-partitions-with-pass (prompt-luks-passwords
  user-partitions))
  (form (draw-formatting-page user-partitions)))
 ;; Make sure the disks are not in use before proceeding to formatting.
-(free-parted non-install-devices)
+(free-parted eligible-devices)
 (format-user-partitions user-partitions-with-pass)
 (syslog "formatted ~a user partitions~%"
 (length user-partitions-with-pass))
diff --git a/gnu/installer/parted.scm b/gnu/installer/parted.scm
index 289cd660fd..77902599d6 100644
--- a/gnu/installer/parted.scm
+++ b/gnu/installer/parted.scm
@@ -81,7 +81,7 @@ (define-module (gnu installer parted)
 
 with-delay-device-in-use?
 force-device-sync
-non-install-devices
+eligible-devices
 partition-user-type
 user-fs-type-name
 partition-filesystem-user-type
@@ -356,28 +356,49 @@ (define (installer-root-partition-path)
  (and=> (uuid root)
 find-partition-by-uuid)
 
-(define (non-install-devices)
-  "Return all the available devices, except the install device."
+;; Minimal installation device size.
+(define %min-device-size
+  (* 10 GIBIBYTE-SIZE)) ;10GiB
+
+(define (eligible-devices)
+  "Return all the available device except the install device and the devices
+with are smaller than %MIN-DEVICE-SIZE."
 
   (define the-installer-root-partition-path
 (installer-root-partition-path))
 
+  (define (small-device? device)
+(let ((length (device-length device))
+  (sector-size (device-sector-size device)))
+  (and (< (* length sector-size) %min-device-size)
+   (syslog "~a is not eligible because it is smaller than ~a.~%"
+   (device-path device)
+   (unit-format-custom-byte device
+%min-device-size
+UNIT-GIGABYTE)
+
   ;; Read partition table of device and compare each path to the one
   ;; we're booting from to determine if it is the installation
   ;; device.
   (define (installation-device? device)
 ;; When using CDROM based installation, the root partition path may be the
 ;; device path.
-(or (string=? the-installer-root-partition-path
-  (device-path device))
-(let ((disk (disk-new device)))
-  (and disk
-   (any (lambda (partition)
-  (string=? the-installer-root-partition-path
-(partition-get-path partition)))
-(disk-partitions disk))
-
-  (remove installation-device? (devices)))
+(and (or (string=? the-installer-root-partition-path
+   (device-path device))
+ (let ((disk (disk-new device)))
+   (and disk
+(any (lambda (partition)
+   (string=? the-installer-root-partition-path
+ (partition-get-path pa

bug#52684: [BUG] Multiple Packages Failing to Build

[Christopher Rodriguez]

Alright, I've gotten it working.

After discussing on IRC with a few different people, I decided that 
making a new beets-specific variable was probably the best way forward. 
I've created $GUIX_BEETSPLUGINS for this purpose, which points to 
`/gnu/store/xxx-profile/lib/python3.9/site-packages`, and appended it to 
the $GUIX_PYTHONPATH which wraps 'beets'.


I've also wrapped the whole definition in a `let` to programmatically 
set the python version, so it is easier to update should it change. 
Ideally, this would be set from the input python's version, but I don't 
know how to do that (yet).


I've also taken the liberty of moving all of the 
unnecessarily-propagated inputs to 'beets-bandcamp' and made them normal 
inputs.


Patch is attached, let me know what You think.
From 5ebae013a269c0d82a6d3af9124514bbb0d7536f Mon Sep 17 00:00:00 2001
From: Christopher Rodriguez 
Date: Tue, 21 Dec 2021 14:25:51 -0500
Subject: [PATCH] Added $GUIX_BEETSPLUGINS variable

---
 gnu/packages/music.scm | 177 -
 1 file changed, 102 insertions(+), 75 deletions(-)

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index ba0658470c..f0fa69964a 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -3780,82 +3780,98 @@ (define-public instantmusic
 (license license:expat
 
 (define-public beets
-  (package
-(name "beets")
-(version "1.5.0")
-(source (origin
-  (method url-fetch)
-  (uri (pypi-uri "beets" version))
-  (sha256
-   (base32
-"0arl4nc3y8iwa331hf6ggai19y8ns9pl03g5d6ac857wq2x7nzw8"
-(build-system python-build-system)
-(arguments
- `(#:phases
-   (modify-phases %standard-phases
- (add-after 'unpack 'set-HOME
-   (lambda _
- (setenv "HOME" (string-append (getcwd) "/tmp"))
- #t))
- (replace 'check
-   (lambda* (#:key tests? #:allow-other-keys)
- (when tests?
-   (invoke "pytest" "-v" "test"
- ;; Wrap the executable, so it can find python-gi (aka
- ;; pygobject) and gstreamer plugins.
- (add-after 'wrap 'wrap-typelib
-   (lambda* (#:key outputs #:allow-other-keys)
- (let ((prog (string-append (assoc-ref outputs "out")
-"/bin/beet"))
-   (plugins (getenv "GST_PLUGIN_SYSTEM_PATH"))
-   (types (getenv "GI_TYPELIB_PATH")))
-   (wrap-program prog
- `("GST_PLUGIN_SYSTEM_PATH" ":" prefix (,plugins))
- `("GI_TYPELIB_PATH" ":" prefix (,types)))
-   #t))
-(native-inputs
- (list gobject-introspection
-   python-flask
-   python-mock
-   python-py7zr
-   python-pytest-6
-   python-responses))
-(inputs
- (list bash-minimal
-   gst-plugins-base
-   gst-plugins-good
-   gstreamer
-   python-confuse
-   python-jellyfish
-   python-mediafile
-   python-munkres
-   python-musicbrainzngs
-   python-pyyaml
-   python-six
-   python-unidecode
-   ;; Optional dependencies for plugins. Some of these are also required by tests.
-   python-beautifulsoup4 ; For lyrics.
-   python-discogs-client ; For discogs.
-   python-mpd2 ; For mpdstats.
-   python-mutagen ; For scrub.
-   python-langdetect ; For lyrics.
-   python-pillow ; For fetchart, embedart, thumbnails.
-   python-pyacoustid ; For chroma.
-   python-pygobject ; For bpd, replaygain.
-   python-pylast ; For lastgenre, lastimport.
-   python-pyxdg ; For thumbnails.
-   python-rarfile ; For import.
-   python-reflink ; For reflink.
-   python-requests
-   python-requests-oauthlib)) ; For beatport.
-(home-page "https://beets.io";)
-(synopsis "Music organizer")
-(description "The purpose of beets is to get your music collection
+  (let ((beets-python-version "3.9"))
+(package
+  (name "beets")
+  (version "1.5.0")
+  (source (origin
+(method url-fetch)
+(uri (pypi-uri "beets" version))
+(sha256
+ (base32
+  "0arl4nc3y8iwa331hf6ggai19y8ns9pl03g5d6ac857wq2x7nzw8"
+  (build-system python-build-system)
+  ;; Beets plugins are found by beets via PYTHONPATH; the following
+  ;; search path ensures that they are found even when Python is not
+  ;; present in the profile.
+  (native-search-paths
+   ;; XXX: Attempting to use (package-native-search-paths python) here would
+   ;; cause an error about python being an unbound variable in the
+   ;; tests. Instead, we set and use an explicit python version.
+   (list
+(search-path-specification
+ (variable "GUIX_BEE

bug#52749: G-expressions don't consistently preserve #nil

[Philip McGrath]

Hi!

Just as a general disclaimer, I'm a Racketeer and only incidentally a 
Schemer, so I'm not very familiar with the universe of Guile libraries.


On 12/23/21 01:59, Maxime Devos wrote:
> Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]:
>> G-expressions currently do not consistently preserve the distinction
>> between #nil and '(), which causes trouble for programs that rely on
>> that distinction. In particular, the issue affects programs that use
>> (guix build json), because that library uses #nil to represent the JSON
>> value `null', whereas it uses '() to represent an empty JSON array.
>
> The constant #nil is only for elisp compatibility and not something
> supposed to be used in Scheme code that isn't for Scheme/elisp
> compatibility, so this seems more a bug in (guix build json) to me.

That was not the impression I had gotten from `info "(guile)Nil"`. For 
example, I think someone who wanted to finish the implementation 
described in `info "(guile)ECMAScript"` might want to use #nil for one 
of the false-y ECMAScript values to take advantages of the documented 
efficiencies in its bit-level representation. More concretely, 
guile-json@1 and guile-json@3 use #nil in the same way as (guix build json).


On 12/23/21 12:58, Maxime Devos wrote:
> Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]:
>> G-expressions currently do not consistently preserve the distinction
>> between #nil and '(), which causes trouble for programs that rely on
>> that distinction. In particular, the issue affects programs that use
>> (guix build json), because that library uses #nil to represent the JSON
>> value `null', whereas it uses '() to represent an empty JSON array.
>>
>> The following program exposes the error:
>> [
>> ;...]
>>
>> ; This one fails!
>> (check-equal? (gexp->json-string #~'(@ ("k" . #nil)))
>> "{\"k\":null}"
>> "gexp: null in object")
>
> A simpler test:
>
> Compare this:
>(cdr (gexp->approximate-sexp #~("stuff" . #nil)))
>; output: #nil --- seems like everything is ok?
>
> with:
>(gexp->approximate-sexp #~("stuff" . #nil))
>; output: ("stuff") --- where did the #nil go?
>
> I think the idea is that, if you construct a list (a b c . #nil)
> in elisp, and pass it to Scheme, then Scheme should treat it as a
> Scheme list, so it should be printed as (a b c) when using Scheme's
> 'write' or 'display'.

Since `write` and `list?` are specified by various Scheme standards, I 
think it is the correct choice for `write` to use a Scheme-compatible 
external representation for values recognized by `list?`, at least by 
default. (Perhaps a parameter could control this behavior?)


I think the behavior of `gexp->approximate-sexp` is at least defensible, 
since its documentation (`info guix "gexp->approximate-sexp"`) warns 
that "some information can be lost".


But I think the implementation of G-expressions faces more stringent 
obligations. I see it as analogous to the implementation of syntax 
objects, a macro expander, or a compiler, in that it should have a 
semantics-preserving representation of arbitrary Guile code, including 
Guile's extensions to Scheme.


(I haven't yet understood at a theoretical level how "strata" and 
"staging" relate to the more familiar concept of "phases", but my 
intuition is that, while the R6RS model of phases wouldn't be enough, it 
seems like would probably to express staging/strata in terms of phases 
with Racket enhancements like the label phase level and arbitrary 
submodule-implemented phases.)


So, I agree that:

On 12/25/21 06:13, Maxime Devos wrote:

That said, it would be less surprising if the #nil/() distinction is
preserved by gexp->derivation and friends. This can be done by writing
our own 'write' procedure. Downside: it might be less efficient than
Guile's write which is implemented in C. Can be resolved by writing our
own 'write' procedure in C.


I haven't looked at the implementation at all, but extending `write` 
certainly would be a reasonable option, and, longer-term, it might be 
possible to upstream a patch adding the needed behavior.


A more radical option could be to use a format other than plain-text 
s-expressions for compiled G-expressions. For example, Racket has a 
forward-compatible "fast-load serialization" binary format for the kinds 
of values that can be embedded in compiled code.[0] There are obvious 
disadvantages to a binary format, but advantages include the ability to 
preserve source-location information and to avoid some the quirks that 
come with functions like `write` and `read`, for historical reasons or 
for the convenience of humans writing code directly. The implementation 
is in Racket, so it should be fairly easy to port to Guile, if that were 
wanted.[1] Or maybe there's something related to Guile bytecode that 
would work, or maybe just making a `#nil`-preserving version of `write` 
would be easier.


-Philip

[0]: https://docs.racket-lang.org/reference/fasl

bug#52829: GNOME Bluetooth integration is broken

[Mathieu Othacehe]

Hello,

Using the bluetooth-service and blueman, I can manage to connect to
bluetooth devices. However, the "Bluetooth" section in the GNOME
settings reports: "No Bluetooth Found", as can be seen in the attached
capture.

Thanks,

Mathieu

bug#52684: [BUG] Multiple Packages Failing to Build

[Maxime Devos]

Hi,

Christopher Rodriguez schreef op ma 27-12-2021 om 13:18 [-0500]:
> +   `("GST_PLUGIN_SYSTEM_PATH" ":" prefix (,gst-
> plugins))
> +   `("GI_TYPELIB_PATH" ":" prefix (,types))
> +   `("GUIX_PYTHONPATH" ":" prefix (,beets-
> plugins

I think this needs to be '=' instead of 'prefix', otherwise the GUIX_PYTHONPATH,
GI_TYPELIB_PATH and GST_PLUGIN_SYSTEM_PATH from the environment might interfere,
which is probably harmless most of the time but might be a source of potential
problems.

I'll look more at this patch later.

Greetings,
Maxime.

bug#52559: guix pull fails with `Unknown command: nix fish: nix show-derivation "~/.fr-sqOEpp/....-module-import-compiled.drv"

[Maxime Devos]

Grigory Shepelev schreef op ma 27-12-2021 om 21:01 [+0300]:
> Created new user. Tested from it. Guix pull works great. Now will
> move the stuff. 
> Thanks a lot. 

Seems like the issue has been resolved, so closing.
If you want to re-open the bug report, see
.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#52749: G-expressions don't consistently preserve #nil

[Maxime Devos]

Philip McGrath schreef op ma 27-12-2021 om 13:38 [-0500]:
> Hi!
> 
> Just as a general disclaimer, I'm a Racketeer and only incidentally a 
> Schemer, so I'm not very familiar with the universe of Guile libraries.
> 
> On 12/23/21 01:59, Maxime Devos wrote:
>  > Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]:
>  >> G-expressions currently do not consistently preserve the distinction
>  >> between #nil and '(), which causes trouble for programs that rely on
>  >> that distinction. In particular, the issue affects programs that use
>  >> (guix build json), because that library uses #nil to represent the JSON
>  >> value `null', whereas it uses '() to represent an empty JSON array.
>  >
>  > The constant #nil is only for elisp compatibility and not something
>  > supposed to be used in Scheme code that isn't for Scheme/elisp
>  > compatibility, so this seems more a bug in (guix build json) to me.
> 
> That was not the impression I had gotten from `info "(guile)Nil"`. For 
> example, I think someone who wanted to finish the implementation 
> described in `info "(guile)ECMAScript"` might want to use #nil for one 
> of the false-y ECMAScript values to take advantages of the documented 
> efficiencies in its bit-level representation. More concretely, 
> guile-json@1 and guile-json@3 use #nil in the same way as (guix build json).

There is

‘Guile has chosen to support ‘nil’ as a separate value, distinct from
‘#f’ and ‘'()’.  This allows existing Scheme and Elisp code to maintain
their current semantics.  ‘nil’, which in Elisp would just be written
and read as ‘nil’, in Scheme has the external representation ‘#nil’.’

and

‘This decision to have ‘nil’ as a low-level distinct value facilitates
interoperability between the two languages.  Guile has chosen to have
Scheme deal with ‘nil’ as follows: [...]’

and this is only documented under ‘Emacs Lisp’, though this doesn't
explicitely say it's not supposed to be used elsewhere.

Also, see e.g.
.

Anyway, this doesn't really matter here, because:

> So, I agree that:
> 
> On 12/25/21 06:13, Maxime Devos wrote:
> > That said, it would be less surprising if the #nil/() distinction is
> > preserved by gexp->derivation and friends. This can be done by writing
> > our own 'write' procedure. Downside: it might be less efficient than
> > Guile's write which is implemented in C. Can be resolved by writing our
> > own 'write' procedure in C.
> [...]

I'll try to look into other parts of your response later.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

bug#52684: [BUG] Multiple Packages Failing to Build

[Christopher Rodriguez]

Hi Maxime,

Copy that, I can swap the 'prefix'es out for '='s. Would it be best to 
do that for all of them, to totally isolate the derivation from the 
environment?


No rush on reviewing, thank You for spending so much time on this with 
me. I have learned a lot about Guix packages working through this; 
Hopefully I can use that knowledge to help out more often.


--

Christopher Rodriguez


OpenPGP_0x1102102EBE7C3AE4.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#52834: sanity-check fails with namespace packages

[Hartmut Goebel]

Hi,

I just investigated some failing python packages 
 and found that 
"python2-zppe-*" packages fail. (Most due to a dependency failing , 
though. Actually failing are python2-zope-testing and python2-zope-event).


These fail due to sanity-check not being able to import "zope" - which 
is a namespace package. Both use the "src directory layout" (source is 
contained in a sub-directory "src").


This could be solved by fetching a list og namespace-packages and 
checking whether a fails import is a namespace-package. Maybe there are 
other solution.


try:

 nspkgs = set(dist.get_metadata_lines('namespace_packages.txt'))

except:

    nspkgs = set()

Anyhow, since Python2 is EOL since long, I'm not sure whether it's worth 
the effort.


WDYT?

--
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#43579: g++ does not provide std::fegetround

[Ricardo Wurmus]

Hi,

I just rediscovered this issue by adding “gcc-7” to a package’s input
without also adjusting the variable that determines the order of
includes.  (I ended up not needing to use GCC 7 in the end.)

Seeing that issue #42392 (“GCC includes ordering issue? g++: error:
'round' is not a member of 'std'”) has since been solved, should we
close this issue, too?

Or are there still reasons to want an adjustment of the
gnu-build-system?  What do you think, Miguel?

-- 
Ricardo

bug#52836: "guix import pypi" fails with "Failed to extract file from wheel" and "no requires.txt file found"

[bbb ee]

Hello,
I have encounter a issue with "guix import pypi" :
```
guix import: warning: Failed to extract file:
PyPortfolioOpt-1.5.1.dist-info/METADATA from wheel.
guix import: warning: Cannot guess requirements from source archive: no
requires.txt file found.
```
## reproduce the bug

```
(base) guix import pypi  PyPortfolioOpt
following redirection to `https://pypi.org/pypi/pyportfolioopt/json'...

Starting download of /tmp/guix-file.mwZdLg
From
https://files.pythonhosted.org/packages/97/c2/c7569f2773f3e942367e90dcca15a235af3d3330ac8abfcbfbe67a8ba8dd/PyPortfolioOpt-1.5.1.tar.gz.
..
 …t-1.5.1.tar.gz  56KiB   2.7MiB/s 00:00 [##]
100.0%

Starting download of /tmp/guix-file.mHBgak
From
https://files.pythonhosted.org/packages/90/98/3906835b783ba39cfc613c7b0c0fde9c758c729ff3406d45f1c2a1116961/PyPortfolioOpt-1.5.1-py3-none-any.whl.
..
 ….1-py3-none-any.whl  60KiB  2.1MiB/s 00:00 [##]
100.0%
guix import: warning: Failed to extract file:
PyPortfolioOpt-1.5.1.dist-info/METADATA from wheel.
guix import: warning: Cannot guess requirements from source archive: no
requires.txt file found.
(package
  (name "python-pyportfolioopt")
  (version "1.5.1")
  (source
(origin
  (method url-fetch)
  (uri (pypi-uri "pyportfolioopt" version))
  (sha256
(base32 "162d6jyvba0xk2blssbp52rrjqpjv011h988k150p1fg7x7nzbs9"
  (build-system python-build-system)
  (home-page "https://github.com/robertmartin8/PyPortfolioOpt";)
  (synopsis "Financial portfolio optimization in python")
  (description "Financial portfolio optimization in python")
  (license license:expat))
(base) guix describe
Generation 220 Dec 27 2021 12:01:04 (current)
  guix 9bbbac6
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 9bbbac6783bcdace17d967e85c8ae8d14cbf1ef9
```
## additional information
This user has encountered a similar issue for "guix import pypi httpie"
https://www.mail-archive.com/bug-guix@gnu.org/msg14277.html

However "guix import pypi httpie" runs for my version of guix.

bug#52837: Failed to compile rav1e which is dependence for tons of packages

[Evgenii Lepikhin via Bug reports for GNU Guix]

Hi there,

rav1e failed to compile with error:

starting phase `build'
Error: CliError { error: Some(failed to select a version for `clang-sys`.
... required by package `bindgen v0.58.1`
... which is depended on by `dav1d-sys v0.3.4`
... which is depended on by `rav1e v0.4.1 
(/tmp/guix-build-rav1e-0.4.1.drv-0/rav1e-0.4.1)`
versions that meet the requirements `^1` are: 1.0.0

the package `clang-sys` links to the native library `clang`, but it conflicts 
with a previous package which links to `clang` as well:
package `clang-sys v0.29.3`
... which is depended on by `bindgen v0.54.1`
... which is depended on by `aom-sys v0.2.1`
... which is depended on by `rav1e v0.4.1 
(/tmp/guix-build-rav1e-0.4.1.drv-0/rav1e-0.4.1)`

The issue caused by commit ad1e8a0906c. Possible fix:

diff --git a/gnu/packages/crates-graphics.scm b/gnu/packages/crates-graphics.scm
index e4cd01fadf..269bd991ab 100644
--- a/gnu/packages/crates-graphics.scm
+++ b/gnu/packages/crates-graphics.scm
@@ -208,7 +208,7 @@ (define-public rust-aom-sys-0.2
 (build-system cargo-build-system)
 (arguments
   `(#:cargo-inputs
-(("rust-bindgen" ,rust-bindgen-0.54)
+(("rust-bindgen" ,rust-bindgen-0.58)
  ("rust-metadeps" ,rust-metadeps-1
 (native-inputs
  (list pkg-config))


-- 

bug#52837: Failed to compile rav1e which is dependence for tons of packages

[Leo Famulari]

On Tue, Dec 28, 2021 at 02:09:42AM +0300, Evgenii Lepikhin via Bug reports for 
GNU Guix wrote:
> Hi there,
> 
> rav1e failed to compile with error:

Oof, thanks for the report. Looking into it now...

bug#52837: Failed to compile rav1e which is dependence for tons of packages

[Leo Famulari]

On Tue, Dec 28, 2021 at 02:09:42AM +0300, Evgenii Lepikhin via Bug reports for 
GNU Guix wrote:
> Hi there,
> 
> rav1e failed to compile with error:

Alright, for now I've reverted the commits that caused the problem.

Specifically, I reverted this range of commits:
5b1ec376239602725171d4523406801b684ee195^..13d3120095e4baa03594d095b0afe9febbb7cee0

IIUC, these were pushed together.

Nicolas, can you take a look at the suggested fix shown below?

> The issue caused by commit ad1e8a0906c. Possible fix:
> 
> diff --git a/gnu/packages/crates-graphics.scm 
> b/gnu/packages/crates-graphics.scm
> index e4cd01fadf..269bd991ab 100644
> --- a/gnu/packages/crates-graphics.scm
> +++ b/gnu/packages/crates-graphics.scm
> @@ -208,7 +208,7 @@ (define-public rust-aom-sys-0.2
>  (build-system cargo-build-system)
>  (arguments
>`(#:cargo-inputs
> -(("rust-bindgen" ,rust-bindgen-0.54)
> +(("rust-bindgen" ,rust-bindgen-0.58)
>   ("rust-metadeps" ,rust-metadeps-1
>  (native-inputs
>   (list pkg-config))
> 
> 
> -- 

bug#52840: cuirass/UI: don't use color as only source of information

[raingloom]

This is one of the most basic accessibility principles, I think Cuirass
should adhere to it.
Specifically on pages like this:
https://ci.guix.gnu.org/build/251721/details
the weather field is just a colored circle.
There is no reason to hide the text behind a hover action, especially
since not all input devices support that.
Also, not all output devices support color. And obviously, colorblind
people exist too.

bug#52837: Failed to compile rav1e which is dependence for tons of packages

[0xFA11BABE via Bug reports for GNU Guix]

I got the same problem.

> starting phase `build'
> Error: CliError { error: Some(failed to select a version for `clang-sys`.
> ... required by package `bindgen v0.58.1`
> ... which is depended on by `dav1d-sys v0.3.4`
> ... which is depended on by `rav1e v0.4.1 
> (/tmp/guix-build-rav1e-0.4.1.drv-0/rav1e-0.4.1)`
> versions that meet the requirements `^1` are: 1.0.0
>
> the package `clang-sys` links to the native library `clang`, but it conflicts 
> with a previous package which links to `clang` as well:
> package `clang-sys v0.29.3`
> ... which is depended on by `bindgen v0.54.1`
> ... which is depended on by `aom-sys v0.2.1`
> ... which is depended on by `rav1e v0.4.1 
> (/tmp/guix-build-rav1e-0.4.1.drv-0/rav1e-0.4.1)`
>
> failed to select a version for `clang-sys` which could resolve this 
> conflict), exit_code: 101 }
> error: in phase 'build': uncaught exception:
> %exception #<&invoke-error program: "cargo" arguments: ("cinstall" 
> "--release" 
> "--prefix=/gnu/store/83mfvccy0szp2v9v2qk8xf5wz867ndnx-rav1e-0.4.1") 
> exit-status: 1 term-signal: #f stop-signal: #f>
> phase `build' failed after 0.7 seconds
> command "cargo" "cinstall" "--release" 
> "--prefix=/gnu/store/83mfvccy0szp2v9v2qk8xf5wz867ndnx-rav1e-0.4.1" failed 
> with status 1

bug#52837: We need deeper research

[Evgenii Lepikhin via Bug reports for GNU Guix]

Hi,

Suggested fix is insufficient because dependency on version is hard coded in 
the crate: 
https://github.com/rust-av/aom-rs/blob/ea9a45d6ec7bfd2cd0d6f9f43268d9e379bba168/aom-sys/Cargo.toml#L18

We need to update both rust-aom-sys to == 0.3.0 and rav1e to >= 0.5.0.


-- 
QA automation teamlead at Mail.ru.