GNU bug report logs - #56799
(gnu services configuration) usage of *unspecified* is problematic

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: bug#56799: closed (Re: bug#56799: (gnu services configuration)
 usage of *unspecified* is problematic)
Date: Thu, 25 Aug 2022 04:15:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#56799: (gnu services configuration) usage of *unspecified* is problematic

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 56799 <at> debbugs.gnu.org.

-- 
56799: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56799
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Attila Lendvai <attila <at> lendvai.name>
Cc: 56799-done <at> debbugs.gnu.org
Subject: Re: bug#56799: (gnu services configuration) usage of *unspecified*
 is problematic
Date: Thu, 25 Aug 2022 00:14:30 -0400

Hi Attila,

Attila Lendvai <attila <at> lendvai.name> writes:

> The new value of %unset-value sticks out more when something goes wrong, and
> is also more unique; i.e. easier to search for.
> ---
>  gnu/services/configuration.scm   | 5 +++--
>  gnu/services/messaging.scm       | 2 +-
>  tests/services/configuration.scm | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)

Thanks for the series!  I've now pushed all of the 5 commits.  Yay!

Closing!

Maxim

[Message part 3 (message/rfc822, inline)]

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Cc: attila <at> lendvai.name
Subject: (gnu services configuration) usage of *unspecified* is problematic
Date: Wed, 27 Jul 2022 12:23:58 -0400

Hello Guix,

Since commit 8cb1a49a3998c39f315a4199b7d4a121a6d66449, the
define-configuration machinery in (gnu services configuration) uses
*unspecified* instead of 'disabled for an unspecified field value.

While this is indeed an improvement in readability, it introduces an
extra complication: because this new value is not self-quoting, it
cannot be used as is in G-Exps, and values using it must be carefully
expanded outside the gexp context, which is error prone.

This broke the jami-service-type, when partially specifying a
jami-account like so:

--8<---------------cut here---------------start------------->8---
(service jami-service-type
               (jami-configuration
                (accounts
                 (list (jami-account
                        (archive "/etc/jami/some-jami-account.gz"))))))
--8<---------------cut here---------------end--------------->8---

When building the operating system containing the above fragment, the
following error is throw:

--8<---------------cut here---------------start------------->8---
guix system: error: #<unspecified>: invalid G-expression input
--8<---------------cut here---------------end--------------->8---

The following change to the jami-provisioning test can also reproduce
the problem:

--8<---------------cut here---------------start------------->8---
modified   gnu/tests/telephony.scm
@@ -60,7 +60,7 @@ (define %moderators '("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
 (define %dummy-jami-account (jami-account
                              (archive %dummy-jami-account-archive)
                              (allowed-contacts %allowed-contacts)
-                             (moderators %moderators)
+;                             (moderators %moderators)
                              (rendezvous-point? #t)
                              (peer-discovery? #f)
                              (bootstrap-hostnames '("bootstrap.me"
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ make check-system TESTS=jami-provisioning
Selected 1 system tests...
guix build: error: #<unspecified>: invalid G-expression input
make: *** [Makefile:6734: check-system] Error 1
--8<---------------cut here---------------end--------------->8---

I'd suggest we revisit 8cb1a49a3998c39f315a4199b7d4a121a6d66449 to use
'unspecified (the symbol) instead of *unspecified*, which *can* be
serialized without any fuss in gexps.

Thoughts?

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.