GNU bug report logs - #59423
Invalid 'location' field generated in dovecot configuration

Previous Next

Full log

Message #44 received at 59423 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>, 59423 <at> debbugs.gnu.org
Subject: Re: bug#59423: Invalid 'location' field generated in dovecot
 configuration
Date: Mon, 28 Nov 2022 16:01:47 +0100

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

>>> The issue seems to be with the serialization of the
>>> <namespace-configuration> object nested in the <dovecot-configuration>
>>> record.  I tried this at the REPL:
>>>
>>> scheme@(guile-user)> ,m (gnu services mail)
>>> scheme@(gnu services mail)> (namespace-configuration (name "inbox"))
>>> $8 = #<<namespace-configuration> name: "inbox" type: "private" separator: "" prefix: "" location: "" inbox?: #f hidden?: #f list?: #t subscriptions?: #t mailboxes: () %location: #f>
>>> scheme@(gnu services mail)> (serialize-configuration $8 namespace-configuration-fields)
>>> name=inbox
>>> type=private
>>> separator=
>>> prefix=
>>> location=#f
>>
>> The location here should probably be empty rather than `#f' no? It looks
>> as though the value is coming from the internal %location, rather than
>> the user-provided location.

Uh.

>> I'll if I can find anything the macro, it looks quite complex to me :-).
>
> It's not only to you, if that helps.  It's rather... intimidating ^^'.

[...]

> Ludovic, would you have an idea of where the %location field or its
> CONFIGURATION-location accessor come into play?

We have this:

         (define-record-type* #,(id #'stem #'< #'stem #'>)
           stem
           #,(id #'stem #'make- #'stem)
           #,(id #'stem #'stem #'?)
           #,@(map (lambda (name getter def)
                     #`(#,name #,getter (default #,def)
                               (sanitize
                                #,(id #'stem #'validate- #'stem #'- name))))
                   #'(field ...)
                   #'(field-getter ...)
                   #'(field-default ...))
           (%location #,(id #'stem #'stem #'-location)
                      (default (and=> (current-source-location)
                                      source-properties->location))
                      (innate)))

That generates two accessors called ‘namespace-configuration-location’.
The second one shadows the first one.  With commit
44554e7133aa60e1b453436be1e80394189cabd9, the second one is the “wrong”
one: ‘namespace-configuration-location’ now returns the ‘%location’
field, not the user-specified ‘location’ field.  (I reported that issue
in <https://issues.guix.gnu.org/48284>.)

What do you think of reverting 44554e7133aa60e1b453436be1e80394189cabd9?

After that we can work on renaming the ‘location’ field of
<namespace-configuration> while preserving backward compatibility.

Thanks,
Ludo’.

Previous Next

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