Arch Linux User Repository

When building on kernel >=6.12 you'll get fatal error: asm/unaligned.h: No such file or directory

See here https://github.com/gnif/vendor-reset/issues/87

And see here for a workaround: https://github.com/gnif/vendor-reset/pull/86#issuecomment-2892784009

For Linux >6.8, currently there is a pull request open. To build from that, change the url in the PKGBUILD to git+https://github.com/sakarie9/vendor-reset#branch=fix-6.8

When modprobing I get: modprobe: FATAL: Module vendor-reset not found in directory /lib/modules/5.9.11-arch2-1 How can I fix that?

Edit: As a workaround, I have downgraded kernel to 5.9.9.arch1-1 and the module worked.

Edit: For the kernel 5.9.14 the solution is to remove vendor-reset-git and install vendor-reset-dkms-git.

@spencerharmon I took a stab at creating a DKMS package vendor-reset-dkms-git. Feedback is more than welcome.

It was simpler than I expected. In case someone else will use this module with linux-vfio you need to install linux-vfio-headers as well. @spencerharmon, thanks.

@Hugano You may have better luck using an AUR helper like yay: https://aur.archlinux.org/packages/yay

It bares mentioning that this pkgbuild is quite rough and only motivated by the desire to avoid running make install and polluting my system with packages not tracked by pacman.

There are two glaring deficiencies other than the incorrect versioning scheme discussed below: 1. this PKGBUILD only builds the module for the currently-running kernel and 2. Kernel updates will break the module and it will need to be reinstalled.

I'm sure this can be resolved, but the preferable thing to do would be to make a dkms package. I'd prefer to spend any cycles I have for this project to that end (assuming no one else does it, which would be great!). I'm hampered by hardware problems for now, but I'm building a vm now to implement the version scheme discussed below on this package.

Ideally, we can set up tagging and CI from the repo upstream as well to reduce the number of humans in the loop to push releases, especially since it seems they're pretty active at the moment.

It's a downgrade, right?

@caltlgin Thanks for the example. Is there going to be any trouble going from semver to release number/commit? i.e. if 0.0.13-1 > 0.r94.6140e2f, will it impact users who have already installed the current version?

IMO, the right thing to do is to work with upstream to tag the repo and replace the pkgver then. That way, I can do it the right way without breaking monotonicity.

They do say "maintainers should favor a pkgver that makes sense."

Edit: I did what I did intuitively since it "makes sense" to use the actual revision number if it's right there, but as I was writing this, I found in the docs that this is exactly the right thing to do:

"If there are public releases but repo has no tags then the developer should get the release version somehow e.g. by parsing the project files."

So. I'll work with upstream. I'll achieve RELEASE.rREVSION as the version prototype, but I don't downgrade from 0.0.13-1 to 0.r94.6140e2f because that doesn't make sense and the documentation is clear about that.

It could make sense to add the rREVSION number sooner than later, though. In this regard, my pkgver() function is clearly wrong (and if this is what you meant, you were very unclear in your approach).