Bug#949259: buster-pu: package linux/4.19.67-2+deb10u1

[Julien Cristau <jcristau@debian.org>]

On Sun, Feb 16, 2020 at 04:27:11PM +0000, Ben Hutchings wrote:
> This was discussed on IRC with Julien Cristau, but unfortunately I
> didn't save a log.  The main points that came up were:
> 
> * Executables built for the O32 FP64 ABI require this kernel config
>   change and older kernel versions will refuse to load them.  So the
>   kernel needs to be upgraded before installing any binaries built
>   for the new FP ABI.
> 
> * Normally the support for an additional ABI would be included in
>   release N.0 and used in N+1.  Since this was not present in 10.0, it
>   would be possible for users to start upgrading to bullseye while
>   still running a kernel that does not support O32 FP64.  We need to
>   prevent them getting a broken system.
> 
> * Julien proposed that libc6 would have a preinst check on the kernel
>   when it is changed to use the new FP ABI.  Presumably all binaries
>   built for the new FP ABI should also have a versioned dependency on
>   at least this version of libc6.
> 
> So I don't see any reason not to update the kernel configuration
> already, as it will remain compatible with the O32 FPXX binaries in
> buster.  Only the user-space changes in unstable (libc6 and toolchain)
> need to be carefully coordinated.
> 
Here's the irc log for the record:

< bwh> jcristau: While you are here, could you have a quick look at #949259?
< jcristau> that's kind of awkward
< jcristau> maybe it's ok because it's only mips, but...
< bwh> but what?
< jcristau> well i'd normally expect bullseye to run on buster r0
< jcristau> what's the failure mode if the kernel doesn't support O32_FP64?
< bwh> syq_: Can you answer?
< bwh> jcristau: It looks to me like exec will fail for programs built for the new FP ABI
< jcristau> so they'll need to get a dependency on a new libc with a preinst check?
< bwh> jcristau: That seems like a reasonable approach
< bwh> that + prominent notice in the release notes
< syq_> jcristau: it will complain that not support such binary
< syq_> jcristau: if kernel doesn't enable FP64

I think you can go ahead provided that:
- enabling this support in the kernel doesn't break previously-supported
  userspace
- Aurélien as glibc maintainer is OK with this plan

Thanks,
Julien