A lot of code seems to depend on these modules (for instance libkface requires the facial recognition module from opencv2). It would be best to make an optional use flag for openCV that pulls in to the opencv-contrib repo. See here: http://code.opencv.org/projects/opencv/wiki/ChangeLog Otherwise, a lot of OpenCV's functionality some may have considered core (though evidently upstream does not) is absent from the library. Reproducible: Always
(In reply to Adam Stylinski from comment #0) > A lot of code seems to depend on these modules (for instance libkface > requires the facial recognition module from opencv2). It would be best to > make an optional use flag for openCV that pulls in to the opencv-contrib > repo. See here: > > http://code.opencv.org/projects/opencv/wiki/ChangeLog > > Otherwise, a lot of OpenCV's functionality some may have considered core > (though evidently upstream does not) is absent from the library. > > Reproducible: Always Yes, Changelog looks very nice. But can you please tell me what exactly do you want from us? I got from it that you want some opencvcontrib useflag for opencv which pulls the repo ??????? And that libkface example? What do you mean? If you want them to add support for opencv just fill a bug. Amy
Yes on the former, I planned on writing a patch for upstream on the latter. It would just be nice if the ebuild for opencv had a contrib use flag that would optionally bring down the code and compile and install it. That way I don't have compile a temporary out of portage copy of opencv for my work.
Created attachment 409310 [details] Ebuild which has contrib option Here, I'll attach the ebuild I just modified to do this for my local overlay.
(In reply to Adam Stylinski from comment #3) > Created attachment 409310 [details] > Ebuild which has contrib option > > Here, I'll attach the ebuild I just modified to do this for my local overlay. It should work now. Can you please test it? Thanks. Amy
Looks good to me, but with a a couple of caveats: The disabling of CUDA for GCC's >=4.8 I don't believe is valid anymore, CUDA 7.0 and higher have support for I think up to gcc 4.9 (I've disabled this in my local overlay and it works just fine with the exception of the nvcc falling apart when ccache is enabled). So that can probably be bumped up to 5 for the gcc version check. Another thing to note: the source that is being pulled in from is a zip archive that is generated by Github based on the contents of the master repo. They don't seem to have versioned branches for it, so at some point in the future the digests most likely will be wrong as the source could be different. I don't know of a more consistent source archive mirrored on the web, though. The obvious option would be to name the zip archive something that reflects the date and time of the download and host the zip archive on Gentoo's mirrors.
(In reply to Adam Stylinski from comment #5) > Looks good to me, but with a a couple of caveats: > > The disabling of CUDA for GCC's >=4.8 I don't believe is valid anymore, CUDA > 7.0 and higher have support for I think up to gcc 4.9 (I've disabled this in > my local overlay and it works just fine with the exception of the nvcc > falling apart when ccache is enabled). So that can probably be bumped up to > 5 for the gcc version check. Ok I will look at it. > > Another thing to note: the source that is being pulled in from is a zip > archive that is generated by Github based on the contents of the master > repo. They don't seem to have versioned branches for it, so at some point > in the future the digests most likely will be wrong as the source could be > different. I don't know of a more consistent source archive mirrored on the > web, though. The obvious option would be to name the zip archive something > that reflects the date and time of the download and host the zip archive on > Gentoo's mirrors. Well solved. Next time it would be probably more professional to say so before sending me an updated ebuild. Thanks anyway.. Amy
Sorry about that, I meant to mention it in the initial upload of the ebuild. I considered making a mirror somewhere on the internet but I figured that would be bad form.
Np.:) Problem with cuda is that I don't really use it so I can't test it and Andreas the same. So well I will try to find someone in kde team or you can help maybe? Amy
For the Digikam stuff, I have a patch that works for libkface and digikam but I still need to do some more testing with it. A big boy from RedHat stepped in and contributed more to my patch, he caught something I hadn't (there was initial data that wasn't being sourced in located in the /usr/share/OpenCV subdirectory). I suspect this was the main cause for the issues I was observing in face detection. I'd watch the upstream patches on the bug report (https://bugs.kde.org/show_bug.cgi?id=349601), I suspect Viktor's two patches (to digikam & libkface) will work and we can include them pretty soon until upstream has official patches. You'd have to get in touch with the ebuild maintainers for media-libs/libkface and media-gfx/digikam for that. There are probably other ebuilds / packages that could be broken due to this version bump, but none that I seem to have installed. I can help test the CUDA stuff if you'd like. Their CMake configuration doesn't seem to play friendly when paired with nvcc and ccache, but that's a pretty trivial fix (not sure if there's a mechanism for blacklisting ebuilds from ccache but there really ought to be).
