I like that yafti can be configurable from being a informational pop-up, selection prompt, 1st time
I like that yafti can be configurable from being a informational pop-up, selection prompt, 1st time installer or OS configurator
FWe plan to use yafti as an selection prompt or informational pop-up where notifications are not enough for BlueBuild's
Specifically, when maintainer decides to automatically remove the flatpak, so that users can get a pop-up with info on why it's removed & get a prompt if they want it removed or not
default-flatpaks moduleSpecifically, when maintainer decides to automatically remove the flatpak, so that users can get a pop-up with info on why it's removed & get a prompt if they want it removed or not
Fwe considered Zenity also, but why reinvent the wheel with it when yafti exists
FThat's one aspect where I find yafti amazing
FThe scope of powerwash is not well defined in the issue imo.
https://github.com/ublue-os/main/issues/95
As can be noticed by latest comments.
It's either a full proper reset like Androids or it's just reset of some configs.
I prefer to go all in, as partial config reset is already possible to some extent.
https://github.com/ublue-os/main/issues/95
As can be noticed by latest comments.
It's either a full proper reset like Androids or it's just reset of some configs.
I prefer to go all in, as partial config reset is already possible to some extent.
GitHub
We should look at a functional equivalent of a ChromeOS "powerwash": https://support.google.com/chromebook/answer/183084?hl=en
FBut I'm looking forward to see that presentation, it's gonna be spicy heh
NI am storing state in gsettings make this type of functionality possible. Though, unless the python bindings get some love it might be a good idea to talk about rust... I would have went this direction if I knew how bad they have gotten ahead of time 
VFile location for flatpak:
Hkinda implemented this at work but i did it by just having a service remake the users homefolder at boot if it didnt exist, although our environment is a lot more predictable and 
/etc is entierly controlled by me the admin 
KThats a Monster!
Hey Kyle, how are your temps on your 6900 XT Noctua Mod under full load? :D
Hey Kyle, how are your temps on your 6900 XT Noctua Mod under full load? :D
Jyeah someone needs to drive concensus
JI agree it's important but I have other things on my plate, maybe someone else can drive
EI'm thinking two features here, but let's start with one:
Powerwash would mimic the behavior of ChromeOS and rinse would just reset any dangling configuration in the home directory
Personally, I'm significantly more interested in a
As for
just powerwash and just rinsePowerwash would mimic the behavior of ChromeOS and rinse would just reset any dangling configuration in the home directory
Personally, I'm significantly more interested in a
powerwssh so let's begin there:- We can wipe the contents of /home without ramification. All necessary configs will just be pulled from /etc. so that handles resetting home
- In an ideal world, we could just wipe /etc and /usr/etc would pick up the pieces, but that's far from the case. We need to determine what, following s fresh installation, is changed (and whether or not it's automated), pin those files, reset /etc, and restore the pinned files
As for
rinse, I think most conflicting configs when rebasing are out of .config. I've found removing that folder inconsequential but we should definitely explore that further at some point as I know KDE has skewed configs too. I think the dotfiles that get wiped should be explicitly set because we likely wouldn't want to clear out someone's Steam library for instance
Bi wish if we could powerwash/factory reset without being able to boot into OS
Bkinda like windows can
Bwell in theory you could just remov whole /etc and replace it with one from image
EI still think a generic Ublue image with restoration utilities could be helpful. Either install it on a flash drive or a separate partition, boot into it, run
just powerwash, decrypt the drive, and it does it's thing... but that's going way out of scope for an initial feature
DuRestore
Band it woild be hard to achieve currently at least with seperate partition
DuFixit yourself
J
Jcolin sent me this
Jif someone has time to go dig in and see what you can find that'd be awesome, context:
JBTW on the build system side...I did a spike on this: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base
- it significantly reduces the "rpm-ostree/ostree stuff" for the "base image from scratch" flow and is way more "container native". It's just a rough draft so far, I haven't tried using it "in anger" like to build a desktop with or anything, but I'm much happer with this as a landing spot than what we have with the existing rpm-ostree YAML bits.
Dhttps://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base#adding-arbitrary-content-making-arbitrary-changes
this is interesting, so DNF is being used instead of rpm-ostree?
this is interesting, so DNF is being used instead of rpm-ostree?
RDNF being used in the "builder" container, which is regular Fedora
This is then packaged as an OCI archive somehow and copied to the scratch image
This is then packaged as an OCI archive somehow and copied to the scratch image
Bi can look into this but yea as far as i know he want to achieve the end in which you deploy oci image without any ostree bits at all
Bwhat im sitll waiting for is bootupd to be able to do any distro
Bi really want to be able to make some other distros not just fedora
EThe build rationale is really comprehensive: https://gitlab.com/bootc-org/fedora-bootc/fedora-bootc-base/-/blob/main/README-build-rationale.md?ref_type=heads
FResetting gsetting is also useful & something I do in my image
Blooking at the containerfile its quite genious and works based on fedora:40 image not some special rpm-ostree image
ELooking at the build scripts and it's brilliant
EThis reminds me of how we handle 
-base packages in Wolfi E(but obviously not as clean, but it can't be given they have to work with specs)
EThey also have inconsistent pulls from Quay 
Bforget "significantly reduces" this nearly completely removes rpm-ostree from our consciousnesses regarding image builds!
pretty impressive!
and without using rpm-ostree, it's no wonder that bootc wipes out local package layers installed by rpm-ostree, it's just not part of the paradigm
pretty impressive!
and without using rpm-ostree, it's no wonder that bootc wipes out local package layers installed by rpm-ostree, it's just not part of the paradigm
Jyeah
Fhow would the local user uninstall the "dnf" package from this experimental image?
Jugh git submodules, don't like that
Bthe local user would not.
the entire design is to build images ... you want to customize? you build a new image with the changes
the entire design is to build images ... you want to customize? you build a new image with the changes
Jyeah this is the full move to The Final Shape, you're not bringing all that stuff forward, pure cloud native.
Bi actually think the reuse of spec here is pretty nice... it's well definied... rhel/fedora are very much RPM-centric, so resuing that to compose the whole OS image is cool
ENo problems there at all!
EI think it's great
Jyeah it lets you skip a step
Jlike imagine if we're just putting the specs in here
Bi don't read that as "git submodules are required" for custom images... just a possible way if you want to rebuild the world
Jfile issues and leave feedback, the more we give feedback the less work for us in the future.
Jyeah I know I was just in the mood to maybe try it now I'm like, ugh every time I run into those things it ruins an afternoon for me
