Package Details: vendor-reset-git 0.0.17.r94-1

Git Clone URL: https://aur.archlinux.org/vendor-reset-git.git (read-only, click to copy)
Package Base: vendor-reset-git
Description: reset routines for navi et al.
Upstream URL: https://github.com/gnif/vendor-reset
Licenses: GPL-2.0
Submitter: spencerharmon
Maintainer: spencerharmon
Last Packager: spencerharmon
Votes: 2
Popularity: 0.59
First Submitted: 2020-11-14 06:23
Last Updated: 2020-11-15 23:35

Dependencies (2)

Required by (0)

Sources (1)

Latest Comments

Ashark commented on 2020-12-05 18:46

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.

zaszi commented on 2020-11-18 08:57

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

Hugano commented on 2020-11-15 22:29

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.

spencerharmon commented on 2020-11-15 20:41

@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.

spencerharmon commented on 2020-11-15 19:06

It's a downgrade, right?

spencerharmon commented on 2020-11-15 18:55

@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).

Hugano commented on 2020-11-15 10:56

@spencerharmon, thanks for the answer. Yes, both of them gives me the same result. I read about it a bit and found out that I need a linux-headers package. arch wiki. But since I'm building it from source I can't just install it from repo but need to get it from local build. Currently I'm trying to modify PKGBUILD of linux-vfio aur package and enable CONFIG_HEADERS_INSTALL in the config file. No idea will it work or not, but I'll try. I also updated linux-vfio to the latest version.

 pacman -Qi linux-vfio
Name            : linux-vfio
Version         : 5.9.4.arch1-1

 uname -r
5.9.4-arch1-1-vfio

spencerharmon commented on 2020-11-15 00:28

If you have a patch ready, you can co-maintain. I'm unable to test for the next week or so. Do you want to be specific about what you think is "wrong" and what "correct" is?

spencerharmon commented on 2020-11-14 18:01

Presumably both pacman -Qi linux-vfio and uname -r agree on your kernel version?

Do you have a Makefile in /lib/modules/5.9.4-arch1-1-vfio/build/? It should be there. It should be a symlink to /usr/lib, but you could also check what's going on in /usr/lib/modules/5.9.4-arch1-1-vfio/build/.

You're a couple of minor revisions behind on linux-vfio. You could try to update that package/rebuild the kernel.

Do you have any other kernels installed you can try?

Hugano commented on 2020-11-14 14:40

0.13-1 gives me this. How can I fix it?

==> Starting build()...
make -C /lib/modules/5.9.4-arch1-1-vfio/build M=/home/user/.cache/yay/vendor-reset-git/src/vendor-reset modules
make[1]: *** /lib/modules/5.9.4-arch1-1-vfio/build: No such file or directory.  Stop.
make: *** [Makefile:8: build] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
error making: vendor-reset-git