yeah I have a gnome extension for the battery and libratbag
yeah I have a gnome extension for the battery and libratbag
CIt's probably packaged with Solaar which I use to configure mine
JI wonder why alsa-firmware isn't included
KJI got
alsa-sof-firmware, but no alsa-firmware
K
JI was showerthinking if it made sense to have all that codec stuff in a layer similar to the udev rules ...
K
Kthat's how mine works
K"Candy" is their wireless charging mousepad, for whatever reason
Jthis is what I have
Kclean, I like it
Jyeah the icon turns yellow when I need to charge it
JI think we could certainly do more sharing, like if there was a ublue-os base image that installed all of the extra nice-to-haves while the nvidia image continues to exist to specialize in catering to nvidia runtime support. I think the main thing holding me back from using the ublue base image is that it doesn't support all of the releases and flavors
Jyeah I haven't figured out how to grid out releases
Jbut someone started it last week but then kind of bailed, so not sure how to proceed other than asking for help, heh
Jbecause I'd also like to figure that out for
ubuntu so I can have nvidia builds as well for thatJCIntriguing
JWhat I also like about the upstream container images is that they're quite "pure". If there was a ublue-os image that existed to just install additional runtime packages within rpm-ostree and separated the first-boot additions into another layer, then that'd be really nice
JMany of these packages for example I think would be generally useful for anyone wanting to consume a base ublue-os image https://github.com/ublue-os/nvidia/blob/main/Containerfile#L103
GitHub
Vanilla Fedora variants with Nvidia drivers added. Contribute to ublue-os/nvidia development by creating an account on GitHub.
JOnly a few of these like nvtop and nvidia-vaapi-driver are actually necessary for nvidia
CI'm all for wide-reach QoL and modularity
CWe've demonstrated that the Nvidia drivers, multiple channels, and date tags work remarkably well. I don't really know what more could be done for them aside from tacking on new ones for F38 eventually. From the outside looking in with a Nvidia card, I think shifting focus to other use cases enabled by similar tools and images makes sense
JDo we want the version to match exactly, or do we want a minimum?
JIt's looking like we're close to officially reaching 1.0 status if we've implemented all of the major features and are just doing routine updates 
Jwe're missing 2 things I think
JISOs
Jand the zenity jank thing still needs to go, initially it was designed for new installs but if you look in #general we need to make it so people can cancel out of it
KGood question, not sure on that one. Nothing seems to care about the version but matching upstream makes sense since if they change something we're immediately aware and can pull in those changes and update the provides
JI've also been thinking, the part for adding rebasing to a custom image will be added to the installer, there's probably a lot of things we could be doing to automate the ISO generation and stuff so when the feature lands we'd be ready
Jlike, I was thinking, when you do a release and merge the release action bot message thing, that should be an explicit "generate ISOs", then we set the release action thing to fire off once a month instead of every PR
JOr we could just generate ISOs on a cron monthly and call it a day
JThis I think it a great justification for breaking up ublue-os into a base image that's generally designed for consumption, and have the first boot functionality provided in another image which consumes it so there's a separation of concerns and there's more sharing
Jso no first-boot in base at all?
Kmaybe include it but no config so it doesn't do anything?
Kleave that up to downstream
JYeah, have a ublue-os-base that does all of the generally useful package installs like the udev-rules packages, codecs, ffmpeg package swaps, ffmpegthumbnailer, etc, that're almost always what people look to install and can be used by other images in our organization, and have a ublue-os-firstrun (gonna workshop that one) which includes all of the firstboot functionality that's being working on
KI like this
Jwe'd need a handful of things in first boot still, namely a browser 
Jwe could make it so it's browser-only and then leave the rest to whatever file they plop on the disk for their flatpaks
JIn theory I'd be able to invoke
ARG BASE_IMAGE="ghcr.io/ublue-os/ublue-${IMAGE_NAME}" and skip having to install rpmfusion and ffmpeg knowing they'd already exist in the base imageJthat sounds like the promised land to me
Jbecause I want to add an ffmpeg thumbnailer to my image but I also don't want to do all the rpmfusion stuff by hand if someone else is doing it somewhere else
JI set my 2-in-1 to be our "builder hero dashboard" heh
Jublue-os/ublue-* would essentially be the place for people to file generally useful QoL enhancements and all other images in our organizations will automatically pull in these enhancements with a daily rebuild
JIf I'm looking at this right, the support matrix for such an image should be vastly simpler since there would be no driver streams. It'd be 9 builds for both F37 and F38 as well as the various DEs? https://github.com/ublue-os/nvidia/blob/main/.github/workflows/build.yml#L30
GitHub
Vanilla Fedora variants with Nvidia drivers added. Contribute to ublue-os/nvidia development by creating an account on GitHub.
JAnd you almost certainly wouldn't need to have signing keys
JMaybe we want to have something like
ghcr.io/ublue-os/silverblue, which then can be consumed by ghcr.io/ublue-os/silverblue-ublue and ghcr.io/ublue-os/silverblue-nvidia ?Jsec I need to read that three times to double check
