Hi Sören,

On 2024-03-10 21:12, Sören Tempel wrote:
> I don't think there is an issue with the binaries. angr is a binary
> analysis tools. Naturally, the test suite will need sample binaries
> for testing purposes. The GNU FSDG has an explicit clause regarding
> "non-functional data", I believe this very much applies here as these
> binaries are not executed and only needed for testing angr's analysis
> capabilities. Without the binaries there are no tests to run for angr.
> I would strongly advocate for not disabling the angr test suite as
> running it on Guix has resulted in the discovery bugs both in angr
> and in capstone [1, 2].

Thanks for finding some references. I also found Poppler ran into a
similar problem [1]. I am in favour of having these tests too, but I
think the difficult part will be the licensing. AFAIK we would have to
make sure all binaries that are included can be freely distributed.

I had a quick look and most (if not all) binaries are free. I would also
assume, if the angr authors are distributing the binaries in this way,
it should very likely be fine. I will have a more in-depth look the
coming week, feel free to do so as well.

By the way, I see the tests for python-cle require binaries. Are these
the same binaries as used for the python-angr tests? I didn't try it
out, but if so, it might be possible to run those tests during the build
as well.

> Newer version of angr will require an update of the python-rich and
> python-pygments Guix package. Since this would entail a lot of rebuilds
> (and the upstream integration of the present changeset has already been
> quite effortful), I opted for packaging an "older" version of angr for
> now which does not depend on python-rich yet. As soon as python-rich and
> python-pygments are updated, we can update angr too.

Sounds good!

> This is intended, all of these packages are distributed by the angr
> development team and need to be set to the same version as angr itself.
> I added a corresponding comment.

Super!

> With the exception of one patch these are all upstreamed patches. I
> don't want to package unreleased Git versions of these packages and
> I think it's therefore preferable to just backport the bug fixes. Also
> consider that angr is very sensitive to versions of packages distributed
> by angr developers (see the prior comment).

Fair enough, I see all patches that come from commits and PRs have a
reference, so it shouldn't be too hard to check whether they should be
removed/updated when updating the package version.

> What is left to do in order to get this merged?

We have to find someone with commit rights :-) I pinged the Python team
before, but might be good to do so again once we are sure about the
licensing of the binaries. I will keep you posted. The rest LGTM.

Best wishes,

Troy

[1] https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00394.html