Yeah, have a ublue-os-base that does all of the generally useful package installs like the udev-rule

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

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

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

j0rge•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

jstoneOP•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

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

that sounds like the promised land to me

j0rge•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

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

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

jstoneOP•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

jstoneOP•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.

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

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

jstoneOP•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

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

sec I need to read that three times to double check

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

ok so the first one is just our QoL fixes

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

2nd one is ... ?

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

and the third ones is adding in the nvidia drivers?

jstoneOP•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

j0rge•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

jstoneOP•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

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

that all sounds good to me

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

for the first one though

j0rge•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

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

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

jstoneOP•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

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

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

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

nod

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

ok sgtm

j0rge•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.

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

ok so then my last question is, for the versions

j0rge•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

j0rge•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

j0rge•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

j0rge•2/27/23, 12:24 AM

anyone have an idea on this one? https://github.com/ublue-os/ubuntu/actions/runs/4277573095/jobs/7446670599

GitHub

feat: remove gnome-extensions · ublue-os/ubuntu@934feec

Fedora Silverblue for Ubuntu Expatriates. Contribute to ublue-os/ubuntu development by creating an account on GitHub.

j0rge•2/27/23, 12:24 AM

it works fine locally but errors out in the action, I'm just trying to remove gnome-extensions-app

j0rge•2/27/23, 12:29 AM

ah, got it to fail locally at least now

j0rge•2/27/23, 12:32 AM

this 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

Marco (马可)•2/27/23, 1:09 AM

Is it being added further up the chain?

Marco (马可)•2/27/23, 1:09 AM

in zenity or elsewhere?

j0rge•2/27/23, 1:40 AM

nope, not afaict

j0rge•2/27/23, 2:30 AM

I had dependabot turned on on base and it found a version update so PRing to other repos... sorry for the noise

Jj0rge I had dependabot turned on on base and it found a version update so PRing to oth...

Kyle Gospo•2/27/23, 6:09 AM

all good, merging that now, appreciate it

Yeah, have a ublue-os-base that does all of the generally useful package installs like the udev-rule

Similar Threads