kexec-tools does not build for armhf

This debdiff applies cleanly and builds https://pastebin.canonical.com/181891/

This debdiff applies and builds cleanly https://pastebin.canonical.com/181893/ on armhf

The attachment "[Xenial] kexec fix armhf build failure" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

This upload is waiting on verification of bug 1663400 and bug 1661363 before this version can make it into -proposed. Thanks.

Hello Manoj, or anyone else affected,

Accepted kexec-tools into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/kexec-tools/1:2.0.10-1ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Manoj, or anyone else affected,

Accepted kexec-tools into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/kexec-tools/1:2.0.10-2ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

$ cat /etc/issue
Ubuntu 16.10 \n \l

$ uname -a
Linux myvm 4.8.0-54-generic #57-Ubuntu SMP Wed May 24 10:21:41 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux

$ dpkg -l | grep kexec-tools
ii kexec-tools 1:2.0.10-2ubuntu1.2 arm64 tools to support fast kexec reboots

$ sudo file /boot/vmlinuz-4.10.0-22-generic
/boot/vmlinuz-4.10.0-22-generic: gzip compressed data, max compression, from Unix

$ sudo kexec -d -l /boot/vmlinuz-4.10.0-22-generic --initrd=/boot/initrd.img-4.10.0-22-generic --reuse-cmdline
arch_process_options:141: command_line: root=LABEL=cloudimg-rootfs ro quiet splash vt.handoff=7
arch_process_options:143: initrd: /boot/initrd.img-4.10.0-22-generic
arch_process_options:144: dtb: (null)
Try gzip decompression.
kernel: 0xffffaf279010 kernel_size: 0x12bc200
get_memory_ranges_iomem_cb: 0000000040000000 - 000000005855ffff : System RAM
get_memory_ranges_iomem_cb: 00000000585c0000 - 00000000585ebfff : System RAM
get_memory_ranges_iomem_cb: 0000000058750000 - 000000005bc1ffff : System RAM
get_memory_ranges_iomem_cb: 000000005c000000 - 000000005fffffff : System RAM
elf_arm64_probe: Not an ELF executable.
image_arm64_load: kernel_segment: 0000000040000000
image_arm64_load: text_offset: 0000000000080000
image_arm64_load: image_size: 00000000013cf000
image_arm64_load: phys_offset: 0000000040000000
image_arm64_load: vp_offset: ffffffffffffffff
image_arm64_load: PE format: yes
read_1st_dtb: found /sys/firmware/fdt
initrd: base 4144f000, size 1af840fh (28279823)
dtb_set_initrd: start 1095036928, end 1123316751, size 28279823 (27617 KiB)
dtb: base 42f48000, size 1c49h (7241)
sym: sha256_starts info: 12 other: 00 shndx: 1 value: e80 size: 58
sym: sha256_starts value: 42f4ae80 addr: 42f4a014
machine_apply_elf_rel: CALL26 5800065394000000->580006539400039b
sym: sha256_update info: 12 other: 00 shndx: 1 value: 2df0 size: c
sym: sha256_update value: 42f4cdf0 addr: 42f4a030
machine_apply_elf_rel: CALL26 eb16027f94000000->eb16027f94000b70
sym: sha256_finish info: 12 other: 00 shndx: 1 value: 2e00 size: 1bc
sym: sha256_finish value: 42f4ce00 addr: 42f4a048
machine_apply_elf_rel: CALL26 aa1603e194000000->aa1603e194000b6e
sym: memcmp info: 12 other: 00 shndx: 1 value: 604 size: 34
sym: memcmp value: 42f4a604 addr: 42f4a058
machine_apply_elf_rel: CALL26 340003a094000000->340003a09400016b
sym: printf info: 12 other: 00 shndx: 1 value: 524 size: 80
sym: printf value: 42f4a524 addr: 42f4a068
machine_apply_elf_rel: CALL26 5800042094000000->580004209400012f
sym: printf info: 12 other: 00 shndx: 1 value: 524 size: 80
sym: printf value: 42f4a524 addr: 42f4a070
machine_apply_elf_rel: CALL26 5800043694000000->580004369400012d
sym: printf info: 12 other: 00 shndx: 1 value: 524 size: 80
sym: printf value: 42f4a524 addr: 42f4a084
machine_apply_elf_rel: CALL26 f100827f94000000->f100827f94000128
sym: printf info: 12 other: 00 shndx: 1 value: 524 size: 80
sym: printf value: 42f4a524 addr: 42f4a0a0
machine_apply_elf_rel: CALL26 5800032094000000->5800032094000121
sym: printf info: 12 other: 00 shndx: 1 value: 524 size: 80
sym: printf value: 42f4a524 addr: 42f4a0a8...

This doesn't seem to be verified for xenial yet, right? That's what I see from the testing comment at least. Please add the verification-done-xenial tag once xenial testing is finished.

I don't know what Manoj's comment is about but this bug is about the package failing to build from source for armhf. This is something we can check in LP and there are armhf builds of kexec-tools for Xenial and Yakkety so I think (my only doubt comes from Manoj's comment) the verification is done for both releases.

Package was successfully built for Yakkety
https://launchpad.net/ubuntu/+source/kexec-tools/1:2.0.10-2ubuntu1.2
https://launchpad.net/ubuntu/+source/kexec-tools/1:2.0.10-2ubuntu1.2/+build/12706353

And on Xenial:
https://launchpad.net/ubuntu/+source/kexec-tools/1:2.0.10-1ubuntu2.2
https://launchpad.net/ubuntu/+source/kexec-tools/1:2.0.10-2ubuntu1.2/+build/12706353

This bug was fixed in the package kexec-tools - 1:2.0.10-2ubuntu1.2

---------------
kexec-tools (1:2.0.10-2ubuntu1.2) yakkety; urgency=medium

  [ Manoj Iyer ]
  * d/p/arm-do-not-build-iomem.o-target-with-no-soruce.patch:
    Fix regression in previous release that caused armhf to FTBFS.
    (LP: #1671246)

  [ dann frazier ]
  * Expanded above changelog entry for clarity.

 -- dann frazier <email address hidden> Wed, 08 Mar 2017 17:55:26 -0700

The verification of the Stable Release Update for kexec-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package kexec-tools - 1:2.0.10-1ubuntu2.2

---------------
kexec-tools (1:2.0.10-1ubuntu2.2) xenial; urgency=medium

  [ Manoj Iyer ]
  * d/p/arm-do-not-build-iomem.o-target-with-no-soruce.patch:
    Fix regression in previous release that caused armhf to FTBFS.
    (LP: #1671246)

  [ dann frazier ]
  * Expanded above changelog entry for clarity.

 -- dann frazier <email address hidden> Wed, 08 Mar 2017 17:57:31 -0700