We chatted a long time ago about it, gasket enables google TPU hardware
We 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.67550.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
