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 <stu@spacehopper.org> 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.
> 
>