I noticed that the readme uses "container image" in other places. Should I call it (the mentioned li

I noticed that the readme uses "container image" in other places. Should I call it (the mentioned line) "published image" or "published container image"?

AArcitec I noticed that the readme uses "container image" in other places. Should I call ...

xyny•5/16/23, 4:48 PM

I 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.

ArcitecOP•5/16/23, 4:49 PM

Agreed, it reads more nicely too.

ArcitecOP•5/16/23, 4:51 PM

@hermmm The fix is pushed. Was there anything else that needs doing before TV?

AArcitec @hermmm The fix is pushed. Was there anything else that needs doing before TV? �...

xyny•5/16/23, 4:51 PM

You're good for TV!

ArcitecOP•5/16/23, 4:52 PM

Sweet, time to see episode 2 of The Wire!

Hope you have a nice evening in Finland too!

xyny•5/16/23, 4:52 PM

Everything is done and dusted, well, it never is, but regarding this PR yes.

AArcitec Sweet, time to see episode 2 of The Wire! 😄 Hope you have a nice evening in Fin...

xyny•5/16/23, 4:52 PM

Thanks, you too!

ArcitecOP•5/16/23, 4:56 PM

Last 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.

ArcitecOP•5/16/23, 4:57 PM

https://tenor.com/view/network-confused-john-travolta-wire-gif-5799547

Tenor

ArcitecOP•5/16/23, 4:57 PM

^ Now it's time for The Wire!

j0rge•5/16/23, 4:59 PM

yeah we can't run stuff on forks and PRs

j0rge•5/16/23, 4:59 PM

like 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)

xyny•5/16/23, 5:06 PM

Now that you're here @j0rge , could you go ahead and rename

main

main

in startingpoint to templatetemplate if that is possible, as I seem to lack the required permissions or knowhow to do it.

j0rge•5/16/23, 5:07 PM

nor me, but we're about to find out lol

xyny•5/16/23, 5:08 PM

Well it changed!

xyny•5/16/23, 5:08 PM

So thanks

xyny•5/16/23, 5:12 PM

BTW, 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.

bsherman•5/16/23, 5:16 PM

this probably should have it's "fork" threads cut https://github.com/ublue-os/startingpoint

edit: more specifically, it shouldn't be a "fork" of ublue-os/baseublue-os/base and show how far ahead/behind it is from ublue-os:mainublue-os:main

xyny•5/16/23, 5:18 PM

what does that mean

bsherman•5/16/23, 5:18 PM

it's a standalone thing

xyny•5/16/23, 5:19 PM

yeah yeah that's true

bsherman•5/16/23, 5:19 PM

i think it can be done, but may be a github support ticket

xyny•5/16/23, 5:19 PM

i just created it as a fork originally, because that was the easiest way

Bbsherman i think it can be done, but may be a github support ticket

xyny•5/16/23, 5:20 PM

It's a Github support ticket with a bot that does it in like max 10 min, I've done it before.

xyny•5/16/23, 5:20 PM

https://support.github.com/contact?flow=detach_fork&subject=Detach%20Fork&tags=rr-forks

GitHub Support is here to help. Learn about GitHub products, browse our helpful resources, and contact support with your questions.

Xxyny It's a Github support ticket with a bot that does it in like max 10 min, I've do...

bsherman•5/16/23, 5:20 PM

yeah, 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!

xyny•5/16/23, 5:21 PM

~~you do it~~

xyny•5/16/23, 5:22 PM

or I guess @j0rge and @marcoceppi are the only ones that can do it

j0rge•5/16/23, 5:23 PM

ok trying it

Bigpod•5/16/23, 5:55 PM

isnt it a setting to disasocate it from what it is based on

AArcitec My recommendation would be to: - Move <https://github.com/ublue-os/bluefin/blob...

bsherman•5/16/23, 5:56 PM

you want some feedback on this recommendation?

Bbsherman this probably should have it's "fork" threads cut https://github.com/ublue-os/s...

ArcitecOP•5/16/23, 6:30 PM

Definitely. 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.

Xxyny Well it changed!

ArcitecOP•5/16/23, 6:30 PM

The rename even propagates to forks of startingpoint. This is cool!

Bbsherman you want some feedback on this recommendation?

ArcitecOP•5/16/23, 6:32 PM

Yes 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!

AArcitec Yes would love to. But I was gonna mention that I figured out another big issue ...

bsherman•5/16/23, 6:33 PM

look at this: https://discord.com/channels/1072614816579063828/1087140903031943178/1107849123610234930

AArcitec Yes would love to. But I was gonna mention that I figured out another big issue ...

akdev•5/16/23, 6:43 PM

I think trying to fix home directory configuration hysteresis is out of scope for ostree-based systems so if you keep going this way you can probably find this problem with anything that writes to the home

akdev•5/16/23, 6:44 PM

Clean rebasing would need something to deal with all the homedir stuff

j0rge•5/16/23, 6:44 PM

yeah

j0rge•5/16/23, 6:45 PM

I am totally fine being like "hey so dconf is old so like, here's the gotchas when rebasing."

j0rge•5/16/23, 6:45 PM

like I'm not filing issues on kde/gnome's home settings and paths, I ain't got time for that

ArcitecOP•5/16/23, 6:50 PM

gonna move this message to bluefin

ArcitecOP•5/16/23, 10:21 PM

Sherman and I discovered that we don't seem to be calling "cleanup" anywhere, which means that we're shipping the RPM caches of all installed packages. That's a lot of useless data.

ArcitecOP•5/16/23, 10:22 PM

RUN rpm-ostree install NetworkManager-wifi NetworkManager-wwan wpa_supplicant wireless-regdb && \
    rpm-ostree cleanup -m && \
    ostree container commit

RUN rpm-ostree install NetworkManager-wifi NetworkManager-wwan wpa_supplicant wireless-regdb && \
    rpm-ostree cleanup -m && \
    ostree container commit

This example of how to clean caches is given by cgwalters: https://github.com/coreos/rpm-ostree/issues/4178

ArcitecOP•5/16/23, 10:23 PM

I've done a ripgrep across all repo files and can't see cleanup anywhere:

rg --hidden 'ostree.*cleanup'

rg --hidden 'ostree.*cleanup'

ArcitecOP•5/16/23, 10:24 PM

Wait, maybe this is a false alarm. I was looking at fixing startingpoint and noticed that it does manual cleanup. I guess all repos do it this way.

RUN rm -rf \
        /tmp/* \
        /var/* && \
    ostree container commi

RUN rm -rf \
        /tmp/* \
        /var/* && \
    ostree container commi

ArcitecOP•5/16/23, 10:25 PM

It's only being done in startingpoint and main.

ArcitecOP•5/16/23, 10:25 PM

rg -g 'Containerfile' --hidden 'var'
os-startingpoint/Containerfile
35:        /var/* && \

os-main/Containerfile
19:RUN rm -rf /tmp/* /var/*
21:RUN mkdir -p /var/tmp && chmod -R 1777 /var/tmp

rg -g 'Containerfile' --hidden 'var'
os-startingpoint/Containerfile
35:        /var/* && \

os-main/Containerfile
19:RUN rm -rf /tmp/* /var/*
21:RUN mkdir -p /var/tmp && chmod -R 1777 /var/tmp

AArcitec Wait, maybe this is a false alarm. I was looking at fixing startingpoint and not...

bsherman•5/16/23, 10:26 PM

yeah, but this is a good example where its a different step from another RUN where we do installs

and each RUN is a layer, so cleanup happens too late

ArcitecOP•5/16/23, 10:26 PM

Yep, exactly. And nvidia image doesn't clean up.

ArcitecOP•5/16/23, 10:26 PM

Out of the repos I have cloned (main, nvidia, startingpoint), only main and startingpoint wipe out temp files.

I noticed that the readme uses "container image" in other places. Should I call it (the mentioned li

Similar Threads

Similar Threads

Similar Threads