From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Pierre Langlois <pierre.langlois@gmx.com>
Cc: "Ludovic Courtès" <ludo@gnu.org>, 59423@debbugs.gnu.org
Subject: bug#59423: Invalid 'location' field generated in dovecot configuration
Date: Sat, 26 Nov 2022 21:33:32 -0500 [thread overview]
Message-ID: <87o7stw2gz.fsf@gmail.com> (raw)
In-Reply-To: <87cz995wwu.fsf@gmx.com> (Pierre Langlois's message of "Sat, 26 Nov 2022 19:32:37 +0000")
Hi Pierre,
Pierre Langlois <pierre.langlois@gmx.com> writes:
> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
[...]
>> The change was reinstated as part of the mcron update, in
>> 44554e7133aa60e1b453436be1e80394189cabd9. The bit that seems to cause
>> the issue here (still not clearly understood) is probably this one:
>>
>> diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
>> index 636c49ccba..dacfc52ba9 100644
>> --- a/gnu/services/configuration.scm
>> +++ b/gnu/services/configuration.scm
>> @@ -242,17 +242,17 @@ (define-record-type* #,(id #'stem #'< #'stem #'>)
>> stem
>> #,(id #'stem #'make- #'stem)
>> #,(id #'stem #'stem #'?)
>> - (%location #,(id #'stem #'stem #'-location)
>> - (default (and=> (current-source-location)
>> - source-properties->location))
>> - (innate))
>> #,@(map (lambda (name getter def)
>> #`(#,name #,getter (default #,def)
>> (sanitize
>> #,(id #'stem #'validate- #'stem #'- name))))
>> #'(field ...)
>> #'(field-getter ...)
>> - #'(field-default ...)))
>> + #'(field-default ...))
>> + (%location #,(id #'stem #'stem #'-location)
>> + (default (and=> (current-source-location)
>> + source-properties->location))
>> + (innate)))
>>
>> (define #,(id #'stem #'stem #'-fields)
>> (list (configuration-field
>>
>>
>> Reverting it would likely fix the issue (haven't tried), but it'd be
>> nice to have a clear understanding of what's going on. It may have
>> unmasked a bug waiting to bite.
>>
>> 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.
Good eye! Perhaps my earlier simple session was able to reproduce after
all! #f sure doesn't read as a successfully serialized value :-). It
probably came from %location, which is set to #f when working at the
REPL.
> If the two fields can shadow each other,
> then indeed, that looks like an existing bug that was exposed by the
> reordering, rather than a bug with the reorder itself.
>
> 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 ^^'.
Looking at it again, the problem is not so mysterious after all... The
%location field has its accessor set to be:
--8<---------------cut here---------------start------------->8---
(%location #,(id #'stem #'stem #'-location)
(default (and=> (current-source-location)
source-properties->location))
(innate)))
--8<---------------cut here---------------end--------------->8---
#,(id #'stem #'stem #'-location)
which gets expanded to namespace-configuration-location, which shadows
that of the now preceding "location" field.
The bug in the previous condition would have been reversed; the source
location would have been shadowed by the "location" field value.
Ludovic, would you have an idea of where the %location field or its
CONFIGURATION-location accessor come into play? I tried tracing it in
the source, but I only see it being set and the location being pulled
from the sanitizer via "(datum->syntax #'value (syntax-source #'value)"
in (gnu services configuration) around line 227, which is the location
that would get printed in the error handler CALL-WITH-ERROR-HANDLING
from (guix ui):
--8<---------------cut here---------------start------------->8---
((formatted-message? c)
(apply report-error
(and (error-location? c) (error-location c))
(gettext (formatted-message-string c) %gettext-domain)
(formatted-message-arguments c))
(when (fix-hint? c)
(display-hint (condition-fix-hint c)))
(exit 1))
--8<---------------cut here---------------end--------------->8---
I could be wrong, but since the "location" of a field appears to be an
"intrinsic" property rather than something explicitly attached to it,
perhaps there's no need for a "location" accessor? Or it could be named
differently, such as "%location" to reduce the risk of clashing with
user-defined fields.
Does that make sense?
--
Thanks,
Maxim
next prev parent reply other threads:[~2022-11-27 2:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-20 21:53 bug#59423: Invalid 'location' field generated in dovecot configuration Pierre Langlois
2022-11-22 8:10 ` Ludovic Courtès
2022-11-25 15:36 ` Maxim Cournoyer
2022-11-25 20:19 ` Pierre Langlois
2022-11-25 19:17 ` mirai
2022-11-25 20:06 ` Maxim Cournoyer
2022-11-25 20:25 ` Pierre Langlois
2022-11-25 20:50 ` Pierre Langlois
2022-11-25 21:09 ` Pierre Langlois
2022-11-26 2:54 ` Maxim Cournoyer
2022-11-26 19:32 ` Pierre Langlois
2022-11-27 2:33 ` Maxim Cournoyer [this message]
2022-11-28 15:01 ` Ludovic Courtès
2022-11-28 20:00 ` Maxim Cournoyer
2022-11-28 21:33 ` Ludovic Courtès
2022-11-29 1:58 ` Maxim Cournoyer
2022-12-02 9:30 ` Ludovic Courtès
2022-12-02 21:18 ` Ludovic Courtès
2022-12-03 3:05 ` Maxim Cournoyer
2022-12-04 16:53 ` Ludovic Courtès
2022-12-04 21:43 ` Maxim Cournoyer
2022-12-06 8:53 ` Ludovic Courtès
2022-12-01 20:29 ` Pierre Langlois
2022-11-26 23:17 ` Fredrik Salomonsson
2022-12-01 21:55 ` Pierre Langlois
2022-12-03 2:24 ` Maxim Cournoyer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7stw2gz.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=59423@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=pierre.langlois@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.