bug#62954: Valgrind blocks R on powerpc64le

[Simon Tournier]

Hi,

On mer., 19 avril 2023 at 22:08, Andreas Enge <andreas@enge.fr> wrote:

> Currently r-minimal depends on texlive-latex-xkeyval, which depends on
> texlive-ms, which for a reason I do not see pulls in the valgrind variable.

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix graph --path r-minimal texlive-ms
r-minimal@4.2.3
texlive-updmap.cfg@59745
texlive-latex-xkeyval@59745
texlive-pgf@59745
texlive-ms@59745
--8<---------------cut here---------------end--------------->8---

But I do not see either how valgrind enters in the picture as a
dependency for r-minimal,

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix graph --path r-minimal -e '(@@ (gnu packages valgrind) 
valgrind)' -t bag -s powerpc64le-linux
guix graph: error: no path from 'r-minimal@4.2.3' to 'valgrind@3.17.0'
--8<---------------cut here---------------end--------------->8---

However, please note:

--8<---------------cut here---------------start------------->8---
$ for p in $(./pre-inst-env guix refresh -l -e '(@@ (gnu packages valgrind) 
valgrind)' | cut -f2 -d':'); do echo $p ;done | grep '^r\-'
r-bigmelon@1.24.0
r-multidplyr@0.1.3
r-cistopic-next@0.3.0-1.04cecbb
r-cistopic@2.1.0
r-chromunity@0.0.1-1.09fce8b
r-cicero-monocle3@1.3.2-1.fa2fb65
r-tmaptools@3.1-1
r-zonebuilder@0.0.2
r-chipseeker@1.34.1
r-snapatac@2.0
r-rastervis@0.51.5
r-insol@1.2.2
r-bien@1.2.6
r-sungeo@0.2.292
r-leaflet@2.1.2
r-spectre@0.5.5-1.f6648ab
r-zonator@0.6.0
r-zoon@0.6.5
r-biocdockermanager@1.10.0
r-irkernel@1.3.2
r-prereg@0.6.0
r-doubletcollection@1.1.0-1.c0d62f1
r-rmpi@0.7-1
r-pbdmpi@0.4-6
r-torch@0.10.0
r-ctrdata@1.12.1
--8<---------------cut here---------------end--------------->8---

and I guess that’s what you are observing.  Somehow, something like,

--8<---------------cut here---------------start------------->8---
for q in $(for p in $(./pre-inst-env guix refresh -l -e '(@@ (gnu packages 
valgrind) valgrind)' | cut -f2 -d':' | sort); do echo $p ;done | grep '^r\-'); 
do  echo "# $q";./pre-inst-env guix graph --path $q -e '(@@ (gnu packages 
valgrind) valgrind)' ;done | grep -B 2 valgrind
--8<---------------cut here---------------end--------------->8---

shows that most of the paths do not involve texlive-ms.  Instead, it
seems related to lz4 or openmpi or jq.

> This is at version 3.17, which fails on powerpc64le. The user facing
> variable valgrind/interactive, however, is at 3.20, and it builds.

As far I can see, it is hard to cross-compile since substitutes are
missing.  Well, maybe the CI is not building them.  I do not know.


> After the impending core-updates merge, we should update valgrind to
> 3.20.

Note the update of valgrind is not “so much“. :-)

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix refresh -l -e '(@@ (gnu packages valgrind) valgrind)' | 
cut -f1 -d':'
Building the following 569 packages would ensure 1169 dependent packages are 
rebuilt
--8<---------------cut here---------------end--------------->8---

Well, some packages are intensive to rebuild as ungoogled-chromium but I
guess that if these:

     23 jq@1.6
     37 qtwebengine@5.15.8
     39 openmpi@4.1.4
     45 dtc@1.6.1
    405 lz4@1.9.3

passes with valgrind at 3.20, we should almost be good, IMHO. :-)

Most of the 569 packages are rebuilt because lz4 is rebuild.  Well, I am
giving a try… If it is not part of the next core-updates merge, then
using a feature branch building the substitutes, the update of valgrind
could go to master. ;-)


Cheers,
simon