Do we want the version to match exactly, or do we want a minimum?
Do 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}"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
