-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debian packaging improvements (module autoloading) #54
base: master
Are you sure you want to change the base?
Conversation
(Sorry for the late response) The two commits in this merge request should be in at least two separate MRs. |
Hello, Thanks for updating this tool :) I created a separate merge request for just the udev rules: #61 |
This DKMS script will be run when the package is installed. It will run the standard DKMS build steps (compiling the module against the current kernel version), and will additionally: - Load the module immediately - Configure the module to be loaded automatically at boot This is not handled by default by DKMS, because usually, kernel modules are associated with some hardware, and the hardware detection in the kernel will be enough to load the module. But, in the case of tty0tty, there is no associated hardware, and so, the module must be explicitly loaded.
Now I have removed that part from this pull request, so you can merge them independently. |
|
||
DKMS_NAME=tty0tty | ||
DKMS_PACKAGE_NAME=$DKMS_NAME-dkms | ||
DKMS_VERSION=1.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be updated when/if a version 1.3 of tty0tty (orany other new version number) is released. I'm not sure if it is possible to extract this info from somewhere else, what would be considered appropriate here?
On Mon, Sep 16, 2024 at 04:02:43AM -0700, Adrien Destugues wrote:
+DKMS_VERSION=1.2
This needs to be updated when/if a version 1.3 of tty0tty (orany
other new version number) is released. I'm not sure if it is possible
to extract this info from somewhere else,
what would be considered appropriate here?
Appropriate would be discussioning it outside this merge request.
Groeten
Geert Stappers
--
Silence is hard to parse
|
This merge request changes two things: