acpi-call 1.1.0-4 ADT test failure with linux 5.2.0-0.1

[Seth Forshee]

Testing failed on:
    armhf: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/armhf/a/acpi-call/20190522_121539_b9a77@/log.gz
    ppc64el: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/ppc64el/a/acpi-call/20190522_044953_b9a77@/log.gz
    s390x: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-unstable/eoan/s390x/a/acpi-call/20190522_043919_b9a77@/log.gz

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Raphaël Halimi (raph)]

Information from Thadeu Lima de Souza Cascardo:

acpi_root_dir is undefined on architectures which are not built with ACPI. That means that building acpi-call on those arches will fail starting with 5.2.

On previous kernels, only a warning would be emitted during modpost, telling that the symbol was undefined. But it also meant that such a module would not load, making the build kinda pointless.

Starting with 5.2, external modules will also have to define KBUILD_MODPOST_WARN, in order to build with undefined symbols. See upstream commit 83da1bed86cdfe3abb2a33c36a2a5aaf5f390ef6 ("modpost: make KBUILD_MODPOST_WARN also configurable for external modules").

However, I don't think we should fix the build of the module here, as it's pointless on those architectures where we don't support ACPI.

Duplicate bug: https://bugs.launchpad.net/ubuntu/+source/acpi-call/+bug/1830787

[Raphaël Halimi (raph)]

Hi,

Thanks for the bug report.

I'm preparing an upload of this package for Debian. As suggested by Thadeu Lima de Souza Cascardo, I intend to disable the package for architectures which don't support ACPI.

Are there other architectures supported by Debian or Ubuntu which doesn't support ACPI, aside from armhf, ppc64el and s390x ?

Regards,

--
Raphaël Halimi

[Thadeu Lima de Souza Cascardo (cascardo)]

Sorry about the duplicate.

According to excerpts below, only i386, amd64, ia64 and arm64 would support ACPI.

drivers/acpi/Kconfig:
config ARCH_SUPPORTS_ACPI
        bool

menuconfig ACPI
        bool "ACPI (Advanced Configuration and Power Interface) Support"
        depends on ARCH_SUPPORTS_ACPI

$ git grep ARCH_SUPPORTS_ACPI arch/
arch/arm64/Kconfig: select ARCH_SUPPORTS_ACPI
arch/ia64/Kconfig: select ARCH_SUPPORTS_ACPI if (!IA64_HP_SIM)
arch/x86/Kconfig: select ARCH_SUPPORTS_ACPI

[Seth Forshee (sforshee)]

On Wed, May 29, 2019 at 11:14:35AM -0000, Raphaël Halimi wrote:
> Are there other architectures supported by Debian or Ubuntu which
> doesn't support ACPI, aside from armhf, ppc64el and s390x ?

I can't speak to Debian, but it looks like the only kernel architectures
which support ACPI are x86, arm64, and ia64. In Ubuntu we have ACPI
enabled for amd64, arm64, and i386.

[Raphaël Halimi (raph)]

Hi,

Could you try with:

BUILD_EXCLUSIVE_ARCH="(i.86|(x86_|ia|aarch)64)"

In dkms.conf and see if it fixes the problem ?

With this additional line, the module should build only on i386, amd64, arm64 and ia64, and output a (non-fatal) error on other architectures.

I'd like to check that the regexp is correct before uploading, and since I'm only a Debian Maintainer (not Debian Developer), I don't have access to porter boxes, and requesting it is quite tedious. Moreover, the Debian machines pages [1] doesn't mention any ia64 machine.

[1] https://db.debian.org/machines.cgi

Thanks a lot for your help !

[Thadeu Lima de Souza Cascardo (cascardo)]

On a ppc64el, I got:

ubuntu@P8lpar5:~$ cat /usr/src/acpi-call-1.1.0/dkms.conf
BUILD_EXCLUSIVE_ARCH="(i.86|(x86_|ia|aarch)64)"
PACKAGE_NAME="acpi-call"
PACKAGE_VERSION="1.1.0"
MAKE[0]="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build"
CLEAN="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"
BUILT_MODULE_NAME[0]="acpi_call"
DEST_MODULE_LOCATION[0]="/extra"
AUTOINSTALL="yes"
ubuntu@P8lpar5:~$ sudo dkms install acpi-call/1.1.0 -k `uname -r `
Error! The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which
does not match this kernel/arch. This indicates that it should not be built.

[Raphaël Halimi (raph)]

Hi,

Thanks again for your help.

Finally, instead of hard-coding a list of architectures supporting ACPI, someone on debian-devel suggested to test for ACPI support at build time, and I like this idea a lot.

Can you please tell me what's the value of "CONFIG_ARCH_SUPPORTS_ACPI" on an architecture which doens't support ACPI ? For example, please grep CONFIG_ARCH_SUPPORTS_ACPI in /lib/modules/<version>-<arch>/build/.config.

For the moment, my solution consist of adding this snippet at the end of the DKMS config file:

# On architectures which don't support ACPI, disable building
if ! grep -q "^CONFIG_ARCH_SUPPORTS_ACPI=y$" "$kernel_source_dir/.config" 2>/dev/null ; then
  BUILD_EXCLUSIVE_ARCH="^do_not_build$"
fi

I'd just like to test it on an unsupported architecture before uploading the new package.

[Seth Forshee (sforshee)]

I think you would be better off checking CONFIG_ACPI, this can be off in the kernel config even when an architecture selects CONFIG_ARCH_SUPPORTS_ACPI.

[Raphaël Halimi (raph)]

Hmm. Not a bad idea.

In that case the test line should be:

if ! grep -q -E "^CONFIG_ACPI=[ym]$" "$kernel_source_dir/.config" 2>/dev/null ; then

[Thadeu Lima de Souza Cascardo (cascardo)]

Hi, Raphaël.

Same result:

ubuntu@P8lpar5:~$ cat /usr/src/acpi-call-1.1.0/dkms.conf
PACKAGE_NAME="acpi-call"
PACKAGE_VERSION="1.1.0"
MAKE[0]="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build"
CLEAN="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"
BUILT_MODULE_NAME[0]="acpi_call"
DEST_MODULE_LOCATION[0]="/extra"
AUTOINSTALL="yes"
if ! grep -q -E "^CONFIG_ACPI=[ym]$" "$kernel_source_dir/.config" 2>/dev/null ; then
        BUILD_EXCLUSIVE_ARCH="^do_not_build$"
fi
ubuntu@P8lpar5:~$ sudo dkms install acpi-call/1.1.0 -k `uname -r `
Error! The dkms.conf for this module includes a BUILD_EXCLUSIVE directive which
does not match this kernel/arch. This indicates that it should not be built.
ubuntu@P8lpar5:~$

And I changed CONFIG_ACPI for CONFIG_OF, and it tried to build it, so should work just fine on the arches that really do support ACPI.

Thanks.
Cascardo.

[Raphaël Halimi (raph)]

Thanks a lot for your help and your patience. I'm now going yo finalize the package and have it uploaded soon.

[Seth Forshee (sforshee)]

Hi Raphaël, I was curious if your fix for this issue was ever uploaded. Please let us know.

[Raphaël Halimi (raph)]

Well, I uploaded it to Debian on May 31st, and it was even accepted in Buster (which was testing at the time) five days later, on June 6th; but I see on my Debian Maintainer dashboard that it never reached eoan. I didn't investigate further about why it was not automatically synced as usually.

I also see in my dashboard, for eoan, "prop: 1.1.0-5". I don't know what this means; "proposed updates" maybe ? But I thought proposed updates was a testing ground for updates to **stable** ?

I wouldn't mind an explanation...

Also, if kernel 5.2 is ever backported to disco, acpi-call would also need a backport.

[Seth Forshee (sforshee)]

On Thu, Jul 18, 2019 at 07:12:58PM -0000, Raphaël Halimi wrote:
> Well, I uploaded it to Debian on May 31st, and it was even accepted in
> Buster (which was testing at the time) five days later, on June 6th; but
> I see on my Debian Maintainer dashboard that it never reached eoan. I
> didn't investigate further about why it was not automatically synced as
> usually.
>
> I also see in my dashboard, for eoan, "prop: 1.1.0-5". I don't know what
> this means; "proposed updates" maybe ? But I thought proposed updates
> was a testing ground for updates to **stable** ?

Ah, so it is in eoan-proposed. We do use -proposed in development, to
run tests before promoting to -release.

The testing is showing regressions for armhf, ppc64el, and s390x,
exactly the architectures which lack ACPI support. Here's one of the
test logs:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/armhf/a/acpi-call/20190710_172506_2bce8@/log.gz

It looks like it correctly identified that ACPI support was missing,
however this is still registering as an error. I'm not sure why, but
I'll ask around.

> I wouldn't mind an explanation...
>
> Also, if kernel 5.2 is ever backported to disco, acpi-call would also
> need a backport.

We won't backport to disco, but we will backport to bionic, and yes it
will need to be fixed there.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package acpi-call - 1.1.0-5

---------------
acpi-call (1.1.0-5) unstable; urgency=medium

  * [302afec] Migrate project to Salsa
  * [a412748] Use secure copyright file specification URI.
    Thanks to Jelmer Vernooij
  * [c633d47] Add patch to fix memory leak.
    Thanks to Colin Ian King for the patch (Closes: #929316) (LP: #1829883)
  * [8f5f753] Don't build module when ACPI is disabled.
    Thanks to Seth Forshee, Thadeu Lima de Souza Cascardo, Michael Jeanson and
    others for ideas and testing (LP: #1830040)
  * [757be2b] Bump Standards-Version to 4.3.0
  * [1e7e83a] Override lintian warning about missing test suite

 -- Raphaël Halimi <email address hidden> Fri, 31 May 2019 17:33:13 +0200