opencv-2.4.9 is available (for awhile), and seems to be a requirement for newer versions of digikam. Looks like the update should be straight forward, only one patch (ts_static) patch needs rebasing. I've got it prep'd, and did a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=7088732
Created attachment 913205 [details] update to 2.4.9
(approximate patch anyway, it doesnt include new/cleaned sources)
*** Bug 1114375 has been marked as a duplicate of this bug. ***
See https://projects.kde.org/projects/extragear/libs/libkface/repository/revisions/4662dd94102f8144bc65ce1cb66d6b6cb1d500fd Can it be updated also for F20?
Not for F20 in the same update. Please let the update settle in devel,then I will revisit the update for F-20. (not yet looked at opencv git at this step - but uptream isn't always at keeping ABI)
Rex, your patch miss the rebased ts_static I've only limited time to check. (will check tomorrow).
I think bugzilla may have munged it. I'll upload things to fedorapeople: Here's the pristine patch: http://rdieter.fedorapeople.org/rpms/opencv/0001-2.4.9.patch with all of .spec, .src.rpm, patches: http://rdieter.fedorapeople.org/rpms/opencv/
Fixed in Rawhide, @Rex, there are lot of cmake patches from you (IIRC), can you help upstreaming them in github ?
Only cmake_paths.patch is from me, opencv-pkgcmake.patch predates my involvement, but both should be upstreamable with a little extra work. I've never done the github workflow before, but I should learn sooner or later. So yeah, eventually.
What about update for F20?
Digikam needs to be updated to 4.1.0 in F20 to fix at least bug 1123841, so please update opencv to 2.4.9.
Now on to Digikam 4.2.0, more essential bug fixes and still waiting on opencv 2.4.9. Please provide the update for F20, not just F21. Thanks!
Yet one bug 1128494 fixed in digiKam 4.2.0, but it can't be built because of old opencv in F20.
Hi, I just check openv-2.4.9 and openv-2.4.7 provides same .so versions, so no soname bump , it is safe put in Fedora 20 , and it is needed for not hack digikam rpm -q opencv --provides libopencv_calib3d.so.2.4()(64bit) libopencv_contrib.so.2.4()(64bit) libopencv_features2d.so.2.4()(64bit) libopencv_highgui.so.2.4()(64bit) libopencv_legacy.so.2.4()(64bit) libopencv_objdetect.so.2.4()(64bit) libopencv_ocl.so.2.4()(64bit) libopencv_stitching.so.2.4()(64bit) libopencv_superres.so.2.4()(64bit) libopencv_ts.so.2.4()(64bit) libopencv_videostab.so.2.4()(64bit) opencv = 2.4.9-1.fc20 opencv(x86-64) = 2.4.9-1.fc20 and libopencv_calib3d.so.2.4()(64bit) libopencv_contrib.so.2.4()(64bit) libopencv_features2d.so.2.4()(64bit) libopencv_highgui.so.2.4()(64bit) libopencv_legacy.so.2.4()(64bit) libopencv_objdetect.so.2.4()(64bit) libopencv_ocl.so.2.4()(64bit) libopencv_stitching.so.2.4()(64bit) libopencv_superres.so.2.4()(64bit) libopencv_ts.so.2.4()(64bit) libopencv_videostab.so.2.4()(64bit) opencv = 2.4.7-6.fc20 opencv(x86-64) = 2.4.7-6.fc20
http://upstream.rosalinux.ru/versions/opencv.html shows updates as compatible. Can we get an F20 update now please?
(In reply to Orion Poplawski from comment #15) > http://upstream.rosalinux.ru/versions/opencv.html shows updates as > compatible. Can we get an F20 update now please? I agree with Orion , I request commit access to do update myself ... Thanks,
(In reply to Sergio Monteiro Basto from comment #16) > (In reply to Orion Poplawski from comment #15) > > http://upstream.rosalinux.ru/versions/opencv.html shows updates as > > compatible. Can we get an F20 update now please? Still rpmsodiff exbibits many removed symbols despite the SONAME is the same. I still consider opencv updates (even minor) as unsafe in a release, specially as critical multimedia component rely on it (ffmpeg-libs, many others from known third parties). If one could make a patch that would hide the "internally used symbols" from the rpmsodiff computation, I may consider a version update. But until then I prefer to focus on atomic backports. So if you can find the commit that fix your issue, I could agree to apply. Last, I'm totally open to co-maintainer advices based on contributions (such as updating and testing opencv 2.4.10.1 in devel).
Would this release fix the issue ? https://github.com/Itseez/opencv/archive/2.4.7.2.tar.gz
The main problem (for me) is Digikam 4.1+ that requires opencv 2.4.9. As I don't use or test opencv much, I can't give an valid opinion . but http://upstream.rosalinux.ru/versions/opencv.html says from 2.4.7 to 2.4.8 added 5 symbols and none removed from 2.4.8 to 2.4.9 none added none removed , only 3 symbol problem low http://upstream.rosalinux.ru/compat_reports/opencv/2.4.8_to_2.4.9/abi_compat_report.html#Symbol_Problems_Low
Created attachment 963926 [details] rpmsodiff between 2.4.6.1-1.fc20.x86_64 and 2.4.7-6.fc20.x86_64 Haven't played much with rpmsodiff before. Just for grins, see attached full report between 2.4.6.1-1.fc20.x86_64 and 2.4.7-6.fc20.x86_64 which shows some removals: libopencv_calib3d.so.2.4: 2 symbols removed W _ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPSt4pairIfiESt6vectorIS3_SaIS3_EEEEPFb RKS3_SA_EEvT_SD_SD_T0_ W _ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPSt4pairIifESt6vectorIS3_SaIS3_EEEEPFb RKS3_SA_EEvT_SD_SD_T0_ libopencv_features2d.so.2.4: 2 symbols removed W _ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIP4SIdxSt6vectorIS2_SaIS2_EEEEEvT_S8_S8 _ W _ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPN2cv6DMatchESt6vectorIS3_SaIS3_EEEEEv T_S9_S9_ libopencv_objdetect.so.2.4: 1 symbols removed W _ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPN2cv7linemod5MatchESt6vectorIS4_SaIS4 _EEEEEvT_SA_SA_ libopencv_stitching.so.2.4: 1 symbols removed W _ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPSt4pairImmESt6vectorIS3_SaIS3_EEEEN2c v6detail12DpSeamFinder13ImagePairLessEEvT_SD_SD_T0_ libopencv_ts.so.2.4: 3 symbols removed W _ZN2cv9ExceptionC1ERKS0_ W _ZN2cv9ExceptionC2ERKS0_ W _ZN7testing15AssertionResultlsIA8_cEERS0_RKT_ But upstream-tracker show no symbol removals between those versions. I wonder what is different here.
Created attachment 963927 [details] rpmsodiff between 2.4.7-6.fc20.x86_64 and 2.4.9-4.fc20.x86_6 libopencv_ocl.so.2.4: 18 symbols removed D _ZN2cv3ocl18arithm_bitwise_notE D _ZN2cv3ocl21arithm_bitwise_binaryE D _ZN2cv3ocl26arithm_bitwise_binary_maskE D _ZN2cv3ocl28arithm_bitwise_binary_scalarE D _ZN2cv3ocl33arithm_bitwise_binary_scalar_maskE T _ZN2cv3ocl11ContextImplD1Ev T _ZN2cv3ocl11ContextImplD2Ev T _ZN2cv3ocl17distanceToCentersERNS0_6oclMatES2_RKS1_S4_iS4_ T _ZN2cv3ocl21createDerivFilter_GPUEiiiiii T _ZN2cv3ocl24createGaussianFilter_GPUEiNS_5Size_IiEEddi T _ZN2cv3ocl31createSeparableLinearFilter_GPUEiiRKNS_3MatES3_RKNS_6Point_IiEEdi W _ZSt11__push_heapIN2cv12MatIterator_I9cl_float2EElS2_PFiS2_S2_EEvT_T0_S7_T1_T2_ W _ZSt13__adjust_heapIN2cv12MatIterator_I9cl_float2EElS2_PFiS2_S2_EEvT_T0_S7_T1_T2_ W _ZSt13__heap_selectIN2cv12MatIterator_I9cl_float2EEPFiS2_S2_EEvT_S6_S6_T0_ W _ZSt16__insertion_sortIN2cv12MatIterator_I9cl_float2EEPFiS2_S2_EEvT_S6_T0_ W _ZSt16__introsort_loopIN2cv12MatIterator_I9cl_float2EElPFiS2_S2_EEvT_S6_T0_T1_ W _ZSt22__final_insertion_sortIN2cv12MatIterator_I9cl_float2EEPFiS2_S2_EEvT_S6_T0_ W _ZSt25__unguarded_linear_insertIN2cv12MatIterator_I9cl_float2EEPFiS2_S2_EEvT_T0_
So in comment 20, all symbols are weak symbols, which should not be a problem. D - data, also should not be a problem T - text - could be an issue.
ContextImpl - totally private class to modules/ocl/src/cl_context.cpp. distanceToCenters: opencv-2.4.7/modules/ocl/include/opencv2/ocl/ocl.hpp: CV_EXPORTS void distanceToCenters(oclMat &dists, oclMat &labels, const oclMat &src, const oclMat ¢ers, int distType = NORM_L2SQR, const oclMat &indices = oclMat()); opencv-2.4.9/modules/ocl/include/opencv2/ocl/ocl.hpp: CV_EXPORTS void distanceToCenters(const oclMat &src, const oclMat ¢ers, Mat &dists, Mat &labels, int distType = NORM_L2SQR); this looks like it could be a problem. createDerivFilter_GPU: opencv-2.4.7/modules/ocl/include/opencv2/ocl/ocl.hpp: CV_EXPORTS Ptr<FilterEngine_GPU> createDerivFilter_GPU( int srcType, int dstType, int dx, int dy, int ksize, int borderType = BORDER_DEFAULT ); opencv-2.4.9/modules/ocl/include/opencv2/ocl/ocl.hpp: CV_EXPORTS Ptr<FilterEngine_GPU> createDerivFilter_GPU( int srcType, int dstType, int dx, int dy, int ksize, int borderType = BORDER_DEFAULT, Size imgSize = Size(-1,-1) ); adds an argument with a default. One would hope that the linker could handle this. Same with createGaussianFilter_GPU and createSeparableLinearFilter_GPU. Anyone know for sure?
Upstream commit for the distanceToCenters change - https://github.com/Itseez/opencv/pull/1759
No, the linker cannot handle default arguments. This is source-compatible, but binary-incompatible. The binary-compatible way to handle this would be to use a wrapper overload instead of a default argument.
(And it's a clear bug that upstream does that kind of binary-incompatible changes without a soname bump.)
Fully agree, but it appears the upstream treats the ocl component as unstable/in development and so free to break compatibility. I suspect most applications don't make use of it (digikam at least does not), but currently it appears that applications get linked to all of the opencv_* libraries whether they use them or not (or at least digikam does).
Well, if there isn't anything in Fedora that uses the unstable stuff, then why do we care?
I said *I suspect* - at this point we have no data. We would need to find all *real* users of ocl first.
Created attachment 1024357 [details] update to opencv-2.4.11 Hi, I'm working on update opencv to 2.4.11 , this is a complex package, also is a requirement of ffmpeg-libs, so many packages depend on it. http://upstream-tracker.org/versions/opencv.html show that compatibility is > 99% since opencv-2.4.9 . but Patch0: opencv-pkgcmake.patch and all gst1 doesn't apply to new source. +#patch0 -p1 -b .pkgcmake +#if 0%{?gst1} +#patch10 -p1 -b .10 +#patch11 -p1 -b .11 +#patch12 -p1 -b .12 +#patch13 -p1 -b .13 +#patch14 -p1 -b .14 +#endif So I made opencv-clean-2.4.11.tar.xz archive like we have for 2.4.9 and the patch in attach. Can I apply it on rawhide and after a few days on F22 , before GA ?
Can you test other package that would depend on opencv, specially if they will rebuild cleanly without the commnented out patches ? If they all rebuilt fine (even only in rawhide) I'm fine to update opencv in f22 branch also. (even as f21 later as it seem to be a bugfix updates).
repoquery opencv\* --whatrequires --alldeps --source | perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | sort -u cinnamon digikam fawkes ffmpeg frei0r-plugins libfreenect mlt mrpt nomacs opencfu opencv php-facedetect player python-SimpleCV shogun simarrange simon vlc repoquery --qf "%{repoid} %{name}-%{version}-%{release}" `cat list3` | sort -u fedora fawkes-0.5.0-19.fc21 fedora frei0r-plugins-1.4-3.fc21 fedora opencfu-3.8.11-3.fc21 fedora opencv-2.4.9-3.fc21 fedora php-facedetect-1.0.1-13.fc21 fedora simarrange-0.0-5.20140729git9500190.fc21 fedora simon-0.4.1-2.fc21 rpmfusion-free-updates ffmpeg-2.4.9-1.fc21 rpmfusion-free-updates mlt-0.9.6-2.fc21 rpmfusion-free-updates-testing vlc-2.2.1-5.fc21 updates cinnamon-2.4.8-1.fc21 updates digikam-4.9.0-1.fc21 updates libfreenect-0.5.2-2.fc21 updates nomacs-2.4.2-2.fc21 updates player-3.0.2-39.fc21 updates python-SimpleCV-1.3-4.fc21 updates shogun-4.0.0-1.fc21 to much things to test ... , I need suggestions ?
Cinnamon can be ignored as it only uses opencv-python so no rebuild needed.
OK Thanks, so just depends on opencv-core opencv : repoquery opencv-core opencv --whatrequires --alldeps --source | perl -pe 's/-\d.*?-\d+(\..*)?\.fc\d+(\..*)?.src.rpm//' | sort -u | xargs repoquery --qf "%{repoid} %{name}-%{version}-%{release}" | sort -u fedora fawkes-0.5.0-19.fc21 fedora frei0r-plugins-1.4-3.fc21 fedora opencfu-3.8.11-3.fc21 fedora opencv-2.4.9-3.fc21 fedora php-facedetect-1.0.1-13.fc21 fedora simarrange-0.0-5.20140729git9500190.fc21 fedora simon-0.4.1-2.fc21 rpmfusion-free-updates ffmpeg-2.4.9-1.fc21 rpmfusion-free-updates mlt-0.9.6-2.fc21 rpmfusion-free-updates-testing vlc-2.2.1-5.fc21 updates digikam-4.9.0-1.fc21 updates libfreenect-0.5.2-2.fc21 updates nomacs-2.4.2-2.fc21 updates player-3.0.2-39.fc21
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.