Yeah, it'll also install it when you install a gnome flatpak (which is how I discovered it) with the
Yeah, it'll also install it when you install a gnome flatpak (which is how I discovered it) with the system theme set.
ASurprisingly not.
ASo it seems to behave the same as nvidia/amd drivers: Installed on
flatpak update.
POh maybe it's because you're installing things as system flatpaks? I definitely had it auto install the theme flatpak when I installed another flatpak
AExact same result if I do --user instead. No theme.
AActually, wow, even though I said "no" to installing it during
So I can't test the thing you're saying. ^^ It's glued in there now. So there's a good chance that you're right that it installs itself during
flatpak update it has still installed itself, and if I try to remove it, it's saying that every Flatpak depends on it now, so they would uninstall too.So I can't test the thing you're saying. ^^ It's glued in there now. So there's a good chance that you're right that it installs itself during
flatpak install <something else> too.AYikes, dconf-editor as Flatpak was totally unusable. It was showing the wrong data (Flatpak environment's rather than the host's) and was unable to see the host environment at all. RIP to anyone who was using it:
https://github.com/flathub/ca.desrt.dconf-editor/pull/24
https://github.com/flathub/ca.desrt.dconf-editor/pull/26
Pretty amazing how those bugs escaped notice for 2111 days (first Flatpak release was on Aug 4, 2017).
https://github.com/flathub/ca.desrt.dconf-editor/pull/24
https://github.com/flathub/ca.desrt.dconf-editor/pull/26
Pretty amazing how those bugs escaped notice for 2111 days (first Flatpak release was on Aug 4, 2017).
AKind of an important tool for everyone building new defaults for immutable distros! 
A@hermmm and I are trying to figure out an appropriate name for a special branch on the
The layout will be:
-
-
We need a name for
Names that have been considered and rejected:
-
-
-
-
Uncertain names:
-
Leading names (clearest names so far):
-
-
startingpoint repo:The layout will be:
-
template: Untouched template branch, which comes from the startingpoint repo itself. People don't modify it. It's used for easy fast-forwarding / syncing of repos to update their local copy of the template.-
<something>: The ONLY branch that gets deployed (published) to GHCR. All other branches will merely build but won't deploy. This ensures total control over GHCR publishing.We need a name for
<something>.Names that have been considered and rejected:
-
deploy or deployment: Very accurate names but also very ugly word.-
public: I thought about it but all branches are public, so it makes no sense.-
release: Too confusing since Releases are a GitHub feature.-
production: Strange name.Uncertain names:
-
custom: Decent but doesn't make it clear to anybody that this is the ONLY branch that gets published to live GHCR.Leading names (clearest names so far):
-
publish: The only branch that is published to GHCR.-
live: The branch that goes live (deploys).
XI like live, it's a noun but implies the same thing
AI agree, it's a neat name.
XOther one could be
prod being short for productionAMaybe, but still unclear. I definitely think
live is the clearest name so far.XAgreed
AI would love to hear some other opinions to decide if we should settle on that name, think you'll be on in like 1-2 hours when we'll hopefully have heard someone else? Or should I just go for it and force-push new commits that switch to 
live? It's a good name, could get used to it quickly. AIt's a clear name, purpose is obvious, and it's not a verb so it doesn't sound weird in that way.
ASo depending on how you feel about it, I could have updated commits ready in 5 minutes.
XSure, but maybe read my other comment first. And excuse me for maybe not getting it.
ADidn't see it, reading now. Edit: I'll reply there to keep that discussion there.
Edit: I'll reply there to keep that discussion there.A@hermmm Okay the PR is updated and ready. Thanks for a good discussion, I really like the new name we came up with.
A@hermmm Sorry I didn't mean to click "disable auto-merge". Mistake. Let's re-enable it.
XRead my comment. Auto-merge is a new thing I think jorge turned on, and it requires the workflows to run. There's no other ways to merge.
AI am not sure. The repo's own existing workflow file should be the one that runs. It would be a literal exploit if I could submit a pull request where I change teh workflow to submit code to GHCR. I could literally make a PR to ublue-os/main that installs a virus if that were the case. 
So I dunno why it's not running the old workflow on the current PR! It should be running the old
Anyway, the changes are two things:
1. The publish to GHCR only happens if the branch is named
2. The auto-trigger workflows are changed to the following:
https://i.imgur.com/7EW7t9D.png
So I dunno why it's not running the old workflow on the current PR! It should be running the old
mainAnyway, the changes are two things:
1. The publish to GHCR only happens if the branch is named
live. That part is simple and is taken care of at the bottom of the workflow. No issues there.2. The auto-trigger workflows are changed to the following:
https://i.imgur.com/7EW7t9D.png
Imgur
XThe repo's own existing workflow file should be the one that runs. It would be a literal exploit if I could submit a pull request where I change teh workflow to submit code to GHCR.Hmm I wonder how PRs with changes to workflows are handled then...
AWhat this means is:
- Pull requests will only run builds when they target
- Cron schedule will run every branch every day.
- Pushes to branches will only run automatic builds if they target
- Any branch can manually trigger the workflow (that's
- Pull requests will only run builds when they target
live.- Cron schedule will run every branch every day.
- Pushes to branches will only run automatic builds if they target
live.- Any branch can manually trigger the workflow (that's
workflow_dispatch:).XI actually think that, since it's a PR coming from a branch outside the repo, it doesn't have the secrets and access, and thus can't push to GHCR.
XSo this PR might be running your workflow, actually.
AI dunno, it still makes no sense. The workflow inside the repo itself is the "action" that triggers.
X- Pull requests will only run builds when they target live.And this PR doesn't target live.
AHmm yeah it might be running MY local copy of the workflow instead of the upstream one i nstartingpoint.
XYeah the workflows and everything are in your repo.
AOkay that is good, that settles how workflows work in PRs. So they run in my local repo, not yours. Good security, phew.
XDo you even have the GHA enabled?
ANo. But I have some ideas how to fix this. We're gonna need some changes.
XAAh, yeah it's not visible there.
AI'm thinking atm, and will try to add
maintemplate to the auto-build targets.AAlternatively...
XWas just about to comment that.
XThen we'll just remove
mainWe could also just remove the list of branches to make every branch build no matter its name. Only
live gets published to GHCR. So that may be the most desirable?AI am pretty sure this https://i.imgur.com/7EW7t9D.png list of
branches: was the old-school "protect against push to GHCR" idea before I changed it to only push live.XWell, I don't know. If there's some in-repo development on a custom branch. I guess I should start making my PRs from a custom repo too to not pollute the template?
AI think removing
branches: filtering for the auto-build triggers would solve that. So that way every branch gets built no matter its name. We're exactly as safe as before, since the deploy/sign steps only run for live.AAnd the builds seem to happen in the PR sender's own home.
XSure, do it. I guess stressing GHA shouldn't cause any issues.
AHmm, you make a point actually. Do we WANT anything except
template (main atm) and live to build? If we want all other branches to be non-building, I could just list the exact branches.APeople can still trigger manual builds on all other branches by manually triggering the workflow (that's the
workflow_dispatch: trigger).A
So... let's list main, template and live.XWell, we don't exactly want-want it but it shouldn't cause any issues.
AYeah. This solution sounds good, I'll refactor the docs a little bit around it.
