Search Criteria
Package Details: vendor-reset-git 0.1.1.r117-1
Package Actions
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: | daftaupe |
Votes: | 2 |
Popularity: | 0.000000 |
First Submitted: | 2020-11-14 06:23 (UTC) |
Last Updated: | 2024-12-13 17:08 (UTC) |
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.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 modifyPKGBUILD
oflinux-vfio
aur package and enableCONFIG_HEADERS_INSTALL
in the config file. No idea will it work or not, but I'll try. I also updatedlinux-vfio
to the latest version.1 2 Next › Last »