Jyeah that's much nicer in general
COooo, tidy!
JGitHub
RPM OSTree is getting new functionality to use containers as the base
image. Thanks to that it's possible to use standard container
repositories.
This source enables to use these repositories.
...
image. Thanks to that it's possible to use standard container
repositories.
This source enables to use these repositories.
...
Jthey're getting close
Jok we'll need to add the file stuff to the readme, I'll try to get to that later
JAlright, I turned this on org-wide everyone
M@j0rge I'll update the action to drop the label requirement
JI'd like to sort out our label story ... but that, is a fight for another day
Xnp, cheers!
XI was going to try it in a vm too, I created a vm with the same password as my host but I got a typo in it and now I have clean silverblue a vm I'm locked out of...
XAlso: I'm probably going to be updating the Making your own page in the docs, but the base repository should probably link to it as a guide for people forking, as both guides are currently about forking base.
JI create one VM, install it, then I run through the first run of it, adding my username, etc. and then I shut that down, then I take a snapshot of it and then never touch it again, when I test a new thing I call it "silverblue-pr-79" for example
Jbut virt-manager is kinda clunky
XI was supposed to ostree pin the vanilla image, but I guess it's no use now. Next time round I'll maybe use another password...
Jyeah the reason I VM, especially with base is that we're touching flatpaks and I don't want to mess with that on my host
XI used to use virtualbox and TBH virt-manager is pretty good, atleast as good as virtualbox. After installing the correct packages it just works. I tried the gnome Boxes flatpak, and it didn't work one bit, so I gave up and added virt-manager in my container. It's a breeze.
Boh, you don't need libvirtd and friends in the silverblue host? just virt-manager and deps in a distrobox container is good enough?
JJlooks like they won't be switching until F39
XBy container-layering I meant not exactly layering by running rpm-ostree installs on the host but installing it in my own rpm-ostree native container image. I don't know if installing in a distrobox would cut it, as as far as I know some of the required deps have some kernel-level interfaces and need to be priviliged on the host.
XSorry for saying it in a bit of a confusing way, I'm not sure what would be a better term for it.
BOk, yes, what you meant is what I would have expected. I was surprised that perhaps one could make it work with what I thought I read.
Bmaybe "host container image"?
it's a new world of terminology
it's a new world of terminology
Xor native container, as that's what they're officially
Xinstalling in native container
adding to native container
adding to native container
BI've been meaning to add libvirtd & virt-manager to my native container image as well, also because the Gnome Boxes flatpak doesn't work well... and really, even when Boxes works, it's still not as good.
Jyou mean just a container right?
J"native container" doesn't seem to make sense in this context to me?
Jyeah the reason I use virt-manager is gnome boxes was just too unreliable for me, flatpak or otherwise. I'll give it a shot next cycle because the ui is nice.
Xnative container as in Ostree Native Container
BI'm going to try, because why not:
C...
BYeah, so, it's what I had assumed... virt-manager is happy to live in a distrobox container as it's just a frontend, but libvirt needs to be on the host
XAhh, cool. I wont be switching to that though as I'd rather just have all the vm-related things on host then.
DGitHub
Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available...
Bah, yes, a rootful container is needed, doable...
thanks for sharing, I knew I'd seen something about it.
thanks for sharing, I knew I'd seen something about it.
XYall didn't really provide any comments about this so I'm publishing a well-documented "demo" version as I can now add repos to the org myself.
XXGitHub
Contribute to ublue-os/images-website development by creating an account on GitHub.
JGitHub![build(deps): bump actions/checkout from 2 to 3 by dependabot[bot] ·...](https://images-ext-2.discordapp.net/external/c6rO7J_VC3SoecMbX8fRlS6n-d_0VWdHWsOaVDACQqw/https/opengraph.githubassets.com/8d5548a5c0d4dd8b4fa682936f7426a753cb549a8c078baee37aad7a3e91ab4a/ublue-os/nvidia/pull/52)
Bumps actions/checkout from 2 to 3.
Release notes
Sourced from actions/checkout's releases.
v3.0.0
Updated to the node16 runtime by default
This requires a minimum Actions Runner version of...
Release notes
Sourced from actions/checkout's releases.
v3.0.0
Updated to the node16 runtime by default
This requires a minimum Actions Runner version of...
JI'm thinking of creating a ublue-os/mainline repo so that I can start to experiment with moving generally useful driver bits from the nvidia image into a general purpose upstream image. Is this a good idea?
JI'm envisioning something like
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/{$FLAVOR}-mainline:latestCSounds good to me
CI would enjoy being able to recommend ublue for the QoL instead of a cagey combination of SB and -Nvidia
Рhow would mainline differ from base?
JBase has QoL improvements but also has some first run functionality like installing flatpaks. What I'm proposing is a mainline image intended to be consumed by other images and doing little more than installing additional packages so they don't have to be layered
Рso base would be on top of mainline?
JIn theory, yes. It would be the upstream image in which all other images in the ublue-os organization could derive from
Рlike that?
