I spent several hours today unable to access my email locally (I use neomutt to access notmuch queries), after having run dnf update. After some trial and error, I was able to narrow the problem down to the fact that glib2's ini parser functions regressed in functionality. My ~/.notmuch_config file contained something akin to this (edited to protect the innocent): [query] foo = ( from:example.com or from:"/.*\.example\.org/" ) which allows me to do things like 'notmuch search query:foo' to see all emails from the example.com domain as a literal string, and from any subdomain of example.org via a regex. But with today's update in library, glib's ini parser now treats that line as invalid, and completely chokes on parsing the file, at which point notmuch was not able to proceed any further, with bizarre results. For example, 'notmuch config list' was printing no output but exiting with status 0 (so it may ALSO be a bug in notmuch for not handling failures from the glib function correctly, in that I wasn't given any error message about the failed parse). After more trial and error, I determined that I could work around the failures by rewriting my config file to use "[.]" instead of "\.", and then with prodding from the libera.chat #notmuch community, we then tackled finding which part of my 'dnf update' caused it. We were able to reliable narrow it down to a 100% reproducible issue: Temporarily downgrading to glib2-2.76.1-1.fc38 lets \. work; upgrading back to glib2-2.76.5-1.fc38.x86_64 breaks it. I'm not sure which library function in glib2 changed behaviors, but it seems like a nasty change to treat \. inside "" differently than before. Another user claimed that 2.77.2 on Debian does not have the problem, so it may be something that upstream glib2 is already aware of, although I have not yet searched their database. Reproducible: Always Steps to Reproduce: 1. write an ini file containing a regex inside double quotes that wants to match a literal '.'. In my case, ~/.notmuch-config containing [query] foo = ( from:example.com or from:"/.*\.example\.org/" ) 2. Use glib to parse the ini file, In my case, 'notmuch config list' works well. 3. Actual Results: the parse fails, and any further attempt to use config loaded from the file is doomed Expected Results: the parse succeeds, with the resulting string value for the associated query.foo config item being a regex containing the two-byte sequence \. Workaround: rewrite the affected ini files use the regex [.] instead of \. (but only helps ini files where the use of "\." was for a regex)
https://github.com/GNOME/glib/commit/71b7efd0 looks relevant. glib may have recently made intentional changes to g_key_file_parse_value_as_string() to start declaring \ before unusual character (like .) as an unrecognized escape, instead of its previous behavior of passing both the \ and next character on to the caller, but may have messed up error handling in the process. I didn't look further to see what other recent glib changes may be relevant.
Looks like there's already a fix for this upstream: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3565
(In reply to Kalev Lember from comment #2) > Looks like there's already a fix for this upstream: > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3565 Confirmed; I've commented on that merge commit upstream after testing locally that it fixes my issue. We'll definitely want to backport that into Fedora; according to glib, there are a number of other affected projects including Midnight Commander.
Thanks! I went ahead and backported the upstream patch to F38, F39 and rawhide.