We'll just have to instruct potential contributors with this issue to update their main branches
We'll just have to instruct potential contributors with this issue to update their main branches
AYeah I added a note about that in build.yml too. It's ready for final check/merge. 
AThis discovery also gives us another good reason why forks should keep an untouched "upstream main branch". Haha.
XTrue, 'xcept when working you'd probably want to set
live as the main branch for it to be the one displayed when opening the repoAOh yeah true, so they'd still have to rebase. Good thing my comment is phrased that way:
A"primary branch" is mentioned, phew.
AI was really surprised that PRs build using the fork's primary workflow. It feels very backwards, since that means upstream has no control over the workflow checks of PRs. I could then write a funny workflow that just succeeds instantly, and fool any upstream repo into accepting the "successful build".
ABut it makes some sense too, otherwise people could hog the upstream repo's build queue for their own PR spam.
ATo fix this, I really think GitHub should be using the fork's build queue + upstream's primary workflow. That'd be a good fix.
XYeah. But I'd've thought it at least used the divergent branch's workflow instead of the forks main branch's one
AYeah, that was the most nuts thing to me. Literally not even using the PR's own branch's workflow.
A@hermmm
AGot done just in time to watch some TV. 
AAh I see your comment, will do that first!
XStill got some complaints for ya!
AOkay I'll wait and do those now.
AI noticed that the readme uses "container image" in other places. Should I call it (the mentioned line) "published image" or "published container image"?
XI think container image is alright in the README, cause that's what it technically is. I think either is fine and I'd go with "published image" for the mentioned line.
AAgreed, it reads more nicely too.
A@hermmm The fix is pushed. Was there anything else that needs doing before TV?
XYou're good for TV!
ASweet, time to see episode 2 of The Wire! Hope you have a nice evening in Finland too!
Hope you have a nice evening in Finland too!XEverything is done and dusted, well, it never is, but regarding this PR yes.
XThanks, you too!
ALast minute thought: I just realized why forks don't run upstream's workflow when submitting PRs. Because that'd be the reverse security exploit: Then the upstream could create malicious actions that run in every fork that submits a PR, using the fork's secrets/credentials.
Likewise, PRs don't run on the upstream/target's build machine either, because that'd allow PRs to run exploits on the target infrastructure.
So yeah @j0rge : All Pull requests in all our repos run with the GitHub Actions workflow of the primary branch of the fork, using the fork's secrets/environments, using the fork's build queue/runner.
Therefore, we need to remind people to sync their fork's primary branch's workflow with upstream whenever they submit PRs.
Likewise, PRs don't run on the upstream/target's build machine either, because that'd allow PRs to run exploits on the target infrastructure.
So yeah @j0rge : All Pull requests in all our repos run with the GitHub Actions workflow of the primary branch of the fork, using the fork's secrets/environments, using the fork's build queue/runner.
Therefore, we need to remind people to sync their fork's primary branch's workflow with upstream whenever they submit PRs.
A
A^ Now it's time for The Wire!
Jyeah we can't run stuff on forks and PRs
Jlike at first we wanted to make per PR builds but to do that securely requires more infra so we tabled it (it's the last card allllll the way to the right on the board)
XNow that you're here @j0rge , could you go ahead and rename
maintemplate if that is possible, as I seem to lack the required permissions or knowhow to do it.Jnor me, but we're about to find out lol
XWell it changed!
XSo thanks
XBTW, how's it with the website? All the PRs seem to be failing (https://github.com/ublue-os/website/pulls). I just submitted two PRs the other day and there's another approved one from last week that hasn't merge yet because of build failures.
Bthis probably should have it's "fork" threads cut https://github.com/ublue-os/startingpoint
edit: more specifically, it shouldn't be a "fork" of
edit: more specifically, it shouldn't be a "fork" of
ublue-os/base and show how far ahead/behind it is from ublue-os:mainXwhat does that mean
Bit's a standalone thing
Xyeah yeah that's true
Bi think it can be done, but may be a github support ticket
Xi just created it as a fork originally, because that was the easiest way
XIt's a Github support ticket with a bot that does it in like max 10 min, I've done it before.
XGitHub Support is here to help. Learn about GitHub products, browse our helpful resources, and contact support with your questions.
Byeah, no complaints about how it got here, but i was just reading, looking at some of what y'all were discussing and I noticed that.
cool that it's so easy to do!
cool that it's so easy to do!
X
Xor I guess @j0rge and @marcoceppi are the only ones that can do it
Jok trying it
Bisnt it a setting to disasocate it from what it is based on
Byou want some feedback on this recommendation?
ADefinitely. We just got a ticket in ublue-os/base which got labeled inside ublue-os/startingpoint as "related". The ties need to be cut for sure.
The ties need to be cut for sure.AThe rename even propagates to forks of startingpoint. This is cool!
AYes would love to. But I was gonna mention that I figured out another big issue with how bluefin is forcibly writing to the dconf database of the system:
Rebasing away from bluefin breaks the system because all the bluefin settings (since they're settings rather than mere defaults) will stay behind.
On the other hand, if we soften it to use overridden per-image system defaults instead, then rebasing to bluefin would also break in reverse if a person rebases to bluefin but has modified some defaults on their system. Then those don't get synced.
So yeah it's a mess. Dconf was written long before the idea of rebasing between distros ever existed as a thought!
Rebasing away from bluefin breaks the system because all the bluefin settings (since they're settings rather than mere defaults) will stay behind.
On the other hand, if we soften it to use overridden per-image system defaults instead, then rebasing to bluefin would also break in reverse if a person rebases to bluefin but has modified some defaults on their system. Then those don't get synced.
So yeah it's a mess. Dconf was written long before the idea of rebasing between distros ever existed as a thought!
