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: daftaupe
Last Packager: spencerharmon
Votes: 2
Popularity: 0.000000
First Submitted: 2020-11-14 06:23 (UTC)
Last Updated: 2020-11-15 23:35 (UTC)

Dependencies (2)

Required by (0)

Sources (1)

Latest Comments

1 2 Next › Last »

trallafitti commented on 2024-03-23 19:25 (UTC)

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

ipaqmaster commented on 2023-02-24 07:56 (UTC) (edited on 2023-02-27 14:03 (UTC) by ipaqmaster)

For the source git://github.com/gnif/vendor-reset it causes my makepkg to hang indefinitely on "Cloning into bare repository" until it eventually times out.

fatal: unable to connect to github.com: github.com[0: x.x.x.x]: errno=Connection timed out

Switching that prefix to https:// fixes that hang, but now I get src/vendor-reset: Not a directory which is just a broken symlink.

Ashark commented on 2020-12-05 18:46 (UTC) (edited on 2020-12-20 20:50 (UTC) by Ashark)

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 (UTC)

@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 (UTC) (edited on 2020-11-15 22:32 (UTC) by Hugano)

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 (UTC)

@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 (UTC)

It's a downgrade, right?

spencerharmon commented on 2020-11-15 18:55 (UTC) (edited on 2020-11-15 19:05 (UTC) by spencerharmon)

@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 (UTC)

@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