This package deliberately bundles a bunch of libraries. Apparently some of them with TODO to package them... java? ( http://repo1.maven.org/maven2/org/xerial/sqlite-jdbc/3.8.11/sqlite-jdbc-3.8.11.jar http://repo1.maven.org/maven2/com/zaxxer/SparseBitSet/1.1/SparseBitSet-1.1.jar ) ewf? ( https://dev.gentoo.org/~gokturk/distfiles/app-forensics/libewf/libewf-20130128.tar.gz )"
Hi, The libraries sqlite-jdbc and SparseBitSet don't exist in the tree. I've been meaning to add them to the tree. I'm not a java developer, so I need to set aside time to understand ant, maven, ivy a bit more in detail to properly package those. I work two research projects now and I really don't have the time. To move things forward, I've created maintainer-wanted bugs for those (#690010 and #690012) in case someone more knowledgable can get it done faster. About libewf, the situation is a bit more complex. Sleuthkit depends on libewf 20130128, which is quite old but still was in the tree. That is until Pacho decided to treeclean it (see commit 37d9e41ab5c6fb2031aefdeb7af72a7354472031). As a compromise, I've decided to compile a local copy of libewf as part of the sleuthkit build and let the treecleaning continue. Note that we are not shipping a prebuilt libewf, it does get compiled from source. I've checked the MITRE for libewf vulnerabilities to make sure that we are not installing vulnerable software to users' systems. In the meantime, radhermit bumped libewf (see commit 750940bd218774fa8ce3ca0c65894b99dfde48c1) and stopped libewf from being treecleaned. I didn't realize this until after the libewf version sleuthkit depends on got removed (see commit 706e2ada58a2c9c18e3c8f0ace2b6dbf6e562b75). Right now, we have a couple of options: 1) Add back the libewf version sleuthkit depends on to app-forensics/libewf 2) Reintroduce the libewf version sleuthkit depends on as libewf-legacy until the upstream transitions to the latest version of libewf (see https://github.com/sleuthkit/sleuthkit/issues/642) 3) Keep things as-is until the upstream transitions to the latest version of libewf. There are no other packages that depend on this version of libewf. We are statically linking against the local copy, so no libewf sofile is being installed. Build time of libewf is small compared to that of sleuthkit, so the overhead of having to rebuild with every bump is rather small. Once the upstream transition is complete, we can establish the proper DEPEND structure.
Created attachment 720816 [details, diff] sleuthkit-4.10.1-unbundle.patch i just unbundled the deps (that we have now) for your convenience. sleuthkit compiles fine. i did not test runtime though. also, it compiles fine with java 11 so i lessened the java restriction. and finally, there is no need to specify both jre and jdk for the runtime, specifying jre is sufficient. and finally, you can also try to compile sleuthkit without commons-validator, it seems it might not be needed in the end (as reported by an emerge hook here).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=04ab922842c1f5e18aef9a268dfd7e177b8da024 commit 04ab922842c1f5e18aef9a268dfd7e177b8da024 Author: Göktürk Yüksek <gokturk@gentoo.org> AuthorDate: 2021-08-09 21:42:30 +0000 Commit: Göktürk Yüksek <gokturk@gentoo.org> CommitDate: 2021-08-09 23:16:08 +0000 app-forensics/sleuthkit: unbundle commons-validator and gson Also bump to EAPI7 Bug: https://bugs.gentoo.org/689752 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Göktürk Yüksek <gokturk@gentoo.org> app-forensics/sleuthkit/sleuthkit-4.10.1-r4.ebuild | 296 +++++++++++++++++++++ 1 file changed, 296 insertions(+)
