BTAL? I'm investigating this surface akmods issue right now...
Bso, no, we don't explicitly build for that version of the kernel, we build against the latest kernel in the surface-kernel repo
it seems that a few of the kmods are not compiling with 6.8... i actually saw this on our fedora preview builds, too
it seems that a few of the kmods are not compiling with 6.8... i actually saw this on our fedora preview builds, too
B@Kyle Gospo maybe instead of checking for F40, i should gate those broken kmod builds on kernel 6.8 for now?
KWorks for me, 6.8 I have to be careful with anyway
EGasket doesn't build against the Surface kernel causing the build to fail. The module likely just needs to be excluded
Bits because of 6.8
Bsame reason it fails on F40
KNobody is depending on gasket right now so we can just exclude until fixed
KI only included it here for ucore
Bwha?
KWe chatted a long time ago about it, gasket enables google TPU hardware
Bwho asked for gasket for ucore? I don't use it 
KSo you can do stuff like ML image recognition on a home security camera
Boh lol, well, i'm sorry, i don't recall, i've never actually installed it
KNice to have for a server OS
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.54ERtl 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
