Discussion:
Bug#915721: transition: opencv
Add Reply
Mo Zhou
2018-12-06 12:20:01 UTC
Reply
Permalink
Package: release.debian.org
Severity: normal
User: ***@packages.debian.org
Usertags: transition

opencv 3.4.4 introduced new features, bug fixes including CVE fixes.
I'd like to request for a transition slot.

The rebuild for all reverse build depends has been done locally,
and here is the result:

(12 packages FTBFS)

actiona [skipped: already FTBFS with Qt 5.11 #909828]
auto-multiple-choice [OK]
beads [OK]
caffe [OK]
cheese [OK]
cimg [skipped; arch=all]
digikam [OK]
eviacam [FTBFS #915708]
ffmpeg [FTBFS #915544]
freecad [OK]
freemedforms-project [OK]
freeture [skipped; already #914060 freeture FTBFS with boost 1.67]
frei0r [FTBFS #915707]
gmic [OK]
gnome-dvb-daemon [OK]
gnome-mousetrap [skipped; arch=all]
gst-plugins-bad1.0 [FTBFS #915709]
gstreamer-vaapi [OK]
libkf5kface [FTBFS #915710]
limereg [OK]
mldemos [FTBFS #915711]
mrpt [OK]
nomacs [OK]
oggvideotools [OK]
openalpr [OK]
opencfu [OK]
openimageio [OK]
os-autoinst [OK]
otb [OK]
php-facedetect [FTBFS #915712]
psychopy [skipped: arch=all]
remotecv [skipped: arch=all]
ros-opencv-apps [FTBFS #915529]
ros-vision-opencv [OK]
saga [OK]
sdaps [OK]
siril [skipped, already ftbfs against glibc 2.28 #913854]
sitplus [FTBFS #915592]
thumbor [OK (test skipped)]
uprightdiff [OK]
visp [OK]
webkit2gtk [OK]
willow [skipped; arch=all]


Ben file:

title = "opencv";
is_affected = .depends ~ /\b(libopencv\-calib3d3\.2|libopencv\-contrib3\.2|libopencv\-core3\.2|libopencv\-features2d3\.2|libopencv\-flann3\.2|libopencv\-highgui3\.2|libopencv\-imgcodecs3\.2|libopencv\-imgproc3\.2|libopencv\-ml3\.2|libopencv\-objdetect3\.2|libopencv\-photo3\.2|libopencv\-shape3\.2|libopencv\-stitching3\.2|libopencv\-superres3\.2|libopencv\-video3\.2|libopencv\-videoio3\.2|libopencv\-videostab3\.2|libopencv\-viz3\.2|libopencv3\.2\-java|libopencv3\.2\-jni)\b/ | .depends ~ /\b(libopencv\-calib3d3\.4|libopencv\-contrib3\.4|libopencv\-core3\.4|libopencv\-dnn\-dev|libopencv\-dnn3\.4|libopencv\-features2d3\.4|libopencv\-flann3\.4|libopencv\-highgui3\.4|libopencv\-imgcodecs3\.4|libopencv\-imgproc3\.4|libopencv\-ml3\.4|libopencv\-objdetect3\.4|libopencv\-photo3\.4|libopencv\-shape3\.4|libopencv\-stitching3\.4|libopencv\-superres3\.4|libopencv\-video3\.4|libopencv\-videoio3\.4|libopencv\-videostab3\.4|libopencv\-viz3\.4|libopencv3\.4\-java|libopencv3\.4\-jni)\b/;
is_good = .depends ~ /\b(libopencv\-calib3d3\.4|libopencv\-contrib3\.4|libopencv\-core3\.4|libopencv\-dnn\-dev|libopencv\-dnn3\.4|libopencv\-features2d3\.4|libopencv\-flann3\.4|libopencv\-highgui3\.4|libopencv\-imgcodecs3\.4|libopencv\-imgproc3\.4|libopencv\-ml3\.4|libopencv\-objdetect3\.4|libopencv\-photo3\.4|libopencv\-shape3\.4|libopencv\-stitching3\.4|libopencv\-superres3\.4|libopencv\-video3\.4|libopencv\-videoio3\.4|libopencv\-videostab3\.4|libopencv\-viz3\.4|libopencv3\.4\-java|libopencv3\.4\-jni)\b/;
is_bad = .depends ~ /\b(libopencv\-calib3d3\.2|libopencv\-contrib3\.2|libopencv\-core3\.2|libopencv\-features2d3\.2|libopencv\-flann3\.2|libopencv\-highgui3\.2|libopencv\-imgcodecs3\.2|libopencv\-imgproc3\.2|libopencv\-ml3\.2|libopencv\-objdetect3\.2|libopencv\-photo3\.2|libopencv\-shape3\.2|libopencv\-stitching3\.2|libopencv\-superres3\.2|libopencv\-video3\.2|libopencv\-videoio3\.2|libopencv\-videostab3\.2|libopencv\-viz3\.2|libopencv3\.2\-java|libopencv3\.2\-jni)\b/;


-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Mo Zhou
2018-12-24 02:00:01 UTC
Reply
Permalink
I was going to ack this, but I noticed that opencv failed to build on some
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental
Please look at that before we start this.
opencv was given-back on armel several days ago. minkus (mips) cannot
reproduce the FTBFS on mips so I assume the reason is similar to armel,
so I'll give-back it later. eller (mipsel/mips64el) has successfully
built the opencv package, although buildd still hasn't started the build
yet.

Can we move on without waiting for mipsel and mips64el? The buildd
scheduler puts too small a weight for experimental distribution...
Mo Zhou
2018-12-27 11:40:01 UTC
Reply
Permalink
OpenCV 3.4.4 is green on all official architectures after uploading
manually built mips{,64}el packages by using Yunqiang's machine.

Shall we move on?
Post by Mo Zhou
I was going to ack this, but I noticed that opencv failed to build on some
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental
Please look at that before we start this.
opencv was given-back on armel several days ago. minkus (mips) cannot
reproduce the FTBFS on mips so I assume the reason is similar to armel,
so I'll give-back it later. eller (mipsel/mips64el) has successfully
built the opencv package, although buildd still hasn't started the build
yet.
Can we move on without waiting for mipsel and mips64el? The buildd
scheduler puts too small a weight for experimental distribution...
Mo Zhou
2018-12-31 10:20:01 UTC
Reply
Permalink
I've uploaded opencv 3.4.5 to experimental which fixed some issues found
in the previous version. This time mipsel and mips64el is still lagging
behind other other architectures. I'll build binaries by myself for the
two architectures and I don't expect any buiid failure.

3.4.5 Will be green on all official architectures in about 36 hours
(each build takes more than 12 hours)
Post by Mo Zhou
OpenCV 3.4.4 is green on all official architectures after uploading
manually built mips{,64}el packages by using Yunqiang's machine.
Shall we move on?
Post by Mo Zhou
I was going to ack this, but I noticed that opencv failed to build on some
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental
Please look at that before we start this.
opencv was given-back on armel several days ago. minkus (mips) cannot
reproduce the FTBFS on mips so I assume the reason is similar to armel,
so I'll give-back it later. eller (mipsel/mips64el) has successfully
built the opencv package, although buildd still hasn't started the build
yet.
Can we move on without waiting for mipsel and mips64el? The buildd
scheduler puts too small a weight for experimental distribution...
Mo Zhou
2019-01-06 04:50:02 UTC
Reply
Permalink
Hi,

Any updates? Transition freeze is close. The current version of OpenCV
(3.2.0) in Sid is quite ancient (Dec 23, 2016).

mips{,64}el buildd are again lagging behind the other architectures for
the last binNMU. And before any ack I'm not going to manually build it
again on mips box since I'm not buildd.

Builds for 3.4.5+dfsg-1~exp1 were successful so I don't expect any
problem for 3.4.5+dfsg-1~exp1+b1 .
Post by Mo Zhou
I've uploaded opencv 3.4.5 to experimental which fixed some issues found
in the previous version. This time mipsel and mips64el is still lagging
behind other other architectures. I'll build binaries by myself for the
two architectures and I don't expect any buiid failure.
M. Zhou
2019-01-13 09:10:01 UTC
Reply
Permalink
Hi pochu,

To make things explicit, do I still have chance to continue with the
opencv transition after the gdal one? And do I need to apply for
freeze exception for opencv?
Mo Zhou
2019-01-14 15:50:01 UTC
Reply
Permalink
I haven't had enough time to test rdeps for another round. But I guess
the situation would be similar to the first round.
#915544 suggests the OpenCV C API is broken, and ffmpeg solved it by disabling
ffmpeg support altogether.
#915709 seems to point to the same brokenness.
Quoted from upstream:
https://github.com/opencv/opencv/issues/10963#issuecomment-369259044

| OpenCV 3.x doesn't not support C compilation mode officially.

And if you look at upstream Pull Requests you will find that upstream
is gradually removing legacy C APIs.

So, those rdeps broken due to the C API are questionable because they
are using non-officially supported (deprecated) part of opencv ...

There are another failing pattern, which stems from changes in C++ class
method, and is easy to fix ...

I'm currently putting out the fire on the julia package so I cannot
make a statistics.
The way it looks, I don't think we can go ahead with this at this stage.
Both result are acceptable to me -- wether we can go ahead or not.
Pausing the transition helps my laziness. Moving forward, although
radical and breaks some questionable rdeps, brings some new features
such as the DNN module which supports not only pre-trained tensorflow
model.
Mo Zhou
2019-09-30 09:10:01 UTC
Reply
Permalink
Hi release team,

Shall we proceed with the opencv transition? The opencv 3.2.0 in
unstable
is too ancient. The automatically generated ben file looks good:

https://release.debian.org/transitions/html/auto-opencv.html

I'm planning to remove the mipsel architecture since it suffers
a lot from OOM issue during compilation, so please ignore the FTBFS
on mipsel:
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental

AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due
to
API changes or header path change.
I have already filed FTBFS bugs against those correcponding packages
when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think
the result won't be different.
Post by Mo Zhou
I haven't had enough time to test rdeps for another round. But I guess
the situation would be similar to the first round.
#915544 suggests the OpenCV C API is broken, and ffmpeg solved it by disabling
ffmpeg support altogether.
#915709 seems to point to the same brokenness.
https://github.com/opencv/opencv/issues/10963#issuecomment-369259044
| OpenCV 3.x doesn't not support C compilation mode officially.
And if you look at upstream Pull Requests you will find that upstream
is gradually removing legacy C APIs.
So, those rdeps broken due to the C API are questionable because they
are using non-officially supported (deprecated) part of opencv ...
There are another failing pattern, which stems from changes in C++ class
method, and is easy to fix ...
I'm currently putting out the fire on the julia package so I cannot
make a statistics.
The way it looks, I don't think we can go ahead with this at this stage.
Both result are acceptable to me -- wether we can go ahead or not.
Pausing the transition helps my laziness. Moving forward, although
radical and breaks some questionable rdeps, brings some new features
such as the DNN module which supports not only pre-trained tensorflow
model.
Mo Zhou
2019-10-09 11:30:03 UTC
Reply
Permalink
ping?
Post by Mo Zhou
Hi release team,
Shall we proceed with the opencv transition? The opencv 3.2.0 in
unstable
https://release.debian.org/transitions/html/auto-opencv.html
I'm planning to remove the mipsel architecture since it suffers
a lot from OOM issue during compilation, so please ignore the FTBFS
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental
AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due
to
API changes or header path change.
I have already filed FTBFS bugs against those correcponding packages
when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think
the result won't be different.
Post by Mo Zhou
I haven't had enough time to test rdeps for another round. But I guess
the situation would be similar to the first round.
#915544 suggests the OpenCV C API is broken, and ffmpeg solved it by disabling
ffmpeg support altogether.
#915709 seems to point to the same brokenness.
https://github.com/opencv/opencv/issues/10963#issuecomment-369259044
| OpenCV 3.x doesn't not support C compilation mode officially.
And if you look at upstream Pull Requests you will find that upstream
is gradually removing legacy C APIs.
So, those rdeps broken due to the C API are questionable because they
are using non-officially supported (deprecated) part of opencv ...
There are another failing pattern, which stems from changes in C++ class
method, and is easy to fix ...
I'm currently putting out the fire on the julia package so I cannot
make a statistics.
The way it looks, I don't think we can go ahead with this at this stage.
Both result are acceptable to me -- wether we can go ahead or not.
Pausing the transition helps my laziness. Moving forward, although
radical and breaks some questionable rdeps, brings some new features
such as the DNN module which supports not only pre-trained tensorflow
model.
Paul Gevers
2019-10-10 11:10:01 UTC
Reply
Permalink
Control: block -1 by 922566
Control: block -1 by 922569
Control: block -1 by 922570
Control: block -1 by 922573
Control: block -1 by 922574
Control: block -1 by 922578
Control: block -1 by 922579
Control: block -1 by 922582
Control: block -1 by 922583
Control: block -1 by 922584
Control: block -1 by 922585
Control: block -1 by 922586
Control: block -1 by 922587
Control: block -1 by 922588
Control: block -1 by 922589
Control: block -1 by 922590
Control: block -1 by 922591
Control: block -1 by 922592
Control: block -1 by 922593
Control: block -1 by 922595
Control: block -1 by 922596
Control: block -1 by 922597
Control: block -1 by 922600
Control: tags -1 - moreinfo

Hi Mo,
Post by Mo Zhou
Shall we proceed with the opencv transition? The opencv 3.2.0 in
unstable
https://release.debian.org/transitions/html/auto-opencv.html
I'm planning to remove the mipsel architecture since it suffers
a lot from OOM issue during compilation, so please ignore the FTBFS
https://buildd.debian.org/status/package.php?p=opencv&suite=experimental
Make sure you involve ftp-master straight away when you upload.
Post by Mo Zhou
AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due
to
API changes or header path change.
I have already filed FTBFS bugs against those correcponding packages
when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think
the result won't be different.
Could you please check that I have found all these bugs that you filed?
Please add any that I missed.

Although the tracker doesn't show any collision, I'd like to finish the
perl transition first. Please go ahead when perl 5.30 migrates to
testing. Once uploaded raise the severity of all those FTBFS bugs.

Paul
Mo Zhou
2019-10-11 06:40:02 UTC
Reply
Permalink
Control: block -1 by 915708
Control: block -1 by 915711
Control: block -1 by 915712
Post by Paul Gevers
Post by Mo Zhou
AFAIK opencv 3.x -> 4.x breaks nearly all the reverse dependencies, due
to
API changes or header path change.
I have already filed FTBFS bugs against those correcponding packages
when opencv 4.0.1 landed onto experimental. Now it's 4.1.1 and I think
the result won't be different.
Could you please check that I have found all these bugs that you filed?
Please add any that I missed.
I've added 3 missing blockers.
Post by Paul Gevers
Although the tracker doesn't show any collision, I'd like to finish the
perl transition first. Please go ahead when perl 5.30 migrates to
testing. Once uploaded raise the severity of all those FTBFS bugs.
Got it. I'll postpone the unstable upload until the perl transition
is finished.

Loading...