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}"that 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/silverblueghcr.io/ublue-os/silverblue-ublueghcr.io/ublue-os/silverblue-nvidiasec I need to read that three times to double check
Jok so the first one is just our QoL fixes
J2nd one is ... ?
Jand the third ones is adding in the nvidia drivers?
J
: Installs various QoL packages (RPMFusion, ffmpeg, vaapi, etc) installed on top of Silverblue, essentially saves users a bunch ofghcr.io/ublue-os/silverblue
commandsrpm-ostree install $PACKAGE && reboot
: Usesghcr.io/ublue-os/silverblue-ublue
as the base and includes the in-development first-boot functionalityghcr.io/ublue-os/silverblue
: Usesghcr.io/ublue-os/silverblue-nvidia
as the base and installs nvidia-specific packagesghcr.io/ublue-os/silverblue
Jthat sounds fine to me, the only issue is we'd have another rename for people to have to manually do
JHaving a separation of concerns like this ensures that we can have enhancements that're immediately useful for other images and having experimental functionality in another layer
Jthat all sounds good to me
Jfor the first one though
Jif someone wanted to do KDE let's say, that one is all QoL but still picks silverblue by default
JI wonder if deriving base from base makes sense, and then the next image makes the desktop decision
JThere would be builds for every flavor, so for KDE we'd have
ghcr.io/ublue-os/kinoiteghcr.io/ublue-os/kinoite-ublueghcr.io/ublue-os/kinoite-nvidiaIt shouldn't be very different from how the Containerfile for the nvidia image is parameterized
Jnod
Jok sgtm
Joh neat, I moved my Logitech RGB G915 to this machine and fired up openrgb and everything just worked, nice work on the rules.
Jok so then my last question is, for the versions
JI'm still unsure of how best to handle supporting 37, 38, and 39 let's say if we need changes in containerfiles and all the other stuff
CSide note, food for thought
Sequentially inheriting images remind me of something
Sequentially inheriting images remind me of something
CA basic, multiple choice, page-based install wizard
CNothing fancy, just a simple thing pulled from a GUI template to basically piece together the command to pull the right image, but I wonder if it could help some people transition and set up by hiding the back-end of modular repos and, what, 30+ images?
CProbably not an idea for 1.0 if it's even worth doing, though
M@j0rge this is a similar conversation to what we were having a week ago. @.jstone I like your proposal
Jyeah, what do we need to do next?
MI think it's worth drafting up a discussion/proposal in the GH org
Mwhat images live where, what images contain what, and a proposed set of "As a user I want to make X" workflow would look like
Jyeah if we're going to make naming changes we should put some thought into it so we don't do it anymore
Myes, that partially as well. I'd like to get us to a point that people instead of forking base and cargo culting (as they'll miss really good changes we make in base) work to a format of
FROM ghcr.io/ublue/${some-base-image} then their customizationsMthat base could be just base, or silverblue, or silverblue-nvidia, or kinoite-nvida, etc
Mdepending on what part of the opinionated stack resonates with them and where they want to diverge
Janyone have an idea on this one? https://github.com/ublue-os/ubuntu/actions/runs/4277573095/jobs/7446670599
GitHub
Fedora Silverblue for Ubuntu Expatriates. Contribute to ublue-os/ubuntu development by creating an account on GitHub.
Jit works fine locally but errors out in the action, I'm just trying to remove gnome-extensions-app
Jah, got it to fail locally at least now
Jthis is odd indeed, I can remove the package just fine on my machine but if I do it in a containerfile it's the same error
MIs it being added further up the chain?
Min zenity or elsewhere?
