dahdi-linux 1:2.10.2~dfsg-1ubuntu2 ADT test failure with linux-hwe-edge 4.15.0-23.25~16.04.1
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dahdi-linux (Ubuntu) |
Invalid
|
Undecided
|
Marcelo Cerri | ||
Xenial |
Fix Released
|
Undecided
|
Marcelo Cerri |
Bug Description
[Impact]
Currently the DKMS package fails to install on supported custom
kernels that are based on 4.15. That includes the current 4.15
hwe-edge and some of the custom and cloud kernels as well.
[Test Case]
Install the dahdi-dkms package with the 4.15 hwe-edge kernel. The
package installation should proceed without any errors.
[Regression Potential]
Although new patches were added, the regression risk is very low since
the new changes are conditionally compiled based on the kernel
version.
Besides that, the new package was tested with the following kernels in
an amd64 environment:
- linux-generic 4.4
- linux-hwe 4.13
- linux-hwe-edge 4.15
The azure kernel doesn't have USB support enabled anymore and I will hint the adt matrix to reflect that.
[Original Description]
Testing failed on:
amd64: https:/
i386: https:/
tags: | added: patch |
description: | updated |
Changed in dahdi-linux (Ubuntu): | |
status: | In Progress → Invalid |
Changed in dahdi-linux (Ubuntu Xenial): | |
status: | New → In Progress |
assignee: | nobody → Marcelo Cerri (mhcerri) |
This debdiff looks mostly good. I had to spend quite a bit of time to figure out where the patches came from. Apparently, they're from this bug:
https:/ /issues. asterisk. org/jira/ browse/ DAHLIN- 359
I've added the Origin dep-3 tag to each patch. I see that you probably just reused the patches from the Bionic or Cosmic package, which didn't include the origin, but the origin is important to include so that we know where the code is coming from, what kind of review it has gotten, etc.
As mentioned while sponsoring another recent package for you, I don't love the SRU versioning scheme used here. If you look at the current artful, bionic, and cosmic version strings, you can see why it could be a problem in future SRUs. The versioning scheme documented here has been proven to work well:
https:/ /wiki.ubuntu. com/SecurityTea m/UpdatePrepara tion#Update_ the_packaging
I'm sponsoring this one to xenial-proposed since you're following the existing SRU versioning scheme for the package. Thanks for the debdiff! :)