Debian Bug report logs - #554843
bullding pure binary deb packages for modules which do not depend on dkms

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: submit@bugs.debian.org

Subject: bullding pure binary deb packages for modules which do not depend on dkms

Date: Fri, 6 Nov 2009 22:10:25 +0100

Package: dkms
Version: 2.1.0.1-2
Severity: wishlist

virtualbox-ose-source now uses dkms. This makes it almost impossible to build 
deb-packages for the kernel-modules for other hosts.

I know dkms provides a method to build such a deb-packages in principle but it 
has several heavy shortcommings compared to the old method:

1) You must install dkms on the target machine. => you must also install gcc, 
cpp, binutils, ... as dkms depends on gcc.

2) You must install the module sources on the target.

3) If you install a new self-build kernel it calls dkms_autoinstaller. Either 
it fails (no kernel-source) or it starts to compile these modules as root.


Please provide a mechanism to build a debian package which doesn't depend 
itself on dkms and which only includes the kernel-modules as binary.

Regards
-- 
Wolfgang Walter

Message #10 received at 554843@bugs.debian.org (full text, mbox, reply):

From: "Anthony L. Awtrey" <tony@awtrey.com>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb packages for modules which do not depend on dkms

Date: Tue, 10 Nov 2009 15:55:12 -0500

YES! YES! YES!

People using Debian in production environments *need* the ability to 
generate stand-alone module packages. I don't want compilers and kernel 
source/headers on production boxes for a shit-ton of reasons. Requiring 
dkms (which requires kernel headers, gcc, build-essential, etc.) is not 
a solution. I'm glad one-off users are finding this easier than m-a, but 
please fix this!

Tony

Message #15 received at 554843@bugs.debian.org (full text, mbox, reply):

From: "Drew Scott Daniels" <ddaniels@umalumni.mb.ca>

To: 554843@bugs.debian.org

Subject: dkms is for building. Packages should only use dkms when needed.

Date: Sat, 20 Feb 2010 10:32:42 -0600

Hi,
dkms is for building so shouldn't this bug be closed? If not, I'd like to
hear a specific example of a driver.

Maybe I'm misunderstanding, but shouldn't this instead be a bug against
drivers in Debian that use dkms instead of requiring a new package be
created in the archive for each relevant kernel release. With pre-compiled
modules there should be separate packages per architecture too. I seem to
recall that Debian used to update all the main kernel modules with a
relevant kernel update (though this is painful for the security and stable
release teams).

I guess non-free drivers need more support since some in Security said
they don't support non-free, but that could be a wont-fix for those
drivers if the maintainers decide they need dkms in order to support
updates.

dkms seems most useful for third party modules from organizations like
hardware vendors who don't yet have in-tree or in-archive drivers and
can't support binaries for all the relevant kernels in distributions that
have dkms.

Alternately, maybe the bug is a request for dkms to be an
install/pre-install time requirement, but removable either by making sure
it's just "recommends" for drivers, or through drivers being released as
"-source" style packages that create an installation. Still, this seems
like a bug for the dkms depending kernel module/driver packages. If this
is the case, then maybe people want dkms installed in such a way that it
doesn't autobuild on reboot, but I guess that's the same argument as
services that provide tools, or that services shouldn't autostart (but
they do).

If dkms is required for drivers, then packages like gcc will become pseudo
required again which was considered a bug with security implications.

Thanks,

     Drew Daniels
Resume: http://www.boxheap.net/ddaniels/resume.html

Message #20 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Christopher Huhn <C.Huhn@gsi.de>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb kernel module packages with the help of dkms

Date: Fri, 30 Apr 2010 18:29:29 +0200

Hi folks,

I'd also appreciate this a lot and I don't think that this is something
the driver packages schould provide by themself.

Simple use case: Many (> 100) file servers running Debian stable with
the same kernel version (ideally the Debian standard kernel) and Adaptec
RAID controllers need a newer/the newest aacraid driver while upgrading
the whole kernel is impossible.

Adaptec provides the driver source with dkms (as a source RPM). dkms on
Debian easily turns it into a aacraid-dkms package that 1) builds the
module and 2) installs it to a location where it takes precedence over
the old module version provided with the stock kernel, runs depmod ...

In this use case it would be very desirable that step 1 is run on only
one server, creates an aacraid-module-<kernel version>.deb containing
the binary module and a postinst executing step 2) that can be deployed
to the other (> 99) servers without the need for dkms and its
dependencies on all servers.

Cheers,
    Christopher

Message #25 received at 554843@bugs.debian.org (full text, mbox, reply):

From: "Anthony L. Awtrey" <tony@awtrey.com>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb kernel module packages with the help of, dkms

Date: Mon, 24 May 2010 16:05:00 -0400

Drew Scott Daniels wrote:
> Maybe I'm misunderstanding, but shouldn't this instead be a bug
> against drivers in Debian that use dkms instead of requiring a new
> package be created in the archive for each relevant kernel release.
> ...
> I guess non-free drivers need more support since some in Security said
> they don't support non-free, but that could be a wont-fix for those
> drivers if the maintainers decide they need dkms in order to support
> updates.

I believe you *are* misunderstanding the issue. Opening dozens of bug
reports for individual drivers is not an answer for anything. If you see
the list of drivers currently in Module Assistant, there are plenty of
Open Source source drivers represented there.

In many cases it is necessary to run newer alsa, kqemu, wifi, scsi or
filesystem drivers than those that ship with otherwise stable kernels.
And since I've got 30 production boxes, the idea of installing all the
dependent packages and then building the same fscking source code 30
times on my production boxes fills me with rage.

Debian's key strength is software packaging and distribution! dkms
should at least provide the option to create stand-alone binary module
packages for distribution of compiled modules to other computers.

Christopher Huhn wrote:
> In this use case it would be very desirable that step 1 is run on only
> one server, creates an aacraid-module-<kernel version>.deb containing
> the binary module and a postinst executing step 2) that can be
> deployed to the other (> 99) servers without the need for dkms and its
> dependencies on all servers.

Exactly! Whoever designed dkms as a replacement for m-a did not talk to
anyone with dozens or hundreds of systems to maintain. It is totally
asinine.

Tony

Message #30 received at 554843-done@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: 554843-done@bugs.debian.org

Subject: re: building pure binary deb packages for modules which do not depend on dkms

Date: Tue, 17 Aug 2010 22:37:31 -0400

you can use the 'mkdeb' option which is available in at least the
latest version in unstable:

$ sudo dkms mkdeb -m virtualbox-ose -v 3.2.8

best wishes,
mike

Message #35 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Bill Gatliff <bgat@billgatliff.com>

To: michael.s.gilbert@gmail.com, 554843@bugs.debian.org

Subject: The mkdeb target isn't producing a binary-only package, though...

Date: Fri, 20 Aug 2010 15:14:45 -0500

Mike et. al:

I'm a DKMS noob but I really like the idea.  But I too need to be able
to produce binary-only packages--- and mkdeb isn't quite there.

Here is what the mkdeb output produces for the psb-kernel-source
package, which I assume is typical:

$ dpkg --contents
/var/lib/dkms/psb-kernel-source/4.41.1/deb/psb-kernel-source-dkms_4.41.1_all.deb
drwxr-xr-x root/root         0 2010-08-20 21:38 ./
drwxr-xr-x root/root         0 2010-08-20 21:38 ./usr/
drwxr-xr-x root/root         0 2010-08-20 21:38 ./usr/src/
-rw-r--r-- root/root   1145212 2010-08-20 21:38
./usr/src/psb-kernel-source-4.41.1.dkms.tar.gz

What I'm really looking for is a package that contains only the
modules themselves, pre-built for a specific kernel.  So instead of
the above, I want to see a content list like:

$ dpkg -L a1rvc-video-modules-2.6.28.10-a1rvc
/.
/usr
/usr/sbin
/usr/bin
/usr/share
/usr/share/doc
/usr/share/doc/a1rvc-video-modules-2.6.28.10-a1rvc
/usr/share/doc/a1rvc-video-modules-2.6.28.10-a1rvc/changelog.gz
/usr/share/doc/a1rvc-video-modules-2.6.28.10-a1rvc/copyright
/lib
/lib/modules
/lib/modules/2.6.28.10-a1rvc
/lib/modules/2.6.28.10-a1rvc/misc
/lib/modules/2.6.28.10-a1rvc/misc/a1rvc_video.ko
/lib/modules/2.6.28.10-a1rvc/misc/app_interface.ko

b.g.

Message #40 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Bill Gatliff <bgat@billgatliff.com>

To: 554843@bugs.debian.org

Subject: Hmm... I take that back :)

Date: Fri, 20 Aug 2010 15:31:36 -0500

Guys:


Seems I'm confused...  Well, I *am* confused, I'm just not sure where
the confusion is coming from...  :)

I took a look at the psb-kernel-source-4.41.1.dkms.tar.gz file, and it
looks like this:

$ dpkg --extract
/var/lib/dkms/psb-kernel-source/4.41.1/deb/psb-kernel-source-dkms_4.41.1_all.deb
.
$ cd usr/src
$ tar xzvf psb-kernel-source-4.41.1.dkms.tar.gz
./dkms_main_tree/
./dkms_main_tree/dkms_dbversion
./dkms_main_tree/2.6.28.10-a1rvc/
./dkms_main_tree/2.6.28.10-a1rvc/i686/
./dkms_main_tree/2.6.28.10-a1rvc/i686/module/
./dkms_main_tree/2.6.28.10-a1rvc/i686/module/drm.ko
./dkms_main_tree/2.6.28.10-a1rvc/i686/module/psb.ko
./dkms_main_tree/2.6.28.10-a1rvc/i686/log/
./dkms_main_tree/2.6.28.10-a1rvc/i686/log/make.log
...

So the package file *does* indeed contain prebuilt, kernel-specific
modules as I had hoped.  Of course, it also contains a big pile of
source code that I don't need, but it looks like --binaries-only
command line option to dkms will fix that.

Unfortunately, when I do:

$ sudo dkms -m psb-kernel-source -v 4.41.1 -k `uname -r`
--binaries-only mkdeb mkdsc
$ sudo dpkg --install
/var/lib/dkms/psb-kernel-source/4.41.1/deb/psb-kernel-source-dkms_4.41.1_all.deb

(Reading database ... 65369 files and directories currently installed.)
Preparing to replace psb-kernel-source-dkms 4.41.1 (using
.../psb-kernel-source-dkms_4.41.1_all.deb) ...
Unpacking replacement psb-kernel-source-dkms ...
Setting up psb-kernel-source-dkms (4.41.1) ...
Removing old psb-kernel-source-4.41.1 DKMS files...
Loading new psb-kernel-source-4.41.1 DKMS files...

Error! Tarball is a DKMS binaries-only archive, but your DKMS tree
does not have the source installed for psb-kernel-source-4.41.1.
To load a DKMS binaries-only archive, you must already have the module
source in your DKMS tree.

This can be overridden by using --force, but this is not recommended since
it will eliminate your ability to actually build for this module.
dpkg: error processing psb-kernel-source-dkms (--install):
 subprocess post-installation script returned error exit status 6
Errors were encountered while processing:
 psb-kernel-source-dkms



If I already have the pre-built binaries, why do I need the sources
for them?  The target machine has no need for the source code.  Oh,
and I don't know which --force I should be using...


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Message #45 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: Bill Gatliff <bgat@billgatliff.com>, 554843@bugs.debian.org

Subject: Re: [Pkg-dkms-maint] Bug#554843: Hmm... I take that back :)

Date: Mon, 23 Aug 2010 23:37:35 -0400

On Fri, 20 Aug 2010 15:31:36 -0500 Bill Gatliff wrote:

> Guys:
> 
> 
> Seems I'm confused...  Well, I *am* confused, I'm just not sure where
> the confusion is coming from...  :)
> 
> I took a look at the psb-kernel-source-4.41.1.dkms.tar.gz file, and it
> looks like this:
> 
> $ dpkg --extract
> /var/lib/dkms/psb-kernel-source/4.41.1/deb/psb-kernel-source-dkms_4.41.1_all.deb
> .
> $ cd usr/src
> $ tar xzvf psb-kernel-source-4.41.1.dkms.tar.gz
> ./dkms_main_tree/
> ./dkms_main_tree/dkms_dbversion
> ./dkms_main_tree/2.6.28.10-a1rvc/
> ./dkms_main_tree/2.6.28.10-a1rvc/i686/
> ./dkms_main_tree/2.6.28.10-a1rvc/i686/module/
> ./dkms_main_tree/2.6.28.10-a1rvc/i686/module/drm.ko
> ./dkms_main_tree/2.6.28.10-a1rvc/i686/module/psb.ko
> ./dkms_main_tree/2.6.28.10-a1rvc/i686/log/
> ./dkms_main_tree/2.6.28.10-a1rvc/i686/log/make.log
> ...
> 
> So the package file *does* indeed contain prebuilt, kernel-specific
> modules as I had hoped.  Of course, it also contains a big pile of
> source code that I don't need, but it looks like --binaries-only
> command line option to dkms will fix that.
> 
> Unfortunately, when I do:
> 
> $ sudo dkms -m psb-kernel-source -v 4.41.1 -k `uname -r`
> --binaries-only mkdeb mkdsc
> $ sudo dpkg --install
> /var/lib/dkms/psb-kernel-source/4.41.1/deb/psb-kernel-source-dkms_4.41.1_all.deb
> 
> (Reading database ... 65369 files and directories currently installed.)
> Preparing to replace psb-kernel-source-dkms 4.41.1 (using
> .../psb-kernel-source-dkms_4.41.1_all.deb) ...
> Unpacking replacement psb-kernel-source-dkms ...
> Setting up psb-kernel-source-dkms (4.41.1) ...
> Removing old psb-kernel-source-4.41.1 DKMS files...
> Loading new psb-kernel-source-4.41.1 DKMS files...
> 
> Error! Tarball is a DKMS binaries-only archive, but your DKMS tree
> does not have the source installed for psb-kernel-source-4.41.1.
> To load a DKMS binaries-only archive, you must already have the module
> source in your DKMS tree.
> 
> This can be overridden by using --force, but this is not recommended since
> it will eliminate your ability to actually build for this module.
> dpkg: error processing psb-kernel-source-dkms (--install):
>  subprocess post-installation script returned error exit status 6
> Errors were encountered while processing:
>  psb-kernel-source-dkms
> 
> 
> 
> If I already have the pre-built binaries, why do I need the sources
> for them?  The target machine has no need for the source code.  Oh,
> and I don't know which --force I should be using...

this looks like an issue with the way the mkdeb feature is currently
designed. it can definately be improved, and i'll take a look at that
at some point, but it won't get into squeeze at this point.

mike

Message #52 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Sylvain Munaut <246tnt@gmail.com>

To: 554843@bugs.debian.org

Subject: pure binary packages with DKMS

Date: Wed, 7 Mar 2012 17:16:05 +0100

[Message part 1 (text/plain, inline)]

Hi,

I don't quite see how this is closed ?

If I try to build deb with the 'binaries only' option, the resulting
packages are still dependant of DKMS so ... what's the solution here ?

Cheers,

    Sylvain

[Message part 2 (text/html, inline)]

Message #57 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Jan Arie Gutter <kernel@jangutter.com>

To: 554843@bugs.debian.org

Date: Thu, 7 Jun 2012 16:48:21 +0200

I have no idea if anyone is still interested in this, but here's my
two cents worth:

We need to deploy pre-built modules (from source) to a lot of servers
that, for various reasons (security, CPU load, space, etc.) do not
have gcc and the kernel headers installed. DKMS solves a similar, but
completely different problem. I used module-assistant (m-a) for a
workaround, but honestly, it might be just as easy as to tar up the
modules on the build box, and copy them over to the production boxes.
If this were slightly more automated, it would be much appreciated,
but for now, we have a workaround.

Here's a detail example of how the process works to install
xtables-addons to multiple machines without using dkms and therefore
installing gcc + kernel headers.

On the "Build/Staging" box:

1. Mirror the exact configuration of the production server: we're
basically imaging them so they're exactly the same.
2. Install all build dependencies for xtables-addons (apt-get
build-dep xtables-addons-common and apt-get build-dep
xtables-addons-dkms), also install module-assistant
3. Run the following:
apt-get install xtables-addons-source
m-a build xtables-addons
apt-get -d install xtables-addons-common
4. Now, the following files should have been created/downloaded (I'm
using our specific version example here):
/usr/src/xtables-addons-modules-3.2.0-24-generic_1.41-2ubuntu0.1_amd64.deb
/var/cache/apt/archives/xtables-addons-common_1.41-2ubuntu0.1_amd64.deb
They can be distributed to the "Production/Deployed" server.

On the "Production/Deployed" box:

1. do a dpkg -i of both packages at the same time, so dependencies are
resolved: dpkg -i *.deb
2. enjoy!

I'm horribly certain that this method I just described has got lots of
caveats, but, it seems to work, and adds tracking to the few .ko files
that is copied over. Moreover it also seems to allow the userspace
half required to be installed with correct dependency tracking. It
just goes to show that some of the more underdocumented utilities may
still shine in a lot of places!

Jan Gutter

Message #62 received at 554843@bugs.debian.org (full text, mbox, reply):

From: "Anthony L. Awtrey" <tony@awtrey.com>

To: 554843@bugs.debian.org

Subject: Re: bullding pure binary deb packages for modules which do not depend on dkms

Date: Mon, 20 Aug 2012 15:36:09 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, three years have come and gone, and the relentless, aggravating
march to DKMS continues. The latest victim in the apparent effort to
move Debian out of production environments is open-vm-tools, which
recently dropped support for m-a.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659735

Daniel Baumann, maintainer of open-vm-source states:
> m-a is not really maintained and deprecated too, so no, doesn't
> make sense to add it back, sorry.

I've searched for discussions on mailing lists or comments on wiki
pages where the DKMS design decisions are being made... can't find
anything. Is no one driving this bus?

I will obviously solve this problem for myself internally, but the
fact that I have to seems to mean that no one really cares about
production security anymore. There is no way in hell I'd deploy a box
to the cloud with compilers. Apparently I'm alone in this.

Whatever. I give up.

Tony
- -- 
Anthony L. Awtrey

http://awtrey.com/
http://orlandotenor.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQMpGlAAoJEC1MrsQmmCjYpsMH+wWsUVIm63pAsn9IBdv1DSGP
O+KoqRMy7RIWhaJRHUnQnHro3Y7k254kBExuIGQRXOJlJVU+5fQtcyGHXVS5b+f6
MRS+CQoRkm7Ov3XvzZ6qOyvewQPGaDmEvjJ4FVUMiP97yWceDzwD0/MYgNJFINQD
UUBDmNYwI6fY98c65+nu0Fmeu+cnm88Gw8rXXV2YTAVJx+JHCcW7BaSuAZ0lIBm0
qtkJk0cH5jfBUAw0ylNPtfuOxnFZ119SAmoqjqyrKXG1RDHZ3NvVhroenli4l9XW
bo3eAEeGbkCYpCCdDKvbHy3wDRuffg3f4yWdDQyZvklU5aZpvoenUhqvVT82lVU=
=ycOr
-----END PGP SIGNATURE-----

Message #67 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: "Anthony L. Awtrey" <tony@awtrey.com>, 554843@bugs.debian.org

Subject: Re: Bug#554843: bullding pure binary deb packages for modules which do not depend on dkms

Date: Tue, 21 Aug 2012 14:29:04 +0200

Hi Anthony,

dkms is designed so that you it will build a .deb package for you which you 
can install on any machine, no need for compilers or anything.

see for example: 
http://linux.dell.com/git/dkms.git/?p=dkms.git;a=blob;f=debian/HOWTO.Debian;hb=HEAD


cheers,
	Holger

Message #72 received at 554843@bugs.debian.org (full text, mbox, reply):

From: "Anthony L. Awtrey" <tony@awtrey.com>

To: 554843@bugs.debian.org

Subject: Re: Bug#554843: bullding pure binary deb packages for modules which do not depend on dkms

Date: Tue, 21 Aug 2012 09:51:39 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holger,

I know you really believe that, but this is exactly the point! It
isn't true now and hasn't been for over three years.

I know you can build a binary deb package using dkms like this:

dkms mkdeb -m open-vm-tools -v 2012.05.21 \
  --dkmsframework framework.conf --binaries-only

And if you dump out the deb package it builds, you will find this
control file in it:

Package: open-vm-tools-dkms
Version: 2012.05.21
Architecture: all
Maintainer: Dynamic Kernel Modules Support Team
<pkg-dkms-maint@lists.alioth.debian.org>
Installed-Size: 160
Depends: dkms (>= 1.95)
Section: misc
Priority: optional
Description: open-vm-tools driver in DKMS format.


This package depends in dkms, which further depends / recommends in
gcc, make, and all the kernel headers and debian package build
infrastructure.

I don't want any dependencies except on the kernel image that we are
building against. I want the *.ko files dropped into the proper
/lib/module/* kernel tree without requiring some kind of postinst
script that is causing the exact problem I'm trying to avoid!

I seriously give up. I will write my own solution. Thanks.

Tony
- -- 
Anthony L. Awtrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQM5JnAAoJEC1MrsQmmCjY3+kIAILBIX1kRFVKL7aj1qpzWiCX
6Q9CRvtE6HHftMmdu+ATUWqkAvWUATO8N74qPNS1/N2hq9Iq+3RFrDxO9opG0Uod
vWaOJo2T1/dOoVVb/W+0NMyJjxO4sR4sCoG0ZCNs+znEM+AjOKUe4oTjjB7KNyuI
imla5n6XbiUFiUtTAfeeMlPOYBMei8Fu1iriyQmqA53uZMHOIZ2AWka5RrrjbNwc
gl71ABZLL5RPXHmrSctNzcWphelSi9sIisPReQ22P/+Vlxy/fooNfQp4LGq7pxXc
HLx/KFE6e3SlT3VeL3nb9/YWTnvjcffr6mYSy+yRC8YvH/QlPBXZngeVd19mdvI=
=ms9g
-----END PGP SIGNATURE-----

Message #77 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 554843@bugs.debian.org

Subject: Re: [Pkg-dkms-maint] Bug#554843: bullding pure binary deb packages for modules which do not depend on dkms

Date: Tue, 21 Aug 2012 12:38:08 -0400

On Tue, Aug 21, 2012 at 9:51 AM, Anthony L. Awtrey wrote:
> I know you can build a binary deb package using dkms like this:
>
> dkms mkdeb -m open-vm-tools -v 2012.05.21 \
>   --dkmsframework framework.conf --binaries-only

mkdeb certainly has some issues, but complaining is not going to solve
them.  Please take a look at what the code is currently doing, and
figure out how to fix it.  Then send us a patch, and we'll apply it.
That's how things get done.  A volunteer needs to step up to do it.
It should be pretty straightforward since the right bits are built,
they're just put in a tarball within the deb, rather than in the
correct paths.  Anyway, it should be fairly easy for anyone with
sufficient motivation and a bit of time.

Best wishes,
Mike

Message #82 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Stefan Seidel <debian@stefanseidel.info>

To: 554843@bugs.debian.org

Subject: Re: [Pkg-dkms-maint] Bug#554843: bullding pure binary deb packages

Date: Thu, 30 Aug 2012 12:11:12 +0200

It is indeed possible to build those module packages. After dkms
build, cd to /var/lib/dkms/$MODULE$/$MOD_VERS$/build and execute

KVERS=`uname -r` fakeroot debian/rules binary-modules

This will create the correct $MODULE-module-$KVERS-$MOD_VERS deb
package with no Depends. I tested this with iscsitarget-dkms.

It should be possible to add a mkbmdeb (make binary-modules deb)
action to dkms which executes this command (possibly with KVERS as a
parameter, just like for the mkkmp target).

Stefan

Message #87 received at 554843@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: 554843@bugs.debian.org

Cc: "Stefan Seidel" <debian@stefanseidel.info>

Subject: Re: [Pkg-dkms-maint] Bug#554843: bullding pure binary deb packages

Date: Fri, 19 Oct 2012 11:33:27 +0200

Hi Stefan,

> It is indeed possible to build those module packages. After dkms
> build, cd to /var/lib/dkms/$MODULE$/$MOD_VERS$/build and execute
>
> KVERS=`uname -r` fakeroot debian/rules binary-modules
>
> This will create the correct $MODULE-module-$KVERS-$MOD_VERS deb
> package with no Depends. I tested this with iscsitarget-dkms.

This feature depends on that target being available in the
iscsitarget-dkms package so is not easily generalised to other modules,
unfortunately.

I do agree that such a feature is very desirable in dkms.

Cheers,
Thijs

Message #92 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@uvt.nl>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb packages: patch

Date: Fri, 19 Oct 2012 14:44:35 +0200

[Message part 1 (text/plain, inline)]

tags 554843 +patch
thanks

Hi,

Here's a patch to extend dkms to also build 'pure binary' deb packages which 
can be installed on hosts without requiring gcc and friends to be present. The 
use cases can be found in this bug log. It can be dropped in the 
debian/patches dir directly.

This works for me with one module, so I'm submitting it here. It may of course 
be open to improvement or a different way of implemneting this that the dkms 
maintainers may prefer.



Cheers,
Thijs

-- 
Thijs Kinkhorst <thijs@uvt.nl> – LIS Unix

Universiteit van Tilburg – Library and IT Services • Postbus 90153, 5000 LE
Bezoekadres > Warandelaan 2 • Tel. 013 466 3035 • G 236 • http://www.uvt.nl

[mkbmdeb (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #99 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Mathieu Parent <math.parent@gmail.com>

To: 554843@bugs.debian.org

Subject: Patch tested

Date: Wed, 14 Nov 2012 19:18:53 +0100

Hi,

This patch works for me for open-vm-tools.


Some remarks:
The package should probably be renamed to
DEBIAN_PACKAGE-dkms-modules-KERNEL_VERSION (where
KERNEL_VERSION=3.2.0-4-amd64, aka the modules subdirectory). And the
package should probably depends on linux-image-KERNEL_VERSION.

Regards

--
Mathieu Parent

Message #102 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Christoph Berg <myon@debian.org>

To: Thijs Kinkhorst <thijs@uvt.nl>, 554843@bugs.debian.org

Subject: Re: Bug#554843: bullding pure binary deb packages: patch

Date: Wed, 10 Jul 2013 15:14:51 +0200

[Message part 1 (text/plain, inline)]

Re: Thijs Kinkhorst 2012-10-19 <201210191444.39967.thijs@uvt.nl>
> Here's a patch to extend dkms to also build 'pure binary' deb packages which 
> can be installed on hosts without requiring gcc and friends to be present. The 
> use cases can be found in this bug log. It can be dropped in the 
> debian/patches dir directly.
> 
> This works for me with one module, so I'm submitting it here. It may of course 
> be open to improvement or a different way of implemneting this that the dkms 
> maintainers may prefer.

Here's an improved verion of the patch that builds
_$DEB_BUILD_ARCH.deb files instead of _all.deb, and makes the .deb
depend on the kernel version needed.

Previously, the module .deb files had the kernel version in the
package name, not sure if that should also be done here - I haven't
touched that in the patch.

Christoph
-- 
cb@df7cb.de | http://www.df7cb.de/

[mkbmdeb (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #107 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Zang MingJie <zealot0630@gmail.com>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb packages for modules which do not depend on dkms

Date: Wed, 17 Sep 2014 20:42:47 +0800

I found this feature is very useful for deploying kernel module to a cluster.

And Christoph's patch works pretty well

Message #112 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Dustin Gooding <dustingooding@gmail.com>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb packages for modules which do not depend on dkms

Date: Fri, 31 Jul 2015 21:26:51 +0000

[Message part 1 (text/plain, inline)]

What's the status on this?

Patch was provided in 2012. Further patched in 2013.  It's almost 3 years
since the first patch and almost 6 since the bug was reported.  What's
steps haven't been completed in order for this to be adopted into mainline
DKMS?

--
dustin

[Message part 2 (text/html, inline)]

Message #117 received at 554843@bugs.debian.org (full text, mbox, reply):

From: Steven Schlansker <stevenschlansker@gmail.com>

To: 554843@bugs.debian.org

Subject: bullding pure binary deb packages for modules which do not depend on dkms

Date: Thu, 3 Mar 2016 16:06:06 -0800

I too just ran across this bug -- this is exactly what I need to help get VirtualBox
guest extensions installed in all our VMs without requiring each to have a local
install of kernel headers!

I'll echo the request: how do we get this moving forward?  Seems like a really useful
feature to have!

Message #122 received at 554843-close@bugs.debian.org (full text, mbox, reply):

From: Aron Xu <aron@debian.org>

To: 554843-close@bugs.debian.org

Subject: Bug#554843: fixed in dkms 2.2.0.3-5

Date: Tue, 05 Jul 2016 22:26:59 +0000

Source: dkms
Source-Version: 2.2.0.3-5

We believe that the bug you reported is fixed in the latest version of
dkms, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 554843@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aron Xu <aron@debian.org> (supplier of updated dkms package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 06 Jul 2016 05:51:37 +0800
Source: dkms
Binary: dkms
Architecture: source
Version: 2.2.0.3-5
Distribution: unstable
Urgency: medium
Maintainer: Dynamic Kernel Modules Support Team <pkg-dkms-maint@lists.alioth.debian.org>
Changed-By: Aron Xu <aron@debian.org>
Description:
 dkms       - Dynamic Kernel Module Support Framework
Closes: 554843 653176 707008 724566 829123
Changes:
 dkms (2.2.0.3-5) unstable; urgency=medium
 .
   [ Aron Xu ]
   * Remove obsolete virtual package 'linux-image' from Recommends (Closes: #724566)
   * Do not ignore --kernelsourcedir (Closes: #653176)
   * Update upstream link to github
   * Use gbp-pq to manage patches
 .
   [ Daniel Kahn Gillmor ]
   * Make dh_dkms name and version parsing more proper (Closes: #829123)
 .
   [ Dirk Griesbach ]
   * Port apport hook to python3 and add python3-apport to Suggests (Closes: #707008)
 .
   [ Thijs Kinkhorst ]
   * mkbmdeb: support for lean binary package with only the built modules (Closes: #554843)
Checksums-Sha1:
 ed439bed3ca7f4cdc5653f570b759ad261cd8629 1676 dkms_2.2.0.3-5.dsc
 53c8fd66fbd8ed40d44fbcdca222b3bb0a6d6869 23848 dkms_2.2.0.3-5.debian.tar.xz
Checksums-Sha256:
 eccc5d46ed251ba9686dd42f2810134c5ff5343b614439d6836e979d36476d68 1676 dkms_2.2.0.3-5.dsc
 fb76dd4d2bf0b4e7d4e75891ef2b07e2ae0723d90f8956a433ce69777b3b947f 23848 dkms_2.2.0.3-5.debian.tar.xz
Files:
 6caaffd34bf026deee7120be0854aa43 1676 kernel optional dkms_2.2.0.3-5.dsc
 5ec647de561c069540acc83bc384aaa8 23848 kernel optional dkms_2.2.0.3-5.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJXfCxMAAoJEPbsVcVkKA0egdgH/06hahFV/RhM/yk4VxiM7XVm
Cs+SRbOJr7jCJRf4Z9VeKiOVHsRbLZu1G77KaxesN/wpREDnbHhUPIVhzSK3/6Yc
rIQHZvf4UcJFif6lO8Yvr+JoWwiwdCLzfTobKd4g7vU8uP+BNYoc/wqKWF4u0WNf
/vzN+ctC5jVLyi018wf77zAoxv2PKJHinJFLLeW54jj1E8VWQ3bGP1A9M2RyNFZJ
QTucN40Y+WpvNH8YcxenrPpzwT+WKJyBu4xPxqyn2VV3PukkI5Q4A9PqhlPZBTZj
nPm1S4dO0YvfqZ6EcolRABvFqJMp1up2wfaaMeSB35vC4iDmbmJwU3J66qhsh78=
=UWnA
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.