Hi there

[snip]
> Last night, I filed
> https://bugzilla.redhat.com/show_bug.cgi?id=2237562.  Later, I found
> this about glib 2.77 introducing regressions:
> https://bugzilla.redhat.com/show_bug.cgi?id=2225257; looks like Fedora
> backported enough of that into 2.76.5 to cause similar issues in
> relation to 2.76.1, even though a patchlevel release of glib shouldn't
> be changing behaviors.

Fedora has no related patches in 2.76.5-1 at all (only hmac/eperm).
So, if that's the same regression as in 2.77 it was introduced
earlier, and purely in upstream.

> I presume that 'notmuch config set' should be the preferred way to
> modify the config file - but since it IS a human-readable file,
> notmuch should do a much better job of reporting errors whenever
> glib's gkeyfile API cannot parse the file (even if that failure to
> parse is caused by an unintended regression in glib behavior for
> rejecting something it used to accept).

Yes. This round of glib2 gave us quite some headaches to get config
back working at all. The typical response from glib2 upstream was that
what we called regressions were fixes to wrong behaviour in glib2 and
that we should not rely on established behaviour (my words) but only
on the documentation, the latter exposing a sense of humour which I do
appreciate at times.

In particular, glib2's read and write results are the authoritative
answer. And probably the older glib2 was "wrong" in what it accepted
leniently ... Does notmuch even get the chance to read partially?

Michael
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org