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

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

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.

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

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

Bluefin and Aurora are now shipping this kmod and it can be moved from extras to common.

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

Any chance to include the acpi_ec kmod package?
it provides /dev/ec which is used to control fans and other features in several MSI laptops
upstream: https://github.com/saidsay-so/acpi_ec
there is a repo which contains required files to build: https://copr.fedorainfracloud.org/coprs/maximmaxim345/nbfc-linux/package/acpi_ec-kmod/

Image

Desktop

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

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

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

Describe the package

There are a number of copr packages for system76 support https://copr.fedorainfracloud.org/coprs/szydell/system76/

These are a lot or quality of life pieces and hardware support for things like the keyboard backlight and fan control.

Image

All Images

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

In my custom image, the facetimehd kmod fails. I have checked with the blue-build team and they think it has something to do with kernel versions.

Here is what it gives me:
`#37 0.311 ================================================= Start Akmods Module =================================================
#37 0.618 Installing akmods
#37 0.620 Installing: facetimehd
#37 0.674 Enabled rpm-md repositories: copr:copr.fedorainfracloud.org:ublue-os:akmods fedora-multimedia copr:copr.fedorainfracloud.org:ublue-os:staging copr:copr.fedorainfracloud.org:che:nerd-fonts copr:copr.fedorainfracloud.org:kylegospo:bazzite copr:copr.fedorainfracloud.org:kylegospo:system76-scheduler copr:copr.fedorainfracloud.org:kylegospo:bazzite-multilib tailscale-stable rpmfusion-nonfree rpmfusion-nonfree-updates-testing rpmfusion-free rpmfusion-nonfree-updates rpmfusion-free-updates-testing rpmfusion-free-updates updates fedora-cisco-openh264 fedora updates-archive
#37 1.212 Updating metadata for 'copr:copr.fedorainfracloud.org:ublue-os:akmods'...done
#37 2.781 Updating metadata for 'fedora-multimedia'...done
#37 3.448 Updating metadata for 'copr:copr.fedorainfracloud.org:ublue-os:staging'...done
#37 3.775 Updating metadata for 'copr:copr.fedorainfracloud.org:che:nerd-fonts'...done
#37 3.895 Updating metadata for 'copr:copr.fedorainfracloud.org:kylegospo:bazzite'...done
#37 4.538 Updating metadata for 'copr:copr.fedorainfracloud.org:kylegospo:system76-scheduler'...done
#37 4.850 Updating metadata for 'copr:copr.fedorainfracloud.org:kylegospo:bazzite-multilib'...done
#37 5.142 Updating metadata for 'tailscale-stable'...done
#37 5.914 Updating metadata for 'rpmfusion-nonfree'...done
#37 6.705 Updating metadata for 'rpmfusion-nonfree-updates-testing'...done
#37 7.878 Updating metadata for 'rpmfusion-free'...done
#37 8.725 Updating metadata for 'rpmfusion-nonfree-updates'...done
#37 9.518 Updating metadata for 'rpmfusion-free-updates-testing'...done
#37 10.81 Updating metadata for 'rpmfusion-free-updates'...done
#37 12.23 Updating metadata for 'updates'...done
#37 12.61 Updating metadata for 'fedora-cisco-openh264'...done
#37 15.32 Updating metadata for 'fedora'...done
#37 15.94 Updating metadata for 'updates-archive'...done
#37 15.95 error: Updating rpm-md repo 'updates-archive': cannot update repo 'updates-archive': Yum repo downloading error: Downloading error(s): repodata/2e7db4492173b6c437fd1299dc335e63d09f24cbdadeac5175a61b787c2f7a44-filelists.xml.zck - Cannot download, all mirrors were already tried without success; Last error: Status code: 403 for https://fedoraproject-updates-archive.fedoraproject.org/fedora/40/x86_64/repodata/2e7db4492173b6c437fd1299dc335e63d09f24cbdadeac5175a61b787c2f7a44-filelists.xml.zck (IP: 3.161.213.74)
#37 ERROR: process "/bin/sh -c source /tmp/scripts/exports.sh && /tmp/scripts/run_module.sh akmods '{"type":"akmods","install":["facetimehd"]}'" did not complete successfully: exit code: 1

[stage-5 4/5] RUN --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind,from=stage-modules,src=/modules,dst=/tmp/modules,rw --mount=type=bind,from=stage-akmods-main,src=/rpms,dst=/tmp/rpms,rw --mount=type=bind,from=ghcr.io/blue-build/cli:83d654d3a25c2fc679e8d814badd579ec5337020-build-scripts,src=/scripts/,dst=/tmp/scripts/ --mount=type=cache,dst=/var/cache/rpm-ostree,id=rpm-ostree-cache-myos-gnome-intel-mac-latest,sharing=locked source /tmp/scripts/exports.sh && /tmp/scripts/run_module.sh akmods '{"type":"akmods","install":["facetimehd"]}':
6.705 Updating metadata for 'rpmfusion-nonfree-updates-testing'...done
7.878 Updating metadata for 'rpmfusion-free'...done
8.725 Updating metadata for 'rpmfusion-nonfree-updates'...done
9.518 Updating metadata for 'rpmfusion-free-updates-testing'...done
10.81 Updating metadata for 'rpmfusion-free-updates'...done
12.23 Updating metadata for 'updates'...done
12.61 Updating metadata for 'fedora-cisco-openh264'...done
15.32 Updating metadata for 'fedora'...done
15.94 Updating metadata for 'updates-archive'...done
15.95 error: Updating rpm-md repo 'updates-archive': cannot update repo 'updates-archive': Yum repo downloading error: Downloading error(s): repodata/2e7db4492173b6c437fd1299dc335e63d09f24cbdadeac5175a61b787c2f7a44-filelists.xml.zck - Cannot download, all mirrors were already tried without success; Last error: Status code: 403 for https://fedoraproject-updates-archive.fedoraproject.org/fedora/40/x86_64/repodata/2e7db4492173b6c437fd1299dc335e63d09f24cbdadeac5175a61b787c2f7a44-filelists.xml.zck (IP: 3.161.213.74)

Containerfile:59

58 | # Module RUNs
59 | >>> RUN
60 | >>> --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw
61 | >>> --mount=type=bind,from=stage-modules,src=/modules,dst=/tmp/modules,rw
62 | >>> --mount=type=bind,from=stage-akmods-main,src=/rpms,dst=/tmp/rpms,rw
63 | >>> --mount=type=bind,from=ghcr.io/blue-build/cli:83d654d3a25c2fc679e8d814badd579ec5337020-build-scripts,src=/scripts/,dst=/tmp/scripts/
64 | >>> --mount=type=cache,dst=/var/cache/rpm-ostree,id=rpm-ostree-cache-myos-gnome-intel-mac-latest,sharing=locked
65 | >>> source /tmp/scripts/exports.sh
66 | >>> && /tmp/scripts/run_module.sh akmods '{"type":"akmods","install":["facetimehd"]}'
67 |

ERROR: failed to solve: process "/bin/sh -c source /tmp/scripts/exports.sh && /tmp/scripts/run_module.sh akmods '{"type":"akmods","install":["facetimehd"]}'" did not complete successfully: exit code: 1
[02:07:02 ERROR] => Failed to build image
Error: Process completed with exit code 1.
`

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

It would be nice if we can at least include the major.minor.patch for the kernel version in the tag.

Ie

akmods:fsync-40-6.9.8

As an additional tag. It would make it easier to grab older versions and match them to the kernel instead of looping through the ostree.linux label and then pulling through date-tag

Describe the package

I'd like to request Fingerprint Drivers XPS 15 9500 to allow logging into the system with.

I am running on bluefin dx.

Image

All Images

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.

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.

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.

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

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

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

Describe the package

I'd like to request that the digimend-kernel-drivers be included to allow support for more drawing tablets than the Wacom driver supports.

I hope this request is being done properly.

Image

Bazzite

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

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.

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

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

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

@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) / removed ~~ - will be added to ucore
• nvidia-470xx: compile failure - will not enable: rpmfusion has dropped support
• ~~ rtl18814au: compile failure (kernel 6.8) ~~ see #185
• ~~ rtl188xxau: compile failure (kernel 6.8)~~ see #185
• #168 (kernel 6.8 builds on F40 but not F39, rpmfusion fix pending)
• xpadneo: negativo17 does not yet provide F40

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

These kmods have spec files here: https://github.com/ublue-os/packages/tree/main/akmods
And build in our copr here: https://copr.fedorainfracloud.org/coprs/ublue-os/akmods/packages/

They aren't currently building for kernel 6.8, so they are still in the repo but skipping build conditionally.

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.

Hello,

Surface books come with an integrated wireless xbox receiver but no hardware pairing button. This means on the current surface images there is no way to initiate paring. Would it be possible to integrate the patch in the following pull request? medusalix/xone#45

Thanks!

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

Here is the relevant terminal output:
0.161 ================================================ Start 'akmods' Module ================================================ 0.174 Installing akmods 0.175 Installing: openrgb xpadneo 0.198 error: Handling argument /tmp/rpms/kmods/*openrgb*.rpm: No such file or directory (os error 2)

Here is my recipe.yml:
Recipe.yml

We have "kernel package skew" when our upstream images are built on kernel A.B.C, but before our akmods images are built the the fedora repos update to kernel A.B.D. Or sometimes, even while the upstream images are building the change happens resulting in those having both kernels, while we expect a single kernel version.

The idea would be to notice if our upstream base image is not current with fedora repo, and upgrade the kernel packages during the build.

Major Concern - this may prevent downstream (eg, hwe and bazzite) from further replacing kernels?
Minor Concern - this WILL add the extra weight of another set of kernel packages in a layer to to main images, which is wasted in downstream images which replace the kernel.

This requires implementation in both akmods and main.

Describe the package

I'd like to request the it87 kernel module because sensors and sensors-detect doesn't expose my fans on my motherboard (Gigabyte B550i). I need this functionality because I have a deshrouded GPU and use mobo fan headers for my GPU fans. I can use CoolerControl for that easily, however I need the sensors/control of those sensors via this module.

I was evaluating EndeavourOS and was able to install that from AUR by going down a rabbit hole.

Image

Bazzite

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

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

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 have been added which are only used in Bazzite. While these are good for us to build, Bazzite builds less frequently and is more actively than managed than some other downstream images.

I propose to add another "stream" of kmod builds to this repo so we'll have:

• Containerfile.nvidia - as is, just builds nvidia kmod
• Containerfile.common - will build common/shared kmods (eg, those which were originally in main:kmods images, and/or are used in both Aurora/Bluefin and Bazzite)
• Containerfile.extra - new addition will be primarily for kmods used in Bazzite or any others we need to build but don't fit in common

The new extra category would NOT blog merge queues for akmods which would allow our hwe and bluefin builds to stay more reliable, even if we have somewhat experimental kmods in extra.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository