like herm's pr I want to test in a VM to test all the flatpak installation, etc.
like herm's pr I want to test in a VM to test all the flatpak installation, etc.
Byea its a dilema
MThe current workflow we have fixes that
Mwhich is a pull_request that pushes to an artifact on the run, then a second run that executes when that workflow completes, using the artifact that was uploaded to publish
M@j0rge I'm going to dig back in and finish up what we were doing last night
MIf we use the above require approval for all outside contributors we can remove the need to use PR labels
MActually, I guess using ECR for PR pushes and GHCR for prod would be good (or any other registry)
J@marcoceppi I hadn't thought about that "Require approval" setting in github, I think if we had that we wouldn't want the label
MYeah, I think we can use that and drop the label
J@herm @marcoceppi tested PR-79 in a vanilla VM and everything worked perfectly!
M@j0rge you can approve and merge 
Jyeah on it
JGitHub
Base image: Silverblue with unfiltered Flathub, distrobox, and automatic updates - base/Containerfile at main · ublue-os/base
Joh yeah
Jmuch cleaner now too
J
Jnice and cleaaaaaan!
MI'll make sure this format is compat with the installer we're building for 38 as well
M@hermmm thanks for the contribution!
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:
