This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Dconf dot separator rather than a slash #402
Description
Describe the bug
Exporting system dconf setting to be converted and used in NixOS, the resulting cawbird entry in the dconf dump, uses a dot separator rather than the usual slash -> [uk.co.ibboard.cawbird]
dconf dump / > dconf.settings`
produces;
[uk.co.ibboard.cawbird]
round-avatars=false
startup-accounts=['account_name']
window-geometry={'account_name': (30, 26, 694, 1182)}
Rather than the usual;
[org/gnome/nautilus/window-state]
initial-size=(2115, 738)
maximized=false
sidebar-width=485
start-with-sidebar=true
I cannot find that dconf accepts a dot separator and am not sure if it is a bug with the way cawbird saves its dconf config, or whether a dot separator is valid in dconf?
Activity
IBBoard commentedon Oct 4, 2021
I noticed it a while back when poking around in DConf Editor. I suspect it happened prior to v1.0 when I did a find-and-replace of
org.badert.Cawbirdwithuk.co.ibboard.Cawbird. But if it took the original as a regex then it would match slashes between and replace with dots.Since it works fine in Gnome then I've not fixed it. Partly because I don't want to change what isn't (obviously) broken and partly because I don't know how we'd migrate the settings across cleanly.
If someone knows how to migrate settings then we can look at fixing it so that stricter platforms handle our DConf settings as well. It's probably the gsettings path that's causing it.
CodedOre commentedon Oct 5, 2021
It's indeed the path that would need to be changed.
Have just tested it quickly using the keyfile backend (Flatpaks method where it stores the settings in a file), and here is what I can say:
If you change the path Cawbird will store new settings in the new path, but is still able to use old settings. Would be interesting if someone could check with the dconf-setting as well.
I think this could be something that Cawbird 2.0 could do. As we might already change some settings (maybe not, but who knows?), we probably would already have to include code to take over existing settings, so we could just read the settings from the old path and save them on the new when starting the first time.
mannp commentedon Oct 5, 2021
Thanks both for your input 👍🏻 I too did a little test converting [uk.co.ibboard.cawbird] to [uk/co/ibboard/cawbird] and saw no ill effects when rebuilding my nix config.
Little comfort for you though I guess, but looking at the settings that are saved in the dconf in my case they seem minimal to have to reselect, if you are not able to read them and write them back with slashes.
The startup account will be the same for people with only one twitter account entered and the window location and icon type.
The key config appears to be saved in .config.cawbird for me, so at least my accounts etc are not being reset by this change.
IBBoard commentedon Oct 5, 2021
I'll have to check how easy it is to access keys that aren't ours (I'd assumed that packaging the schema also gave us control, but I guess people can query Gnome settings etc).
If we can just package the correct path and copy settings when (for example) the geometry is empty then that should work. Assuming we can do it in a way that fails cleanly and doesn't crash when a first-time user uses the post-change version and it looks for old keys that don't exist!
IBBoard commentedon Oct 16, 2021
I was just looking at this and trying to work out how to fix it. It looks like we create a
GLib.Settingsobject by ID, which then finds the schema and looks up its path.To port the user's settings between dotted and slashed then I need to access to both, which needs a schema for both. I think I know how do it but the big problem might be that the old schema will still exist, which probably means that it's going to remain in the dump.
I need to think a bit more and explore the API a bit more to understand what solves the underlying problem (wrong path format) and what solves the resulting bug (dconf dump is invalid)
[-]Dconf dot separator rather than a slash? Valid or a bug....[/-][+]Dconf dot separator rather than a slash[/+]mannp commentedon Oct 16, 2021
Sounds good, thanks for working through the potential solutions 👍
IBBoard commentedon Oct 16, 2021
I think I've got a solution. And it wasn't too painful. I just had to find out a semi-hidden feature of GSchema files by digging around in the XML DTD!
Since you're trying to convert dconf for NixOS, can I assume that you know how to build a custom Cawbird for testing? 🙂
Re #402: Fix dconf separator without setting loss
mannp commentedon Oct 16, 2021
A potential solution is great :)
Well the general answer is 'very likely' but not perhaps in NixOS as I am currently testing it for a couple of months after using Arch Linux for many years.
Building on Arch and dumping the dconf might help which I am happy to do.
Happy to do some research how to do it on NixOS, but it might not be fast :)
IBBoard commentedon Oct 16, 2021
@schmittlauch might be able to help - I believe they made the original NixOS config. I don't know how "local builds" works, though 🙂
I'm running the patches on my local copy now. I'll put it in Unstable in a bit. I just need people to check that it doesn't break things (or forget existing settings).
schmittlauch commentedon Oct 16, 2021
@mannp Building cawbird from a newer commit is pretty straight forward:
From a nixpkgs repo clone:
pkgs/applications/networking/cawbird/default.nix, updaterevto the desired commit hash. Also change thesha256hash to make sure a re-download is triggered, I just randomly change one of the hash characters to0to obtain a different valid hash.nix build -f . cawbird. You'll get a build error containing the actual correct hash of the new downloaded sources.nix build -f . cawbird. This should build successfully now../result/bin/cawbirdschmittlauch commentedon Oct 16, 2021
Regarding dconf, I don't really have a clue about that honestly ^^
As NixOS does not sandbox applications somehow and by default – unless you try to explicitly populate dconf like @mannp wants to do – still provides a user-global dconf store that is statefully modified by applications at runtime, just like in each other distribution.
I also use dconf that way, so I'm interested in whatever @mannp is trying to achieve, how that works, and whether it's successful. So far, the nixpkgs cawbird build from commit 541b0d7 is not working well though:
While it still loads tweets, I get a lot of dconf schema warnings.
Details
and so on
mannp commentedon Oct 16, 2021
@schmittlauch I am using dconf2nix and tried to convert my dconf dump, link in my first post, but it failed due to this issue.
I logged an issue with dconf2nix and the dev flagged the none standard dconf delimiter.
Hey and thanks for the build howto 🙂
IBBoard commentedon Oct 17, 2021
@schmittlauch Those errors are a bit odd. ca.desrt.dconf has nothing to do with us, and all I've really done is change the path on the schema. As long as you've rebuilt your DConf schemas then everything should just work as before (with the tricky bit being whether we migrate settings or not).
The top results on Google for that error are all NixOS related ;)
schmittlauch commentedon Oct 17, 2021
It's hard to say whether things have been migrated, in
dconf dump /I cannot find any trace of cawbird, neither with dots nor with slashes. I still found some old corebird settings though.IBBoard commentedon Oct 18, 2021
Odd. It looks like
dconf dumponly dumps customised settings but you should at least havestartup-accountsandwindow-geometryset if nothing else.schmittlauch commentedon Oct 18, 2021
Okay, turns out that this is the result of no dconf daemon running. I'm running this under KDE Plasma, which does not enable a dconf daemon by default, that's only done for Gnome/Mate/Cinnamon/Pantheon/…. See NixOS/nixpkgs#73880 (comment) for reference.
So after enabling the dconf, schema migration works fine. At least if it isn't supposed to delete the dotted schema, that one is still there.
IBBoard commentedon Oct 19, 2021
I've not been deleting them for now on the basis that 1) I wanted to be able to test it without it wiping my settings each time! and 2) if users are concerned about the old settings (like mannp's situation) then they go away with a manual reset of those settings. But I could probably add it to be tidy.
Re #402: Delete transferred keys
IBBoard commentedon Oct 24, 2021
I've decided that it makes sense to tidy the settings up, and I'm fairly comfortable that it's working. If we were transferring old Corebird settings then we definitely shouldn't, and if we change things between 1.x and 2.x then we probably shouldn't (in case people want to go back) but this is going to be a 1.x to 1.x upgrade, so it seems reasonable and right and people rolling back (probably) 1.5 to 1.4.1 just have to deal with lost settings.
Re #402: Fix dconf separator without setting loss
Re #402: Delete transferred keys
IBBoard commentedon Dec 5, 2021
Finally merged with Master since no-one complained of any issues in Unstable.