Well it changed!

X

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

So thanks

X

xynyOP•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.

B

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/base

ublue-os/base

and show how far ahead/behind it is from

ublue-os:main

ublue-os:main

X

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

what does that mean

B

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

it's a standalone thing

X

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

yeah yeah that's true

B

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

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

X

xynyOP•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

X

xynyOP•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.

X

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

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

Contact us - GitHub Support

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

B

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!

X

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

~~you do it~~

X

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

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

J

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

ok trying it

B

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

B

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

A

Arcitec•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!

A

Arcitec•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?

A

Arcitec•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 ...

B

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

A

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

A

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

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

J

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

yeah

J

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

J

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

A

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

gonna move this message to bluefin

A

Arcitec•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.

A

Arcitec•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

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

A

Arcitec•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'

A

Arcitec•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

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

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

A

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

It's only being done in startingpoint and main.

A

Arcitec•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

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

B

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

A

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

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

A

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

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

B

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

As far as I'm concerned, this can be part of https://github.com/ublue-os/main/issues/94

A

akdev•5/16/23, 10:27 PM

We should change to the rpm-ostree cleanup call if that works

A

akdev•5/16/23, 10:27 PM

Does it clean /tmp?

Aakdev Does it clean /tmp?

B

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

no, it just cleans the rpmdb metedata stuff

Aakdev We should change to the rpm-ostree cleanup call if that works

A

Arcitec•5/16/23, 10:28 PM

I was thinking the same but I think it only cleans

/var/cache

/var/cache

folders related to rpms (downloaded packages).

J

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

we should check

J

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

when we started we had to do all this cleanup

J

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

and at some point colin told us that the ostree container commit was good enough

A

Arcitec•5/16/23, 10:29 PM

rg -g '*Containerfile*' --hidden 'var'
os-nvidia/install.Containerfile
21:RUN rm -rf /tmp/* /var/*
23:RUN mkdir -p /var/tmp && chmod -R 1777 /tmp /var/tmp

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

os-nvidia/build.Containerfile
36:COPY --from=builder /var/cache /var/cache

os/Containerfile
35:        /var/* && \

rg -g '*Containerfile*' --hidden 'var'
os-nvidia/install.Containerfile
21:RUN rm -rf /tmp/* /var/*
23:RUN mkdir -p /var/tmp && chmod -R 1777 /tmp /var/tmp

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

os-nvidia/build.Containerfile
36:COPY --from=builder /var/cache /var/cache

os/Containerfile
35:        /var/* && \

rg -g '*Containerfile*' --hidden 'var'
os-nvidia/install.Containerfile
21:RUN rm -rf /tmp/* /var/*
23:RUN mkdir -p /var/tmp && chmod -R 1777 /tmp /var/tmp

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

os-nvidia/build.Containerfile
36:COPY --from=builder /var/cache /var/cache

os/Containerfile
35:        /var/* && \

rg -g '*Containerfile*' --hidden 'var'
os-nvidia/install.Containerfile
21:RUN rm -rf /tmp/* /var/*
23:RUN mkdir -p /var/tmp && chmod -R 1777 /tmp /var/tmp

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

os-nvidia/build.Containerfile
36:COPY --from=builder /var/cache /var/cache

os/Containerfile
35:        /var/* && \

J

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

like I am reasonably certain we don't need to rm anything anymore or do the cleanup -m

Jj0rge and at some point colin told us that the ostree container commit was good enough

A

Arcitec•5/16/23, 10:29 PM

Yeah definitely not good enough, since cgwalters said to use cleanup

https://github.com/coreos/rpm-ostree/issues/4178#issuecomment-1331441533

J

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

but I could be wrong

Jj0rge and at some point colin told us that the ostree container commit was good enough

B

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

i think its good enough IF run in the same layer (RUN line)

J

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

is thaty the newest thing we can find?

A

Arcitec•5/16/23, 10:30 PM

Dunno but nov 2022 is new.

Similar Threads

Similar Threads

Similar Threads