Public bug reported:
One common case of facing a new dkms build error is on new uploads to the
Ubuntu archive.
Proposed migration will trigger the dkms install of a bunch of modules and e.g.
some of them will fail on a new kernel.
The default behavior has a local system & user in mind and will report
something like:
Error! Bad return status for module build on kernel: 5.0.0-20-generic (x86_64)
Consult /var/lib/dkms/virtualbox-guest/6.0.8/build/make.log for more
information.
dpkg: error processing package virtualbox-guest-dkms (--configure):
That is fine (don't clutter the console especially for a potentially unskilled
user).
But in the testing environment it is just a harmstring to require to run this
over again in a local test environment.
Instead I'd propose that we could check in /usr/sbin/dkms around
1299 invoke_command "{ $the_make_command; } >>
$dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command"
background || \
1300 report_build_problem 10 $"Bad return status for module build on
kernel: $kernelver ($arch)" \
1301 $"Consult $dkms_tree/$module/$module_version/build/make.log for
more information."
If the autopkgtest environment is set like $AUTOPKGTEST_TMP.
If set we should report the full failed build log here.
Often once the build error is seen the fix is quite clear, so I'd hope
that this might save quite some time especially for packages around the
kernel and the kernel itself.
I have never messed with dkms code, but it seems only bash.
So something like this might do it (untested suggestion):
--- /usr/sbin/dkms.orig 2019-07-11 07:58:14.119155474 +0200
+++ /usr/sbin/dkms.new 2019-07-11 08:02:02.659813014 +0200
@@ -1296,10 +1296,16 @@
date >> "$dkms_tree/$module/$module_version/build/make.log"
local the_make_command="${make_command/#make/make -j$parallel_jobs
KERNELRELEASE=$kernelver}"
- invoke_command "{ $the_make_command; } >>
$dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command"
background || \
+ if ! invoke_command "{ $the_make_command; } >>
$dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command"
background; then
report_build_problem 10 $"Bad return status for module build on
kernel: $kernelver ($arch)" \
$"Consult $dkms_tree/$module/$module_version/build/make.log for more
information."
+ if [[ ! -z "${AUTOPKGTEST_TMP}" && -d "${AUTOPKGTEST_TMP}" ]]; then
+ echo "Running under Autopkgtest, reporting full build failure"
+ cat $dkms_tree/$module/$module_version/build/make.log
+ fi
+ fi
+
# Make sure all the modules built successfully
for ((count=0; count < ${#built_module_name[@]}; count++)); do
[[ -e
${built_module_location[$count]}${built_module_name[$count]}$module_suffix ]]
&& continue
** Affects: dkms (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1836144
Title:
report build full log if failing under autopkgtest
Status in dkms package in Ubuntu:
New
Bug description:
One common case of facing a new dkms build error is on new uploads to the
Ubuntu archive.
Proposed migration will trigger the dkms install of a bunch of modules and
e.g. some of them will fail on a new kernel.
The default behavior has a local system & user in mind and will report
something like:
Error! Bad return status for module build on kernel: 5.0.0-20-generic
(x86_64)
Consult /var/lib/dkms/virtualbox-guest/6.0.8/build/make.log for more
information.
dpkg: error processing package virtualbox-guest-dkms (--configure):
That is fine (don't clutter the console especially for a potentially
unskilled user).
But in the testing environment it is just a harmstring to require to run this
over again in a local test environment.
Instead I'd propose that we could check in /usr/sbin/dkms around
1299 invoke_command "{ $the_make_command; } >>
$dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command"
background || \
1300 report_build_problem 10 $"Bad return status for module build on
kernel: $kernelver ($arch)" \
1301 $"Consult $dkms_tree/$module/$module_version/build/make.log for
more information."
If the autopkgtest environment is set like $AUTOPKGTEST_TMP.
If set we should report the full failed build log here.
Often once the build error is seen the fix is quite clear, so I'd hope
that this might save quite some time especially for packages around
the kernel and the kernel itself.
I have never messed with dkms code, but it seems only bash.
So something like this might do it (untested suggestion):
--- /usr/sbin/dkms.orig 2019-07-11 07:58:14.119155474 +0200
+++ /usr/sbin/dkms.new 2019-07-11 08:02:02.659813014 +0200
@@ -1296,10 +1296,16 @@
date >> "$dkms_tree/$module/$module_version/build/make.log"
local the_make_command="${make_command/#make/make -j$parallel_jobs
KERNELRELEASE=$kernelver}"
- invoke_command "{ $the_make_command; } >>
$dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command"
background || \
+ if ! invoke_command "{ $the_make_command; } >>
$dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command"
background; then
report_build_problem 10 $"Bad return status for module build on
kernel: $kernelver ($arch)" \
$"Consult $dkms_tree/$module/$module_version/build/make.log for more
information."
+ if [[ ! -z "${AUTOPKGTEST_TMP}" && -d "${AUTOPKGTEST_TMP}" ]]; then
+ echo "Running under Autopkgtest, reporting full build failure"
+ cat $dkms_tree/$module/$module_version/build/make.log
+ fi
+ fi
+
# Make sure all the modules built successfully
for ((count=0; count < ${#built_module_name[@]}; count++)); do
[[ -e
${built_module_location[$count]}${built_module_name[$count]}$module_suffix ]]
&& continue
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1836144/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
