Bug 2225257

Summary:	glib2 2.77.0 changes keyfile output
Product:	[Fedora] Fedora	Reporter:	Michael J Gruber <mjg>
Component:	glib2	Assignee:	Matthias Clasen <mclasen>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	39	CC:	gnome-sig, klember, mclasen, rhughes, rstrode
Target Milestone:	---	Keywords:	Regression, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	glib2-2.77.0-8.fc39	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-07-25 18:33:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2226033

Description Michael J Gruber 2023-07-24 19:07:08 UTC

glib2 2.77.0 writes keyfiles (mostly used for config files) in a different way compared to 2.76.4. Typically, the actual content (groups, keys, values) remains the same but the formatting changes:
- group comments may get placed differently (before keys of the previous group)
- empty lines which used to separate group comments from the preceding keys visually are omitted
- comments may not get written at all (if they are set for a group which does not "exist" yet, where "existence" can only be forced by setting a key and removing it).
Some of these are not completely new or even considered bugfixes rather than regressions by upstream. Some of these will get reverted in 2.77.1 but (as per the current state) not all of them.

This creates two possible problems:
- Readibility of config files (for humans) can suffer
- Automatic testing fails if other packages if their written config is compared literally

Until glib2 comes out with a version which produces (literally) the same keyfiles as 2.76 (which may very well never happen at all) this bug can serve as a tracker for affected packages (the F39 mass rebuild produces FTBFS) and as a place for pointing at solutions.

Reproducible: Always

Steps to Reproduce:
1. Build a package which uses GKeyFile against 2.7.0
2. Compare written files before and after
Actual Results:  
Differently formatted key files

Expected Results:  
Unchanged key files

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3498
and similar

Failed F39 build (failing test shows the problem):
https://src.fedoraproject.org/rpms/notmuch.git#a5eafe0721a437deaa9f734dcff5232c87600add
https://koji.fedoraproject.org/koji/taskinfo?taskID=103636455

Comment 1 Kalev Lember 2023-07-24 20:29:04 UTC

Thanks - let me go ahead and backport the upstream fix.

Comment 2 Fedora Update System 2023-07-24 21:12:44 UTC

FEDORA-2023-cd301afed7 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd301afed7

Comment 3 Fedora Update System 2023-07-25 18:33:01 UTC

FEDORA-2023-cd301afed7 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 4 Michael J Gruber 2023-07-28 07:50:36 UTC

Thanks for the backport.

As indicated (maybe not clearly enough), the upstream commit fixes things partly only: it restores the position of group comments to be right before the group header again.

It does not restore keyfiles formatting completely. In particular:

- A file comment (before the first group/key) is not written any more - maybe it has to be forced now like the group headers (write value, remove value to "cretae" a group, then write comment), instead of just written?
- Group comments are not lead by an empty line.

I'll attach a diff from notmuch's test suite below. It is from today's build attempt (now that emacs good in the rawhide chroot again).

So, glib upstream needs to do more fixing, or useres of glib's keyfile need to adjust. Not writing a file header comment is kind of bad though. Empty lines are to be dealt with probably. Just let me know whether you prefer individual bugs for individual facets. It's all keyfile/2.77.0 regression.

https://copr.fedorainfracloud.org/coprs/mjg/notmuch/build/6219308/

T040-setup: Testing "notmuch setup"
PASS Notmuch new without a config suggests notmuch setup
FAIL Create a new config interactively
--- T040-setup.2.config-with-comments 2023-07-28 07:37:33.765432327 +0000
+++ T040-setup.2.new-notmuch-config 2023-07-28 07:37:33.766432283 +0000
@@ -1,7 +1,3 @@
-# .notmuch-config - Configuration file for the notmuch mail system
-#
-# For more information about notmuch, see https://notmuchmail.org
-
# Database configuration
#
# The only value supported here is 'path' which should be the top-level
@@ -12,7 +8,6 @@
#
[database]
path=/path/to/maildir
-
# User configuration
#
# Here is where you can let notmuch know how you would like to be
@@ -32,7 +27,6 @@
name=Test Suite
primary_email=test.suite
other_email=another.suite
-
# Configuration for "notmuch new"
#
# The following options are supported here:
@@ -49,7 +43,6 @@
#
[new]
tags=foo;bar;
-
# Search configuration
#
# The following option is supported here:
@@ -61,7 +54,6 @@
#
[search]
exclude_tags=baz
-
# Maildir compatibility configuration
#
# The following option is supported here:

Comment 5 Kalev Lember 2023-07-28 19:14:05 UTC

Ah, bummer. In, any case, thanks for testing the change!

Could you please file this upstream as a new issue against glib? That would help make sure the relevant people know about this.

https://gitlab.gnome.org/GNOME/glib/-/issues

Comment 6 Michael J Gruber 2023-08-06 19:51:16 UTC

FYI: I patch the test in notmuch to fix the FTBFS now, but I'll try to submit reproducers upstream (missing file comment, missing newlines in keyfiles).

Comment 7 Kalev Lember 2023-08-06 20:15:24 UTC

Excellent, thanks!

Comment 8 Fedora Release Engineering 2023-08-16 08:13:31 UTC

This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.