@KyleGospo this terminal feels so good, I'm not switching back
@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)
EGot Surface NVIDIA too
EQuite happy with how well everything has been working on my Pro 7+. Just need IPU4 camera support but I don't expect that anytime soon... Pixel got an update to use it as a webcam so not the end of the world either
ETrying Squeekboard on GNOME too see if it's a viable replacement for GNOME keyboard in our downstream images for Surface and Deck too
Jwe have an open issue for ipu4
Jthere's a copr and everything
Jhttps://github.com/ublue-os/main/issues/229 oh sorry that's IPU6, I'm unfamiliar with the nomenclature of these new cameras
EInteresting IPU6 support came before IPU4
EFrom what I've read, IPU3 support took forever so I wouldn't expect IPU4 support anytime soon. I've seen work on a driver for it though it doesn't work atm
J
Jthat is a curious binary
