It's a Github support ticket with a bot that does it in like max 10 min, I've done it before.
It'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!
AI 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
AClean rebasing would need something to deal with all the homedir stuff
Jyeah
JI am totally fine being like "hey so dconf is old so like, here's the gotchas when rebasing."
Jlike I'm not filing issues on kde/gnome's home settings and paths, I ain't got time for that
Agonna move this message to bluefin
ASherman 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.
AThis example of how to clean caches is given by cgwalters: https://github.com/coreos/rpm-ostree/issues/4178
AI've done a ripgrep across all repo files and can't see cleanup anywhere:
rg --hidden 'ostree.*cleanup'AWait, 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.
AIt's only being done in startingpoint and main.
AByeah, 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
and each RUN is a layer, so cleanup happens too late
AYep, exactly. And nvidia image doesn't clean up.
AOut of the repos I have cloned (main, nvidia, startingpoint), only main and startingpoint wipe out temp files.
BAWe should change to the rpm-ostree cleanup call if that works
ADoes it clean /tmp?
Bno, it just cleans the rpmdb metedata stuff
AI was thinking the same but I think it only cleans
/var/cache folders related to rpms (downloaded packages).Jwe should check
Jwhen we started we had to do all this cleanup
Jand at some point colin told us that the ostree container commit was good enough
AJlike I am reasonably certain we don't need to rm anything anymore or do the cleanup -m
AYeah definitely not good enough, since cgwalters said to use cleanup 
https://github.com/coreos/rpm-ostree/issues/4178#issuecomment-1331441533
https://github.com/coreos/rpm-ostree/issues/4178#issuecomment-1331441533Jbut I could be wrong
Bi think its good enough IF run in the same layer (RUN line)
Jis thaty the newest thing we can find?
ADunno but nov 2022 is new.
Jbecause something in rpm-ostree from november might as well be written on a clay tablet
Jso it could go either way, heh
Bcolin walters is a machine
Bcranking out the goodness
JGitHub
Contribute to coreos/layering-examples development by creating an account on GitHub.
Jthis is what we want right?
A^ So it turned out that the containerfiles have different names in the nvidia image. Turns out they do cleanup of
vartmp too.BThere's no need to debate this. Just test it and demonstrate if it's helpful or not.
AThen we probably need a script to clean /tmp too
