CI can unlayer, update, and test the udev rules when they're shipped
KSolaar is for logitech mice
KI have the udev so it works in distrobox
Jyeah, I have one but I don't think I had to put rules in it
Kneeded for me, weird
Kcould be down to the mouse in use
Kand then for ffmpeg thumbnails and aptx as you mentioned @.jstone
Jyeah 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-firmwarealsa-firmware
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
ubuntuIntriguing
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 image