GNU bug report logs - #62954
Valgrind blocks R on powerpc64le

Previous Next

Full log

Message #8 received at 62954 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Andreas Enge <andreas <at> enge.fr>, 62954 <at> debbugs.gnu.org
Subject: Re: bug#62954: Valgrind blocks R on powerpc64le
Date: Thu, 20 Apr 2023 13:26:37 +0200

Hi,

On mer., 19 avril 2023 at 22:08, Andreas Enge <andreas <at> 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 <at> 4.2.3
texlive-updmap.cfg <at> 59745
texlive-latex-xkeyval <at> 59745
texlive-pgf <at> 59745
texlive-ms <at> 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 <at> 4.2.3' to 'valgrind <at> 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 <at> 1.24.0
r-multidplyr <at> 0.1.3
r-cistopic-next <at> 0.3.0-1.04cecbb
r-cistopic <at> 2.1.0
r-chromunity <at> 0.0.1-1.09fce8b
r-cicero-monocle3 <at> 1.3.2-1.fa2fb65
r-tmaptools <at> 3.1-1
r-zonebuilder <at> 0.0.2
r-chipseeker <at> 1.34.1
r-snapatac <at> 2.0
r-rastervis <at> 0.51.5
r-insol <at> 1.2.2
r-bien <at> 1.2.6
r-sungeo <at> 0.2.292
r-leaflet <at> 2.1.2
r-spectre <at> 0.5.5-1.f6648ab
r-zonator <at> 0.6.0
r-zoon <at> 0.6.5
r-biocdockermanager <at> 1.10.0
r-irkernel <at> 1.3.2
r-prereg <at> 0.6.0
r-doubletcollection <at> 1.1.0-1.c0d62f1
r-rmpi <at> 0.7-1
r-pbdmpi <at> 0.4-6
r-torch <at> 0.10.0
r-ctrdata <at> 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 <at> 1.6
     37 qtwebengine <at> 5.15.8
     39 openmpi <at> 4.1.4
     45 dtc <at> 1.6.1
    405 lz4 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.