Pkg xen devel - Jan 2021 - [PATCH 04/16] debian/rules: Correct shim install step for current Xen

Ian,

Can you take a look at this? There are too many intricacies involved in
the shim story for me to figure out what's actually happening.

Because, when trying to get 4.14 in, I ended up doing the following
(from d/changelog):

    "* Revert upstream commit a516bddbd3 ("tools/firmware/Makefile:
CONFIG_PV_SHIM: enable only on x86_64") and cherry-pick our previous
commits 0b898ccc2 ("tools/firmware/Makfile: Respect caller's
CONFIG_PV_SHIM") and a516bddbd3 ("tools/firmware/Makefile:
CONFIG_PV_SHIM: enable only on x86_64") again to work around a FTBFS
where the shim would not be built during the i386 package build."

This was a workaround to at least get it going, but it should be
improved, to have something that DTRT based on the new upstream change
a516bddbd3.

Elliot, did you test/use this based on a package that does or does not
have the above mentioned workaround?

Thanks,

Hans

On 7/17/20 7:16 AM, Elliott Mitchell wrote:
> When originally implemented, the separated shim install step relied on
> the shim install being a NOP on shimless architectures.  Either this is
> no longer the case, or else cross-building confuses the architecture
> detection.
> 
> Take out a typo while at it.
> 
> Signed-off-by: Elliott Mitchell <ehem+debian at m5p.com>
> ---
>  debian/rules | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/debian/rules b/debian/rules
> index 60d99e6dc2..0a7fcc9553 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -251,11 +251,13 @@ override_dh_auto_install: $(TEMPLATED_FILES)
>  	:
>  	@# shim install target needs to be run separately because we
>  	@# need to pass it the make_args_xen settings, in particular
> -	@# on i386 bwe need to pass x86_64 here to actually build it.
> -	@# Luckily this target, unlike the build, is a noop on
> -	@# shimless arches, so it does not need to be conditional.
> -	$(MAKE) $(make_args_xen) DESTDIR=$t $(make_args_xen) \
> -		-C tools/firmware install-shim
> +	@# on i386 we need to pass x86_64 here to actually build it.
> +	case $(flavour) in \
> +	amd64|i386) \
> +		$(MAKE) $(make_args_xen) DESTDIR=$t $(make_args_xen) \
> +			-C tools/firmware install-shim \
> +	;; \
> +	esac
>  	:
>  	@# Inexplicably, upstream puts the efi binares in usr/lib64
>  	find "$t"/usr/lib*/efi -mindepth 1 -maxdepth 1 -print0 | xargs
-r -0 mv -t "$t/boot"
>

Hans van Kranenburg writes ("Re: [PATCH 04/16] debian/rules: Correct shim
install step for current Xen"):
> Can you take a look at this? There are too many intricacies involved in
> the shim story for me to figure out what's actually happening.
I think the right way to test this would be to do a debdiff.
Specifically, to compare
  1. i386 and amd64 buster packages
  2. experimental packages build with these patches, not cross build

There result should show that the patch has no effect on which
packages contain shims, and where those shims are found.

If that is the case then it won't break anyone's install.

In general, debdiff off non-cross-built results is a good way to test
fixes that are supposed to fix cross building but not break anything
else.

Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my
own.

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.