Bug#1007222: transition: onetbb
36 views
Skip to first unread message
M. Zhou
Mar 13, 2022, 5:10:04 PM3/13/22
to
Package: release.debian.org
Severity: normal
User: release.d...@packages.debian.org
Usertags: transition
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
Severity: normal
User: release.d...@packages.debian.org
Usertags: transition
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
Sebastian Ramacher
Mar 13, 2022, 5:40:03 PM3/13/22
to
Control: forwarded -1 https://release.debian.org/transitions/html/onetbb.html
Control: tags -1 moreinfo
On 2022-03-13 16:59:48 -0400, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> 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.
Please remove the moreinfo tag once these issues have been investigated
and bugs have been filed.
Cheers
>
> Ben file:
>
> title = "tbb";
> is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
> is_good = .depends ~ "libtbb12";
> is_bad = .depends ~ "libtbb2";
> Thank you for using reportbug
>
--
Sebastian Ramacher
Control: tags -1 moreinfo
On 2022-03-13 16:59:48 -0400, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> 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.
and bugs have been filed.
Cheers
>
> Ben file:
>
> title = "tbb";
> is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
> is_good = .depends ~ "libtbb12";
> is_bad = .depends ~ "libtbb2";
> Thank you for using reportbug
>
Sebastian Ramacher
Matthias Klose
Mar 13, 2022, 9:50:03 PM3/13/22
to
On 13.03.22 21:59, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> 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.
"I heard from archlinux" is not good enough. I sent you email about this
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> 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.
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)
> Ben file:
>
> title = "tbb";
> is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
> is_good = .depends ~ "libtbb12";
> is_bad = .depends ~ "libtbb2";
libtbb12. Please fix this first.
Matthias
Jose Luis Rivero
Mar 21, 2022, 1:00:03 PM3/21/22
to
On Mon, 14 Mar 2022 02:30:08 +0100 Matthias Klose <do...@debian.org> wrote:
> >
> > 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.
>
> >
> > 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.
>
> "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
>
> 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
>
...
>
> * gazebo
>
>
> * gazebo
>
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.
Paul Gevers
Mar 24, 2022, 8:20:03 AM3/24/22
to
Hi lumin,
On 14-03-2022 02:30, Matthias Klose wrote:
> On 13.03.22 21:59, M. Zhou wrote:
>> 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.
>
> "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:
[...]
> this breaks everything immediately because of the conflicting libtbb2
> and libtbb12. Please fix this first.
Can you please respond to these remarks? They raise valid points for us.
Paul
On 14-03-2022 02:30, Matthias Klose wrote:
> On 13.03.22 21:59, M. Zhou wrote:
>> 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.
>
> "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:
> this breaks everything immediately because of the conflicting libtbb2
> and libtbb12. Please fix this first.
Paul
M. Zhou
Mar 24, 2022, 11:50:03 AM3/24/22
to
On Thu, 2022-03-24 at 13:12 +0100, Paul Gevers wrote:
> >
> > "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:
Sorry for the late response but I think that's what usually happens when
> >
> > "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:
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.
>
> > this breaks everything immediately because of the conflicting libtbb2
> > and libtbb12. Please fix this first.
>
> Can you please respond to these remarks? They raise valid points for us.
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.
Sebastian Ramacher
Mar 24, 2022, 1:10:03 PM3/24/22
to
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
--
Sebastian Ramacher
M. Zhou
Mar 24, 2022, 3:20:05 PM3/24/22
to
On Thu, 2022-03-24 at 17:55 +0100, Sebastian Ramacher wrote:
> >
> > 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.
>
> 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?
Ok. Before we start, a user said "Following this up,
> >
> > 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.
>
> 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?
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.
Andrius Merkys
May 17, 2022, 2:40:03 AM5/17/22
to
Hello,
uploads.
Best,
Andrius
> this breaks everything immediately because of the conflicting libtbb2 and
> libtbb12. Please fix this first.
This has been fixed recently with tbb/2020.3-2 and onetbb/2021.5.0-8
> libtbb12. Please fix this first.
uploads.
Best,
Andrius
M. Zhou
May 25, 2022, 8:10:03 PM5/25/22
to
Control: tags -1 -moreinfo
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]
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]
M. Zhou
May 25, 2022, 8:30:03 PM5/25/22
to
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.
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.
Graham Inggs
Jun 1, 2022, 2:40:03 PM6/1/22
to
Control: tags -1 + moreinfo
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
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
M. Zhou
Jun 1, 2022, 9:20:03 PM6/1/22
to
On Wed, 2022-06-01 at 20:29 +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo
>
> Control: tags -1 + moreinfo
>
> 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.
My bad. So solely `reverse-depends -b` may miss something. I'll
> 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.
investigate and append results to the transition bug.
> 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.
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.
Andrius Merkys
Jun 3, 2022, 3:10:04 AM6/3/22
to
Hello,
On Wed, 1 Jun 2022 20:29:02 +0200 Graham Inggs <gin...@debian.org>
wrote:> I noticed some packages in the tracker not appearing in your list;
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
On Wed, 1 Jun 2022 20:29:02 +0200 Graham Inggs <gin...@debian.org>
wrote:> 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.
I have ratt-rebuilt the reverse dependencies (I believe ratt catches the
> build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
> libvtk9-dev, and should be investigated as well.
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
Graham Inggs
Jun 3, 2022, 9:40:04 AM6/3/22
to
Hi
On Thu, 2 Jun 2022 at 03:11, M. Zhou <lu...@debian.org> wrote:
> 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.
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".
> 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.
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
On Thu, 2 Jun 2022 at 03:11, M. Zhou <lu...@debian.org> wrote:
> 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.
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".
> 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.
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
Graham Inggs
Jun 3, 2022, 10:20:03 AM6/3/22
to
Hi Andrius
Thanks for your work on this. My comments below are inlined.
On Fri, 3 Jun 2022 at 09:06, Andrius Merkys <mer...@debian.org> wrote:
> Unrelated FTBFS
> ===============
>
> freeture - not in testing
> gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html
> kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html
> limereg - not in testing
> madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html
> mldemos - not in testing
> mpqc3 - not in testing
> numba - not in testing
> olive-editor - not in testing
> opencolorio - not in testing
> php-facedetect - not in testing
> pigx-rnaseq - not in testing
> pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html
> plastimatch - #1005485
> pytorch-audio - not in testing
> pytorch-text - not in testing
> pytorch-vision - not in testing
> trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html
>
> Unsatisfiable dependencies
> ==========================
>
> hyperspy - not in testing
> poliastro - not in testing
> pynpoint - not in testing
> python-cogent - not in testing
> python-epimodels - not in testing
> python-fluids - not in testing
> python-loompy - not in testing
> python-numpy-groupies - not in testing
> python-pynndescent - not in testing
> python-sparse - not in testing
> sfepy - not in testing
> tiledarray - not in testing
> umap-learn - not in testing
again at those marked 'Unrelated FTBFS' where I have placed a link to
reproducible builds where they do not FTBFS.
Regards
Graham
Thanks for your work on this. My comments below are inlined.
On Fri, 3 Jun 2022 at 09:06, Andrius Merkys <mer...@debian.org> wrote:
> Unrelated FTBFS
> ===============
>
> freeture - not in testing
> gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html
> kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html
> limereg - not in testing
> madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html
> mldemos - not in testing
> mpqc3 - not in testing
> numba - not in testing
> olive-editor - not in testing
> opencolorio - not in testing
> php-facedetect - not in testing
> pigx-rnaseq - not in testing
> pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html
> plastimatch - #1005485
> pytorch-audio - not in testing
> pytorch-text - not in testing
> pytorch-vision - not in testing
> trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html
>
> Unsatisfiable dependencies
> ==========================
>
> hyperspy - not in testing
> poliastro - not in testing
> pynpoint - not in testing
> python-cogent - not in testing
> python-epimodels - not in testing
> python-fluids - not in testing
> python-loompy - not in testing
> python-numpy-groupies - not in testing
> python-pynndescent - not in testing
> python-sparse - not in testing
> sfepy - not in testing
> tiledarray - not in testing
> umap-learn - not in testing
>
> Is this enough to remove 'moreinfo'?
We can ignore everything that's not in testing, but please do look
> Is this enough to remove 'moreinfo'?
again at those marked 'Unrelated FTBFS' where I have placed a link to
reproducible builds where they do not FTBFS.
Regards
Graham
Andrius Merkys
Jun 7, 2022, 12:40:03 PM6/7/22
to
Hi Graham,
On 2022-06-03 17:14, Graham Inggs wrote:
> Unrelated FTBFS
> ===============
>
> freeture - not in testing
> gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html
> kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html
> limereg - not in testing
> madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html
> mldemos - not in testing
> mpqc3 - not in testing
> numba - not in testing
> olive-editor - not in testing
> opencolorio - not in testing
> php-facedetect - not in testing
> pigx-rnaseq - not in testing
> pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html
> plastimatch - #1005485
> pytorch-audio - not in testing
> pytorch-text - not in testing
> pytorch-vision - not in testing
> trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html
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
On 2022-06-03 17:14, Graham Inggs wrote:
> Unrelated FTBFS
> ===============
>
> freeture - not in testing
> gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html
> kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html
> limereg - not in testing
> madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html
> mldemos - not in testing
> mpqc3 - not in testing
> numba - not in testing
> olive-editor - not in testing
> opencolorio - not in testing
> php-facedetect - not in testing
> pigx-rnaseq - not in testing
> pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html
> plastimatch - #1005485
> pytorch-audio - not in testing
> pytorch-text - not in testing
> pytorch-vision - not in testing
> trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html
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
Graham Inggs
Jun 12, 2022, 3:40:03 AM6/12/22
to
Control: tags -1 + confirmed - moreinfo
Hi
On Tue, 7 Jun 2022 at 18:39, Andrius Merkys <mer...@debian.org> wrote:
> In the meantime I am test-rebuilding plastimatch, now unblocked by
> #1005485.
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
On Tue, 7 Jun 2022 at 18:39, Andrius Merkys <mer...@debian.org> wrote:
> In the meantime I am test-rebuilding plastimatch, now unblocked by
> #1005485.
Please go ahead with the upload of onetbb to unstable.
Regards
Graham
Andrius Merkys
Jun 13, 2022, 5:10:03 AM6/13/22
to
Hi,
On 2022-06-12 10:29, Graham Inggs wrote:
> Please go ahead with the upload of onetbb to unstable.
Uploaded. Thanks for the guidance!
Best wishes,
Andrius
On 2022-06-12 10:29, Graham Inggs wrote:
> Please go ahead with the upload of onetbb to unstable.
Best wishes,
Andrius
M. Zhou
Jun 13, 2022, 12:00:04 PM6/13/22
to
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 :-)
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 :-)
Andrius Merkys
Jun 14, 2022, 6:00:03 AM6/14/22
to
Hi Mo,
On 2022-06-13 18:54, M. Zhou wrote:
> 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.
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.
> Nowadays I sort of started to dislike packages that my laptop cannot
> easily build within a few minutes :-)
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
On 2022-06-13 18:54, M. Zhou wrote:
> 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.
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.
> Nowadays I sort of started to dislike packages that my laptop cannot
> easily build within a few minutes :-)
background. But yes, life is so much easier with smaller packages :)
[1] https://salsa.debian.org/lucas/collab-qa-tools
Best wishes,
Andrius
Graham Inggs
Jun 14, 2022, 6:10:04 AM6/14/22
to
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
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
Andrius Merkys
Jun 14, 2022, 8:40:04 AM6/14/22
to
Hi,
On 2022-06-14 13:05, Graham Inggs wrote:
> 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?
My guess is that libtbb12 lacks some shlib dependency, but I have little
idea where __atomic_* symbols come from.
> 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?
libtbbmalloc2 is not provided for mips* architectures. I guess
bin:r-cran-rcppparallel should be RMed from mips* then.
Best,
Andrius
On 2022-06-14 13:05, Graham Inggs wrote:
> 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?
idea where __atomic_* symbols come from.
> 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?
bin:r-cran-rcppparallel should be RMed from mips* then.
Best,
Andrius
M. Zhou
Jul 15, 2022, 4:10:04 PM7/15/22
to
I've filed the RM bug here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014990
Seems that we still have a bunch of blockers -- so this is not likely
happening soon.
On Fri, 2022-07-15 at 20:16 +0200, Graham Inggs wrote:
> 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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014990
Seems that we still have a bunch of blockers -- so this is not likely
happening soon.
On Fri, 2022-07-15 at 20:16 +0200, Graham Inggs wrote:
> 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
Reply all
Reply to author
Forward
0 new messages