[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#948378: marked as done (transition: boost-python)

Your message dated Sat, 14 Mar 2020 10:52:28 +0100
with message-id <e78d58cd-b106-ac19-e0d8-1c7797b304cc@debian.org>
and subject line Re: Bug#948378: transition: boost-python
has caused the Debian Bug report #948378,
regarding transition: boost-python
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 owner@bugs.debian.org
immediately.)


-- 
948378: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948378
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

This is not a real transition, just a request for a bunch of binNMUs to
tighten the boost-python dependencies.

Boost currently builds these packages:
  libboost-python1.67.0
  libboost-mpi-python1.67.0
  libboost-numpy1.67.0
each containing a shared library for each supported python version (at
the moment python2.7, python3.7, python3.8).
Removing a supported python version is currently not possible since that
requires removal of shared libraries which will break rdepends.
Since 1.67.0-12 these packages provide virtual packages for each
supported python version: ${packagename}-pyXY and since 1.67.0-17 the
shlibs files generate dependencies of the form
  ${packagename}, ${packagename}-pyXY
that will allow removal of supported python versions in the future,
since these are now reflected in the dependencies. (This will work best
from boost1.71 onwards since upgrades from buster need to be taken into
account, but bullseye ideally shouldn't ship with boost1.67.)

So let's rebuild all rdepends of libboost-python1.67.0 and friends to
tighten the dependencies and properly document which python support is
being used. That should help with the python2 removal (and a future
removal of python3.7 as a supported version).

I don't know how to express something like
  "depends on libboost-python1.67.0
   AND NOT depends on libboost-python1.67.0-py.*"
in ben, so the below ben file will only generate "unknown" and "good"
states. (Is ".false" the correct syntax for that?)
You can exclude src:boost1.67 and src:boost1.71 if you want.
Please binNMU the remaining "unknown" packages once, hopefully they
should all turn green. Since this is not a real transition, all could be
scheduled at the same time.

This is the debdiff for antimony_0.9.3-1.1_amd64.deb built against
boost1.67 1.67.0-13 and 1.67.0-17:

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: python3:any, libboost-python1.67.0,
{+libboost-python1.67.0-py37,+} libc6 (>= 2.29), libgcc1 (>= 1:3.0),
libpng16-16 (>= 1.6.2-1), libpython3.7 (>= 3.7.0), libqt5core5a (>=
5.12.2), libqt5gui5 (>= 5.8.0) | libqt5gui5-gles (>= 5.8.0),
libqt5network5 (>= 5.0.2), libqt5widgets5 (>= 5.3.0), libstdc++6 (>=
5.2)

and for freeorion_0.4.8-3_amd64.deb:

File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: freeorion-data (= 0.4.8-3), libboost-date-time1.67.0,
libboost-filesystem1.67.0, libboost-iostreams1.67.0,
libboost-locale1.67.0, libboost-log1.67.0, libboost-python1.67.0,
[-libboost-regex1.67.0 (>= 1.67.0-10),-] {+libboost-python1.67.0-py27,
libboost-regex1.67.0-icu63,+} libboost-serialization1.67.0,
libboost-system1.67.0, libboost-thread1.67.0, libc6 (>= [-2.27),-]
{+2.29),+} libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.4), libgl1,
libglew2.1 (>= 1.12.0), libglu1-mesa | libglu1, libopenal1 (>= 1.14),
libpng16-16 (>= 1.6.2-1), libpython2.7 (>= 2.7), libsdl2-2.0-0 (>=
[-2.0.9),-] {+2.0.10),+} libstdc++6 (>= [-7),-] {+9),+} libvorbis0a (>=
1.2.3), libvorbisfile3 (>= 1.1.2)
Installed-Size: [-29168-] {+30778+}


Similar changes are expected for all relevant packages.

Ben file:

title = "boost-python";
is_affected = .depends ~ /libboost.*(python|numpy)[0-9.]*/;
is_good = .depends ~ /libboost.*(python|numpy)[0-9.]*-py[0-9]*/;
is_bad = .false;

--- End Message ---
--- Begin Message --- 
On 26/01/2020 08:33, Sebastiaan Couwenberg wrote:
> On 1/25/20 3:57 PM, Andreas Beckmann wrote:
>> On 25/01/2020 08.04, Paul Gevers wrote:
>>> All rebuilds have been scheduled.
>>> There are 2 packages (python-escript
>>> (sid only) and pythonmagick) that FTBFS now, but didn't before. Can you
>>> please check? Especially pythonmagick looks suspicious to my untrained eyes.
>>
>> python-escript got hit by an underlinked netcdf-cxx library (unrelated
>> to the ongoing netcdf transitions): #949828
> 
> netcdf-cxx is fixed now, python-escript can be given back.

Looks like this transition is done (k3d is still buggy but is sid-only and has a
bug opened about this).

Cheers,
Emilio

--- End Message ---
Reply to: