Search Criteria
Package Details: tp_smapi-dkms 0.44-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/tp_smapi-dkms.git (read-only, click to copy) |
---|---|
Package Base: | tp_smapi-dkms |
Description: | DKMS controlled modules for ThinkPad's SMAPI functionality |
Upstream URL: | http://www.thinkwiki.org/wiki/Tp_smapi |
Licenses: | GPL |
Conflicts: | tp_smapi |
Provides: | tp_smapi |
Submitter: | TamCore |
Maintainer: | barbuk |
Last Packager: | barbuk |
Votes: | 63 |
Popularity: | 0.000561 |
First Submitted: | 2011-08-30 13:12 (UTC) |
Last Updated: | 2023-08-01 06:59 (UTC) |
Required by (7)
- auto-rotation-hdaps-git (requires tp_smapi)
- hdapsicon-git (requires tp_smapi)
- thinkwatt (requires tp_smapi) (optional)
- tlp-git (requires tp_smapi) (optional)
- tlp-ppd-git (requires tp_smapi) (optional)
- tp-battery-icon-git (requires tp_smapi) (optional)
- xfce4-hdaps (requires tp_smapi)
Latest Comments
1 2 3 4 Next › Last »
MartinX3 commented on 2023-07-12 08:21 (UTC)
Please create a hotfix release with commit https://github.com/linux-thinkpad/tp_smapi/commit/0c3398b1acf2a2cabd9cee91dc3fe3d35805fa8b
MartinX3 commented on 2023-07-12 07:31 (UTC)
Broken on kernel 6.4
barbuk commented on 2023-05-04 07:23 (UTC)
Hdaps is owned by the kernel package:
The installation still works for the thinkpad_ec and tp_smapi modules, but
dkms status
now show a warning:I don't know if it's an issue with a bad dkms tree, but removing the module and rebuilding it works fine:
Atomisirsi commented on 2023-03-13 18:15 (UTC) (edited on 2023-03-13 18:15 (UTC) by Atomisirsi)
I do not remember exactly when it started, but
dkms
had problems installing thetp_smapi
modules due to already existinghdaps.ko.zst
for some weeks.I solved this by adding the following line to the
pacman.conf
:nosada commented on 2021-05-30 07:43 (UTC)
@ryshglene Thank you so much for your detailed explanation and patch. It seems to work collectly. I updated this package to 0.43-4 to merge your patch.
I confirmed there's a bunch of leftovers... Thanks for your advice.
ryshglene commented on 2021-05-28 17:48 (UTC) (edited on 2021-05-28 18:23 (UTC) by ryshglene)
I think I've found the issue.
TLDR: tp_smapi
Makefile
deletes the originalhdaps
module. DKMS backs it up, so it should be fine, but it doesn't know how to restore it correctly. So it restores it under/lib/modules/$(uname -r)/updates
. This results in leftover files under/lib/module
by DKMS when removing or upgrading the package. See patch below for fix.Edit: wrong dir in TLDR
One of the commands DKMS will run during install is
make install
. Because we setHDAPS=1
, one of the things that command will do is remove the original module from the source tree and install its own, as we can see from theMakefile
here:Despite removing modules from the kernel package, that's actually all well and good, because DKMS will restore it later for us, when we do
dkms remove
on the package.Now, the problem arises when we run
dkms remove
. As I've seen from your (and my) logs, it looks like, since DKMS installs the module under/lib/modules/$(uname -r)/updates
, it also thinks when it has to restore later, it can restore the original module on that same location.We know this isn't the case, because the kernel package installs its
hdaps
module under/lib/modules/$(uname -r)/drivers/platform/x86
, whereas this package installs its patchedhdaps
under/lib/modules/$(uname -r)/updates
via DKMS.This disconnect in installation and restore location, causes the issue I've described earlier. And, surprisingly, it's already been observed years ago on this Fedora bug report I've found (albeit with a different module).
The solution I've found is simple. Since we want DKMS to restore under
/lib/modules/$(uname -r)/drivers/platform/x86
, we also tell DKMS to install on that same location. That way, we won't have to deal with DKMS not knowing how to put things back where it got them from.Applying this patch solves the issue for me. Please update the package if you get the same results.
Edit2: I'm not sure if you've noticed, but your logs clearly shows DKMS moving back files where it shouldn't be:
If you've been using this package for a while, you should also have a bunch of leftover "restored"
hdaps.ko.xz
files under/lib/modules
from older kernel versions (which there shouldn't be):nosada commented on 2021-05-26 15:33 (UTC)
Ah, no, I'm misunderstanding. dkms will delete module on pre-transaction hook in
pacman -R
...I manually call
dkms remove --no-depmod -m tp_smapi-dkms
and it showshdaps.ko.xz
is restored from DKMS tree; maybe it's not provided by this package.(I'm using linux-hardened 5.12.6.hardened1-1)
nosada commented on 2021-05-26 15:13 (UTC) (edited on 2021-05-26 15:13 (UTC) by nosada)
hdaps.ko.xz
is by dkms, not by this package itself. So I think it may correct thathdaps.ko.xz
isn't deleted when uninstalling this package.As far as I'm concerned, the followings will be deleted on removal by
pacman -R tp_smapi-dkms
:ryshglene commented on 2021-05-24 02:27 (UTC)
This package has weird behavior.
It deletes the existing
hdaps.ko.xz
from the kernel package, and installs its own in under/lib/modules/$(uname -r)/updates/hdaps.ko.xz
.On removal, it doesn't remove the created
/lib/modules/$(uname -r)/updates/hdaps.ko.xz
, which dirties the/lib/modules/
directory with some unowned files.I'm not sure how this could be fixed yet, but I think it needs some attention. I understand that the
updates
directory is for overriding the includedhdaps.ko.xz
in the repository kernel(s), but it shouldn't be deleting files from other packages.crumpledrhyme commented on 2020-02-24 22:50 (UTC)
@nosada this seems to be the issue indeed, I am using a Thinkpad T470. Your latest change "fixed" it :)
1 2 3 4 Next › Last »