Hi release team,

This involves an upstream source name change (from tbb to onetbb),
as well as SOVERSION bump (from 2 to 12), along with a major API
change including some changes in the core API.

I should have submitted this after my local build test for the
reverse dependencies of libtbb-dev, but fellow developers from
debian-science are eager to see this in unstable to unblock
their works.

I have not tested by myself, but I heard from an archlinux
developer that this API bump breaks a lot packages. And
some upstreams decided to disable or drop tbb support as
a result. I guess we can take similar measures for short
term workaround.

Ben file:

title = "tbb";
is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
is_good = .depends ~ "libtbb12";
is_bad = .depends ~ "libtbb2";
Thank you for using reportbug

Control: forwarded -1 https://release.debian.org/transitions/html/onetbb.html
Control: tags -1 moreinfo

Please remove the moreinfo tag once these issues have been investigated
and bugs have been filed.

Cheers

"I heard from archlinux" is not good enough.  I sent you email about this
without getting a reply, then filed #1006920, without getting a reply, now this
incomplete proposal. you may want to look at all the build rdeps for libtbb2-dev
in Ubuntu to get an overview what at least breaks:

$ reverse-depends -b libtbb2-dev

Reverse-Testsuite-Triggers

* intel-mkl



Reverse-Build-Depends

* casparcg-server

* flexbar

* gazebo

* opencascade

* opensubdiv

* r-cran-rcppparallel
  (plus implicit dependencies)

this breaks everything immediately because of the conflicting libtbb2 and
libtbb12. Please fix this first.

Matthias

now this
libtbb2-dev
...

Speaking as the maintainer of Gazebo, upstream has released a new 11.10.2
version that is compatible with new tbb. I've uploaded it to experimental,
it builds fine. The package should be ready for the transition as far as I
can tell.

Thanks guys for working on the transition.

Hi lumin,

[...]

Can you please respond to these remarks? They raise valid points for us.

Paul

Sorry for the late response but I think that's what usually happens when
the maintainer is occupied by research and studies. I would not have
submitted this incomplete transition slot if I did not hear so much
request.

I think the solution for allowing the co-existence of tbb and onetbb
is not the best. Because tbb will not have upstream support in the
future due to deprecation.

libtbb2 and libtbb12 contains some common files hence the conflict.
I'd rather wait for all the reverse deps to be ready for this
transition, compared to going through NEW again due to binary
package change.

I've started rebuilding the reverse dependencies and filing bugs,
will get back to you soon.

This makes the transition and upgrades more painful than necessary. The
files shared between both packages are actually shared libraries with
their own SONAME that did not change. Why are the contained in libtbb12
if they do not follow the same version as libtbb itself?

Cheers

Ok. Before we start, a user said "Following this up,
the split of the libraries is breaking some common use
cases in the robotics community" at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006920

But I did not figure out what bad could happen from the
links provided. I'm requesting more information there.
Once confirmed I'll merge doko's patches and go through NEW
again.

Hello,

This has been fixed recently with tbb/2020.3-2 and onetbb/2021.5.0-8
uploads.

Best,
Andrius

Reverse-Build-Depends
* blender [irrelevant; ftpfs, no matching function for call to openvdb... ] #1011653
* bowtie  [ok]
* bowtie2 [ok]
* casparcg-server [ftbfs, TBB not found during cmake] #1011654
* deal.ii [ftbfs, cmake could not find tbb] #1011655
* embree [ok]
* flexbar [ftbfs, cannot find tbb header] #1011656
* gazebo [irrelevant; ftbfs, missing symbol from libtiff] #1011657
* gudhi [ok]
* libatomic-queue [ok]
* libpmemobj-cpp [ftbfs, tbb api break] #1011658
* macaulay2 [unknown, timeout for doc build during ThreadedGB ... Minimal.out]
* madness [ok]
* mathicgb [ok]
* mpqc3 [irrelevant; eigen3 api break; already FTBFS]
* numba [irrelevant; incompatible with py3.10]
* onednn [ok]
* open3d [ok]
* opencascade [ftbfs; tbb api break] #1011659
* opencv [ok]
* opensubdiv [ftbfs; tbb api break] #1011660
* openturns [ok]
* openvdb [irrelevant; help2man error during manpage build; already FTBFS]
* pmemkv [ok]
* ptl [ok]
* r-cran-markovchain [ftbfs; tbb api break] #1011661
* r-cran-rcppparallel [ok]
* r-cran-uwot [ok]
* salmon [ftbfs; tbb api break] #1011662
* slic3r-prusa [FTBFS, TBB api break] #1011663
* sysdig [ok]
* tiledarray [irrelevant: other build depenency uninstallable]
* tiny-dnn [ftbfs, TBB not found during cmake] #1011664
* trilinos [irrelevant: isinf not defined]
* vtk9 [ok]


On Sun, 2022-03-13 at 22:28 +0100, Sebastian Ramacher wrote:
Control: forwarded -1
https://release.debian.org/transitions/html/onetbb.html
Control: tags -1 moreinfo

Please remove the moreinfo tag once these issues have been
investigated
and bugs have been filed.

Cheers

This is the most uneasy transition I've ever handled. There was
massive upstream code overhaul breaking basically everything.

Build system has changed so I rewritten the d/rules, this took
me a while.

Going through NEW due to upstream rename took a while.

Then only amd64 does not FTBFS. I wrote patches to make it
green on release architectures, this took me a while.

Then there is package split, which means we have to go through
NEW again. This is relatively fast IIRC.

Throughout the whole process I'm dealing with paper submission
deadline which has passed several days ago. Before that
I wasn't able to allocate time for the massive reverse dependency
build. This took a while as well.

Now we can finally go ahead.

Hi

I noticed some packages in the tracker not appearing in your list;
e.g. openimageio, pcl and yade.  These packages have transitive
build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
libvtk9-dev, and should be investigated as well.

Note that we will require fixes, or at least patches, for "key
packages" [1] before starting with this transition, and at least
trilinos is currently on that list.

It may be worth considering again Matthias' suggestion in #1006920 to
keep the old tbb package around as libtbb2-dev and libtbb2-doc in
order to allow packages like numba to get the new tbb soon, and other
packages stuck with the old tbb more time to get fixed.

Regards
Graham


[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

My bad. So solely `reverse-depends -b` may miss something. I'll
investigate and append results to the transition bug.

I personally dislike making the old package libtbb2-dev.
How about we make the old src:tbb package go through NEW again
with the following renames:

libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev
              because it explains itself to be a to-be-deprecated version.

In this way we can finish the transition very quickly and leave
longer time for broken packages to migrate to onetbb.

For me, submitting patches is as well much easier as I only have to
change libtbb-dev -> libtbb-legacy-dev for broken packages.

Hello,

On Wed, 1 Jun 2022 20:29:02 +0200 Graham Inggs <ginggs@debian.org>
wrote:> I noticed some packages in the tracker not appearing in your list;

I have ratt-rebuilt the reverse dependencies (I believe ratt catches the
transitive ones). Here are my results:

OK
==

actiona
arc-theme
asl
auto-multiple-choice
bcnc
beads
bowtie
bowtie2
budgie-control-center
cheese
cimg
darknet
digikam
embree
empathy
esys-particle
eviacam
f3d
finalcif
freecad
frei0r
gearhead2
gfpoken
gmic
gnome-dvb-daemon
gnome-initial-setup
gnome-mousetrap
gnome-sound-recorder
golang-github-thecreeper-go-notify
gst-plugins-bad1.0
gstreamer-editing-services1.0
gstreamer-vaapi
gst-rtsp-server1.0
gtk4
gudhi
kdenlive
kylin-scanner
lammps
libatomic-queue
liggghts
mathicgb
mlt
monado
mrcal
mrgingham
mrpt
netgen
nheko
node-opencv
nomacs
obs-advanced-scene-switcher
octave-bim
octave-msh
odin
oggvideotools
onednn
open3d
opencfu
opencv
opendrop
openqa
openturns
os-autoinst
otb
pcl
planetary-system-stacker
pmemkv
pmemkv-python
pragha
psychopy
ptl
pulseeffects
pygmsh
pymatgen
python-escript
python-notify2
python-pcl
pytorch
pytorch-ignite
q2-dada2
qimgv
r-cran-luminescence
r-cran-openmx
r-cran-projpred
r-cran-rcppparallel
r-cran-rlumshiny
r-cran-rstantools
r-cran-semplot
r-cran-stanheaders
r-cran-treescape
r-cran-treespace
r-cran-uwot
ros-image-pipeline
ros-opencv-apps
ros-perception-pcl
ros-vision-opencv
sayonara
sdaps
seer
shotcut
sight
simple-whip-client
siril
skorch
sunpy
synfig
synfigstudio
sysdig
therion
tpot
trinityrnaseq
ukui-biometric-auth
ukui-biometric-manager
ukui-control-center
ukui-greeter
ukui-screensaver
uprightdiff
vecgeom
vedo
visp
vtk9
willow
yade

FTBFS with TBB (bugs reported)
==============================

blender
deal.ii
flexbar
gazebo
libpmemobj-cpp
opencascade
openimageio
opensubdiv
openvdb
r-bioc-dada2
r-cran-brms
r-cran-lamw
r-cran-markovchain
r-cran-prophet
r-cran-rstan
r-cran-rstanarm
r-cran-shinystan
salmon
slic3r-prusa
tiny-dnn

Unrelated FTBFS
===============

freeture
gmsh
kicad
limereg
madness
mldemos
mpqc3
numba
olive-editor
opencolorio
php-facedetect
pigx-rnaseq
pitivi
plastimatch
pytorch-audio
pytorch-text
pytorch-vision
trilinos

Unsatisfiable dependencies
==========================

hyperspy
poliastro
pynpoint
python-cogent
python-epimodels
python-fluids
python-loompy
python-numpy-groupies
python-pynndescent
python-sparse
sfepy
tiledarray
umap-learn

Is this enough to remove 'moreinfo'?

Best,
Andrius

Hi

I personally don't like tbb-legacy-dev.  It's not common in the
archive for a -dev package.  Most are unversioned, otherwise they
match the library package, so libtbb2-dev for libtbb2. See e.g.
lmsensors-dev, lmsensors4-dev, libpcre2-dev, libpcre3-dev, libvtk7-dev
and libvtk9-dev, etc.  Explanations can go in the package description,
e.g. from libpcre3-dev
"New packages should use the newer pcre2 packages, and existing
packages should migrate to pcre2".

Changing libtbb-dev -> libtbb2-dev should be even easier :).  However,
we don't **have** to reintroduce the old tbb package, and **you**
don't have to be the one maintaining it.  If all the packages that
FTBFS with the new tbb can be removed from testing, the old tbb can be
reintroduced after the transition, by some maintainers who wish to
care for it.

Regards
Graham

Hi Andrius

Thanks for your work on this.  My comments below are inlined.

We can ignore everything that's not in testing, but please do look
again at those marked 'Unrelated FTBFS' where I have placed a link to
reproducible builds where they do not FTBFS.

Regards
Graham

Hi Graham,

I gave these a better look to find out the following actually builds fine:

gmsh
kicad
madness
pitivi

trilinos FTBFS with onetbb, but it can be patched to build without it
[1]. In the meantime I am test-rebuilding plastimatch, now unblocked by
#1005485.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011928#26

Best,
Andrius

Hi

There you will hit #1012439, but plastimatch is now no longer in testing.

Please go ahead with the upload of onetbb to unstable.

Regards
Graham

Hi,

Uploaded. Thanks for the guidance!

Best wishes,
Andrius

Hi Andrius,

Thank you so much for the help! I was still looking for time slot
to login into a build server to deal with this hard-to-build package.

Nowadays I sort of started to dislike packages that my laptop cannot
easily build within a few minutes :-)

Hi Mo,

Thank you for updating the onetbb package! Building and uploading it was
not that much of a work. Admittedly, ratt-rebuilding all reverse
dependencies took quite some time and effort. I became aware of Lucas's
collab-qa-tools [1] only since, this could have saved some time.

I do not mind running unstable VM on my desktop to do builds in the
background. But yes, life is so much easier with smaller packages :)

[1] https://salsa.debian.org/lucas/collab-qa-tools

Best wishes,
Andrius

Hi

I've noticed some binNMUs failed on armel; mathicgb [1] (subsequently
fixed by maintainer upload) and r-cran-rcppparallel [2].  Both seem to
fail in a similar way:

/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
undefined reference to `__atomic_fetch_sub_8'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
undefined reference to `__atomic_load_8'

  call: dyn.load(path, local = FALSE, now = TRUE)
  error: unable to load shared object '/usr/lib/arm-linux-gnueabi/libtbb.so':
  /usr/lib/arm-linux-gnueabi/libtbb.so: undefined symbol: __atomic_fetch_sub_8

I also noticed the following in the armel build of onetbb [3]:

dpkg-shlibdeps: warning: symbol __atomic_fetch_sub_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries
dpkg-shlibdeps: warning: symbol __atomic_load_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries
dpkg-shlibdeps: warning: symbol __atomic_fetch_add_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries

Is this something that can/should be fixed in onetbb, or should this
be fixed in the reverse-dependencies?

Additionally, r-cran-rcppparallel failed on mipsel [4] and mips64el
[5] with the following:

/usr/bin/ld: cannot find -ltbbmalloc: No such file or directory
collect2: error: ld returned 1 exit status

This seems related to #1011112 [6].  What needs to happen here?

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=mathicgb&arch=armel
[2] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=armel
[3] https://buildd.debian.org/status/fetch.php?pkg=onetbb&arch=armel&ver=2021.5.0-10&stamp=1655112619&raw=0
[4] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mipsel
[5] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mips64el
[6] https://bugs.debian.org/1011112

Hi,

My guess is that libtbb12 lacks some shlib dependency, but I have little
idea where __atomic_* symbols come from.

libtbbmalloc2 is not provided for mips* architectures. I guess
bin:r-cran-rcppparallel should be RMed from mips* then.

Best,
Andrius

Hi

libtbb2 is now gone from testing.  Please file a RM bug for src:tbb
against ftp.debian.org, but maybe tag it 'moreinfo' until it is clear
what will happen to libtbb2's reverse-dependencies still in unstable.

Regards
Graham