Description of problem: In the past, Fedora's Flatpak of ca.desrt.dconf-editor from registry.fedoraproject.org has not given me any issues. So this issue may or may not be related to the fact im on Fedora 34 Beta now. Many, if not all, system attributes are out of sync on dconf-editor vs gsettings. For example, gsettings cli outputs a text-scaling-factor of 1.3999 while dconf-editor shows text-scaling-factor at the default 1. (gsettings is correct, and dconf-editor is always incorrect). Examples of CLI command: $ gsettings get org.gnome.desktop.interface text-scaling-factor $ gsettings get org.gnome.desktop.interface gtk-theme Version-Release number of selected component (if applicable): Fedora 34 Silverblue Beta. ca.desrt.dconf-editor 3.38.3 via registry.fedoraproject.org How reproducible: 100% of time. Steps to Reproduce: 1. open ca.desrt.dconf-editor and change and attribute 2. there are not changes to the system 3. --end-- Actual results: There are not changes to the system Expected results: Changes to the system Additional info:
Looks like this is fallout from removing dconf from F34 flatpak runtime. It's now built as a module and installed into /app. Looking at dconf-editor flatpak container build logs (https://kojipkgs.fedoraproject.org//packages/dconf-editor/stable/3420210331103641.1/data/logs/x86_64-build.log), I see the following: Installing : dconf-editor-3.38.3-1.module_f34+11746+dcc4e864. 209/210 Installing : flatpak-runtime-config-34-1.module_f34+11711+cd7 210/210 Running scriptlet: flatpak-runtime-config-34-1.module_f34+11711+cd7 210/210 Running scriptlet: filesystem-3.14-5.fc34.x86_64 210/210 Running scriptlet: crypto-policies-scripts-20210213-1.git5c710c0.fc 210/210 Running scriptlet: ca-certificates-2020.2.41-7.fc34.noarch 210/210 Running scriptlet: fontconfig-2.13.93-6.fc34.x86_64 210/210 Running scriptlet: dconf-0.40.0-2.module_f34+11746+dcc4e864.x86_64 210/210 /var/tmp/rpm-tmp.35hedi: line 1: dconf: command not found warning: %posttrans(dconf-0.40.0-2.module_f34+11746+dcc4e864.x86_64) scriptlet failed, exit status 127 [91mError in POSTTRANS scriptlet in rpm package dconf [0m Running scriptlet: flatpak-runtime-config-34-1.module_f34+11711+cd7 210/210 Verifying : dconf-0.40.0-2.module_f34+11746+dcc4e864.x86_64 1/210 Verifying : dconf-editor-3.38.3-1.module_f34+11746+dcc4e864. 2/210 Verifying : flatpak-runtime-config-34-1.module_f34+11711+cd7 3/210 Looks like flatpak-runtime-config gets installed _after_ dconf, which makes it so that PATH isn't correctly set up for dconf's %posttrans script (dconf update). I assume this is what's making it all not work, although it could be just a red herring. In any case, there seems to be a general problem here with PATH and scriptlets. Owen, do you have any ideas how we could fix this and make sure that flatpak-runtime-config gets installed before other packages?
Or hm, I got the above a bit wrong: flatpak-runtime-config doesn't actually seem to change PATH in any way. Do we even have anything that sets up PATH for scriptlets? For runtime, flatpak sets it itself, but what should set it up for rpm scripts?
A quick fix should be to just change the 'dconf update' script that's in dconf package to be '%{_prefix}/dconf update' because both the script and the dconf binary are in the same package and have the same prefix.
We could also set "%{_install_script_path} somewhere that should override rpm's PATH -- but then we are back at the transaction ordering problem if we do it from flatpak-runtime-config.
I pushed https://src.fedoraproject.org/rpms/dconf/c/9f421adea425a2c1de4658d5b428ef4b1abd577f as a workaround for the PATH issues.
OK, after some more debugging, the 'dconf update' issue was really just a red herring. The reason why dconf-editor stopped working is because gio doesn't find the /app-installed dconf module: /app/lib64/gio/modules/libdconfsettings.so. $ flatpak run --command=sh ca.desrt.dconf-editor export GIO_EXTRA_MODULES=/app/lib64/gio/modules start-dconf-editor ... makes it work again.
OK, https://src.fedoraproject.org/flatpaks/dconf-editor/c/9a91b41133369cfbc5424bc7e3cb1e2df86d7dae?branch=stable fixes this. I think we should be able to do something in the flatpak runtime to get gio to load modules from /app automatically, but this should be sufficient for now.
FEDORA-FLATPAK-2021-bdfe4149b8 has been submitted as an update to Fedora 34 Flatpaks. https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2021-bdfe4149b8
FEDORA-FLATPAK-2021-bdfe4149b8 has been pushed to the Fedora 34 Flatpaks testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2021-bdfe4149b8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-FLATPAK-2021-bdfe4149b8 has been pushed to the Fedora 34 Flatpaks stable repository. If problem still persists, please make note of it in this bug report.