about switching from dconf to gschema overrides for gnome customization
I understand the caution. I think that issue with why your & Arcitec modification failed is because of the naming.
Bwe should probably thread this
FI think you used 50_ instead of 50- for naming gschema override
Fand that caused it to not implement the changes
FWhen using zzz-nameofoverride-gschema.override
Fyou will be ensured that modifications will apply
F.
This thread is about migration from dconf to gschema override for at least Bluefin & Bazzite, if people are not aware of what is talked about
This thread is about migration from dconf to gschema override for at least Bluefin & Bazzite, if people are not aware of what is talked about
Band referencing this PR https://github.com/ublue-os/bluefin/pull/858
FHere, I wrote in detail in how to get gschema working properly. I tested this on my own image & it works:
https://github.com/ublue-os/bling/issues/53#issuecomment-1915474038
https://github.com/ublue-os/bling/issues/53#issuecomment-1915474038
BFThe only thing I did not document in GitHub link is using
For now, it just reports the error, but keeps the build going.
--strict for automatic abort on error.For now, it just reports the error, but keeps the build going.
Binteresting that likely the only problem i had was "99_foo" instead of "99-foo"
FIf we agree on this change, I think we should have a time clearance on not merging any dconf stuff before this transition is completed
I could close the current PR & start again to ensure there are no conflicts, as there are some currently
I could close the current PR & start again to ensure there are no conflicts, as there are some currently
Bdon't worry about PR maintenance on this... i intend to test the concept for myself and on bluefin's behalf.
BI liked the idea months ago, and still do... just need some time to check it out.
FIt's a shame that
If we could include only our gschema override into this to make it work, it would be great
However, the only location is
--strict is failing because of 1 invalid key used by FedoraIf we could include only our gschema override into this to make it work, it would be great
However, the only location is
/usr/share/glib-2.0/schemas unfortunatelyFSo it would fail on errors for our gschema only
Jthis stuff is great and I think we need it, I just want to make sure we don't skew bazzite and bluefin away from each other. It's more of the timing issue since we're also close to the installer. we don't want to be in a major transition in both of those and then that day "hey the installer is ready let's go!"
Jlike I'm hoping to quiet bluefin down for a bit once we finish the quadlets
Jbut as a bonus, we do have a testing branch now
FI solved the conflicts, figured out
FI understand your point of view, but I think we can do transition without issues. I think it is a good time to transition around this period now, than after new installer is released.
As you said, you hope Bluefin quiets down around that period after
As you said, you hope Bluefin quiets down around that period after
FI mean, no rush of course
F@Kyle Gospo @EyeCantCU Are you open for this change in Bazzite too?
Kyes, though with the amount of gnome extensions we tweak I worry a bit
FAs long as extensions use /usr/share/glib-2.0/schemas location, you will be safe
FI only know Caffeine extension which doesn't do this, which should be fixed in spec file
Fin that case, dconf will suffice
Fwe have
-testing branch/image after all, where we can test each dconf/gsettings key when neededKawesome, yeah this looks like a great change then
Kall for it
Bto be clear, i understand this to mean, any extension NOT respecting the proper schema location simply can't be configured via the gschema override... it doesn't mean we break extensions
Fif that happens, dconf can suffice, as it does not care about schema locations
Frephrased once more, just to be clear
FI managed to add support for aborting on errors:
https://github.com/ublue-os/bluefin/pull/858/commits/4a47ba37dbe4457b5ea2c9df6aa008a471f58a89
https://github.com/ublue-os/bluefin/pull/858/commits/4a47ba37dbe4457b5ea2c9df6aa008a471f58a89
FHere's how it looks like for my image:
Success:
https://github.com/fiftydinar/gidro-os/actions/runs/7734127817/job/21087553625#step:14:1090
Fail:
https://github.com/fiftydinar/gidro-os/actions/runs/7734266214/job/21087947001#step:14:1084
I misstyped
Success:
https://github.com/fiftydinar/gidro-os/actions/runs/7734127817/job/21087553625#step:14:1090
Fail:
https://github.com/fiftydinar/gidro-os/actions/runs/7734266214/job/21087947001#step:14:1084
I misstyped
org.gnome.desktop.wm.preferences title-bar-font on purpose, proper key should be titlebar-font. Bluefin previously used the same incorrect key like I mentioned in example, which makes it perfect for fail demonstration.FAnd build-time is actually not increased, as gschema is compiled instantly. That was my mistake in commit note
Bok, i've marked the PR ready for review and commented my thoughts.
Bthanks for the work on this @fiftydinar
FNo problem.
I would like to ask something if I may.
Can you explain me how to test the image with this PR only? If I enable GitHub Actions & build with this PR branch, will it pull the ghcr.io/fiftydinar/bluefin image with those PR changes?
I would like to ask something if I may.
Can you explain me how to test the image with this PR only? If I enable GitHub Actions & build with this PR branch, will it pull the ghcr.io/fiftydinar/bluefin image with those PR changes?
Bfair question... but we don't push images to ghcr from our PR builds in ublue-os... so....
what i usually do is build the image locally and then manually push to a local container registry on another machine at home
what i usually do is build the image locally and then manually push to a local container registry on another machine at home
FI tested the image & everything works now except LogoMenu settings.
However, It's possible to fix it.
Check the updated PR which contains explanation.
However, It's possible to fix it.
Check the updated PR which contains explanation.
