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.
>
>
No comments:
Post a Comment