Describe the package

I'd like to request the package akmod-VirtualBox.
Currently, I cannot use VirtualBox in ublue with secure boot. I should be very straightforward, since it is already provided in RPM Fusion Free.

Image

All Images

Should improve the README to help users know how to use this repo to install a single kmod rather than all of them as the current instructions describe.

@bsherman has enabled builds for Fedora 40 but disabled those which are not yet supported or fail to compile.

This issue will track the rollout to the remaining packages.

Builds to enable:

• evdi: negativo17 does not yet provide F40
• gasket: compile failure (kernel 6.8)
• nvidia-470xx: compile failure - will not enable: rpmfusion has dropped support
• rtl18814au: compile failure (kernel 6.8)
• rtl188xxau: compile failure (kernel 6.8)
• v4l2loopback: compile failure (kernel 6.8)
• xpadneo: negativo17 does not yet provide F40

Describe the package

Running Silverblue as a VM inside of Parallels on an M1 Mac, it would be great to have a way to install the Parallels Tools into the VM.

I did some googling and couldn't find an easy way to download these tools from the internet - Parallels seems to want you to get the ISO from the Parallels installation. I'm willing to provide them if needed, I don't want to put a link in the issue in case it violates Parallels terms of use (I don't know that it does, I just haven't looked)

Thanks!

Image

Silverblue

The xone driver disables too many other controllers by disabling the stock xpad driver in the kernel ... to properly use it, we also need to include xpad-noone .

Goals of this ticket:

1. get xpad-noone building as akmod
2. add xpad-noone to this repo/image
3. re-enable xone

See: #25 and ublue-os/main#256 for context.

Hi everyone! Just got Bazzite on my desktop and this is my first daily drive immutable distro. Loving it so far.

I know it's kinda niche but I would like to request the Akmod for the Nuvoton NCT6687-R chipset. It is responsible for the sensors on some B550 motherboards from MSI and ASUS.

Here is a repository that already builds a kmod for it: https://github.com/Fred78290/nct6687d
Not sure why no one tried to upstream it to mainline kernel, tho.

Image

All Images

Hello,

I see that currently Bazzite has dedicated images for Framework/Surface/Asus laptops (as seen in Image Picker). Would it be possible/feasible to also add dedicated images for Tuxedo latpops?

From what I gather, this would require building/including kernel modules/drivers from tuxedo-drivers and also preinstalling Tuxedo Control Center app - which itself depends on said tuxedo-drivers.

I found that there was already ticket related to that in akmods repo, but I'm not sure if any decision regarding it has been made. Also (in the meantime), tuxedo-keyboard has been deprecated in favor of tuxedo-drivers.

I'm asking this because I have a Tuxedo laptop on the way (Pulse 14 Gen 3) and there are some HW related features (KB backlight, fan control etc.) which won't work properly with Linux kernel without those drivers. If possible, I'd like to use Bazzite or Bluefin on this laptop since Bazzite has been great on my Steam Deck OLED so far.

Thank you in advance.

Best Regards

Background

There are several packages which we'd like to include in ublue, specifically kmods, which do not have an upstream akmod build, or do not have an RPMs built at all, even if the project provides a spec file.

Some examples:

• openrazer ( see #5 )
• xpad-noone ( see #26 )
• snapraid (for ucore) ( see ublue-os/ucore#25 )

Beyond these which have no current solution, there are things we install which are in random COPR repos or in negativo17. Negativo17 seems reliable, but it's still an additional third party beyond rpmfusion, and random COPRs, well, it's like ubuntu-PPA land. If we don't know the maintainer, it's a gamble.

Goal

The goal is to provide a team ublue managed repo that:

1. at LEAST contains packages we can't get anywhere else (see examples above)
2. possibly contains packages which we currently get from random COPRs and other 3rd party repos
3. will NOT replace rpmfusion as it is a hard dependency at this point

Suggested Implementations

1. Host our own SPEC files

For any RPMs we need to build, we should host the spec files in our own github repo. This ensures control of what we are building and minimizes risk of a third party causing our RPMs to include any surprises.

I believe we could have a single repo rpm-specs (open to suggestions on name) with the various maintained spec files in it.

If we went all in on some of my suggestions for packages above it could include:

• openrazer.spec
• snapraid.spec
• xone.spec
• xpad-noone.spec
• etc

There may be subdirs for supporting files for each spec, or perhaps each spec goes into a distinct sub-dir by default.

2a. Github pages ublue-os rpm repo

One proposal, though a potentially janky approach, would involve having a dedicated github repo which is setup for github pages. This is distinct from rpm-specs, maybe call it rpm-repo.

Github actions in this repo would on whatever trigger, build the RPMs from rpm-specs, run a create-repo script that creates the yum repo metadata, and then commits resulting metadata and RPM binaries to the rpm-repo git repo such that the contents of the repo are available to use.

This is kinda janky, but it could possibly work.

The major pro is we don't need any extra user management, its just github.

The major con is we'll be reinventing some wheels and doing some janky stuff.

2b. ublue-os team COPR

Another proposal is to use a single COPR repo/project (insert proper terminology here). The spec files would still be hosted in a github rpm-specs repo as described above, but all building and repo hosting would be done in COPR.

There are webhooks and apis in COPR which should at least allow triggers of builds when changes are made to specs, or from other actions. Possibly the api could be used to add a new spec to the COPR.

The major pro here is COPR is specifically made to build and host RPMs.

The major con is user access/permissions management. We think it's single user. A possible workaround could be to manage limited access to a shared credential similar to how we already manage private key escrow for signing OCI images. Also, if we only need access to "setup" a build/project since webhooks could trigger rebuilds, this may be less of an issue than originally thought.

Feedback

I'd like some team feedback on this. A few of us have been thinking about this for months, but not really made progress. It becomes more of a blocker to progress as the days go on. Whichever path is taken will require some effort. No need to rush it, but it's good to be on the same page with goals and approach.

Describe the package

Tuxedo-keyboard adds drivers for keyboard backlight, fan control and other hardware enablements on Tuxedo Computers and other laptops using Clevo chassis.

Only available as dkms at the moment, although I have opened an issue about kmod availability

Image

All Images

This simplifies things in Containerfile so there is no need to edit this whenever new Fedora version gets released.

main-39 = main-latest

This one benefits from it:
blue-build/legacy-template#212

Following up on: #28

We now have an akmods repo hosted under the org Copr. Access can be requested from the Copr here: https://copr.fedorainfracloud.org/coprs/ublue-os/akmods

This shouldn't impede looking for potentially better options in the future though

@bsherman

the xone driver disables too many other controllers by disabling the stock xpad driver in the kernel ... to properly use it, we also need to include xpad-noone but we don't have a quick way to do that right now.

For now, let's disable xone. I'll file another ticket to get xpad-noone working and add both back.

See ublue-os/main#25

Problem

As of ~5 hours ago, the openrazer and openrgb akmods are causing build failures in my ublue-os/startingpoint builds.

See my GitHub Actions workflow. The error for both akmods appears similar:

Problem 1: package kmod-openrazer-6.7.3-200.fc39.x86_64-100.0.0.git.530.886f986d-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System

 Problem 2: package kmod-openrgb-6.7.3-200.fc39.x86_64-0.0.git.15.f3f94bed-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.7.3-200.fc39.x86_64 from updates
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive
  - package kernel-core-6.6.14-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - conflicting requests
  - cannot install both kernel-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-core-6.7.3-200.fc39.x86_64 from updates
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from updates-archive
  - package kernel-6.6.14-200.fc39.x86_64 from @System requires kernel-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-modules-extra-6.6.14-200.fc39.x86_64 from @System requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System

Context

See my ublue-os image repository for more details, particularly:

Image recipes: recipe-sway.yml and recipe-hyprland.yml -- failure takes place in both recipes, since they share common akmods configuration.
Akmods module: common-akmods.yml
Image Fedora version: 39

These recipes were building successfully without any changes ~19hrs ago, see https://github.com/michaelhaaf/wayblue/actions/runs/7808947655/job/21299949213#step:15:255 for most recent successful build.

Logs

See https://github.com/michaelhaaf/wayblue/actions/runs/7818120114/job/21327583531#step:15:281 for full log.

=== Launching module of type: akmods ===
Installing akmods
Installing: openrazer openrgb
Enabled rpm-md repositories: copr:copr.fedorainfracloud.org:ublue-os:akmods fedora-multimedia rpmfusion-nonfree-updates rpmfusion-free-updates rpmfusion-free rpmfusion-nonfree fedora-cisco-openh264 fedora updates updates-archive
Updating metadata for 'copr:copr.fedorainfracloud.org:ublue-os:akmods'...done
Updating metadata for 'fedora-multimedia'...done
Updating metadata for 'rpmfusion-nonfree-updates'...done
Updating metadata for 'rpmfusion-free-updates'...done
Updating metadata for 'rpmfusion-free'...done
Updating metadata for 'rpmfusion-nonfree'...done
Updating metadata for 'fedora-cisco-openh264'...done
Updating metadata for 'fedora'...done
Updating metadata for 'updates'...done
Updating metadata for 'updates-archive'...done
Importing rpm-md...done
rpm-md repo 'copr:copr.fedorainfracloud.org:ublue-os:akmods'; generated: 2024-02-06T09:39:07Z solvables: 140
rpm-md repo 'fedora-multimedia'; generated: 2024-02-06T09:45:57Z solvables: 380
rpm-md repo 'rpmfusion-nonfree-updates'; generated: 2024-02-04T23:32:13Z solvables: 62
rpm-md repo 'rpmfusion-free-updates'; generated: 2024-02-04T23:14:39Z solvables: 152
rpm-md repo 'rpmfusion-free'; generated: 2023-11-04T16:49:08Z solvables: 445
rpm-md repo 'rpmfusion-nonfree'; generated: 2023-11-04T17:26:32Z solvables: 208
rpm-md repo 'fedora-cisco-openh264'; generated: 2023-03-14T10:57:01Z solvables: 4
rpm-md repo 'fedora'; generated: 2023-11-01T00:12:39Z solvables: 70825
rpm-md repo 'updates'; generated: 2024-02-07T01:42:10Z solvables: 21559
rpm-md repo 'updates-archive'; generated: 2024-02-07T02:09:46Z solvables: 28569
Resolving dependencies...done
error: Could not depsolve transaction; 2 problems detected:
 Problem 1: package kmod-openrazer-6.7.3-200.fc39.x86_64-100.0.0.git.530.886f986d-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System
  - conflicting requests
 Problem 2: package kmod-openrgb-6.7.3-200.fc39.x86_64-0.0.git.15.f3f94bed-1.fc39.x86_64 from @commandline requires kernel-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-uki-virt-6.7.3-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.7.3-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.7.3-200.fc39.x86_64 from updates
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from updates-archive
  - package kernel-core-6.6.14-200.fc39.x86_64 from updates-archive requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-modules-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-modules-core-6.6.14-200.fc39.x86_64 from @System
  - conflicting requests
  - cannot install both kernel-core-6.6.14-200.fc39.x86_64 from updates-archive and kernel-core-6.7.3-200.fc39.x86_64 from updates
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from updates-archive
  - package kernel-6.6.14-200.fc39.x86_64 from @System requires kernel-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
  - package kernel-modules-extra-6.6.14-200.fc39.x86_64 from @System requires kernel-modules-core-uname-r = 6.6.14-200.fc39.x86_64, but none of the providers can be installed
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates and kernel-core-6.6.14-200.fc39.x86_64 from @System
  - cannot install both kernel-core-6.7.3-200.fc39.x86_64 from updates-archive and kernel-core-6.6.14-200.fc39.x86_64 from @System
error building at STEP "RUN chmod +x /tmp/build.sh && /tmp/build.sh &&     rm -rf /tmp/* /var/* && ostree container commit": error while running runtime: exit status 1
time="2024-02-07T16:40:37Z" level=error msg="exit status 1"
Error: Error: buildah exited with code 1

Since we use differing kernels from upstream, we should be properly setting the ostree.linux label on the image to reflect the actual kernel within the image.

Relates: ublue-os/hwe#220

Describe the package

I would like to request to add acpi_call dkms to the akmods. (this way ublue will be superior to fedora (that's a joke please don't kill me))

I have yet another motherboard that uses acpi to controls fans and some other stuff. I don't even understand why it isn't in the mainline kernel since a lot of laptops seems to have use of it but still.

Neraly all lenovo, clevo, PCspecialist laptops are concerned. and there are many more that I don't know.

This is a common issue for me on a lot of distro to control my fans and sometimes power.

Image

All Images

So I'm looking at trying to do a PR to add an akmod to the repo ( https://github.com/DHowett/framework-laptop-kmod ) but there's something that I just don't quite understand, the "how to" points to the wl script, and its just that, a script. How do you actually download the code for the mod into the build? Like I can get the script together, but I don't think that'll download the actual relevant code into the mod. Do I need to wrap it in a COPR? I'm attempting to wrap this up in a script as we speak so I can get it before the akmod is wrapped into ublue so I can simplify it upstream, but even then its complicated, as the make file for the kmod assumes your applying it to the system you're on, so I'd need to know the kernel that's being built, not the kernel of the runner building it... Its a fun challenge! Jorge suggested I open this so here we are.

What I tried

• Roll back to a pinned uBlue image I keep as a backup. That image is from Aug 18, 2023 and the controller WORKS THERE.
• I also tried rebasing to normal, official, latest Silverblue. It also WORKS THERE.

Info about the controller

• It has xbox360 and a ps3 mode switch.
• In the ps3 mode, it works, but that mode is unusable even on Windows.
• In xbox360 mode, under /dev/input/by-id, it shows up as 'usb-ShanWan_Controller_XBOX_360_For_Windows..' Using cat on that file throws SIGPIPE error. This mode worked flawlessly for like 3 years until now.

What I suspect is the issue

• Considering normal latest Silverblue works, a pinned uBlue image from Aug 18, 2023 also works, looking around here I suspect commits from Aug 27, 2023 caused it. Those mention stuff related to xbox controllers.

Describe the package

I try to add the evdi DisplayLink driver in my Containerfile:

COPY --from=ghcr.io/ublue-os/akmods:${AKMODS_FLAVOR}-${IMAGE_MAJOR_VERSION} /rpms/ /tmp/akmods-rpms
RUN find /tmp/akmods-rpms
RUN rpm-ostree install /tmp/akmods-rpms/kmods/kmod-evdi-*.rpm

However, during image building, I get the following error:

error: Could not depsolve transaction; 1 problem detected:
 Problem: conflicting requests
  - nothing provides evdi-kmod-common >= 1.14.1 needed by kmod-evdi-6.6.8-200.fc39.x86_64-1.14.1-4.20231123gita943d98.fc39.x86_64 from @commandline

Did I made a mistake during the integration of this akmods?
Or is this a bug with the package?

Image

All Images

Describe the package

Please merge upstream fixes released recently from https://github.com/medusalix/xone or specifically this commit to fix an issue with the wireless xbox 2.4ghz dongles locking up.

Issue referenced in discord here: https://discord.com/channels/1072614816579063828/1211498927489159168

Thanks!

Image

Bazzite

• xone (xbox one wired/rf usb) driver
• xpadneo (xbox one bluetooth) driver

I saw these failures...
https://github.com/ublue-os/akmods/actions/runs/8421318593/job/23058006965#step:12:160

I checked the COPR...
https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/packages/

Looks like sentry updated fsync-kernel...
from: 6.7.9-204.fsync
to: 6.7.9-207.fsync

It seems RPMfusion has dropped the 470 driver ( https://admin.rpmfusion.org/pkgdb/package/nonfree/nvidia-470xx-kmod/ ). So, it may be time to switch to negativo17 for nvidia.

@KyleGospo and I have previously discussed this. The negativo17 packaging allows more granular installation of only desired components. For example, in ucore I already use negativo17 as it allows only installing nvidia-driver-cuda which is just the driver and CUDA support, as is proper for a server. RPMfusion's package pulled in all of Xorg and Wayland. In addition, negativo17 provides a cuda-gcc package to aid users needing (nvidia's CUDA does not yet support GCC 14 which is current in Fedora).

We were not keen to move to negativo17 before now, but because they only package the latest drivers, while we were using both latest and legacy 470 drivers from RPMfusion.

With RPMfusion's orphaning of the 470 package, I believe we should now move to negativo17. This will mean dropping the 470 driver... but it's orphaned upstream, so I unless we want to maintain the package, I don't think we can continue providing it in good conscience.

I'll prep the appropriate PRs for this.

Describe the package

I think we should also offer https://github.com/NVIDIA/open-gpu-kernel-modules. Maybe do -nvidia and -nvidia-open.

RPMFusion has packages for each variant.

Image

All Images

Sadly, after JUST getting xone added, we've had to disable it as they don't yet have a tagged release with kernel 6.3 support, which is the new kernel on Fedora as of today.

This ticket is a reminder to check-in on the following repos to watch for movement on this issue:

• rpm spec repo: https://github.com/negativo17/xone-kmod
• driver repo: https://github.com/medusalix/xone

See: #18

There was a failed effort to create an akmod spec and build for openrazer over at their official build on OBS

openrazer/OBS-packaging#8

We could probably pickup the contributed akmod spec file and build it in COPR then it would be easy to add here with our new akmods flow.

It is a bit more commitment than just using existing akmods though.

In order to support custom kernels (eg for asus and surface images) we need those kernels to be used as part of the kmods build process.

Perhaps we do something like this:

matrix:
    kernel_flavor: [default, asus, surface]

And then our kmods Containerfile(s):

1. use default kernel/kernel-devel packages for default
2. replace kernel/kernel-devel packages for asus/surface
3. build kmods with the respective kernel packages

Tags should be something like this:

• akmods:main-38
• akmods-nvidia:main-38-535
• akmods:asus-38
• akmods-nvidia:asus-38-535
• akmods:surface-38
• akmods-nvidia:surface-38-535

Describe the package

Hello i cannot find how to install it and i cannot find on the akmod repo https://copr.fedorainfracloud.org/coprs/ublue-os/akmods/

● ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-nvidia:39 (index: 0)
Digest: sha256:f04201a1821488caedbc333991afa5b835f0418f8cc600966be7ee012d65ea58
Version: 39.20240130.0 (2024-01-31T04:03:22Z)
BaseCommit: fc1981d154b646bdf8ec260d8d3acbf5c827689c7570418eaaabe4cce72deff3
Commit: b3ec67a7f59d820ac26b98224bbd0eba66363ad7ae0bbe7d93541456b481911b
├─ copr:copr.fedorainfracloud.org:phracek:PyCharm (2023-08-10T15:35:19Z)
├─ copr:copr.fedorainfracloud.org:ublue-os:akmods (2024-01-30T22:21:21Z)
├─ fedora (2023-11-01T00:12:39Z)
├─ google-chrome (2024-01-30T18:24:44Z)
├─ rpmfusion-free (2023-11-04T16:49:08Z)
├─ rpmfusion-nonfree (2023-11-04T17:26:32Z)
├─ rpmfusion-nonfree-nvidia-driver (2024-01-25T09:11:40Z)
├─ rpmfusion-nonfree-steam (2023-08-10T16:27:35Z)
└─ updates (2024-02-01T01:46:41Z)
Staged: no
StateRoot: fedora
RemovedBasePackages: gst-editing-services 1.22.5-1.fc39 rygel 0.42.5-1.fc39
LayeredPackages: fish flatpak-spawn langpacks-fr openssl1.1 perf strace vagrant
LocalPackages: xpipe-1.7.16-1.x86_64

Image

Silverblue

Per #54 , the akmods repo now builds the following images/tags:

• akmods:37
• akmods:38
• akmods-nvidia:37-470
• akmods-nvidia:38-470
• akmods-nvidia:37-535
• akmods-nvidia:38-535

should update README to reflect this with appropriate examples for usage.

Relates to ublue-os/website#403