Launchpad and cbd generate different deb packages

[Masahiro Yamada]

Hi.

Presumably, the official place for building kernel packages is launchpad.
People who stick to the _golden_ workflow will create a
source package, and dput it to the launchpad.

cbd is available as a quicker path, but a problem is that I get a different
set of *.deb packages.

I am seeing this problem on focal:linux-iot, but I want to escape this
because this is a more global, generic issue.


If I use launchpad, I get linux-image-unsigned-<release>-<abi>-iot_*_arm64.deb

If I use cbd, I get linux-image-<release>-<abi>-iot_*_arm64.deb


This comes to the issue that debian/control is different depending on how you
build the source package.


In the current code, uefi_signed is different depending on architecture.
(I believe this is another bug, but let me continue to focal on the real issue)


$ git grep _signed debian.iot/rules.d/amd64.mk
debian.iot/rules.d/amd64.mk:uefi_signed = true

$ git grep _signed debian.iot/rules.d/arm64.mk
debian.iot/rules.d/arm64.mk:uefi_signed     = false


When you use launchpad, you will create a source package.
Presumably, you run "dpkg-buildpackage -S"  (or cranky build-sources)
Assuming you are using amd64 build host,
debian.iot/rules.d/amd64.mk is included, and "any_signed" is set true.

debian/scripts/control-create will create the following snippet for
control file.


  Package: linux-image-unsigned-5.4.0-1010-iot
  Build-Profiles: <!stage1>
  Architecture: amd64 arm64
  Section: kernel


If you build it in cbd, "dpkg-architecture -qDEB_HOST_ARCH" returns arm64,
so debian.iot/rules.d/arm64.mk is included. "any_signed" is empty.

debian/scripts/control-create will create the following snippet.


  Package: linux-image-5.4.0-1010-iot
  Build-Profiles: <!stage1>
  Architecture: amd64 arm64
  Section: kernel



Given the debian.iot/rules.d/{amd64.mk,arm64.mk} above
debian/scripts/control-create should create the following control file,
but it cannot do this.


  Package: linux-image-unsigned-5.4.0-1010-iot
  Build-Profiles: <!stage1>
  Architecture: amd64
  Section: kernel

  Package: linux-image-5.4.0-1010-iot
  Build-Profiles: <!stage1>
  Architecture: arm64
  Section: kernel





To sum up the problem,

- We requite the user to run 'fakeroot debian/rules clean'
  to generate debian/control.

- The resulting debian/control might be different depending on
  the return value of "dpkg-architecture -qDEB_HOST_ARCH"

- As a consequence, you will get different deb packages
  depending on your build environment.



The easy way is to fix debian/scripts/control-create,
but why do we dynamically generate debian/control
in the first place?

If we had checked-in debian/control (and debian/changelog)
while cranking the kernel, I would not have been hit
by this issue.




-- 
Best Regards
Masahiro Yamada <masahiro.yamada at canonical.com>
Canonical Kernel Team