Your message dated Thu, 27 Jun 2019 12:00:54 +0200
with message-id <ddc4c477-4f66-9283-a41b-aae5d7cbf...@debian.org>
and subject line Re: Bug#929318: unblock: papi/5.7.0+dfsg-1
has caused the Debian Bug report #928368,
regarding transition: papi
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
928368: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928368
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: transition
Hi,
I recently realized that libpapi5 (5.7.0-1) is not compatible with
applications built against papi 5.6 (or any other mismatching
major.minor version) due to the runtime checks performed in
PAPI_library_init() and the way this is to be called from applications.
Applications will abort after PAPI_library_init() returned an error and
require recompilation against the current version. (I ran into this
incompatibility myself.) #928367
Upstream confirmed that they only intend to maintain ABI compatibility
for major.minor.*.* releases, but not between different minor versions.
The soname therefore should have never been libpapi.so.major but rather
libpapi.so.major.minor
Patching out the check completely is non-trivial since it is some kind
of handshake beween caller and callee (app and lib). I'm pretty sure the
ABI has not changed between 5.5 (stretch) and 5.7, but I wouldn't put my
hand into the fire for it. And upstream has no way to track ABI
independently of major.minor version, given that the runtime check
exists for a long time already.
While I could patch papi to use version 5.6.99.99 internally instead of
5.7.0.0 to restore compatibility with the snapshot we had in buster
previously (only major.minor are being compared), this would still be
incompatible with programs built on stretch which had libpapi5 5.5.*
Given the limited amount of packages involved, I'd prefer to perform a
late but proper transition libpapi5 -> libpapi5.7 for buster.
# Depends:
eztrace: libeztrace0 [amd64 arm64 armel armhf i386 mips mips64el mipsel
ppc64el]
# Build-Depends:
eztrace: libpapi-dev
eztrace-contrib/contrib: libpapi-dev
mpqc3: libpapi-dev
Only one binNMU is needed. mpqc3 links statically (will fix post buster)
and eztrace-contrib probably shares the packaging with eztrace, and IIRC
only builds some addon modules.
If I had seen this coming, I would have done the transition in time for
the 5.6 snapshot we previously had and left 5.7 for bullseye.
Ben file:
title = "papi";
is_affected = .depends ~ "libpapi5" | .depends ~ "libpapi5.7";
is_good = .depends ~ "libpapi5.7";
is_bad = .depends ~ "libpapi5";
--- End Message ---
--- Begin Message ---
On Sun, 16 Jun 2019 13:31:47 +0200 Andreas Beckmann <a...@debian.org> wrote:
> The package is in sid, built on all release architectures and I verified
> that all reverse build-depends still build on amd64.
and meanwhile it migrated to buster ... thus closing the transition bug
Andreas
--- End Message ---
