hello, is there any eta for v4l2loopback being enabled again in the akmods repo?
hello, is there any eta for v4l2loopback being enabled again in the akmods repo?
Bwe're waiting on RPM fusion to promote the fixed package from updates-testing to updates: https://github.com/ublue-os/akmods/pull/168
as soon as that happens, this PR is staged to build and merge
as soon as that happens, this PR is staged to build and merge
Jis there any place to see discussions or the status on rpm fusions side
Bi'm not sure, but i welcome a link in a comment on the PR if you find it
Jlook like it disappeared from the link in the comment lol
Bit didn't disappear, it's never been there
Bfor F39, v4l2loopback was built for the
release but never updated... the released version was not kernel 6.8 compatible... so that's what we're waiting on the updated version of the package which will build against kernel 6.8 to be promoted to the updates repoJi see ty
Jhopefully that gets done soon because i need to use my webcam 
JYeah sucky situation for sure. 
Byou CAN rollback to an image which has the module in it
Jsomeone told me that pipewire is gonna eventually have some sort of virtual loopback system
JGitLab
It's very common for content creators (e.g. streamers, YouTube creators, etc.) to take a video source and apply effects and redirect it into another application (like
Hyup looking forward to that
pipewire can already handle video from what i remember (although applications need to support it i believe)
pipewire can already handle video from what i remember (although applications need to support it i believe)
MGoing to respin Bluefin and Aurora ISOs
KYes, where did you want it linked to?
JThe docs section of the forum so it just shows all the doc subcats, sorry in a taxi
JPlanting the flag for the next generation Linux desktop
K@j0rge
Jwoo!
JWotcha think about "Docs" on the top of the website?
Kgood call
K@j0rge
Jballer!
J@Bigpod ^
Bthanks
Bthis is a good addition
B@Kyle Gospo @M2 @Robert (p5) @EyeCantCU wonder if you have feedback for my idea starting with this message kernel version label on ublue images
Bthere was a lot of churn tonight trying to move forward with negativo17 nvidia but it was rolled back nvidia negativo17 swap
Manything i can lend a hand with? seems like there are some PRs stacked up, but look like they are holding on some upstream builds
Bappreciate the offer... hard to give much feedback right now.
in general:
in general:
- we're trying to cleanup a few issues (metadata and build reliability) in akmods
- trying to update the nvidia drivers (though that's on hold for some testing, but i need to cleanup PRs)
- it's not really written down anywhere, but after the metadata cleanup is done, i want to split our akmods so some of the current "extras" and new submissions can be built separate from our current "core" kmods.
MI can take a stab at the last one (extra) if that isn't already in the works somewhere? I can make an issue to track if it doesn't exist and draft up a PR. Were you thinking an image variant like with bluefin/dx?
MThinking about that a little more, it could be very similar to how you currently handle packages with the packages.json files. "core"/"extra" and then include/excludes for the kernel variants and/or fedora major versions
MI would like to add clevis-dracut to our builds. Clevis is already on disk. This will enable Tang Decryption on our builds as part of initramfs and matches what coreOS has by default
MGitHub
Clevis is another scheme for supporting LUKS decryption via tpm2 and/or a network based decryption scheme. Clevis is already included in our images; however, clevis-dracut is not. We've recentl...
IGotta say, I just finished getting an Alma Linux server up two weeks ago, running with clevis-dracut + TPM on boot decryption and it was cake. I like the experience soooo much better than without clevis-dracut
Ijust a thought from a rando
K
KAnyone else deal with this?
Byeah, i know its been discussed a bit, i think its related to other non-writeable paths which have causes issues for @jstone (and others) building F40 custom images
specific to the wget issue... one solution is switching to curl
specific to the wget issue... one solution is switching to curl
Kcoo, ez
Kthanks
Bmy pleasure, i'm kind of on a mission to standardize all the downloads in our akmods/main/hwe builds to only use curl, but it's definitely a back burner project
and mostly it's because it's a bit simpler than wget and i just want a single way to do it
and mostly it's because it's a bit simpler than wget and i just want a single way to do it
JI've had to work around
tarI haven't created an issue yet... and I'm sorry don't feel like i have a bunch of time for it at the moment...
the idea i'm trying to communicate is more akin to how akmods already has "common" and "nvidia" builds split... I imagined another split "extras" which has things which are used in bazzite, but not bluefin, for example, while "common" is the smaller set which are in both and which were in the past, included in our main images
the idea i'm trying to communicate is more akin to how akmods already has "common" and "nvidia" builds split... I imagined another split "extras" which has things which are used in bazzite, but not bluefin, for example, while "common" is the smaller set which are in both and which were in the past, included in our main images
Badded the ticket, i owe everyone at least a small bit of documentation around the idea https://github.com/ublue-os/akmods/issues/176
GitHub
The more kmods we add to Containerfile.common the longer builds take, and, the more likely we break downstream builds for Aurora/Bluefin and others. Specifically, there are a number of kmods which ...
MYepp. /root isn't writable in the build container.
MIt appears harmless right now for our use in bluefin. But I would also like to move away from wget to curl to avoid noise.
Bi welcome PRs in akmods/main/hwe for this 
Bthis is new - from
ujust updateB