Aside from the FaceTime kmod, I’m currently trying to figure out why v4l2loopback kmod will build on
Aside from the FaceTime kmod, I’m currently trying to figure out why v4l2loopback kmod will build on f40’s kernel 6.8 but not on f39
BI’ll welcome help with that!
BI can file a ticket for a place to work around it
FTake in mind that you're closing the issues when issue is upstream related & when you already decided what is going to be done, without having further discussion in the issue.
With that approach, issues are indeed closed rapidly.
While Universal Blue, BlueBuild & some others keep upstream issues, but just tag it as "upstream" or "state: blocked" without closing it, as it's still mostly related to the project.
We also use issues for deep discussion, as I honestly find it better than Discussions GH page.
That's overall subjective, I personally prefer the 2nd approach.
With that approach, issues are indeed closed rapidly.
While Universal Blue, BlueBuild & some others keep upstream issues, but just tag it as "upstream" or "state: blocked" without closing it, as it's still mostly related to the project.
We also use issues for deep discussion, as I honestly find it better than Discussions GH page.
That's overall subjective, I personally prefer the 2nd approach.
FI got so used to saying "we" lol
RHave we ever had to pin a kernel version to a previous one? Would be good to see how this is supposed to look
M39 and 40 have slightly different names for the kernels.
39 is 6.8.4-200
40 is 6.8.4-300
Unsure if that is the cause?
39 is 6.8.4-200
40 is 6.8.4-300
Unsure if that is the cause?
Bi don't that's the issue
Jit would be useful to figure that out and write it down
BBazzite pins kernels
JI don't think we've ever needed to do that, but feels like one of those things that would save the day
Bunless we make a move to ublue "main" defaulting to CoreOS stable/testing kernels, etc... I don't want it to be the norm...
plus, our akmods solution right now has to be in sync with whatever we do in main... since we don't have our own yum repo yet
plus, our akmods solution right now has to be in sync with whatever we do in main... since we don't have our own yum repo yet
Jk
BI've got a draft PR trying to just get akmods building again, without nvidia 470, since it no longer builds as of 6.8 and rpmfusion dropped it anyway
https://github.com/ublue-os/akmods/pull/166
this PR has us NOT building several packages for kernel 6.8... and specifically not building
https://github.com/ublue-os/akmods/pull/166
this PR has us NOT building several packages for kernel 6.8... and specifically not building
v4l2loopback for 6.8 on F38/F39Jso are we stuck waiting for v4l2loopback to be ported to 6.8?
MIt appears to be building for 40
Bright that's why i'm so confused, it DOES build for 6.8 on F40, but NOT on F39/F38
BI think we should merge this sooner than later ... it's building clean, just had to drop v4l2loopback on F38/F39 ... and
there's a couple others not building on 6.8 too, but those aren't included in bluefin, i don't think and bazzite can deal i think
there's a couple others not building on 6.8 too, but those aren't included in bluefin, i don't think and bazzite can deal i think
Jok on it
Jneeds 1 more
MWould love to +1 it...
J@EyeCantCU got a sec ^^
ETaking a look
ELooks good, approved 
Bugh, i need to fix nvidia builds, as we don't have 470 anymore
Jstanding by
Jbuilds are clearing up now, next run should be without queued builders
Bi cancelled the nvidia PR build... trying to get this clean build of akmods then we need to buidl main again
Bpretty annoyed... i started this afternoon hoping to cleanup image metadata and i've just fought with bluefin buils and 6.8 drama 
JBUT SPLIT BUILDS THO
Joh and all the inline bash is gone
Bugh, more side effects i'm so ready to axe F38
BEAvailable to help out as well
BFI found the easy way to install Gnome system extensions without building RPMs.
It's all automated.
The only maintenance is bumping the extension version from time to time when new Fedora releases.
It's only rarely needed to install some additional dependency which some extensions require, like Pano.
Is there an interest in this?
It's all automated.
The only maintenance is bumping the extension version from time to time when new Fedora releases.
It's only rarely needed to install some additional dependency which some extensions require, like Pano.
Is there an interest in this?
MFedora 40 dropped openssl 1.1 compatability
MWe depend on it through devpod in the -dx versions
Jwe casually passed 11 million pulls just now
Mwow
J10 million was less than 2 weeks ago, 13 days
JI use a hardware latency tester to measure how much the VTE-based terminals improved from GNOME 45 to GNOME 46.
Mhttps://github.com/ublue-os/packages/pull/21
I upped the openssl version to the non-compat version. However, devpod doesn't seem to run for me at all with either the version based on openssl1.1 or openssl
I upped the openssl version to the non-compat version. However, devpod doesn't seem to run for me at all with either the version based on openssl1.1 or openssl
Jthey have an issue tracker and luca watches it
Mrpmlint action seems broken on packages.
Bthere are some spec files which don't pass lint
Mmakes sense. Looks like we lint everything
Mokay, the build with openssl works with podman (and appears to work with vscode directly). Docker issue also sorted
MThe appimage version still has an issue so this is an improvement over that
MFiled an issue still with upstream some weird stuff going on
EOnly have a moment - you all see this?
https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-2043087999
https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-2043087999
