On 2026/02/14 09:33, Sebastian Reitenbach wrote: > Hi Stuart, > > this makes the port much easier. > How about the version attached: I left the solution to run the tests in, but > skipped any > setup.py patches and fiddling, so it builds against the bundled versions.
Please leave the MODULES=gnu line, if that is commented-out it will cause problems for DPB builds (it passes in the autoconf cache file, which stops autoconf from looking for gmkdir, gawk, etc) . With that, ok. > > cheers, > Sebastian > > > On Fri, Feb 13, 2026 at 12:58 PM Stuart Henderson <[email protected]> > wrote: > > On 2026/02/12 10:24, Sebastian Reitenbach wrote: > > I think it might be better to bring back the patch and fix > things so > > that it builds against ports sleuthkit rather than the bundled > one, > > but I didn't see how to do that. > > > > I totally overlooked, that the directory contains a bundled version, > and ln -s > > silently fails :/ > > I managed to integrate this with the version we have in the ports tree > by using > > sleuthkit:configure instead of sleuthkit:patch. As I see it now, this > builds > > using our version in Ports. The two should probably always be updated > in-sync > > with each other anyways. > > I figured, with libtalloc it's the same, so I re-introduced the > setup.py patch, > > and was able to build/link against installed libtalloc. > > I didn't manage to do the same with the sleuthkit :/ > > reflecting on this some more, for other ports where there's a Python > binding for a library, where they want to allow it being built against > a 'system' version they usually have something specific in their build > system to allow it, and this doesn't. > > in this case, I think it may be best to roll with what upstream are > doing, and just use their bundled versions of both sleuthkit/talloc. > >
