Bug#926976: [pre-a] unblock: blis/0.5.1-13
Hi,
On Wed, Apr 24, 2019 at 11:02:03AM +0200, Paul Gevers wrote:
> On Sat, 13 Apr 2019 03:30:38 +0000 Mo Zhou <lumin@debian.org> wrote:
> > I'm going to fix this bug (the severity is actually important):
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926909
>
> Please fix the bug's meta info to reflect that.
Done.
> It causes a FTBFS (on non-release architectures) in a reverse dependent
> package, why does that only happen in experimental and not in sid?
The FTBFS is a special case. The slepc package doesn't depend on blis
directly. Some of its dependencies require "libblas-dev | libblas.so",
and for some reason (I'm not quite clear at this point) mpich archs
(e.g. m68k, sh4) picked libblis-openmp-dev as the libblas.so provider.
At the dpkg-shlibdeps stage, error happended because dpkg cannot find
any dependency information for libblas.so.3 , because I didn't write
that information in the symbols control file. So, slepc found
libblas.so, but dpkg failed to resolve dependency when libblis-*-dev is
used to build packages.
The bug actually affects blis << 0.5.2-4 .
> The package in experimental is fixed now, have you considered to ask for a
> gb of slepc, to see if this all works now?
Theoretically the bits about dpkg-shlibdeps are expected to work well,
but I'll try to gb slepc to validate the fix.
> > I plan to first upload (= 0.5.1-12) with this tiny patch,
> > abusing buildd to refresh symbol lists for all architectures:
> > https://salsa.debian.org/science-team/blis/commit/ca29b2850aaaa93acc602b891a993fa38a33f79a
> > Then I'll upload (= 0.5.1-13) with collected symbol patches.
>
> I was going to suggest you use experimental for this, but as I noted
> above experimental is already in use for a newer version, with the
> change you are suggesting here applied IIUC. Do you have proof that this
> works as intended there.
A similar fix for the package in unstable would work because the fix is
associated with dpkg shlibdeps resolving, and is unrelated to the
upstream version. Maybe we don't have to prove that dpkg's dependency
resolving works when the missing information has been added to symbols
control file?
> > Is this (quality improvement) change acceptable to Buster?
>
> https://release.debian.org/buster/freeze_policy.html [Changes which can
> be considered]:
> 2. fixes for severity: important bugs in packages of priority: optional,
> only when this can be done via unstable;
Thanks. The current blis package in testing leads to problematic dpkg
shlib dependency resolving. The bug would also affect amd64 if blis was
the only libblas.so provider (theoretically).
I'll remove the moreinfo tag when the g-b build turns out to be successful.
Reply to: