Launchpad and cbd generate different deb packages

[Dimitri John Ledkov]

On Mon, 16 Jan 2023 at 12:56, Masahiro Yamada
<masahiro.yamada at canonical.com> wrote:
>
> 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.

That's internal only tool, thus I will reply to your email on the
internal mailing list.

Long story short => default cbd build options passed to debian/rules
are supported, but short-circuit certain things. So this packaging
behaviour can be reproduced locally too.

One can use `-o binary` to do a a realistic build instead. And I did a
pr to fix that up, but it was not deployed.

>
> 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
>
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team



-- 
okurrr,

Dimitri