KYea that's fine, I opened an issue but it was like 7 months ago
KJust something to consider later when it's fixed
Bif we're going to have that for ucore, i'll have it in the ucore-kmods
KYep, wasn't even a thing when we added it
KSo let's just pull it and I'll pr there later when 6.8 is fixed
KIf you're interested
NTaking a look I think?
Bok, i'll pull gasket out for now, for sure. and see how it goes that way
Bi think simply rebuilding akmods will fix the nvidia red builds, too... it seems we built akmods just a bit "too soon"... it has a slightly older version of the nvidia version
550.67 is now current but earlier this morning it was still 550.54
ERtl stuff is failing as well
EYup
Byeah I'm going to force merge this, since it's a distinct PR, which does a specific thing
then i'll work more on "fixing surface"
then i'll work more on "fixing surface"
ESounds good 
Bso... @Kyle Gospo any thoughts about this one?
other than liking my comment
other than liking my comment
GAny idea how best to handle the symlinks in the spec file? Also if I update the spec, would I need to update any external scripts with the correct path?
Mtmpfiles.d
G?
Mwith tmpfiles.d it will create the symlink automatically to the correct location so as part of the spec file have a tmpfiles.d file
GOhh
GThanks
MIt will also only create the symlink if it doesn't exist. It will not overwrite a file unless prefixed with a + so it's perfect for our use case. And if the file is removed the symlink will get autocreated on next boot
FCan tmpfiles.d substitute skel for updating files in home directory?
BI'm struggling with local builds of akmods-surface failing with this:
but apparently it works fine in github actions, so that's odd
but apparently it works fine in github actions, so that's odd
B
Jok new website live
EInteresting. Will take a closer look. I think I've seen this before
DLooks like https://copr.fedorainfracloud.org/coprs/kylegospo/gnome-vrr/repo/fedora-40/kylegospo-gnome-vrr-fedora-40.repo doesn't exist yet
Boh geez, i have a dumb typo
Dso F40 on downstream builds bazzite, bluefin are failing
BF40 isn't ready
DYeah. Trying to work on getting it ready
DI think Kyle follows this chat closely, maybe he can branch that COPR for F40
Jas detailed in the release thread, we're doing hwe consolidation and ARM builds in main before moving down the line
JBi doubt this will ever get updated for F40
Gnome 46 is supposed to be part of Fedora 40, and it includes VRR
Gnome 46 is supposed to be part of Fedora 40, and it includes VRR
Bi think it will be archived
Jyep
Bwith F40 release, and F38 EOL, we're probably going to archive several repos which are in ublue-os org, but which don't really have maintainers, and aren't provided by upstream, either fedora official, or fedora-ostree-desktops
Jthat will stay
Jif it's in fedora-ostree-desktops it stayss
Jif not, it's out before GA
Jso beyond is gone
Jkera, deepin will go too
Nyou build deepin images? TIL
Jlxqt is is upstream isn't it? what do they call it?
Jyeah, we have that as a seperate repo rn
Bthe lxqt version here will be archived, currently only building for F38
Bwe should probably add all this archival stuff to the roadmap... too @j0rge
I think it more closely ties to the EOL of F38 than the release of F40...
heh, but I'd persoanlly EOL F38 early
I think it more closely ties to the EOL of F38 than the release of F40...
heh, but I'd persoanlly EOL F38 early
Jindeed
Jit's 05-14, so not that much after
