* Package name : boofcv Version : 0.40.1 Upstream Author : Peter Abeles <peter.abeles@gmail.com> * URL or Web page : http://boofcv.org * License : Apache-2.0 Description : Real-time computer vision library This is for the BoofCV library for computer vision. Andrius: you packaged some of the dependencies of BoofCV, and you mentioned that you were interested in getting BoofCV itself into Debian. Are you still interested in doing that? If you already looked into it, can you share any specific challenges that you hit when trying to package this library? I spoke to the upstream dev (Peter Abeles, Cc-ed), and he's potentially interested in helping with this effort. The 3 of us should be able to get this done. Thanks
Hi Dima, Thanks for an ITP. I am also interested in getting BoofCV into Debian due to one of my interests, Cephis, depending on BoofCV. I recall running into obstacles beyond my capabilities, thus I dropped the ball. Nevertheless I would be happy to revive the effort. One of the obstacles I faced was the Gradle build system. Gradle in Debian is several major releases old, and sources usually quite tightly depend on it. Moreover, I do not have much experience with Gradle in Debian, thus back then I used to spend much time patching the build. Also I got quite many problems with dependencies. Some were difficult to package for Debian, some were even non-free (if I recall right) and some just caused FTBFS possibly due to API changes. Sorry for the vagueness, this was in 2019 and I did not leave much self-notes on this. I ended up patching many submodules due to the problems with dependencies. I have my packaging at hand and I will push it once Salsa becomes online again. I will use my personal namespace. I will let you know when this is done. It is great that you have contacted Peter Abeles about BoofCV. It would surely be great to have Peter's help. However, I am afraid we may have to start by looking into updating Gradle in Debian. Best, Andrius
Hi Andrius, Good to meet you and thanks for the first attempt at getting BoofCV in Debian. To keep things simple, that approach that I'm thinking of is to add "libboofcv-core" to Debian first, which has all the core functionality and can be added to a project now by referencing "boofcv-core" module, which just references several other modules in BoofCV. You might have already added all the required external dependencies. The end goal is to get "BoofCV Applications" into debian. If you strip away video and webcam support it would be much easier, but less functional. Also need to add some tooling to make it more user friendly from a command line. Code modifications will probably be needed to fail gracefully if something is missing. Question: Does your use case require anything outside of "core"? Now on to Gradle. How ancient is Gradle in Debian? BoofCV recently upgraded to Gradle 7 to fix IntelliJ integration issues. Downgrading to Gradle 5 is possible. The main reason it was updated was for support of automatic JDK downloading. Prior to that upgrade, there had been a lot of confusion where people would try building it with an ancient JDK and getting cryptic error messages. I'm hoping to stick with Gradle 7 on my projects for a while. Cheers, - Peter
This is probably a dumb question since I don't know anything about java build systems, but I'll ask it anyway. Most build systems think about: - Which commands are needed to build stuff - Which commands are needed to rebuild stuff (if some artifacts are built already or if we're not building everything) - Obtaining and/or verifying dependencies When building a package for Debian, we only care about the first one of these. debian/control defines the Build-Depends, so once the build system runs, the dependencies are all in place (and if they aren't, we need to fix debian/control, which is not the build system's responsibility). And the build happens just once, so we always start at zero, and we don't need to care about rebuilds. Given this, would it be reasonable to distro-patch all the gradle stuff away, and to co-maintain a parallel (and really simple) build that is mostly a glorified script or better yet, a GNU Makefile, or something? If everything that gradle does boils down to a bunch of "javac" invocations and some "cp" commands to install stuff, then this could be a viable approach. Since this would be a separate, independent build system, this only makes sense if it's REALLY simple, and I don't know enough about gradle or boofcv to answer that. If this doesn't sound too crazy for this project, and if somebody can tell me how to get the "javac" commands, I can put something together. Peter: if I do the build as described in the instructions, using the "gradlew" commands, and I grep the log for "javac", would that give me the bulk of the commands that are needed? What else is needed other than the "javac" commands?
Hello, I have pushed my packaging to Salsa: https://salsa.debian.org/merkys/boofcv I will try to dust it off a bit. Best, Andrius
Based on Dima's comments. Is there any reason we can't just use the Gradle Wrapper? That way each project can use the version of Gradle it works with instead of single version for all projects. The only reason I see to not use Gradle wrapper is because it will download its dependencies and maybe for some reason that's not allowed. BoofCV does have a complex build system because it auto generates code. So you would need to download the jars the auto generate system needs then build a few classes. Now you're ready to create all the code you need for this library. At this point, you can in theory javac the entire project as Dima suggested. Assuming we don't care about mirroring the jar files that are published on Maven central. This would be equivalent of making one large .so instead of 15 little .so. If the end goal is some of the tools included with BoofCV (e.g. calibration and batch scanning of 2d barcodes) into Debian then that's perfectly fine. My preference is using gradle wrapper since that's the least amount of effort for me to do and it's easy to mangle the existing build system. Peter: if I do the build as described in the instructions, using the Hmm been a while since I've used javac directly. Probably the easiest way would be to get a file list using "find" and seeing if it blows up when you give it several hundred files or so. - Peter P.S. I'm going to be a bit erratic when I reply for the next couple of weeks at least.
Dear Peter and Dima, Sorry for the delay. Somehow I did not receive any mails sent to 1006621@bugs.debian.org (will subscribe), thus I only now noticed your conversation after accidentally revisiting the bug page. Good to meet you too, Peter! First of all, regarding Cephis, my original reason to package BoofCV. It depends on io, feature and visualize modules of BoofCV v0.17. AFAIK, these should be static image analysis tools, thus stripping away more complicated video and webcam support should make things much easier for now. Of course, in the long run it would be nice to support video and webcam parts of BoofCV in Debian as well. Regarding Gradle. Debian has 4.4.1 now and updating it is complicated. It would be nice to ask its maintainers in Debian to understand what are the current blockers. Gradle wrapper cannot be used as downloads in the build time are not allowed in Debian. Even more generally, Debian builds can only rely on software which is built from source on Debian build machines. For now I see upgrading Gradle in Debian as the best solution to the build issue. Simplifying/changing the build system is a viable solution too, but I believe this would need much work and add maintenance burden on Peter. Discussion in [1] gives me some hope Gradle will be updated soon. I think it is worth pinging its participants. Peter, you mention BoofCV build system downloading some JARs. Maybe we could build these JARs in Debian as separate packages and use them in BoofCV build? If Gradle blocker goes away, these might be the next blockers. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926714 Best wishes, Andrius
Instead of updating the "gradle" command could we just install a new "gradle7" command that points to Gradle 7 instead? I don't think Gradle is very backwards compatible so that might be the easiest solution. For Jars that BoofCV downloads, It doesn't download anything outside of Gradle. It uses a Gradle plugin i created called gversion to automatically generate version info and a set of tools to do other auto generation tasks: https://plugins.gradle.org/plugin/com.peterabeles.gversion https://github.com/lessthanoptimal/Auto64Fto32F Once the Gradle issue gets resolved we could then start adding these dependencies. Cheers, - Peter
Hi Peter, Thanks for prompt reply. This would not help, I am afraid. Point with Gradle is that it needs itself to build newer versions of Gradle (circular dependency on itself), thus iteratively updating Gradle seems to be the only way to have newer Gradle in Debian. Debian does not do out-of-git builds (.git directory is removed from sources prior to build), thus I guess this plugin would not be of much use (but I may be wrong). Nevertheless Debian precisely tracks source versions, thus version string could be injected via other means. This one I have already packaged for Debian, so the packaged JAR could be used. Sure. Best wishes, Andrius
Hopefully a 1000 projects don't need to be updated from Gradle 4 to Gradle 7! Still required since it creates a BoofVersion.java file that's needed. If it can't find Git information it fills in that field with blank or unknown. Cheers, - Peter