Control: tags -1 upstream
Control: forwarded -1 https://github.com/mapnik/mapnik/issues/4098
On 2020-02-13 11:08, Giovanni Mascellani wrote:
your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:
deb https://people.debian.org/~gio/reprepro gio main
Why isn't the new boost-defaults (also) in experimental?
Apparently something changed in Boost.Spirit, and it doesn't like any
more the way mapnik uses it. Unfortunately it is not easy for me,
without knowing the code, understand how to prepare a patch for this.
Apparently upstream has fixed compatibility with Boost 1.71 in master,
but that patch is not released yet and it doesn't apply to the tree
currently in Debian.
Thanks for looking into the upstream fix.
It seems Gentoo people already reported the issue for Boost 1.70:
Which contains the comment:
Boost Spirit 1.71 has a small bug which is fixed on 1.72
Can't we transition to 1.72 in Debian as well, or cherry-pick the spirit
I think the easiest solution would be to just package the next upstream
version as soon as it is released. Do you have an idea on when this
might happen? In the meantime, once Boost 1.71 is promoted to default,
you can update your dependencies to explicitly use Boost 1.67, which
will not be removed immediately from unstable (unless, of course, you
want to write a patch for mapnik, but to me that seems a waste of
Mapnik releases have become much more infrequent, there is not much
demand for releases from Mapbox which uses development snapshots.
Based on the discussion in the upstream issue, we're likely able to
cherry-pick the upstream commit to have 3.0.x build with boost1.72, but
likely not with 1.71.
However, the plan is to not release Boost 1.67 with bullseye, so I hope
that upstream will release before Debian will. Do you think this is a
If we can't get mapnik to work with the default boost in bullseye, we'll
just not ship it and its rdeps.
While Mapnik is important to the OpenStreetMap project, I won't let it
block progress in Debian.