Mutter w/ Explicit Sync for Nvidia 545 (also fixes an issue with copies that halves the framerate on
Mutter w/ Explicit Sync for Nvidia 545 (also fixes an issue with copies that halves the framerate on Nvidia)
KI'll do any parts of KDE that need it when there's a good MR for it
Kthat's on bazzite:testing atm
CSold
I'll test it tomorrow if I remember
I'll test it tomorrow if I remember
CI tried 545 before and after the kernel update, and had reduced but not eliminated flickering issues which various forum posts indicated were related to a lack of explicit sync
TLots of stuff seems fixed with the patch applied, i.e. spotify and steam don't glitch anymore, but Minecraft and Zoom meetings with camera on are still strobing badly
CSorry to bother, but did this go anywhere? The module seems to not be on the image, and the issue seems inactive
AIs there a way to install RPM's? Even just extracting the contents into the usr folder would work, though i cant seem to achieve that with 'rpm2cpio' either
FI believe that Explicit Sync is also needed for AMD & Intel too.
Will test this new update when I get home on AMD system.
Will test this new update when I get home on AMD system.
Jnot yet, we need someone to PR it in
J
BVery cool! I am not sure how that impacts on a hybrid intel/nvidia but I’m doubtful it hurts
Krpm-ostree install file.rpmAThank 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
