Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hello, Done here: https://github.com/dell/dkms/issues/74 BR, Pierre On 16/01/2019 11:31, Gianfranco Costamagna wrote: hello, diverging from upstream makes no sense to me, since the mkdeb approach has been introduced by us... what about discussing this with them and find a common approach? I'm not a direct user of this tool, so I can't have an opinion :) G. Il lunedì 14 gennaio 2019, 13:21:58 CET, Pierre Neyron ha scritto: Hello Gianfranco, Ok, but what mkdeb patch would you like ? a- should it actually include binaries unless source-only is set ? or b- should it generate an arch independent _all.deb package (with man page fixed accordingly) ? I'm more likely to volunteer for b, even if it makes Debian's dkms diverge from upstream in the way mkdeb works... Cheers Pierre On 14/01/2019 13:01, Gianfranco Costamagna wrote: > Hello, > I'm happy to accept an eventual patch :) > > G. > > Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron > mailto:pierre.ney...@free.fr>> ha scritto: > > > On 13/01/2019 16:18, drake763 wrote: > > Thanks again for your quick and detailed response! > > > > On 1/13/19 2:49 PM, Gianfranco Costamagna wrote: > >> Now, dkms run on amd64 produces binaries for *amd64* architecture, > and if you run the same command > >> on i386 you will produce kernel modules that can run only on *i386* > architecture > > > > In my understanding, running in some src directory (which has to support > > this obviously) > > > > make dkms_mkdeb > > > > produces an architecture independent deb package (hence my thought to > > have the suffix _all.deb). When I then install that very _all.deb > > package with dpkg, DKMS is invoked again and the actual compilation > > takes place where the architecture dependent binary is produced (so dkms > > is invoked twice. Once when creating the package, and again when > installing) > > > > My usecase is applying this patch for intel processors > > (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb > > package with make dkms_mkdeb. The resulting deb package actually has no > > binaries inside but only source code and - what I assume are - some > > instructions for DKMS (dkms.conf and some .c and .patch files) for > > actually installing the deb package with dpkg. > > > > Earlier in this thread, this was also discussed > > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20). > > > > But then again the currently produced package works. So if no one else > > complains, the behaviour may remain I guess (differentiating among > > binary and non-binary packages just by name is probably not really > needed). > > > > Thanks again for fixing this bug. > > > > Cheers > > Hello, > > I also think `dkms mkdeb' should produce a architecture independent > "_all.deb" package as long as content is source only. > > My patch was taking "source-only" as de facto for mkdeb, because it > seemed to me to make sense with regard to the way I understand the usage > of dkms by Debian. However it does not match what the man page explains > and possibly breaks the way the command should act in some places. > > As a result, keeping mkdeb possibly include the binary modules, hence > have an architecture dependent package (e.g. amd64.deb) seems safer. > > That said however, running `dkms mkdeb' does not seem to include the > binary modules in my tests anyway, either with or without the > --binaries-only flag. > > As a result, it seems to me that the mkdeb command is broken anyway ? > > > All that explains why it was not easy to choose to report the fix > upstream or to just fix it in Debian, I guess. > > Hope this helps > (Hope I got it right...) > > Pierre >
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
hello, diverging from upstream makes no sense to me, since the mkdeb approach has been introduced by us...what about discussing this with them and find a common approach? I'm not a direct user of this tool, so I can't have an opinion :) G. Il lunedì 14 gennaio 2019, 13:21:58 CET, Pierre Neyron ha scritto: Hello Gianfranco, Ok, but what mkdeb patch would you like ? a- should it actually include binaries unless source-only is set ? or b- should it generate an arch independent _all.deb package (with man page fixed accordingly) ? I'm more likely to volunteer for b, even if it makes Debian's dkms diverge from upstream in the way mkdeb works... Cheers Pierre On 14/01/2019 13:01, Gianfranco Costamagna wrote: > Hello, > I'm happy to accept an eventual patch :) > > G. > > Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron > ha scritto: > > > On 13/01/2019 16:18, drake763 wrote: > > Thanks again for your quick and detailed response! > > > > On 1/13/19 2:49 PM, Gianfranco Costamagna wrote: > >> Now, dkms run on amd64 produces binaries for *amd64* architecture, > and if you run the same command > >> on i386 you will produce kernel modules that can run only on *i386* > architecture > > > > In my understanding, running in some src directory (which has to support > > this obviously) > > > > make dkms_mkdeb > > > > produces an architecture independent deb package (hence my thought to > > have the suffix _all.deb). When I then install that very _all.deb > > package with dpkg, DKMS is invoked again and the actual compilation > > takes place where the architecture dependent binary is produced (so dkms > > is invoked twice. Once when creating the package, and again when > installing) > > > > My usecase is applying this patch for intel processors > > (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb > > package with make dkms_mkdeb. The resulting deb package actually has no > > binaries inside but only source code and - what I assume are - some > > instructions for DKMS (dkms.conf and some .c and .patch files) for > > actually installing the deb package with dpkg. > > > > Earlier in this thread, this was also discussed > > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20). > > > > But then again the currently produced package works. So if no one else > > complains, the behaviour may remain I guess (differentiating among > > binary and non-binary packages just by name is probably not really > needed). > > > > Thanks again for fixing this bug. > > > > Cheers > > Hello, > > I also think `dkms mkdeb' should produce a architecture independent > "_all.deb" package as long as content is source only. > > My patch was taking "source-only" as de facto for mkdeb, because it > seemed to me to make sense with regard to the way I understand the usage > of dkms by Debian. However it does not match what the man page explains > and possibly breaks the way the command should act in some places. > > As a result, keeping mkdeb possibly include the binary modules, hence > have an architecture dependent package (e.g. amd64.deb) seems safer. > > That said however, running `dkms mkdeb' does not seem to include the > binary modules in my tests anyway, either with or without the > --binaries-only flag. > > As a result, it seems to me that the mkdeb command is broken anyway ? > > > All that explains why it was not easy to choose to report the fix > upstream or to just fix it in Debian, I guess. > > Hope this helps > (Hope I got it right...) > > Pierre >
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hello Gianfranco, Ok, but what mkdeb patch would you like ? a- should it actually include binaries unless source-only is set ? or b- should it generate an arch independent _all.deb package (with man page fixed accordingly) ? I'm more likely to volunteer for b, even if it makes Debian's dkms diverge from upstream in the way mkdeb works... Cheers Pierre On 14/01/2019 13:01, Gianfranco Costamagna wrote: Hello, I'm happy to accept an eventual patch :) G. Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron ha scritto: On 13/01/2019 16:18, drake763 wrote: > Thanks again for your quick and detailed response! > > On 1/13/19 2:49 PM, Gianfranco Costamagna wrote: >> Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you run the same command >> on i386 you will produce kernel modules that can run only on *i386* architecture > > In my understanding, running in some src directory (which has to support > this obviously) > > make dkms_mkdeb > > produces an architecture independent deb package (hence my thought to > have the suffix _all.deb). When I then install that very _all.deb > package with dpkg, DKMS is invoked again and the actual compilation > takes place where the architecture dependent binary is produced (so dkms > is invoked twice. Once when creating the package, and again when installing) > > My usecase is applying this patch for intel processors > (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb > package with make dkms_mkdeb. The resulting deb package actually has no > binaries inside but only source code and - what I assume are - some > instructions for DKMS (dkms.conf and some .c and .patch files) for > actually installing the deb package with dpkg. > > Earlier in this thread, this was also discussed > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20). > > But then again the currently produced package works. So if no one else > complains, the behaviour may remain I guess (differentiating among > binary and non-binary packages just by name is probably not really needed). > > Thanks again for fixing this bug. > > Cheers Hello, I also think `dkms mkdeb' should produce a architecture independent "_all.deb" package as long as content is source only. My patch was taking "source-only" as de facto for mkdeb, because it seemed to me to make sense with regard to the way I understand the usage of dkms by Debian. However it does not match what the man page explains and possibly breaks the way the command should act in some places. As a result, keeping mkdeb possibly include the binary modules, hence have an architecture dependent package (e.g. amd64.deb) seems safer. That said however, running `dkms mkdeb' does not seem to include the binary modules in my tests anyway, either with or without the --binaries-only flag. As a result, it seems to me that the mkdeb command is broken anyway ? All that explains why it was not easy to choose to report the fix upstream or to just fix it in Debian, I guess. Hope this helps (Hope I got it right...) Pierre
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hello,I'm happy to accept an eventual patch :) G. Il domenica 13 gennaio 2019, 17:10:39 CET, Pierre Neyron ha scritto: On 13/01/2019 16:18, drake763 wrote: > Thanks again for your quick and detailed response! > > On 1/13/19 2:49 PM, Gianfranco Costamagna wrote: >> Now, dkms run on amd64 produces binaries for *amd64* architecture, and if >> you run the same command >> on i386 you will produce kernel modules that can run only on *i386* >> architecture > > In my understanding, running in some src directory (which has to support > this obviously) > > make dkms_mkdeb > > produces an architecture independent deb package (hence my thought to > have the suffix _all.deb). When I then install that very _all.deb > package with dpkg, DKMS is invoked again and the actual compilation > takes place where the architecture dependent binary is produced (so dkms > is invoked twice. Once when creating the package, and again when installing) > > My usecase is applying this patch for intel processors > (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb > package with make dkms_mkdeb. The resulting deb package actually has no > binaries inside but only source code and - what I assume are - some > instructions for DKMS (dkms.conf and some .c and .patch files) for > actually installing the deb package with dpkg. > > Earlier in this thread, this was also discussed > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20). > > But then again the currently produced package works. So if no one else > complains, the behaviour may remain I guess (differentiating among > binary and non-binary packages just by name is probably not really needed). > > Thanks again for fixing this bug. > > Cheers Hello, I also think `dkms mkdeb' should produce a architecture independent "_all.deb" package as long as content is source only. My patch was taking "source-only" as de facto for mkdeb, because it seemed to me to make sense with regard to the way I understand the usage of dkms by Debian. However it does not match what the man page explains and possibly breaks the way the command should act in some places. As a result, keeping mkdeb possibly include the binary modules, hence have an architecture dependent package (e.g. amd64.deb) seems safer. That said however, running `dkms mkdeb' does not seem to include the binary modules in my tests anyway, either with or without the --binaries-only flag. As a result, it seems to me that the mkdeb command is broken anyway ? Question is: how should it be fixed ? - should it actually include binaries unless source-only is set ? or - should it generate an arch independent _all.deb package (with man page fixed accordingly) ? All that explains why it was not easy to choose to report the fix upstream or to just fix it in Debian, I guess. Hope this helps (Hope I got it right...) Pierre
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
On 13/01/2019 16:18, drake763 wrote: Thanks again for your quick and detailed response! On 1/13/19 2:49 PM, Gianfranco Costamagna wrote: Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you run the same command on i386 you will produce kernel modules that can run only on *i386* architecture In my understanding, running in some src directory (which has to support this obviously) make dkms_mkdeb produces an architecture independent deb package (hence my thought to have the suffix _all.deb). When I then install that very _all.deb package with dpkg, DKMS is invoked again and the actual compilation takes place where the architecture dependent binary is produced (so dkms is invoked twice. Once when creating the package, and again when installing) My usecase is applying this patch for intel processors (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb package with make dkms_mkdeb. The resulting deb package actually has no binaries inside but only source code and - what I assume are - some instructions for DKMS (dkms.conf and some .c and .patch files) for actually installing the deb package with dpkg. Earlier in this thread, this was also discussed (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20). But then again the currently produced package works. So if no one else complains, the behaviour may remain I guess (differentiating among binary and non-binary packages just by name is probably not really needed). Thanks again for fixing this bug. Cheers Hello, I also think `dkms mkdeb' should produce a architecture independent "_all.deb" package as long as content is source only. My patch was taking "source-only" as de facto for mkdeb, because it seemed to me to make sense with regard to the way I understand the usage of dkms by Debian. However it does not match what the man page explains and possibly breaks the way the command should act in some places. As a result, keeping mkdeb possibly include the binary modules, hence have an architecture dependent package (e.g. amd64.deb) seems safer. That said however, running `dkms mkdeb' does not seem to include the binary modules in my tests anyway, either with or without the --binaries-only flag. As a result, it seems to me that the mkdeb command is broken anyway ? Question is: how should it be fixed ? - should it actually include binaries unless source-only is set ? or - should it generate an arch independent _all.deb package (with man page fixed accordingly) ? All that explains why it was not easy to choose to report the fix upstream or to just fix it in Debian, I guess. Hope this helps (Hope I got it right...) Pierre
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Thanks again for your quick and detailed response! On 1/13/19 2:49 PM, Gianfranco Costamagna wrote: > Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you > run the same command > on i386 you will produce kernel modules that can run only on *i386* > architecture In my understanding, running in some src directory (which has to support this obviously) make dkms_mkdeb produces an architecture independent deb package (hence my thought to have the suffix _all.deb). When I then install that very _all.deb package with dpkg, DKMS is invoked again and the actual compilation takes place where the architecture dependent binary is produced (so dkms is invoked twice. Once when creating the package, and again when installing) My usecase is applying this patch for intel processors (http://linux-phc.org/forum/viewtopic.php?f=7=267). I create a deb package with make dkms_mkdeb. The resulting deb package actually has no binaries inside but only source code and - what I assume are - some instructions for DKMS (dkms.conf and some .c and .patch files) for actually installing the deb package with dpkg. Earlier in this thread, this was also discussed (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#20). But then again the currently produced package works. So if no one else complains, the behaviour may remain I guess (differentiating among binary and non-binary packages just by name is probably not really needed). Thanks again for fixing this bug. Cheers
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
OP here, Am So, 13. Jan 2019 um 14:49:06 +0100 schrieb Gianfranco Costamagna: On Sun, 13 Jan 2019 13:29:13 +0100 drake763 wrote: 2) The fix in 2.6.1-3 produces (when creating a deb package) a package named PACKAGENAME_amd64.deb, where amd64 is my compiling computer's architecture. However, it was my understanding that dkms created debs should have *_all.deb as a naming convention? But this may well be a misunderstanding on my side. Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you run the same command on i386 you will produce kernel modules that can run only on *i386* architecture For binary packages that's what I would expect. So dkms does the right thing. *all* is a suffix used when the built artifacts are the same in every architecture (e.g. an image, a pdf, an html file, a documentation package, that is the same everywhere). Having _all.deb was a mistake on the module generation, because the same file would have had no information about its content, and would have been called exactly the same on different architectures. So, I'm confident enough that the fix now is "correct", and I hope somebody else would ack my changes, because I'm not a direct user of this feature, so my blind fix might have been incorrectly applied. In my case I use dkms --source-only. The package does not contain arch specific binaries but with the current dkms version the result will also get the arch suffix. I would have expected the package to contain a non-arch suffix as there is no need for such a thing in that case. But I also don't mind if the current behaviour stays. It still works for me. Regards, Dirk
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
On Sun, 13 Jan 2019 13:29:13 +0100 drake763 wrote: > Dear maintainers, > > Thank you very much for your work and reply! I have three issues/questions: > > 1) The bug is *NOT* fixed in 2.6.1-1 (which is in stretch-backports) but > first in 2.6.1-3 (testing/sid). > this is normal, I'll backport the fix once you ack my changes :) > 2) The fix in 2.6.1-3 produces (when creating a deb package) a package > named PACKAGENAME_amd64.deb, where amd64 is my compiling computer's > architecture. However, it was my understanding that dkms created debs > should have *_all.deb as a naming convention? But this may well be a > misunderstanding on my side. ok lets make this clear on *both* sides :) dkms is a tool to build custom kernel modules, with the user-pc (e.g. when they aren't ship with the kernel itself). Now, dkms run on amd64 produces binaries for *amd64* architecture, and if you run the same command on i386 you will produce kernel modules that can run only on *i386* architecture (see the other bug that introduced this change: #832558). *all* is a suffix used when the built artifacts are the same in every architecture (e.g. an image, a pdf, an html file, a documentation package, that is the same everywhere). Having _all.deb was a mistake on the module generation, because the same file would have had no information about its content, and would have been called exactly the same on different architectures. So, I'm confident enough that the fix now is "correct", and I hope somebody else would ack my changes, because I'm not a direct user of this feature, so my blind fix might have been incorrectly applied. > 3) Will this fix be backported to Stretch? Or only to Stretch backports? > What would be the debian way to deal with such bugs? I uploaded the fix in stretch-backports, will be available in a day or two > > Of course, these issues shall not reopen this bug, it's just things that > are unclear on my side. the bug is fixed, really no need to reopen (unless my explanation is wrong, and the bug is not really fixed, in that case yes, please reopen it). Updating stable is useful to fix bugs, but I honestly don't care that much, since stable-backports is going fixed soon. (fixing stable means that somebody should confirm that version 2.3-2 is affected, and provide a debdiff with the bug fixed) G. > > Again thank you very much. > > All best > > On 1/2/19 4:28 PM, Gianfranco Costamagna wrote: > > Hello, > > > > On Mon, 3 Dec 2018 14:17:32 +0100 drake763 wrote: > >> Hi, > >> > >> I'd also second the request to patch this bug. This bug is not present > >> in upstream but only in debian and thus ubuntu. It was introduced in > >> debian specific patch [1]. > >> > >> The part of Pierre's patch mentioned in this thread would fix this and > >> it would be highly appreciated if at least the relevant part of the > >> patch could be applied. > >> > >> Thanks a lot! > >> > >> [1] > >> https://salsa.debian.org/debian/dkms/blob/master/debian/patches/0004-mkbmdeb-support-for-lean-binary-package-with-only-th.patch > >> > > can you please confirm that version 2.6.1-1 is good, and we can close this > > bug? > > > > thanks > > > > Gianfranco > > > >
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Dear maintainers, Thank you very much for your work and reply! I have three issues/questions: 1) The bug is *NOT* fixed in 2.6.1-1 (which is in stretch-backports) but first in 2.6.1-3 (testing/sid). 2) The fix in 2.6.1-3 produces (when creating a deb package) a package named PACKAGENAME_amd64.deb, where amd64 is my compiling computer's architecture. However, it was my understanding that dkms created debs should have *_all.deb as a naming convention? But this may well be a misunderstanding on my side. 3) Will this fix be backported to Stretch? Or only to Stretch backports? What would be the debian way to deal with such bugs? Of course, these issues shall not reopen this bug, it's just things that are unclear on my side. Again thank you very much. All best On 1/2/19 4:28 PM, Gianfranco Costamagna wrote: > Hello, > > On Mon, 3 Dec 2018 14:17:32 +0100 drake763 wrote: >> Hi, >> >> I'd also second the request to patch this bug. This bug is not present >> in upstream but only in debian and thus ubuntu. It was introduced in >> debian specific patch [1]. >> >> The part of Pierre's patch mentioned in this thread would fix this and >> it would be highly appreciated if at least the relevant part of the >> patch could be applied. >> >> Thanks a lot! >> >> [1] >> https://salsa.debian.org/debian/dkms/blob/master/debian/patches/0004-mkbmdeb-support-for-lean-binary-package-with-only-th.patch >> > can you please confirm that version 2.6.1-1 is good, and we can close this > bug? > > thanks > > Gianfranco >
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hello, On Mon, 3 Dec 2018 14:17:32 +0100 drake763 wrote: > Hi, > > I'd also second the request to patch this bug. This bug is not present > in upstream but only in debian and thus ubuntu. It was introduced in > debian specific patch [1]. > > The part of Pierre's patch mentioned in this thread would fix this and > it would be highly appreciated if at least the relevant part of the > patch could be applied. > > Thanks a lot! > > [1] > https://salsa.debian.org/debian/dkms/blob/master/debian/patches/0004-mkbmdeb-support-for-lean-binary-package-with-only-th.patch > can you please confirm that version 2.6.1-1 is good, and we can close this bug? thanks Gianfranco
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hi, I'd also second the request to patch this bug. This bug is not present in upstream but only in debian and thus ubuntu. It was introduced in debian specific patch [1]. The part of Pierre's patch mentioned in this thread would fix this and it would be highly appreciated if at least the relevant part of the patch could be applied. Thanks a lot! [1] https://salsa.debian.org/debian/dkms/blob/master/debian/patches/0004-mkbmdeb-support-for-lean-binary-package-with-only-th.patch
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hello,
I understand the exchange between upstream and Debian is a bit sluggish here,
but besides that, is there a reason why Pierre's patch has never been applied?
The current situation breaks mkdeb (in some cases?) (e.g. phc_intel [1]) and
this part of Pierre's patch would fix this:
> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> package filename with -${debian_build_arch} instead of -all.
This situation has been kind of annoying ever since the Stretch release, and I
(and some others) would really appreciate having this fixed for Buster.
[1] http://linux-phc.org/forum/viewtopic.php?f=7=267
(power saving module for older Intel CPUs)
Thanks, and kind regards
hikaru
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Pierre,
There have been a few times the patches got synced between the two, but I'll
admit
I don't know the current home to the patches that live in the Debian package.
Hopefully some of the Debian maintainers can speak up since I haven't tracked
it.
I think it would be good to make sure that all patches that are currently in
2.3 in Debian
are no longer applicable in 2.5 and then update to 2.5 in Debian as well.
Thanks,
> -Original Message-
> From: Pierre Neyron [mailto:pierre.ney...@free.fr]
> Sent: Monday, February 12, 2018 11:54 AM
> To: Limonciello, Mario <mario_limoncie...@dell.com>; 832...@bugs.debian.org;
> pkg-dkms-ma...@lists.alioth.debian.org
> Subject: Re: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
>
> Hi Marco,
>
> Problem is Debian dkms (v2.3) seems to be an old fork of github/dell
> dkms (v2.5). Support for mkbmdeb comes from a patch in the Debian
> package but does not exist upstream. As a result my patch is not so
> relevant for upstream.
>
> Do you know if the current Debian patches were already proposed to
> upstream ? Do you know the roadmap for a possible merge from upstream
> (bump Debian package version to 2.5) ?
>
> Last be not least, since I do not have all the test cases in mind, I'd
> be glad to get a review from the Debian maintainers before sending upstream.
>
>
> Thanks,
> Best regards,
> Pierre
>
> On 02/12/2018 06:27 PM, mario.limoncie...@dell.com wrote:
> >> -Original Message-
> >> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> >> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of
> Pierre
> >> Neyron
> >> Sent: Monday, February 12, 2018 11:21 AM
> >> To: 832...@bugs.debian.org
> >> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> >>
> >> Please find attached a patch for the dkms script (package version 2.3-3)
> >> that fixes the following issues:
> >>
> >> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> >> package filename with -${debian_build_arch} instead of -all.
> >>
> >> - fix mkdeb (2): allow creating a dkms package without requiring to
> >> build the binary module beforehand . The patch actually makes
> >> --source-only de facto for mkdeb and mkdsc.
> >>
> >> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
> >>
> >> - fix usage: lacked mkdsc
> >>
> >> Regards
> >> Pierre
> >
> > Pierre,
> >
> > Can you please submit the patches to upstream at github?
> >
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Hi Marco,
Problem is Debian dkms (v2.3) seems to be an old fork of github/dell
dkms (v2.5). Support for mkbmdeb comes from a patch in the Debian
package but does not exist upstream. As a result my patch is not so
relevant for upstream.
Do you know if the current Debian patches were already proposed to
upstream ? Do you know the roadmap for a possible merge from upstream
(bump Debian package version to 2.5) ?
Last be not least, since I do not have all the test cases in mind, I'd
be glad to get a review from the Debian maintainers before sending upstream.
Thanks,
Best regards,
Pierre
On 02/12/2018 06:27 PM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
>> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of
>> Pierre
>> Neyron
>> Sent: Monday, February 12, 2018 11:21 AM
>> To: 832...@bugs.debian.org
>> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
>>
>> Please find attached a patch for the dkms script (package version 2.3-3)
>> that fixes the following issues:
>>
>> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
>> package filename with -${debian_build_arch} instead of -all.
>>
>> - fix mkdeb (2): allow creating a dkms package without requiring to
>> build the binary module beforehand . The patch actually makes
>> --source-only de facto for mkdeb and mkdsc.
>>
>> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
>>
>> - fix usage: lacked mkdsc
>>
>> Regards
>> Pierre
>
> Pierre,
>
> Can you please submit the patches to upstream at github?
>
Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> -Original Message-
> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of
> Pierre
> Neyron
> Sent: Monday, February 12, 2018 11:21 AM
> To: 832...@bugs.debian.org
> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
>
> Please find attached a patch for the dkms script (package version 2.3-3)
> that fixes the following issues:
>
> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> package filename with -${debian_build_arch} instead of -all.
>
> - fix mkdeb (2): allow creating a dkms package without requiring to
> build the binary module beforehand . The patch actually makes
> --source-only de facto for mkdeb and mkdsc.
>
> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
>
> - fix usage: lacked mkdsc
>
> Regards
> Pierre
Pierre,
Can you please submit the patches to upstream at github?
Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
Please find attached a patch for the dkms script (package version 2.3-3)
that fixes the following issues:
- fix mkdeb (1): mkdeb failed because a mv command was looking for a
package filename with -${debian_build_arch} instead of -all.
- fix mkdeb (2): allow creating a dkms package without requiring to
build the binary module beforehand . The patch actually makes
--source-only de facto for mkdeb and mkdsc.
- fix mkbmdeb: make --binary-only de facto for mkbmdeb
- fix usage: lacked mkdsc
Regards
Pierre
--- dkms-2.3/dkms 2018-02-12 18:03:16.454187565 +0100
+++ dkms.fixed/dkms 2018-02-12 18:02:24.901872644 +0100
@@ -132,8 +132,8 @@
show_usage()
{
echo $"Usage: $0 [action] [options]"
-echo $" [action] = { add | remove | build | install | uninstall | match | autoinstall"
-echo $" | mkdriverdisk | mktarball | ldtarball | mkrpm | mkkmp | mkdeb | mkbmdeb | status }"
+echo $" [action] = { add | remove | build | install | uninstall | match | autoinstall | mkdriverdisk |"
+echo $"mktarball | ldtarball | mkrpm | mkkmp | mkdeb | mkdsc | mkbmdeb | status }"
echo $" [options] = [-m module] [-v module-version] [-k kernel-version] [-a arch]"
echo $" [-d distro] [-c dkms.conf-location] [-q] [--force] [--all]"
echo $" [--templatekernel=kernel] [--directive='cli-directive=cli-value']"
@@ -3087,23 +3087,6 @@
invoke_command "cp '$PREFIX/usr/lib/dkms/common.postinst' '$temp_dir_debian'" "copying legacy postinstall template"
fi
-# Copy in the source tree
-if [[ ! $binaries_only ]]; then
-invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
-fi
-
-# Only if we are shipping binary modules, make a .tgz for the deb
-local archive_location="$dkms_tree/$module/$module_version/tarball/$module-$module_version.dkms.tar.gz"
-if [[ ! $source_only ]]; then
-binaries_only="binaries-only"
-invoke_command "make_tarball" "Gathering binaries"
-if [[ -f $archive_location ]]; then
-invoke_command "cp '$archive_location' '$temp_dir_debian'" "Copying DKMS tarball into DKMS tree"
-else
-die 12 $"Unable to find created tarball."
-fi
-fi
-
# Calculate destination directory
deb_basedir=$dkms_tree/$module/$module_version/${create_type}
mkdir -p ${deb_basedir} >/dev/null 2>&1
@@ -3112,6 +3095,7 @@
pushd "$temp_dir_debian" > /dev/null 2>&1
case "$create_type" in
dsc)
+invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
invoke_command "dpkg-buildpackage -S -us -uc 1>/dev/null" "Building source package" || \
die 7 $"There was a problem creating your ${create_type}."
echo $""
@@ -3119,13 +3103,24 @@
invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_source.changes' '$temp_dir/${debian_package}-dkms_${module_version}.dsc' '$temp_dir/${debian_package}-dkms_${module_version}.tar.gz' '$deb_basedir'" "Moving built files to $deb_basedir"
;;
deb)
+invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
invoke_command "dpkg-buildpackage -rfakeroot -d -b -us -uc 1>/dev/null" "Building binary package" || \
die 7 $"There was a problem creating your ${create_type}."
echo $""
echo $"DKMS: mk${create_type} completed."
- invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_${debian_build_arch}.deb' '$deb_basedir'" "Moving built files to $deb_basedir"
+ invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_all.deb' '$deb_basedir'" "Moving built files to $deb_basedir"
;;
bmdeb)
+ # Only if we are shipping binary modules, make a .tgz for the deb
+ local archive_location="$dkms_tree/$module/$module_version/tarball/$module-$module_version.dkms.tar.gz"
+ binaries_only="binaries-only"
+ invoke_command "make_tarball" "Gathering binaries"
+ if [[ -f $archive_location ]]; then
+ invoke_command "cp '$archive_location' '$temp_dir_debian'" "Copying DKMS tarball into DKMS tree"
+ else
+ die 12 $"Unable to find created tarball."
+ fi
+
export KVER="$kernelver"
export KARCH="$arch"
invoke_command "dpkg-buildpackage -rfakeroot -d -b -us -uc 1>/dev/null" "Building binary package" || \
Bug#832558: dkms: mkdeb --source-only fails: can't find package
Should dkms packages generated with `dpkg mkdeb' not be of arch "all" ? Unless they provide arch specific blobs, they are just source code to be compiled right ? On Tue, 31 Oct 2017 14:54:51 -0300 Martin Galvan <omgalvan...@gmail.com> wrote: > Package: dkms > Version: 2.3-3ubuntu3 > Tags: patch > Followup-For: Bug #832558 > > I'm attaching a patch that fixes /etc/dkms/template-dkms-mkdeb/debian/control > so that the generated .deb has the arch suffix instead of 'all'.
Bug#832558: dkms: mkdeb --source-only fails: can't find package
Package: dkms
Version: 2.3-3ubuntu3
Tags: patch
Followup-For: Bug #832558
I'm attaching a patch that fixes /etc/dkms/template-dkms-mkdeb/debian/control
so that the generated .deb has the arch suffix instead of 'all'.
-- System Information:
Debian Release: stretch/sid
APT prefers artful-updates
APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 'artful')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-16-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dkms depends on:
ii build-essential 12.4ubuntu1
ii coreutils8.26-3ubuntu4
ii dpkg-dev 1.18.24ubuntu1
ii gcc 4:7.2.0-1ubuntu1
ii kmod 24-1ubuntu2
ii make 4.1-9.1
ii patch2.7.5-1build1
Versions of packages dkms recommends:
ii fakeroot 1.21-1ubuntu2
ii linux-headers-4.13.0-16-generic [linux-headers] 4.13.0-16.19
ii linux-headers-generic4.13.0.16.17
ii lsb-release 9.20160110ubuntu5
ii sudo 1.8.20p2-1ubuntu1
Versions of packages dkms suggests:
pn menu
ii python3-apport 2.20.7-0ubuntu3.1
-- no debconf information
--- a/etc/dkms/template-dkms-mkdeb/debian/control 2017-10-31
14:40:41.690069116 -0300
+++ b/etc/dkms/template-dkms-mkdeb/debian/control 2017-10-31
14:41:12.137973994 -0300
@@ -6,6 +6,6 @@
Standards-Version: 3.8.1
Package: DEBIAN_PACKAGE-dkms
-Architecture: all
+Architecture: DEBIAN_BUILD_ARCH
Depends: dkms (>= 1.95), ${misc:Depends}
Description: DEBIAN_PACKAGE driver in DKMS format.
Bug#832558:
This also affects me on Ubuntu 17.10. Why hasn't this been fixed yet?
Bug#832558: dkms: mkdeb --source-only fails: can't find package
Package: dkms
Version: 2.2.0.3-5
Severity: normal
Tags: patch
Hi,
when creating a source-only deb, dkms will call dpkg-buildpackage, which
creates a *_all.deb package. Version 2.2.0.3-5 introduced
$debian_build_arch as part of the then invoked mv command, which fails.
>From a quick glance, calling mkdeb without --source-only will suffer
from the same problem, but I did not test it.
If I glanced right, you can apply revert_all.patch. If I'm wrong, try
source_deb.patch, which will use 'all' only if --source-only was
provided. Or, if thats an option, simply use a wildcard instead of a
specific arch postfix if other options aren't at hand.
Regards,
Dirk
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 4.6.4 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dkms depends on:
ii build-essential 12.2
ii coreutils8.25-2
ii dpkg-dev 1.18.9
ii gcc 4:5.3.1-3
ii kmod 22-1.1
ii make 4.1-9
ii patch2.7.5-1
Versions of packages dkms recommends:
ii fakeroot 1.21-1
ii linux-headers-4.6.4 [linux-headers] 4.6.4-5
ii menu 2.1.47
ii sudo 1.8.17p1-2
Versions of packages dkms suggests:
pn python3-apport
-- Configuration Files:
/etc/modprobe.d/dkms.conf [Errno 2] Datei oder Verzeichnis nicht gefunden:
u'/etc/modprobe.d/dkms.conf'
-- no debconf information
--- a/dkms 2016-07-06 01:12:00.0 +0200
+++ b/dkms 2016-07-26 22:30:26.486793435 +0200
@@ -2960,7 +2960,7 @@
die 7 $"There was a problem creating your ${create_type}."
echo $""
echo $"DKMS: mk${create_type} completed."
- invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_${debian_build_arch}.deb' '$deb_basedir'" "Moving built files to $deb_basedir"
+ invoke_command "mv '$temp_dir/${debian_package}-dkms_${module_version}_all.deb' '$deb_basedir'" "Moving built files to $deb_basedir"
;;
bmdeb)
export KVER="$kernelver"
diff -u a/dkms b/dkms
--- a/dkms 2016-07-26 20:03:17.901049440 +0200
+++ b/dkms 2016-07-26 20:03:04.276981881 +0200
@@ -2887,7 +2887,11 @@
make_common_test "mk${create_type}"
debian_package=${module//_/-}
-debian_build_arch=$(dpkg-architecture -qDEB_BUILD_ARCH)
+if [[ $source_only ]]; then
+debian_build_arch='all'
+else
+debian_build_arch=$(dpkg-architecture -qDEB_BUILD_ARCH)
+fi
# Read the conf file
read_conf_or_die "$kernelver" "$arch"
