AThank you, that works nicely
JJ
J... including Linux desktops.
JI added that to the end. 
Jhttps://github.com/cncf/landscape/issues/3626
- I have a project in the cncf with a dockerfile in need of a github action to publish the container in ghcr.io. I did something similar for another project and can walk you through it. But if someone has "contribute to a cncf project" on their goal list, lmk.
Bhmm interesting
EWould love to help with this. Will be busy for the next couple hours but I'll certainly have the time later this afternoon to look into it
JI'll have more over time, but if someone is going to claim it do it on github so it's clear who's got it
J@KyleGospo this terminal feels so good, I'm not switching back
KSame, I adore it
KCan't wait until we can ship it
EWhat terminal out of curiosity?
EOnyx images seem to have an issue following a rebase. It's impossible to login
EEven via TTY oddly
EGoing to try changing the target run level. Imagine this is somehow related to lightdm
J
ESomeone did it!
JI know, it's awesome too!
Jyou can grab the flatpak from ci and install it via the instructions in the readme
EAbsolutely awesome. Would be amazing to integrate this into Bazzite/Bluefin DX images
JI'm fully switching bluefin to it when it gets pushed to flathub
RCould this be useful for populating /opt or similar during container build-time?
I don't know if my interpretation of the changelog is correct, but my understanding is that if you shove stuff in /usr/share/factory/var (such as 1Password stuff or RPMs that expect to be able to write to /opt?), it will be copied to /var on boot
https://github.com/ostreedev/ostree/releases/tag/v2023.8
I don't know if my interpretation of the changelog is correct, but my understanding is that if you shove stuff in /usr/share/factory/var (such as 1Password stuff or RPMs that expect to be able to write to /opt?), it will be copied to /var on boot
https://github.com/ostreedev/ostree/releases/tag/v2023.8
GitHub
This release stabilizes "deployment finalization locking" which
is very useful for automatic update workflows.
sysroot: Stabilize deployment finalization, add API by @cgwalters in #3090
...
is very useful for automatic update workflows.
sysroot: Stabilize deployment finalization, add API by @cgwalters in #3090
...
AThe easy solution would be to create a symlink in /opt -> /usr/share/factory/var/opt in the container during build time and remove it at the end of the build
LDoes this have positive implications for including pre-installed Flatpaks and Homebrew?
AFlatpaks probably not a good idea
AAs it would require double the storage
LHowever, it may work yeah?
EAt one point I was doing something similar to this but caching it in a different directory. Suffice to say it led to monstrous image sizes that toppled over what GHCR could handle. I would say no as is. There's some work being done to make this process better though
EThe problem is you're not just bringing.in the program. You take in the deps too. Which as you can imagine, especially for systems that use the NVIDIA driver, this can be huuuge
Kmakes every update bigger too untl diffed downloads is complete
AYeah but it is already possible to do that with Lorax (not sure about osbuild)
Fedora upstream does it like this: https://github.com/akdev1l/mkociso/blob/main/src/mkociso/lorax_templates/lorax-embed-flatpaks.tmpl
Fedora upstream does it like this: https://github.com/akdev1l/mkociso/blob/main/src/mkociso/lorax_templates/lorax-embed-flatpaks.tmpl
BWe've got a nice improvement for "just update" pending an approval. Please take a lool.
https://github.com/ublue-os/config/pull/167
https://github.com/ublue-os/config/pull/167
Hooo thats a nice addition
LOK, thank you. Yeah ghcr gets the job done a bunch of the time but it does have a bunch of challenges to it.
Given a different registry, potentially different outcomes
Given a different registry, potentially different outcomes
EEven if it could handle the larger image sizes, Kyle makes a good point. Bigger and bigger updates would be a hurdle as well
EAnd no problem
LThank you for the link.
I'm wondering whether similar commands are able to be called inside of the build steps inside a Fedora image
I'm wondering whether similar commands are able to be called inside of the build steps inside a Fedora image
LI'm interested in how this can be solved in a way where the image size isn't through the room and at least some Flatpaks are pre-installed. Does the standard Fedora Silverblue ISO not include any Flatpaks by default?
EStandard GNOME version does but only in the installation media
EThey are not shipped on the image itself
EWe can do this with lorax
EBut the isogenerator we have in place doesn't support it
LOK, gotcha
LThe purpose of what I'm trying to achieve is to have a pre-installed OS on a bootable USB media to have software, a user account all there.
I'm wondering if it's possible with osbuild, given I'm using this
https://github.com/osbuild/bootc-image-builder and
I'm wondering if it's possible with osbuild, given I'm using this
https://github.com/osbuild/bootc-image-builder and
bootc (trialing each for the purpose)GitHub
Contribute to osbuild/bootc-image-builder development by creating an account on GitHub.
JCan someone with the right permissions sync this repo to bump the nvidia driver version? https://github.com/ublue-os/asus-nvidia
GitHub
ASUS Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/asus-nvidia development by creating an account on GitHub.
JThank you!
Jwoo all green!
J(unless onyx 39 470 decides to hate us)
