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 <[email protected]> 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.
