and the zenity jank thing still needs to go, initially it was designed for new installs but if you l

and 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

Jjstone Do we want the version to match exactly, or do we want a minimum?

Kyle Gospo•2/26/23, 10:11 PM

Good 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

j0rgeOP•2/26/23, 10:12 PM

I'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

j0rgeOP•2/26/23, 10:13 PM

like, 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

j0rgeOP•2/26/23, 10:13 PM

Or we could just generate ISOs on a cron monthly and call it a day

Jj0rge and the zenity jank thing still needs to go, initially it was designed for new i...

jstone•2/26/23, 10:14 PM

This 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

j0rgeOP•2/26/23, 10:14 PM

so no first-boot in base at all?

Jj0rge so no first-boot in base at all?

Kyle Gospo•2/26/23, 10:17 PM

maybe include it but no config so it doesn't do anything?

Kyle Gospo•2/26/23, 10:17 PM

leave that up to downstream

jstone•2/26/23, 10:18 PM

Yeah, 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

Jjstone Yeah, have a ublue-os-base that does all of the generally useful package install...

Kyle Gospo•2/26/23, 10:18 PM

I like this

j0rgeOP•2/26/23, 10:19 PM

we'd need a handful of things in first boot still, namely a browser

j0rgeOP•2/26/23, 10:19 PM

we could make it so it's browser-only and then leave the rest to whatever file they plop on the disk for their flatpaks

jstone•2/26/23, 10:21 PM

In theory I'd be able to invoke

ARG BASE_IMAGE="ghcr.io/ublue-os/ublue-${IMAGE_NAME}"

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

j0rgeOP•2/26/23, 10:22 PM

that sounds like the promised land to me

j0rgeOP•2/26/23, 10:22 PM

because 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

j0rgeOP•2/26/23, 10:23 PM

I set my 2-in-1 to be our "builder hero dashboard" heh

jstone•2/26/23, 10:24 PM

ublue-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

jstone•2/26/23, 10:26 PM

If 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

nvidia/build.yml at main · ublue-os/nvidia

Vanilla Fedora variants with Nvidia drivers added. Contribute to ublue-os/nvidia development by creating an account on GitHub.

jstone•2/26/23, 10:28 PM

And you almost certainly wouldn't need to have signing keys

jstone•2/26/23, 10:33 PM

Maybe we want to have something like

ghcr.io/ublue-os/silverblue

ghcr.io/ublue-os/silverblue

, which then can be consumed by

ghcr.io/ublue-os/silverblue-ublue

ghcr.io/ublue-os/silverblue-ublue

and

ghcr.io/ublue-os/silverblue-nvidia

ghcr.io/ublue-os/silverblue-nvidia

j0rgeOP•2/26/23, 10:36 PM

sec I need to read that three times to double check

j0rgeOP•2/26/23, 10:36 PM

ok so the first one is just our QoL fixes

j0rgeOP•2/26/23, 10:37 PM

2nd one is ... ?

j0rgeOP•2/26/23, 10:37 PM

and the third ones is adding in the nvidia drivers?

jstone•2/26/23, 10:48 PM

```
ghcr.io/ublue-os/silverblue
```
```
ghcr.io/ublue-os/silverblue
```
: Installs various QoL packages (RPMFusion, ffmpeg, vaapi, etc) installed on top of Silverblue, essentially saves users a bunch of
```
rpm-ostree install $PACKAGE && reboot
```
```
rpm-ostree install $PACKAGE && reboot
```
commands

ghcr.io/ublue-os/silverblue-ublue

ghcr.io/ublue-os/silverblue-ublue

: Uses

ghcr.io/ublue-os/silverblue

ghcr.io/ublue-os/silverblue

as the base and includes the in-development first-boot functionality

ghcr.io/ublue-os/silverblue-nvidia

ghcr.io/ublue-os/silverblue-nvidia

: Uses

ghcr.io/ublue-os/silverblue

ghcr.io/ublue-os/silverblue

as the base and installs nvidia-specific packages

j0rgeOP•2/26/23, 10:51 PM

that sounds fine to me, the only issue is we'd have another rename for people to have to manually do

jstone•2/26/23, 10:51 PM

Having 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

j0rgeOP•2/26/23, 10:52 PM

that all sounds good to me

j0rgeOP•2/26/23, 10:54 PM

for the first one though

j0rgeOP•2/26/23, 10:54 PM

if someone wanted to do KDE let's say, that one is all QoL but still picks silverblue by default

j0rgeOP•2/26/23, 10:55 PM

I wonder if deriving base from base makes sense, and then the next image makes the desktop decision

jstone•2/26/23, 10:58 PM

There would be builds for every flavor, so for KDE we'd have

ghcr.io/ublue-os/kinoite

ghcr.io/ublue-os/kinoite

which is then used in

ghcr.io/ublue-os/kinoite-ublue

ghcr.io/ublue-os/kinoite-ublue

and

ghcr.io/ublue-os/kinoite-nvidia

ghcr.io/ublue-os/kinoite-nvidia

jstone•2/26/23, 11:00 PM

It shouldn't be very different from how the Containerfile for the nvidia image is parameterized

j0rgeOP•2/26/23, 11:04 PM

nod

j0rgeOP•2/26/23, 11:04 PM

ok sgtm

j0rgeOP•2/26/23, 11:05 PM

oh neat, I moved my Logitech RGB G915 to this machine and fired up openrgb and everything just worked, nice work on the rules.

j0rgeOP•2/26/23, 11:06 PM

ok so then my last question is, for the versions

j0rgeOP•2/26/23, 11:07 PM

I'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

ChaiQi•2/26/23, 11:23 PM

Side note, food for thought
Sequentially inheriting images remind me of something

ChaiQi•2/26/23, 11:24 PM

A basic, multiple choice, page-based install wizard

ChaiQi•2/26/23, 11:29 PM

Nothing 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?

ChaiQi•2/26/23, 11:31 PM

Probably not an idea for 1.0 if it's even worth doing, though

Marco (马可)•2/26/23, 11:45 PM

@j0rge this is a similar conversation to what we were having a week ago. @.jstone I like your proposal

j0rgeOP•2/26/23, 11:45 PM

yeah, what do we need to do next?

Marco (马可)•2/26/23, 11:46 PM

I think it's worth drafting up a discussion/proposal in the GH org

Marco (马可)•2/26/23, 11:46 PM

what images live where, what images contain what, and a proposed set of "As a user I want to make X" workflow would look like

j0rgeOP•2/26/23, 11:47 PM

yeah if we're going to make naming changes we should put some thought into it so we don't do it anymore

Marco (马可)•2/26/23, 11:48 PM

yes, 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}FROM ghcr.io/ublue/${some-base-image} then their customizations

Marco (马可)•2/26/23, 11:49 PM

that base could be just base, or silverblue, or silverblue-nvidia, or kinoite-nvida, etc

Marco (马可)•2/26/23, 11:49 PM

depending on what part of the opinionated stack resonates with them and where they want to diverge

and the zenity jank thing still needs to go, initially it was designed for new installs but if you l

Similar Threads

Similar Threads

Similar Threads