Am Thu, Apr 20, 2023 at 01:26:37PM +0200 schrieb Simon Tournier: > shows that most of the paths do not involve texlive-ms. Instead, it > seems related to lz4 or openmpi or jq.
So I start to understand. lz4 depends on valgrind. I do not know why. It is given as a native input, so probably the tests require valgrind? If yes, that looks a bit excessive to me - the developers of lz4 are very welcome to check for memory leaks from time to time, but doing this at every compilation is excessive. What do you think of dropping the valgrind input (at the same time as updating valgrind, say)? It does not seem to be necessary, as it is already dropped on architectures that do not provide it, without further ado. Maybe this is what hides it from "guix refresh" and "guix graph"? Then texlive-ms depends on lz4 and indirectly on valgrind: $ ./pre-inst-env guix build --system=powerpc64le-linux texlive-ms -n /gnu/store/j0wzdc36vvgvj4zh49a71sc115m6m76b-texlive-ms-59745.drv /gnu/store/jl6p6m1zngi1rjl2808zvnb9wpiphhjf-texlive-ms-59745-checkout.drv /gnu/store/gfkdb5pys2b8dr2mqgs5gbwfflwlc4kh-subversion-1.14.2.drv /gnu/store/xw5kdli3i92iwd7wpplcb0p89g1p3a29-lz4-1.9.3.drv /gnu/store/z6kf2pg48b9a87angabkfyfv4knhhwjy-valgrind-3.17.0.drv More precisely: texlive-ms is downloaded via subversion via simple-texlive-package in (gnu packages texlive), which relies on texlive-origin from (guix build-system texlive). $ ./pre-inst-env guix build --system=powerpc64le-linux subversion -n The following derivations would be built: /gnu/store/gfkdb5pys2b8dr2mqgs5gbwfflwlc4kh-subversion-1.14.2.drv /gnu/store/xw5kdli3i92iwd7wpplcb0p89g1p3a29-lz4-1.9.3.drv /gnu/store/z6kf2pg48b9a87angabkfyfv4knhhwjy-valgrind-3.17.0.drv So subversion depends on valgrind! And all new simplex-texlive-packages are concerned. I think the solution is to indeed remove valgrind from the native inputs of lz4. And I think there is a shortcoming in "guix refresh" that it does not take the source code of packages into account. What do you think? Andreas
