Hi Emmanuel, On lun., 25 mars 2024 at 11:13, Emmanuel Medernach <Emmanuel.Medernach@iphc.cnrs.fr> wrote: >>> Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build --no-grafts tensorflow -d >>> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv >>> Machine_B # guix time-machine -q -C ~/.config/guix/channels.scm -- build --no-grafts tensorflow -d >>> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv [...] > Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow -d --no-grafts > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv Well, If I open the derivation /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv the header reads: --8<---------------cut here---------------start------------->8--- Derive ([("out","/gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1","","") ,("python","/gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python","","")] --8<---------------cut here---------------end--------------->8--- And you get: > Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow --no-grafts > /gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1 > /gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python Therefore, all seems consistent. IIUC, it is also consistent on both machines (see quote above from earlier message). It means that the manual “--no-grafts” is OK. The question is thus, is this derivation: > Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow -d > /gnu/store/vivxpmrpkh1wq5pnw28vq9c51qd3vwf6-tensorflow-2.13.1.drv built using /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv or using another one? Anyway. :-) Now, if I run on my laptop: --8<---------------cut here---------------start------------->8--- $ guix time-machine -q -C channels.scm -- build tensorflow@2.13 -n [...] The following derivations would be built: /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv /gnu/store/8jfr297mkpv698d4y1cq270a7f03wyh6-bazel-6.3.2.drv /gnu/store/g90vfnx128ifhgy0n1zmlscjrn57l8xm-tensorflow-2.13.1-bazel-deps.tar.xz.drv /gnu/store/h3zcigb52z7m6yyjl785w3a5ls1cjjc7-python-jax-0.4.20.drv /gnu/store/h9m0ix80glph19k4pfqh130nmkil8f39-python-jaxlib-0.4.20.drv /gnu/store/m4icdavpvbryliz34ai8817bb1d3l3xr-python-jaxlib-0.4.20.drv /gnu/store/ha0hl2j607g0wanxqbkwrcfy6yz3k2xq-python-jaxlib-0.4.20-bazel-deps.tar.xz.drv --8<---------------cut here---------------end--------------->8--- the output mentions another no-grafts derivation, i.e., /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv. This derivation 4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv is not the derivation for grafting but the derivation for building the no-grafts. Well, I think the issue with “guix copy” is coming from something similar. There is a mismatch between what is computed. Let give a look. Let transform the one-line file to multi-lines: --8<---------------cut here---------------start------------->8--- $ cat /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv | sed 's/,/\n,/g' > /tmp/manual --8<---------------cut here---------------end--------------->8--- And diff the both files (see complete raw below). Inline comments… 2c2 < ,"/gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1" --- > ,"/gnu/store/yhr2vxh26acz3pzpjlph4f82ffrw6icv-tensorflow-2.13.1" 6c6 < ,"/gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python" --- > ,"/gnu/store/fyjpsvfdmkdimd1vx6d99ik01z3x3j93-tensorflow-2.13.1-python" That’s expected. Because this hash is the result of all the others, i.e., something that comes next; for instance, 90,91d89 < ,("/gnu/store/50vi4ywi79irbg71l814xqkww4k1afh2-python-jaxlib-0.4.20.drv" < ,["out"]) 130,131d127 < ,("/gnu/store/8avai81995rj5h7906nzgyrnrpvqi6if-tensorflow-2.13.1-bazel-deps.tar.xz.drv" < ,["out"]) 135a132,133 > ,("/gnu/store/8jfr297mkpv698d4y1cq270a7f03wyh6-bazel-6.3.2.drv" > ,["out"]) 158,159d155 < ,("/gnu/store/an1hq0y3npd66plwghgnccm4sl7lyvka-bazel-6.3.2.drv" < ,["out"]) 229a226,227 > ,("/gnu/store/g90vfnx128ifhgy0n1zmlscjrn57l8xm-tensorflow-2.13.1-bazel-deps.tar.xz.drv" > ,["out"]) Hum, it seems: + the order is different; + the derivations are also different Ok, the order might be one the problem. And that could be a bug for “guix copy”. And because the derivations are not the same, then the item is different. Let consider tensorflow-2.13.1-bazel-deps.tar which is “fixed-output”: it means the hash (NAR SHA256) is known beforehand. Therefore the hash of the store item should be same. Well, let open these two derivations; they both read: Derive ([("out","/gnu/store/rdpxkb8gl0ym0vrz8viklc0rwnjkn7cl-tensorflow-2.13.1-bazel-deps.tar.xz", "sha256","487a1b6685767e8d9fc0a23a2e82d2d7be305e1bd5aeaa4acd1599bc92e3142f")] It means the derivations are different but their result is the exact same item. Well, I will do further tests. :-) Cheers, simon --8<---------------cut here---------------start------------->8--- 2c2 < ,"/gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1" --- > ,"/gnu/store/yhr2vxh26acz3pzpjlph4f82ffrw6icv-tensorflow-2.13.1" 6c6 < ,"/gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python" --- > ,"/gnu/store/fyjpsvfdmkdimd1vx6d99ik01z3x3j93-tensorflow-2.13.1-python" 90,91d89 < ,("/gnu/store/50vi4ywi79irbg71l814xqkww4k1afh2-python-jaxlib-0.4.20.drv" < ,["out"]) 130,131d127 < ,("/gnu/store/8avai81995rj5h7906nzgyrnrpvqi6if-tensorflow-2.13.1-bazel-deps.tar.xz.drv" < ,["out"]) 135a132,133 > ,("/gnu/store/8jfr297mkpv698d4y1cq270a7f03wyh6-bazel-6.3.2.drv" > ,["out"]) 158,159d155 < ,("/gnu/store/an1hq0y3npd66plwghgnccm4sl7lyvka-bazel-6.3.2.drv" < ,["out"]) 229a226,227 > ,("/gnu/store/g90vfnx128ifhgy0n1zmlscjrn57l8xm-tensorflow-2.13.1-bazel-deps.tar.xz.drv" > ,["out"]) 251a250,251 > ,("/gnu/store/h3zcigb52z7m6yyjl785w3a5ls1cjjc7-python-jax-0.4.20.drv" > ,["out"]) 257a258,259 > ,("/gnu/store/h9m0ix80glph19k4pfqh130nmkil8f39-python-jaxlib-0.4.20.drv" > ,["out"]) 338,339d339 < ,("/gnu/store/lvbjhnrdgl5i5z558b1zpvj4vjqzdm4g-python-jax-0.4.20.drv" < ,["out"]) 519c519 < ,["/gnu/store/r200hqk2jn68qr5wqj6762dpqbns3vqj-tensorflow-2.13.1-builder" --- > ,["/gnu/store/a5pi7l07irynidrfkiw7x44s8angi2fh-tensorflow-2.13.1-builder" 528c528 < ,"/gnu/store/r200hqk2jn68qr5wqj6762dpqbns3vqj-tensorflow-2.13.1-builder"] --- > ,"/gnu/store/a5pi7l07irynidrfkiw7x44s8angi2fh-tensorflow-2.13.1-builder"] 530c530 < ,"/gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1") --- > ,"/gnu/store/yhr2vxh26acz3pzpjlph4f82ffrw6icv-tensorflow-2.13.1") 532c532 < ,"/gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python")]) \ No newline at end of file --- > ,"/gnu/store/fyjpsvfdmkdimd1vx6d99ik01z3x3j93-tensorflow-2.13.1-python")]) \ No newline at end of file --8<---------------cut here---------------end--------------->8---
Hi Alexis,
On ven., 22 mars 2024 at 12:38, Alexis Simon <alexis.simon@runbox.com> wrote:
> I'm attaching the new version for reference.
Cool! Well, maybe this package could be part of Guix Science channel or
another. WDYT?
Cheers,
simon
Hello, I noticed that the following fails guix shell -C --network --emulate-fhs --link-profile julia nss-certs -- julia -e 'using Pkg; Pkg.add("Flux"); using Flux' Any idea why ? Thanks, Cayetano Santos
Le 21/03/2024 à 23:19, Simon Tournier a écrit : > Hi Emmanuel, > > On mar., 19 mars 2024 at 16:40, Emmanuel Medernach <Emmanuel.Medernach@iphc.cnrs.fr> wrote: > >> Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build >> --no-grafts tensorflow -d >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv >> >> Machine_A # md5sum >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv >> c7833f974f217ada62b3eb6cdccee11f >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv >> >> Machine_B # guix time-machine -q -C ~/.config/guix/channels.scm -- build >> --no-grafts tensorflow -d >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv >> >> Machine_B # md5sum >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv >> c7833f974f217ada62b3eb6cdccee11f >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > The 2 derivations are the exact same. Since they build tensorflow > without grafts, it means the issue comes from grafts, no? > > >> Machine_A # guix package --list-installed | grep tensorflow >> tensorflow 2.13.1 out >> /gnu/store/jghvlb5dz4sy1p0cd1qx552r1ldj33wi-tensorflow-2.13.1 > This information is useless, I think. What is needed is the derivation > for grafting. Something like: > > Machine_A# guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow -d > > > >> Machine_B # guix copy --from=<Machine_A> tensorflow --dry-run > […] >> /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv > [...] > >> Without dry-run he would try to recompile tensorflow on Machine_B which >> results in a memory crash. > Yeah, that’s expected because it needs the non-grafted item. > > >> Why 'guix copy' derivation is >> /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv >> instead of >> /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv ? > Well, on Machine_A, these > > # guix build tensorflow -d --without-grafts > # guix build tensorflow -d > > should produce two different derivations. Right? On my machine, I get: > > --8<---------------cut here---------------start------------->8--- > $ guix time-machine -q -C channels.scm -- build tensorflow@2 -d --no-grafts -n > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > > $ guix time-machine -q -C channels.scm -- build tensorflow@2 -d -n > /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv > --8<---------------cut here---------------end--------------->8--- > > > What does “guix copy --no-grafts”? > > > Well, to be sure we are on the same wavelength: there are 4 derivations, > > + Machine_A: the real build (--no-grafts) and the grafted > + Machine_B: idem and idem > > So the debug seems: > > + check the no-grafts derivations are the same on both machines > + check the grafted derivations are the same on both machines > + check that “guix copy” copy both (no-grafts and grafted) > > Emacs provides a mode for easing the manipulation of derivation and > Scheme builder files. If you do not use Emacs, “guix gc” can be helpful > for tracking the derivations, I guess. Hi Simon, Here are the results: Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow -d --no-grafts /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow --no-grafts /gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1 /gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow -d /gnu/store/vivxpmrpkh1wq5pnw28vq9c51qd3vwf6-tensorflow-2.13.1.drv Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow /gnu/store/jghvlb5dz4sy1p0cd1qx552r1ldj33wi-tensorflow-2.13.1 /gnu/store/1pzdf2rfifgwdw92g8438mhqvzx948s5-tensorflow-2.13.1-python For all of this store elements guix copy on Machine B tried to recompile tensorflow. I ended up to copy the whole profile, this copy worked fine: Machine_B # guix copy --from=MachineA /gnu/store/...-profile Machine_B # guix package --list-installed | grep tensorflow tensorflow 2.13.1 out /gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1 For now I will copy whole profile instead of store elements. Thanks for your help, Cheers, Emmanuel > Cheers, > simon
[-- Attachment #1: Type: text/plain, Size: 13148 bytes --] Happy to report a fix for this: Install both geant4-vis and mesa with the --no-grafts option. This makes sure only 1 variant of mesa is used. E.g. #+begin_src sh guix shell geant4-vis cmake make gcc-toolchain mesa --no-grafts #+end_src Cheers Jake On Fri, Mar 22, 2024 at 5:23 AM Jake <jforst.mailman@gmail.com> wrote: > If the problem is that qtbase-5 is propagating a different mesa than the > one we can install (i.e. a different /gnu/store entry), let's try > installing qtbase-5 and using its propagated mesa instead of installing > mesa ourselves. > > #+begin_src sh > > guix shell geant4-vis cmake make gcc-toolchain qtbase@5 > > #+end_src > > Alas, we still have 2 different mesa versions: > > #+begin_example > > CMake Warning at CMakeLists.txt:35 (add_executable): > Cannot generate a safe runtime search path for target exampleA1 because > files in some directories may conflict with libraries in implicit > directories: > > runtime library [libEGL.so.1] in > /gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib may be hidden by > files in: > /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib > runtime library [libGL.so.1] in > /gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib may be hidden by > files in: > /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib > > Some of these libraries may not be found correctly. > > #+end_example > > The installed qtbase-5 propagates the same mesa as the one we can install: > > /gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib/libEGL.so -> > /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libEGL.so > > So then, where is this other mesa coming from (2rzdlwb...), if not > qtbase-5? > > I've included possibly relevant lines from the generated CMakeCache.txt > > #+begin_example > > //Path to a file. > > OPENGL_EGL_INCLUDE_DIR:PATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/ > include > > //Path to a file. > > OPENGL_GLX_INCLUDE_DIR:PATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/ > include > > //Path to a file. > > OPENGL_INCLUDE_DIR:PATH=/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/ > include > > //Path to a library. > > OPENGL_egl_LIBRARY:FILEPATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/ > lib/libEGL.so > > //Path to a library. > > OPENGL_gl_LIBRARY:FILEPATH=/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3 > .2/lib/libGL.so > > #+end_example > > Cheers > Jake > > On Thu, Mar 14, 2024 at 3:25 AM Jake <jforst.mailman@gmail.com> wrote: > >> Hello >> >> In short, I have the mesa package installed and another package I >> installed appears to have a different mesa in /gnu/store/ as a runtime >> dependency. >> As a result, cmake is unable to generate a safe runtime search path, >> because there are 2 different libGL.so.1 and libEGL.so.1 files in the path, >> one from the mesa I installed and another from the other mesa that was >> brought in as a runtime dependency. >> >> Here is the cmake warning: >> >> #+begin_src sh >> >> CMake Warning at CMakeLists.txt:35 (add_executable): >> Cannot generate a safe runtime search path for target exampleA1 >> because >> files in some directories may conflict with libraries in implicit >> directories: >> >> runtime library [libEGL.so.1] in /home/jake/.guix-profile/lib may >> be hidden by files in: >> /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib >> runtime library [libGL.so.1] in /home/jake/.guix-profile/lib may be >> hidden by files in: >> /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib >> >> Some of these libraries may not be found correctly. >> >> #+end_src >> >> I think the guix package definition below is somewhere introducing the >> additional mesa at /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2. >> The input clhep-2.4.6.2 and native inputs are omitted for brevity because >> I don't think they're relevant, but the full package definition and inputs >> can be found at >> https://github.com/jakeforster/guix-channel/blob/master/jforst/packages/geant4.scm >> >> #+begin_src scheme >> >> (define-public geant4-vis-11-1-1 >> (package >> (name "geant4-vis") >> (version "11.1.1") >> (source >> (origin >> (method git-fetch) >> (uri (git-reference >> (url "https://gitlab.cern.ch/geant4/geant4") >> (commit (string-append "v" version)))) >> (file-name (git-file-name name version)) >> (sha256 >> (base32 >> "141fhmh0w8sbp6cckccf3dswn596ds4vgqwc3gz6i53ypyxmv2fw")))) >> (build-system cmake-build-system) >> (inputs (list coreutils >> gcc-toolchain >> xerces-c >> expat >> clhep-2.4.6.2 >> python-2 >> python-3.10 >> perl >> tcsh >> qtbase-5 >> libxmu >> libxt)) >> (arguments >> `(#:configure-flags (let* ((out (assoc-ref %outputs "out")) >> (qt-path (string-append (assoc-ref >> %build-inputs >> "qtbase") >> >> "/lib/cmake/Qt5"))) >> (list (string-append >> "-DCMAKE_INSTALL_PREFIX=" out) >> (string-append "-DCMAKE_PREFIX_PATH=" >> qt-path) >> "-DCMAKE_INSTALL_LIBDIR=lib" >> "-DGEANT4_BUILD_MULTITHREADED=ON" >> "-DGEANT4_ENABLE_TESTING=OFF" >> "-DGEANT4_INSTALL_DATA=OFF" >> "-DGEANT4_USE_GDML=ON" ;xerces-c is >> needed for GDML >> "-DGEANT4_USE_SYSTEM_CLHEP=ON" >> "-DGEANT4_USE_SYSTEM_EXPAT=ON" >> "-DGEANT4_USE_OPENGL_X11=ON" >> "-DGEANT4_USE_QT=ON" >> (let ((datadir (string-append out >> "/share/geant4/data"))) >> (string-append >> "-DGEANT4_INSTALL_DATADIR=" >> datadir >> "/share/geant4/data")))) >> #:phases (modify-phases %standard-phases >> (add-after 'install 'install-data >> (lambda* (#:key inputs outputs #:allow-other-keys) >> (let ((G4NDL (assoc-ref inputs "G4NDL")) >> (G4EMLOW (assoc-ref inputs "G4EMLOW")) >> (G4PhotonEvaporation (assoc-ref inputs >> >> "G4PhotonEvaporation")) >> (G4RadioactiveDecay (assoc-ref inputs >> "G4RadioactiveDecay")) >> (G4PARTICLEXS (assoc-ref inputs >> "G4PARTICLEXS")) >> (G4PII (assoc-ref inputs "G4PII")) >> (G4RealSurface (assoc-ref inputs >> "G4RealSurface")) >> (G4SAIDDATA (assoc-ref inputs "G4SAIDDATA")) >> (G4ABLA (assoc-ref inputs "G4ABLA")) >> (G4INCL (assoc-ref inputs "G4INCL")) >> (G4ENSDFSTATE (assoc-ref inputs >> "G4ENSDFSTATE")) >> (G4TENDL (assoc-ref inputs "G4TENDL")) >> (datadir (string-append (assoc-ref outputs >> "out") >> >> "/share/geant4/data"))) >> (display (list "Data archives:" >> G4NDL >> G4EMLOW >> G4PhotonEvaporation >> G4RadioactiveDecay >> G4PARTICLEXS >> G4PII >> G4RealSurface >> G4SAIDDATA >> G4ABLA >> G4INCL >> G4ENSDFSTATE)) >> (newline) >> (mkdir-p datadir) >> (invoke "tar" "xvf" G4NDL "-C" datadir) >> (invoke "tar" "xvf" G4EMLOW "-C" datadir) >> (invoke "tar" "xvf" G4PhotonEvaporation "-C" >> datadir) >> (invoke "tar" "xvf" G4RadioactiveDecay "-C" >> datadir) >> (invoke "tar" "xvf" G4PARTICLEXS "-C" datadir) >> (invoke "tar" "xvf" G4PII "-C" datadir) >> (invoke "tar" "xvf" G4RealSurface "-C" datadir) >> (invoke "tar" "xvf" G4SAIDDATA "-C" datadir) >> (invoke "tar" "xvf" G4ABLA "-C" datadir) >> (invoke "tar" "xvf" G4INCL "-C" datadir) >> (invoke "tar" "xvf" G4ENSDFSTATE "-C" datadir) >> (invoke "tar" "xvf" G4TENDL "-C" datadir))))) >> ;; no tests in Makefile >> #:tests? #f)) >> (native-inputs `(("G4NDL" ,g4ndl-4.7) >> ("G4EMLOW" ,g4emlow-8.2) >> ("G4PhotonEvaporation" ,photon-evaporation-5.7) >> ("G4RadioactiveDecay" ,radioactive-decay-5.6) >> ("G4PARTICLEXS" ,g4particlexs-4.0) >> ("G4PII" ,g4pii-1.3) >> ("G4RealSurface" ,real-surface-2.2) >> ("G4SAIDDATA" ,g4saiddata-2.0) >> ("G4ABLA" ,g4abla-3.1) >> ("G4INCL" ,g4incl-1.0) >> ("G4ENSDFSTATE" ,g4ensdfstate-2.3) >> ("G4TENDL" ,g4tendl-1.4))) >> (home-page "https://geant4.web.cern.ch") >> (synopsis "Monte Carlo particle track simulations") >> (description >> "Geant4 is a toolkit for the simulation of the passage of particles >> through matter. Its areas of application include high energy, >> nuclear and accelerator physics, as well as studies >> in medical and space science. >> >> This package supports visualisation with OpenGL and Qt.") >> (license (license:non-copyleft >> "https://geant4.web.cern.ch/download/license")))) >> >> #+end_src >> >> Steps to reproduce the cmake warning given above: >> >> #+begin_src sh >> >> git clone https://github.com/jakeforster/guix-channel.git >> guix shell -L ./guix-channel geant4-vis cmake make gcc-toolchain mesa >> >> # copy an example app >> INSTALL_DIR=$(guix build geant4-vis) >> cp -rf $INSTALL_DIR/share/Geant4/examples/basic/B1 . >> >> # the store is read only >> chmod -R 751 B1/ >> >> mkdir B1/build >> cd B1/build >> cmake .. >> >> #+end_src >> >> I have also reproduced the warning using a guix shell -C --pure. There's >> just some extra hassle with making the build dir first and sharing the B1 >> directory containing the CMakeLists.txt file. >> >> If you use your profile instead of a shell, you can confirm the >> libEGL.so.1 and libGL.so.1 libraries in ~/.guix-profile/lib/ point to the >> same mesa in /gnu/store/ that is installed with the following: >> >> #+begin_src sh >> >> $ guix package -I | grep mesa >> mesa 23.3.2 out >> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2 >> >> $ ls -l ~/.guix-profile/lib/ | grep libEGL.so.1 >> lrwxrwxrwx 1 root root 71 Jan 1 1970 libEGL.so.1 -> >> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libEGL.so.1 >> >> $ ls -l ~/.guix-profile/lib/ | grep libGL.so.1 >> lrwxrwxrwx 1 root root 70 Jan 1 1970 libGL.so.1 -> >> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libGL.so.1 >> >> #+end_src >> >> So I'm guessing during the installation of geant4-vis, something is >> bringing in a different mesa from the store >> (/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2) into the path as >> a runtime dependency. >> I note that qtbase-5 has mesa as a propagated input, so perhaps it's that. >> But it's not clear to me why the mesa propagated for qtbase-5 would be >> different (i.e. has a different /gnu/store/ entry) from the mesa that I >> install in my profile or shell. >> Any suggestions for how to resolve this would be much appreciated. >> >> Thanks! >> >> Jake >> > [-- Attachment #2: Type: text/html, Size: 16872 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3332 bytes --] On 22/03/2024 08:25, Simon Tournier wrote: > Hi, > > On jeu., 21 mars 2024 at 18:03, Alexis Simon via Guix-Science <guix-science@gnu.org> wrote: > >> The build is failing with this error: >> running build_ext >> # cyvcf2: htslib mode is BUILTIN >> # cyvcf2: htslib configure options is None >> error: [Errno 2] No such file or directory: './configure' >> error: in phase 'build': uncaught exception: >> %exception #<&invoke-error program: "python" arguments: ("./setup.py" >> "build") exit-status: 1 term-signal: #f stop-signal: #f> >> >> What is very disturbing is that it builds fine in a debugging >> environment following the documentation [2] > > Indeed! Well, another undocumented trick. ;-) > > guix build -L . python-cyvcf2 \ > --with-source=python-cyvcf2=/tmp/cyvcf2-0.30.28 > > where /tmp/cyvcf2-0.30.28 is the uncompressed output of “guix build -S” > that I tweak. Adding this: > > --8<---------------cut here---------------start------------->8--- > diff -u /tmp/guix-build-python-cyvcf2-0.30.28.drv-0/cyvcf2-0.30.28/setup.py /tmp/cyvcf2-0.30.28/setup.py > --- /tmp/guix-build-python-cyvcf2-0.30.28.drv-0/cyvcf2-0.30.28/setup.py 2024-01-30 17:46:32.000000000 +0100 > +++ /tmp/cyvcf2-0.30.28/setup.py 2024-03-22 16:15:28.124301350 +0100 > @@ -83,7 +83,13 @@ > if htslib_configure_options: > configure_args.extend(htslib_configure_options.split()) > > - subprocess.run(configure_args, check=True) > + print(configure_args, > + "File exists?", os.path.exists(configure_args[0]), > + flush=True) > + try: > + subprocess.run(configure_args, check=True) > + except: > + print("BANG!") > subprocess.run(["make"], check=True) > > os.chdir(current_directory) > --8<---------------cut here---------------end--------------->8--- > > It leads to this output: > > --8<---------------cut here---------------start------------->8--- > running build_ext > # cyvcf2: htslib mode is BUILTIN > # cyvcf2: htslib configure options is None > ['./configure', 'CFLAGS=-fPIC'] File exists? True > echo '# Default htscodecs.mk generated by Makefile' > htscodecs.mk > echo 'include $(HTSPREFIX)htscodecs_bundled.mk' >> htscodecs.mk > ./hts_probe_cc.sh 'gcc' '-g -Wall -O2 -fvisibility=hidden ' '-fvisibility=hidden' >> htscodecs.mk > /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: line 1: ./hts_probe_cc.sh: No such file or directory > Makefile:141: htscodecs.mk: No such file or directory > make: *** [Makefile:124: htscodecs.mk] Error 127 > BANG! > Traceback (most recent call last): > [...] > --8<---------------cut here---------------end--------------->8--- > > Arf, then I have not investigated further. > > I think it does not come from ’./configure’ as wrongly reported but from > something triggered by it. > > Let me know your progress. Maybe I could give a closer look next week. Thanks a lot for the trick, I was able to finish compiling it, but going another route (i.e. unbundling htslib). I've abandoned running the tests though, I'm hitting a module not found error. pytest doesn't manage to load the just built module, probably an issue with the paths. I'm attaching the new version for reference. Cheers, Alexis > > Cheers, > simon > [-- Attachment #2: cyvcf2.scm --] [-- Type: text/x-scheme, Size: 3137 bytes --] (define-module (cyvcf2) #:use-module ((guix licenses) #:prefix license:) #:use-module (gnu packages) #:use-module (gnu packages base) #:use-module (gnu packages autotools) #:use-module (gnu packages build-tools) #:use-module (gnu packages cmake) #:use-module (gnu packages check) #:use-module (gnu packages python) #:use-module (gnu packages python-build) #:use-module (gnu packages python-check) #:use-module (gnu packages python-xyz) #:use-module (gnu packages python-science) #:use-module (gnu packages python-web) #:use-module (gnu packages bioinformatics) #:use-module (gnu packages serialization) #:use-module (gnu packages compression) #:use-module (gnu packages curl) #:use-module (gnu packages tls) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix git-download) #:use-module (guix utils) #:use-module (guix build-system python) #:use-module (guix build-system cargo) #:use-module (guix build-system cmake) #:use-module (guix build-system pyproject)) (define-public python-cyvcf2 (package (name "python-cyvcf2") (version "0.30.28") (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/brentp/cyvcf2") (commit (string-append "v" version)))) (sha256 (base32 "16yhfax509zyip8kkq2b0lflx5bdq5why7d785ayrqyzzq2rxqkk")) (modules '((guix build utils))) (snippet '(begin (delete-file-recursively "htslib"))))) (build-system pyproject-build-system) (arguments `(#:tests? #f #:phases (modify-phases %standard-phases ; (add-before 'check 'rm-folder ; (lambda _ ; (copy-recursively "cyvcf2/tests" "./tests") ; (delete-file-recursively "cyvcf2") ; (mkdir-p "cyvcf2") ; (copy-recursively "tests" "cyvcf2/tests"))) (add-after 'unpack 'fix-setup (lambda* (#:key inputs #:allow-other-keys) (substitute* "setup.py" ((" or not check_libhts\\(\\)") "") (("library_dirs=htslib_library_dirs") (string-append "library_dirs=[\"" (assoc-ref inputs "htslib") "/lib\"]")) (("\\+ htslib_include_dirs") (string-append "+ [\"" (assoc-ref inputs "htslib") "/include\"]"))))) (add-before 'build 'setenv (lambda _ (setenv "CYTHONIZE" "1") (setenv "CYVCF2_HTSLIB_MODE" "EXTERNAL")))))) (inputs (list htslib zlib libdeflate curl openssl python-cython)) (native-inputs (list python-pytest)) (propagated-inputs (list python-click python-coloredlogs python-numpy)) (home-page "https://github.com/brentp/cyvcf2/") (synopsis "fast vcf parsing with cython + htslib") (description "fast vcf parsing with cython + htslib") (license license:expat)))
[-- Attachment #1: Type: text/plain, Size: 3332 bytes --] On 22/03/2024 08:25, Simon Tournier wrote: > Hi, > > On jeu., 21 mars 2024 at 18:03, Alexis Simon via Guix-Science <guix-science@gnu.org> wrote: > >> The build is failing with this error: >> running build_ext >> # cyvcf2: htslib mode is BUILTIN >> # cyvcf2: htslib configure options is None >> error: [Errno 2] No such file or directory: './configure' >> error: in phase 'build': uncaught exception: >> %exception #<&invoke-error program: "python" arguments: ("./setup.py" >> "build") exit-status: 1 term-signal: #f stop-signal: #f> >> >> What is very disturbing is that it builds fine in a debugging >> environment following the documentation [2] > > Indeed! Well, another undocumented trick. ;-) > > guix build -L . python-cyvcf2 \ > --with-source=python-cyvcf2=/tmp/cyvcf2-0.30.28 > > where /tmp/cyvcf2-0.30.28 is the uncompressed output of “guix build -S” > that I tweak. Adding this: > > --8<---------------cut here---------------start------------->8--- > diff -u /tmp/guix-build-python-cyvcf2-0.30.28.drv-0/cyvcf2-0.30.28/setup.py /tmp/cyvcf2-0.30.28/setup.py > --- /tmp/guix-build-python-cyvcf2-0.30.28.drv-0/cyvcf2-0.30.28/setup.py 2024-01-30 17:46:32.000000000 +0100 > +++ /tmp/cyvcf2-0.30.28/setup.py 2024-03-22 16:15:28.124301350 +0100 > @@ -83,7 +83,13 @@ > if htslib_configure_options: > configure_args.extend(htslib_configure_options.split()) > > - subprocess.run(configure_args, check=True) > + print(configure_args, > + "File exists?", os.path.exists(configure_args[0]), > + flush=True) > + try: > + subprocess.run(configure_args, check=True) > + except: > + print("BANG!") > subprocess.run(["make"], check=True) > > os.chdir(current_directory) > --8<---------------cut here---------------end--------------->8--- > > It leads to this output: > > --8<---------------cut here---------------start------------->8--- > running build_ext > # cyvcf2: htslib mode is BUILTIN > # cyvcf2: htslib configure options is None > ['./configure', 'CFLAGS=-fPIC'] File exists? True > echo '# Default htscodecs.mk generated by Makefile' > htscodecs.mk > echo 'include $(HTSPREFIX)htscodecs_bundled.mk' >> htscodecs.mk > ./hts_probe_cc.sh 'gcc' '-g -Wall -O2 -fvisibility=hidden ' '-fvisibility=hidden' >> htscodecs.mk > /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: line 1: ./hts_probe_cc.sh: No such file or directory > Makefile:141: htscodecs.mk: No such file or directory > make: *** [Makefile:124: htscodecs.mk] Error 127 > BANG! > Traceback (most recent call last): > [...] > --8<---------------cut here---------------end--------------->8--- > > Arf, then I have not investigated further. > > I think it does not come from ’./configure’ as wrongly reported but from > something triggered by it. > > Let me know your progress. Maybe I could give a closer look next week. Thanks a lot for the trick, I was able to finish compiling it, but going another route (i.e. unbundling htslib). I've abandoned running the tests though, I'm hitting a module not found error. pytest doesn't manage to load the just built module, probably an issue with the paths. I'm attaching the new version for reference. Cheers, Alexis > > Cheers, > simon > [-- Attachment #2: cyvcf2.scm --] [-- Type: text/x-scheme, Size: 3137 bytes --] (define-module (cyvcf2) #:use-module ((guix licenses) #:prefix license:) #:use-module (gnu packages) #:use-module (gnu packages base) #:use-module (gnu packages autotools) #:use-module (gnu packages build-tools) #:use-module (gnu packages cmake) #:use-module (gnu packages check) #:use-module (gnu packages python) #:use-module (gnu packages python-build) #:use-module (gnu packages python-check) #:use-module (gnu packages python-xyz) #:use-module (gnu packages python-science) #:use-module (gnu packages python-web) #:use-module (gnu packages bioinformatics) #:use-module (gnu packages serialization) #:use-module (gnu packages compression) #:use-module (gnu packages curl) #:use-module (gnu packages tls) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix git-download) #:use-module (guix utils) #:use-module (guix build-system python) #:use-module (guix build-system cargo) #:use-module (guix build-system cmake) #:use-module (guix build-system pyproject)) (define-public python-cyvcf2 (package (name "python-cyvcf2") (version "0.30.28") (source (origin (method git-fetch) (uri (git-reference (url "https://github.com/brentp/cyvcf2") (commit (string-append "v" version)))) (sha256 (base32 "16yhfax509zyip8kkq2b0lflx5bdq5why7d785ayrqyzzq2rxqkk")) (modules '((guix build utils))) (snippet '(begin (delete-file-recursively "htslib"))))) (build-system pyproject-build-system) (arguments `(#:tests? #f #:phases (modify-phases %standard-phases ; (add-before 'check 'rm-folder ; (lambda _ ; (copy-recursively "cyvcf2/tests" "./tests") ; (delete-file-recursively "cyvcf2") ; (mkdir-p "cyvcf2") ; (copy-recursively "tests" "cyvcf2/tests"))) (add-after 'unpack 'fix-setup (lambda* (#:key inputs #:allow-other-keys) (substitute* "setup.py" ((" or not check_libhts\\(\\)") "") (("library_dirs=htslib_library_dirs") (string-append "library_dirs=[\"" (assoc-ref inputs "htslib") "/lib\"]")) (("\\+ htslib_include_dirs") (string-append "+ [\"" (assoc-ref inputs "htslib") "/include\"]"))))) (add-before 'build 'setenv (lambda _ (setenv "CYTHONIZE" "1") (setenv "CYVCF2_HTSLIB_MODE" "EXTERNAL")))))) (inputs (list htslib zlib libdeflate curl openssl python-cython)) (native-inputs (list python-pytest)) (propagated-inputs (list python-click python-coloredlogs python-numpy)) (home-page "https://github.com/brentp/cyvcf2/") (synopsis "fast vcf parsing with cython + htslib") (description "fast vcf parsing with cython + htslib") (license license:expat)))
Hi Emmanuel, On mar., 19 mars 2024 at 16:40, Emmanuel Medernach <Emmanuel.Medernach@iphc.cnrs.fr> wrote: > Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build > --no-grafts tensorflow -d > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > > Machine_A # md5sum > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > c7833f974f217ada62b3eb6cdccee11f > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > > Machine_B # guix time-machine -q -C ~/.config/guix/channels.scm -- build > --no-grafts tensorflow -d > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > > Machine_B # md5sum > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > c7833f974f217ada62b3eb6cdccee11f > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv The 2 derivations are the exact same. Since they build tensorflow without grafts, it means the issue comes from grafts, no? > Machine_A # guix package --list-installed | grep tensorflow > tensorflow 2.13.1 out > /gnu/store/jghvlb5dz4sy1p0cd1qx552r1ldj33wi-tensorflow-2.13.1 This information is useless, I think. What is needed is the derivation for grafting. Something like: Machine_A# guix time-machine -q -C ~/.config/guix/channels.scm -- build tensorflow -d > Machine_B # guix copy --from=<Machine_A> tensorflow --dry-run […] > /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv [...] > Without dry-run he would try to recompile tensorflow on Machine_B which > results in a memory crash. Yeah, that’s expected because it needs the non-grafted item. > Why 'guix copy' derivation is > /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv > instead of > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv ? Well, on Machine_A, these # guix build tensorflow -d --without-grafts # guix build tensorflow -d should produce two different derivations. Right? On my machine, I get: --8<---------------cut here---------------start------------->8--- $ guix time-machine -q -C channels.scm -- build tensorflow@2 -d --no-grafts -n /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv $ guix time-machine -q -C channels.scm -- build tensorflow@2 -d -n /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv --8<---------------cut here---------------end--------------->8--- What does “guix copy --no-grafts”? Well, to be sure we are on the same wavelength: there are 4 derivations, + Machine_A: the real build (--no-grafts) and the grafted + Machine_B: idem and idem So the debug seems: + check the no-grafts derivations are the same on both machines + check the grafted derivations are the same on both machines + check that “guix copy” copy both (no-grafts and grafted) Emacs provides a mode for easing the manipulation of derivation and Scheme builder files. If you do not use Emacs, “guix gc” can be helpful for tracking the derivations, I guess. Cheers, simon
Hi,
On jeu., 21 mars 2024 at 18:03, Alexis Simon via Guix-Science <guix-science@gnu.org> wrote:
> The build is failing with this error:
> running build_ext
> # cyvcf2: htslib mode is BUILTIN
> # cyvcf2: htslib configure options is None
> error: [Errno 2] No such file or directory: './configure'
> error: in phase 'build': uncaught exception:
> %exception #<&invoke-error program: "python" arguments: ("./setup.py"
> "build") exit-status: 1 term-signal: #f stop-signal: #f>
>
> What is very disturbing is that it builds fine in a debugging
> environment following the documentation [2]
Indeed! Well, another undocumented trick. ;-)
guix build -L . python-cyvcf2 \
--with-source=python-cyvcf2=/tmp/cyvcf2-0.30.28
where /tmp/cyvcf2-0.30.28 is the uncompressed output of “guix build -S”
that I tweak. Adding this:
--8<---------------cut here---------------start------------->8---
diff -u /tmp/guix-build-python-cyvcf2-0.30.28.drv-0/cyvcf2-0.30.28/setup.py /tmp/cyvcf2-0.30.28/setup.py
--- /tmp/guix-build-python-cyvcf2-0.30.28.drv-0/cyvcf2-0.30.28/setup.py 2024-01-30 17:46:32.000000000 +0100
+++ /tmp/cyvcf2-0.30.28/setup.py 2024-03-22 16:15:28.124301350 +0100
@@ -83,7 +83,13 @@
if htslib_configure_options:
configure_args.extend(htslib_configure_options.split())
- subprocess.run(configure_args, check=True)
+ print(configure_args,
+ "File exists?", os.path.exists(configure_args[0]),
+ flush=True)
+ try:
+ subprocess.run(configure_args, check=True)
+ except:
+ print("BANG!")
subprocess.run(["make"], check=True)
os.chdir(current_directory)
--8<---------------cut here---------------end--------------->8---
It leads to this output:
--8<---------------cut here---------------start------------->8---
running build_ext
# cyvcf2: htslib mode is BUILTIN
# cyvcf2: htslib configure options is None
['./configure', 'CFLAGS=-fPIC'] File exists? True
echo '# Default htscodecs.mk generated by Makefile' > htscodecs.mk
echo 'include $(HTSPREFIX)htscodecs_bundled.mk' >> htscodecs.mk
./hts_probe_cc.sh 'gcc' '-g -Wall -O2 -fvisibility=hidden ' '-fvisibility=hidden' >> htscodecs.mk
/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: line 1: ./hts_probe_cc.sh: No such file or directory
Makefile:141: htscodecs.mk: No such file or directory
make: *** [Makefile:124: htscodecs.mk] Error 127
BANG!
Traceback (most recent call last):
[...]
--8<---------------cut here---------------end--------------->8---
Arf, then I have not investigated further.
I think it does not come from ’./configure’ as wrongly reported but from
something triggered by it.
Let me know your progress. Maybe I could give a closer look next week.
Cheers,
simon
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --] Bonjour à tous, Pour rappel, le prochain Café Guix aura lieu le mercredi 27 Mars à 13h30 en visio sur ce lien : [ https://meet.univ-grenoble-alpes.fr/b/cel-dyj-m93-arv ] [ https://videos.univ-grenoble-alpes.fr/live/my_events/ | https://videos.univ-grenoble-alpes.fr/live/my_events/ ] Attention, cette session aura lieu pendant les Journées du réseau recherche reproductible organisées du 26 au 28 Mars à Grenoble ( [ https://jrfrr-2024.sciencesconf.org/ | https://jrfrr-2024.sciencesconf.org/ ] ) et ce n'est ni le jour ni le lien habituel ! En particulier, pour poser vos questions vous ne pourrez pas utiliser le chat ou prendre la parole mais un pad est mis à disposition sur ce lien : [ https://mensuel.framapad.org/p/cafeguix27022024-a6iy?lang=fr | https://mensuel.framapad.org/p/cafeguix27022024-a6iy ] " Introduction à la reproductibilité des environnements de calcul : construction de paquets et liens avec Software Heritage " animé par Pierre-Antoine Bouttier (GRICAD) et Ludovic Courtès (Inria). Résumé : Comment reproduire l’environnement logiciel de son expérience, sur différentes machines et à différents moments ? Cette question est au cœur de la reproductibilité des calculs et c’est à ça que cherche à répondre Guix. Dans cette session, nous verrons d’abord comment figer son environnement logiciel Guix et en quoi cela va au-delà d’une liste de noms et versions de logiciels, et surtout, comme re-déployer cet environnement avec l’incroyable `guix time-machine`. Tout cela est bien joli, mais on comprend bien que ça risque de ne plus fonctionner si le code source des logiciels disparaît. Nous verrons comment l’intégration avec Software Heritage permet (presque !) d’éliminer ce problème. Le Caf é Guix est un lieu et un temps d'échange informel et francophone autour du gestionnaire d'environnement logiciel Guix . Étudiant-e-s, chercheuses et chercheurs, admin. système, IT support de labos ou de centre de calcul, tout le monde est le bienvenu dans ce rendez-vous mensuel d'une heure où l'on discutera de questionnements apportés par chacun sur Guix et sa pratique au sens large. Vous trouverez toutes les infos concernant les C af és G uix par ici (ainsi que l’adresse d’un mattermost dédié) : [ https://hpc.guix.info/events/2024/caf%C3%A9-guix/ | https://hpc.guix.info/events/2024/café-guix/ ] En espérant vous voir nombreux, Bien cordialement, Céline [-- Attachment #2: Type: text/html, Size: 10213 bytes --]
[-- Attachment #1: Type: text/plain, Size: 12475 bytes --] If the problem is that qtbase-5 is propagating a different mesa than the one we can install (i.e. a different /gnu/store entry), let's try installing qtbase-5 and using its propagated mesa instead of installing mesa ourselves. #+begin_src sh guix shell geant4-vis cmake make gcc-toolchain qtbase@5 #+end_src Alas, we still have 2 different mesa versions: #+begin_example CMake Warning at CMakeLists.txt:35 (add_executable): Cannot generate a safe runtime search path for target exampleA1 because files in some directories may conflict with libraries in implicit directories: runtime library [libEGL.so.1] in /gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib may be hidden by files in: /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib runtime library [libGL.so.1] in /gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib may be hidden by files in: /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib Some of these libraries may not be found correctly. #+end_example The installed qtbase-5 propagates the same mesa as the one we can install: /gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib/libEGL.so -> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libEGL.so So then, where is this other mesa coming from (2rzdlwb...), if not qtbase-5? I've included possibly relevant lines from the generated CMakeCache.txt #+begin_example //Path to a file. OPENGL_EGL_INCLUDE_DIR:PATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/ include //Path to a file. OPENGL_GLX_INCLUDE_DIR:PATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/ include //Path to a file. OPENGL_INCLUDE_DIR:PATH=/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/ include //Path to a library. OPENGL_egl_LIBRARY:FILEPATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/ lib/libEGL.so //Path to a library. OPENGL_gl_LIBRARY:FILEPATH=/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3 .2/lib/libGL.so #+end_example Cheers Jake On Thu, Mar 14, 2024 at 3:25 AM Jake <jforst.mailman@gmail.com> wrote: > Hello > > In short, I have the mesa package installed and another package I > installed appears to have a different mesa in /gnu/store/ as a runtime > dependency. > As a result, cmake is unable to generate a safe runtime search path, > because there are 2 different libGL.so.1 and libEGL.so.1 files in the path, > one from the mesa I installed and another from the other mesa that was > brought in as a runtime dependency. > > Here is the cmake warning: > > #+begin_src sh > > CMake Warning at CMakeLists.txt:35 (add_executable): > Cannot generate a safe runtime search path for target exampleA1 because > files in some directories may conflict with libraries in implicit > directories: > > runtime library [libEGL.so.1] in /home/jake/.guix-profile/lib may be > hidden by files in: > /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib > runtime library [libGL.so.1] in /home/jake/.guix-profile/lib may be > hidden by files in: > /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib > > Some of these libraries may not be found correctly. > > #+end_src > > I think the guix package definition below is somewhere introducing the > additional mesa at /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2. > The input clhep-2.4.6.2 and native inputs are omitted for brevity because > I don't think they're relevant, but the full package definition and inputs > can be found at > https://github.com/jakeforster/guix-channel/blob/master/jforst/packages/geant4.scm > > #+begin_src scheme > > (define-public geant4-vis-11-1-1 > (package > (name "geant4-vis") > (version "11.1.1") > (source > (origin > (method git-fetch) > (uri (git-reference > (url "https://gitlab.cern.ch/geant4/geant4") > (commit (string-append "v" version)))) > (file-name (git-file-name name version)) > (sha256 > (base32 > "141fhmh0w8sbp6cckccf3dswn596ds4vgqwc3gz6i53ypyxmv2fw")))) > (build-system cmake-build-system) > (inputs (list coreutils > gcc-toolchain > xerces-c > expat > clhep-2.4.6.2 > python-2 > python-3.10 > perl > tcsh > qtbase-5 > libxmu > libxt)) > (arguments > `(#:configure-flags (let* ((out (assoc-ref %outputs "out")) > (qt-path (string-append (assoc-ref > %build-inputs > "qtbase") > > "/lib/cmake/Qt5"))) > (list (string-append > "-DCMAKE_INSTALL_PREFIX=" out) > (string-append "-DCMAKE_PREFIX_PATH=" > qt-path) > "-DCMAKE_INSTALL_LIBDIR=lib" > "-DGEANT4_BUILD_MULTITHREADED=ON" > "-DGEANT4_ENABLE_TESTING=OFF" > "-DGEANT4_INSTALL_DATA=OFF" > "-DGEANT4_USE_GDML=ON" ;xerces-c is > needed for GDML > "-DGEANT4_USE_SYSTEM_CLHEP=ON" > "-DGEANT4_USE_SYSTEM_EXPAT=ON" > "-DGEANT4_USE_OPENGL_X11=ON" > "-DGEANT4_USE_QT=ON" > (let ((datadir (string-append out > "/share/geant4/data"))) > (string-append > "-DGEANT4_INSTALL_DATADIR=" > datadir > "/share/geant4/data")))) > #:phases (modify-phases %standard-phases > (add-after 'install 'install-data > (lambda* (#:key inputs outputs #:allow-other-keys) > (let ((G4NDL (assoc-ref inputs "G4NDL")) > (G4EMLOW (assoc-ref inputs "G4EMLOW")) > (G4PhotonEvaporation (assoc-ref inputs > "G4PhotonEvaporation")) > (G4RadioactiveDecay (assoc-ref inputs > "G4RadioactiveDecay")) > (G4PARTICLEXS (assoc-ref inputs > "G4PARTICLEXS")) > (G4PII (assoc-ref inputs "G4PII")) > (G4RealSurface (assoc-ref inputs > "G4RealSurface")) > (G4SAIDDATA (assoc-ref inputs "G4SAIDDATA")) > (G4ABLA (assoc-ref inputs "G4ABLA")) > (G4INCL (assoc-ref inputs "G4INCL")) > (G4ENSDFSTATE (assoc-ref inputs > "G4ENSDFSTATE")) > (G4TENDL (assoc-ref inputs "G4TENDL")) > (datadir (string-append (assoc-ref outputs > "out") > > "/share/geant4/data"))) > (display (list "Data archives:" > G4NDL > G4EMLOW > G4PhotonEvaporation > G4RadioactiveDecay > G4PARTICLEXS > G4PII > G4RealSurface > G4SAIDDATA > G4ABLA > G4INCL > G4ENSDFSTATE)) > (newline) > (mkdir-p datadir) > (invoke "tar" "xvf" G4NDL "-C" datadir) > (invoke "tar" "xvf" G4EMLOW "-C" datadir) > (invoke "tar" "xvf" G4PhotonEvaporation "-C" > datadir) > (invoke "tar" "xvf" G4RadioactiveDecay "-C" > datadir) > (invoke "tar" "xvf" G4PARTICLEXS "-C" datadir) > (invoke "tar" "xvf" G4PII "-C" datadir) > (invoke "tar" "xvf" G4RealSurface "-C" datadir) > (invoke "tar" "xvf" G4SAIDDATA "-C" datadir) > (invoke "tar" "xvf" G4ABLA "-C" datadir) > (invoke "tar" "xvf" G4INCL "-C" datadir) > (invoke "tar" "xvf" G4ENSDFSTATE "-C" datadir) > (invoke "tar" "xvf" G4TENDL "-C" datadir))))) > ;; no tests in Makefile > #:tests? #f)) > (native-inputs `(("G4NDL" ,g4ndl-4.7) > ("G4EMLOW" ,g4emlow-8.2) > ("G4PhotonEvaporation" ,photon-evaporation-5.7) > ("G4RadioactiveDecay" ,radioactive-decay-5.6) > ("G4PARTICLEXS" ,g4particlexs-4.0) > ("G4PII" ,g4pii-1.3) > ("G4RealSurface" ,real-surface-2.2) > ("G4SAIDDATA" ,g4saiddata-2.0) > ("G4ABLA" ,g4abla-3.1) > ("G4INCL" ,g4incl-1.0) > ("G4ENSDFSTATE" ,g4ensdfstate-2.3) > ("G4TENDL" ,g4tendl-1.4))) > (home-page "https://geant4.web.cern.ch") > (synopsis "Monte Carlo particle track simulations") > (description > "Geant4 is a toolkit for the simulation of the passage of particles > through matter. Its areas of application include high energy, > nuclear and accelerator physics, as well as studies > in medical and space science. > > This package supports visualisation with OpenGL and Qt.") > (license (license:non-copyleft > "https://geant4.web.cern.ch/download/license")))) > > #+end_src > > Steps to reproduce the cmake warning given above: > > #+begin_src sh > > git clone https://github.com/jakeforster/guix-channel.git > guix shell -L ./guix-channel geant4-vis cmake make gcc-toolchain mesa > > # copy an example app > INSTALL_DIR=$(guix build geant4-vis) > cp -rf $INSTALL_DIR/share/Geant4/examples/basic/B1 . > > # the store is read only > chmod -R 751 B1/ > > mkdir B1/build > cd B1/build > cmake .. > > #+end_src > > I have also reproduced the warning using a guix shell -C --pure. There's > just some extra hassle with making the build dir first and sharing the B1 > directory containing the CMakeLists.txt file. > > If you use your profile instead of a shell, you can confirm the > libEGL.so.1 and libGL.so.1 libraries in ~/.guix-profile/lib/ point to the > same mesa in /gnu/store/ that is installed with the following: > > #+begin_src sh > > $ guix package -I | grep mesa > mesa 23.3.2 out > /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2 > > $ ls -l ~/.guix-profile/lib/ | grep libEGL.so.1 > lrwxrwxrwx 1 root root 71 Jan 1 1970 libEGL.so.1 -> > /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libEGL.so.1 > > $ ls -l ~/.guix-profile/lib/ | grep libGL.so.1 > lrwxrwxrwx 1 root root 70 Jan 1 1970 libGL.so.1 -> > /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libGL.so.1 > > #+end_src > > So I'm guessing during the installation of geant4-vis, something is > bringing in a different mesa from the store > (/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2) into the path as > a runtime dependency. > I note that qtbase-5 has mesa as a propagated input, so perhaps it's that. > But it's not clear to me why the mesa propagated for qtbase-5 would be > different (i.e. has a different /gnu/store/ entry) from the mesa that I > install in my profile or shell. > Any suggestions for how to resolve this would be much appreciated. > > Thanks! > > Jake > [-- Attachment #2: Type: text/html, Size: 16101 bytes --]
If the problem is that qtbase-5 is propagating a different mesa than the
one we can install (i.e. a different /gnu/store entry), let's try
installing qtbase-5 and using its propagated mesa instead of installing
mesa ourselves.
#+begin_src sh
guix shell geant4-vis cmake make gcc-toolchain qtbase@5
#+end_src
Alas, we still have 2 different mesa versions:
#+begin_example
CMake Warning at CMakeLists.txt:35 (add_executable):
Cannot generate a safe runtime search path for target exampleA1 because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libEGL.so.1] in
/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib may be hidden by
files in:
/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib
runtime library [libGL.so.1] in
/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib may be hidden by
files in:
/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib
Some of these libraries may not be found correctly.
#+end_example
The installed qtbase-5 propagates the same mesa as the one we can install:
/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/lib/libEGL.so ->
/gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libEGL.so
So then, where is this other mesa coming from (2rzdlwb...), if not qtbase-5?
I've included possibly relevant lines from the generated CMakeCache.txt
#+begin_example
//Path to a file.
OPENGL_EGL_INCLUDE_DIR:PATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/
include
//Path to a file.
OPENGL_GLX_INCLUDE_DIR:PATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/
include
//Path to a file.
OPENGL_INCLUDE_DIR:PATH=/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/
include
//Path to a library.
OPENGL_egl_LIBRARY:FILEPATH=/gnu/store/6imr8p8j0d59s4r0912xy8mficw8kc2y-profile/
lib/libEGL.so
//Path to a library.
OPENGL_gl_LIBRARY:FILEPATH=/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3
.2/lib/libGL.so
#+end_example
Cheers
Jake
On Thu, Mar 14, 2024 at 3:25 AM Jake <jforst.mailman@gmail.com> wrote:
> Hello
>
> In short, I have the mesa package installed and another package I
> installed appears to have a different mesa in /gnu/store/ as a runtime
> dependency.
> As a result, cmake is unable to generate a safe runtime search path,
> because there are 2 different libGL.so.1 and libEGL.so.1 files in the path,
> one from the mesa I installed and another from the other mesa that was
> brought in as a runtime dependency.
>
> Here is the cmake warning:
>
> #+begin_src sh
>
> CMake Warning at CMakeLists.txt:35 (add_executable):
> Cannot generate a safe runtime search path for target exampleA1 because
> files in some directories may conflict with libraries in implicit
> directories:
>
> runtime library [libEGL.so.1] in /home/jake/.guix-profile/lib may be
> hidden by files in:
> /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib
> runtime library [libGL.so.1] in /home/jake/.guix-profile/lib may be
> hidden by files in:
> /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2/lib
>
> Some of these libraries may not be found correctly.
>
> #+end_src
>
> I think the guix package definition below is somewhere introducing the
> additional mesa at /gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2.
> The input clhep-2.4.6.2 and native inputs are omitted for brevity because
> I don't think they're relevant, but the full package definition and inputs
> can be found at
> https://github.com/jakeforster/guix-channel/blob/master/jforst/packages/geant4.scm
>
> #+begin_src scheme
>
> (define-public geant4-vis-11-1-1
> (package
> (name "geant4-vis")
> (version "11.1.1")
> (source
> (origin
> (method git-fetch)
> (uri (git-reference
> (url "https://gitlab.cern.ch/geant4/geant4")
> (commit (string-append "v" version))))
> (file-name (git-file-name name version))
> (sha256
> (base32
> "141fhmh0w8sbp6cckccf3dswn596ds4vgqwc3gz6i53ypyxmv2fw"))))
> (build-system cmake-build-system)
> (inputs (list coreutils
> gcc-toolchain
> xerces-c
> expat
> clhep-2.4.6.2
> python-2
> python-3.10
> perl
> tcsh
> qtbase-5
> libxmu
> libxt))
> (arguments
> `(#:configure-flags (let* ((out (assoc-ref %outputs "out"))
> (qt-path (string-append (assoc-ref
> %build-inputs
> "qtbase")
>
> "/lib/cmake/Qt5")))
> (list (string-append
> "-DCMAKE_INSTALL_PREFIX=" out)
> (string-append "-DCMAKE_PREFIX_PATH="
> qt-path)
> "-DCMAKE_INSTALL_LIBDIR=lib"
> "-DGEANT4_BUILD_MULTITHREADED=ON"
> "-DGEANT4_ENABLE_TESTING=OFF"
> "-DGEANT4_INSTALL_DATA=OFF"
> "-DGEANT4_USE_GDML=ON" ;xerces-c is
> needed for GDML
> "-DGEANT4_USE_SYSTEM_CLHEP=ON"
> "-DGEANT4_USE_SYSTEM_EXPAT=ON"
> "-DGEANT4_USE_OPENGL_X11=ON"
> "-DGEANT4_USE_QT=ON"
> (let ((datadir (string-append out
> "/share/geant4/data")))
> (string-append
> "-DGEANT4_INSTALL_DATADIR="
> datadir
> "/share/geant4/data"))))
> #:phases (modify-phases %standard-phases
> (add-after 'install 'install-data
> (lambda* (#:key inputs outputs #:allow-other-keys)
> (let ((G4NDL (assoc-ref inputs "G4NDL"))
> (G4EMLOW (assoc-ref inputs "G4EMLOW"))
> (G4PhotonEvaporation (assoc-ref inputs
> "G4PhotonEvaporation"))
> (G4RadioactiveDecay (assoc-ref inputs
> "G4RadioactiveDecay"))
> (G4PARTICLEXS (assoc-ref inputs
> "G4PARTICLEXS"))
> (G4PII (assoc-ref inputs "G4PII"))
> (G4RealSurface (assoc-ref inputs
> "G4RealSurface"))
> (G4SAIDDATA (assoc-ref inputs "G4SAIDDATA"))
> (G4ABLA (assoc-ref inputs "G4ABLA"))
> (G4INCL (assoc-ref inputs "G4INCL"))
> (G4ENSDFSTATE (assoc-ref inputs
> "G4ENSDFSTATE"))
> (G4TENDL (assoc-ref inputs "G4TENDL"))
> (datadir (string-append (assoc-ref outputs
> "out")
>
> "/share/geant4/data")))
> (display (list "Data archives:"
> G4NDL
> G4EMLOW
> G4PhotonEvaporation
> G4RadioactiveDecay
> G4PARTICLEXS
> G4PII
> G4RealSurface
> G4SAIDDATA
> G4ABLA
> G4INCL
> G4ENSDFSTATE))
> (newline)
> (mkdir-p datadir)
> (invoke "tar" "xvf" G4NDL "-C" datadir)
> (invoke "tar" "xvf" G4EMLOW "-C" datadir)
> (invoke "tar" "xvf" G4PhotonEvaporation "-C"
> datadir)
> (invoke "tar" "xvf" G4RadioactiveDecay "-C"
> datadir)
> (invoke "tar" "xvf" G4PARTICLEXS "-C" datadir)
> (invoke "tar" "xvf" G4PII "-C" datadir)
> (invoke "tar" "xvf" G4RealSurface "-C" datadir)
> (invoke "tar" "xvf" G4SAIDDATA "-C" datadir)
> (invoke "tar" "xvf" G4ABLA "-C" datadir)
> (invoke "tar" "xvf" G4INCL "-C" datadir)
> (invoke "tar" "xvf" G4ENSDFSTATE "-C" datadir)
> (invoke "tar" "xvf" G4TENDL "-C" datadir)))))
> ;; no tests in Makefile
> #:tests? #f))
> (native-inputs `(("G4NDL" ,g4ndl-4.7)
> ("G4EMLOW" ,g4emlow-8.2)
> ("G4PhotonEvaporation" ,photon-evaporation-5.7)
> ("G4RadioactiveDecay" ,radioactive-decay-5.6)
> ("G4PARTICLEXS" ,g4particlexs-4.0)
> ("G4PII" ,g4pii-1.3)
> ("G4RealSurface" ,real-surface-2.2)
> ("G4SAIDDATA" ,g4saiddata-2.0)
> ("G4ABLA" ,g4abla-3.1)
> ("G4INCL" ,g4incl-1.0)
> ("G4ENSDFSTATE" ,g4ensdfstate-2.3)
> ("G4TENDL" ,g4tendl-1.4)))
> (home-page "https://geant4.web.cern.ch")
> (synopsis "Monte Carlo particle track simulations")
> (description
> "Geant4 is a toolkit for the simulation of the passage of particles
> through matter. Its areas of application include high energy,
> nuclear and accelerator physics, as well as studies
> in medical and space science.
>
> This package supports visualisation with OpenGL and Qt.")
> (license (license:non-copyleft
> "https://geant4.web.cern.ch/download/license"))))
>
> #+end_src
>
> Steps to reproduce the cmake warning given above:
>
> #+begin_src sh
>
> git clone https://github.com/jakeforster/guix-channel.git
> guix shell -L ./guix-channel geant4-vis cmake make gcc-toolchain mesa
>
> # copy an example app
> INSTALL_DIR=$(guix build geant4-vis)
> cp -rf $INSTALL_DIR/share/Geant4/examples/basic/B1 .
>
> # the store is read only
> chmod -R 751 B1/
>
> mkdir B1/build
> cd B1/build
> cmake ..
>
> #+end_src
>
> I have also reproduced the warning using a guix shell -C --pure. There's
> just some extra hassle with making the build dir first and sharing the B1
> directory containing the CMakeLists.txt file.
>
> If you use your profile instead of a shell, you can confirm the
> libEGL.so.1 and libGL.so.1 libraries in ~/.guix-profile/lib/ point to the
> same mesa in /gnu/store/ that is installed with the following:
>
> #+begin_src sh
>
> $ guix package -I | grep mesa
> mesa 23.3.2 out
> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2
>
> $ ls -l ~/.guix-profile/lib/ | grep libEGL.so.1
> lrwxrwxrwx 1 root root 71 Jan 1 1970 libEGL.so.1 ->
> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libEGL.so.1
>
> $ ls -l ~/.guix-profile/lib/ | grep libGL.so.1
> lrwxrwxrwx 1 root root 70 Jan 1 1970 libGL.so.1 ->
> /gnu/store/clnk1arbkc6v21a93gxnirvsbjaz5v07-mesa-23.3.2/lib/libGL.so.1
>
> #+end_src
>
> So I'm guessing during the installation of geant4-vis, something is
> bringing in a different mesa from the store
> (/gnu/store/2rzdlwb0f7ksj7a78kjn7a7qs22avi8l-mesa-23.3.2) into the path as
> a runtime dependency.
> I note that qtbase-5 has mesa as a propagated input, so perhaps it's that.
> But it's not clear to me why the mesa propagated for qtbase-5 would be
> different (i.e. has a different /gnu/store/ entry) from the mesa that I
> install in my profile or shell.
> Any suggestions for how to resolve this would be much appreciated.
>
> Thanks!
>
> Jake
>
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --] Hi, I've spent nearly the day on this and it's driving me crazy. I am trying to package this cyvcf2 [1] I am attaching the packaging I've tried. The build is failing with this error: running build_ext # cyvcf2: htslib mode is BUILTIN # cyvcf2: htslib configure options is None error: [Errno 2] No such file or directory: './configure' error: in phase 'build': uncaught exception: %exception #<&invoke-error program: "python" arguments: ("./setup.py" "build") exit-status: 1 term-signal: #f stop-signal: #f> What is very disturbing is that it builds fine in a debugging environment following the documentation [2] The .configure file is present in the failed build, so there must be something going on with the setup.py not managing to change directory to htslib in the build_htslib function. If anyone has any guidelines to debug this further it would be much appreciated. Thanks, Alexis [1] https://github.com/brentp/cyvcf2/ [2] https://guix.gnu.org/manual/en/guix.html#Debugging-Build-Failures [-- Attachment #2: cyvcf2.scm --] [-- Type: text/x-scheme, Size: 2158 bytes --] (define-module (cyvcf2) #:use-module ((guix licenses) #:prefix license:) #:use-module (gnu packages) #:use-module (gnu packages base) #:use-module (gnu packages autotools) #:use-module (gnu packages build-tools) #:use-module (gnu packages cmake) #:use-module (gnu packages check) #:use-module (gnu packages python) #:use-module (gnu packages python-build) #:use-module (gnu packages python-check) #:use-module (gnu packages python-xyz) #:use-module (gnu packages python-science) #:use-module (gnu packages python-web) #:use-module (gnu packages bioinformatics) #:use-module (gnu packages serialization) #:use-module (gnu packages compression) #:use-module (gnu packages curl) #:use-module (gnu packages tls) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix utils) #:use-module (guix build-system python) #:use-module (guix build-system cargo) #:use-module (guix build-system cmake) #:use-module (guix build-system pyproject)) (define-public python-cyvcf2 (package (name "python-cyvcf2") (version "0.30.28") (source (origin (method url-fetch) (uri (pypi-uri "cyvcf2" version)) (sha256 (base32 "03ycp7php5nzvhgj89k8js8z2xm3i8d1f76jlsfdy472f0apgryx")))) (build-system python-build-system) (arguments `(#:use-setuptools? #f #:phases (modify-phases %standard-phases (add-before 'build 'setenv (lambda _ (setenv "CYVCF2_HTSLIB_MODE" "BUILTIN")))))) ; unnecessary (propagated-inputs (list python-click python-coloredlogs python-numpy)) (native-inputs (list zlib libdeflate curl openssl autoconf automake ; htslib python-cython)) (home-page "https://github.com/brentp/cyvcf2/") (synopsis "fast vcf parsing with cython + htslib") (description "fast vcf parsing with cython + htslib") (license license:expat)))
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --] Hi, I've spent nearly the day on this and it's driving me crazy. I am trying to package this cyvcf2 [1] I am attaching the packaging I've tried. The build is failing with this error: running build_ext # cyvcf2: htslib mode is BUILTIN # cyvcf2: htslib configure options is None error: [Errno 2] No such file or directory: './configure' error: in phase 'build': uncaught exception: %exception #<&invoke-error program: "python" arguments: ("./setup.py" "build") exit-status: 1 term-signal: #f stop-signal: #f> What is very disturbing is that it builds fine in a debugging environment following the documentation [2] The .configure file is present in the failed build, so there must be something going on with the setup.py not managing to change directory to htslib in the build_htslib function. If anyone has any guidelines to debug this further it would be much appreciated. Thanks, Alexis [1] https://github.com/brentp/cyvcf2/ [2] https://guix.gnu.org/manual/en/guix.html#Debugging-Build-Failures [-- Attachment #2: cyvcf2.scm --] [-- Type: text/x-scheme, Size: 2158 bytes --] (define-module (cyvcf2) #:use-module ((guix licenses) #:prefix license:) #:use-module (gnu packages) #:use-module (gnu packages base) #:use-module (gnu packages autotools) #:use-module (gnu packages build-tools) #:use-module (gnu packages cmake) #:use-module (gnu packages check) #:use-module (gnu packages python) #:use-module (gnu packages python-build) #:use-module (gnu packages python-check) #:use-module (gnu packages python-xyz) #:use-module (gnu packages python-science) #:use-module (gnu packages python-web) #:use-module (gnu packages bioinformatics) #:use-module (gnu packages serialization) #:use-module (gnu packages compression) #:use-module (gnu packages curl) #:use-module (gnu packages tls) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix utils) #:use-module (guix build-system python) #:use-module (guix build-system cargo) #:use-module (guix build-system cmake) #:use-module (guix build-system pyproject)) (define-public python-cyvcf2 (package (name "python-cyvcf2") (version "0.30.28") (source (origin (method url-fetch) (uri (pypi-uri "cyvcf2" version)) (sha256 (base32 "03ycp7php5nzvhgj89k8js8z2xm3i8d1f76jlsfdy472f0apgryx")))) (build-system python-build-system) (arguments `(#:use-setuptools? #f #:phases (modify-phases %standard-phases (add-before 'build 'setenv (lambda _ (setenv "CYVCF2_HTSLIB_MODE" "BUILTIN")))))) ; unnecessary (propagated-inputs (list python-click python-coloredlogs python-numpy)) (native-inputs (list zlib libdeflate curl openssl autoconf automake ; htslib python-cython)) (home-page "https://github.com/brentp/cyvcf2/") (synopsis "fast vcf parsing with cython + htslib") (description "fast vcf parsing with cython + htslib") (license license:expat)))
Le 19/03/2024 à 16:40, Emmanuel Medernach a écrit : > > Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- > build --no-grafts tensorflow -d > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > > Machine_A # md5sum > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > c7833f974f217ada62b3eb6cdccee11f > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv > > But I cannot copy tensorflow from Machine_A to Machine_B: > > Machine_A # guix package --list-installed | grep tensorflow > tensorflow 2.13.1 out > /gnu/store/jghvlb5dz4sy1p0cd1qx552r1ldj33wi-tensorflow-2.13.1 > > Machine_B # guix copy --from=<Machine_A> tensorflow --dry-run > substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% > substitute: updating substitutes from > 'https://bordeaux.guix.gnu.org'... 100.0% > The following derivations would be built: > /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv > /gnu/store/g90vfnx128ifhgy0n1zmlscjrn57l8xm-tensorflow-2.13.1-bazel-deps.tar.xz.drv > > /gnu/store/h3zcigb52z7m6yyjl785w3a5ls1cjjc7-python-jax-0.4.20.drv > /gnu/store/h9m0ix80glph19k4pfqh130nmkil8f39-python-jaxlib-0.4.20.drv > /gnu/store/m4icdavpvbryliz34ai8817bb1d3l3xr-python-jaxlib-0.4.20.drv > > > Am I doing something wrong ? > > Why 'guix copy' derivation is > /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv > instead of > /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv ? > Here is the diff between the 2 derivations: 1,2c1,2 < Derive([("out","/gnu/store/yhr2vxh26acz3pzpjlph4f82ffrw6icv-tensorflow-2.13.1","","" < ),("python","/gnu/store/fyjpsvfdmkdimd1vx6d99ik01z3x3j93-tensorflow-2.13.1-python","","" --- > Derive([("out","/gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1","","" > ),("python","/gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python","","" 42a43 > ),("/gnu/store/50vi4ywi79irbg71l814xqkww4k1afh2-python-jaxlib-0.4.20.drv",["out"] 61a63 > ),("/gnu/store/8avai81995rj5h7906nzgyrnrpvqi6if-tensorflow-2.13.1-bazel-deps.tar.xz.drv",["out"] 64d65 < ),("/gnu/store/8jfr297mkpv698d4y1cq270a7f03wyh6-bazel-6.3.2.drv",["out"] 75a77 > ),("/gnu/store/an1hq0y3npd66plwghgnccm4sl7lyvka-bazel-6.3.2.drv",["out"] 111d112 < ),("/gnu/store/g90vfnx128ifhgy0n1zmlscjrn57l8xm-tensorflow-2.13.1-bazel-deps.tar.xz.drv",["out"] 123d123 < ),("/gnu/store/h3zcigb52z7m6yyjl785w3a5ls1cjjc7-python-jax-0.4.20.drv",["out"] 127d126 < ),("/gnu/store/h9m0ix80glph19k4pfqh130nmkil8f39-python-jaxlib-0.4.20.drv",["out"] 167a167 > ),("/gnu/store/lvbjhnrdgl5i5z558b1zpvj4vjqzdm4g-python-jax-0.4.20.drv",["out"] 257,258c257,258 < )],["/gnu/store/a5pi7l07irynidrfkiw7x44s8angi2fh-tensorflow-2.13.1-builder","/gnu/store/wkdx6qdj2aikwg6xygymz65ck978xym6-module-import"],"x86_64-linux","/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/wkdx6qdj2aikwg6xygymz65ck978xym6-module-import","-C","/gnu/store/yj6xd6zqbn32zks8cg2nm1sw537zbcsy-module-import-compiled","/gnu/store/a5pi7l07irynidrfkiw7x44s8angi2fh-tensorflow-2.13.1-builder"],[("out","/gnu/store/yhr2vxh26acz3pzpjlph4f82ffrw6icv-tensorflow-2.13.1" < ),("python","/gnu/store/fyjpsvfdmkdimd1vx6d99ik01z3x3j93-tensorflow-2.13.1-python" --- > )],["/gnu/store/r200hqk2jn68qr5wqj6762dpqbns3vqj-tensorflow-2.13.1-builder","/gnu/store/wkdx6qdj2aikwg6xygymz65ck978xym6-module-import"],"x86_64-linux","/gnu/store/g8p09w6r78hhkl2rv1747pcp9zbk6fxv-guile-3.0.9/bin/guile",["--no-auto-compile","-L","/gnu/store/wkdx6qdj2aikwg6xygymz65ck978xym6-module-import","-C","/gnu/store/yj6xd6zqbn32zks8cg2nm1sw537zbcsy-module-import-compiled","/gnu/store/r200hqk2jn68qr5wqj6762dpqbns3vqj-tensorflow-2.13.1-builder"],[("out","/gnu/store/3mq3q11ripx53xg60shbshk7cr470yfx-tensorflow-2.13.1" > ),("python","/gnu/store/qc234r07i3ndgrpa0fdkpkbg4d20h7i1-tensorflow-2.13.1-python" > Cheers, > > Emmanuel
Le 19/03/2024 à 11:26, Simon Tournier a écrit : > Hi Emmanuel, > >> Machine_B # guix copy --from=Machine_A bazel --dry-run >> The following derivation would be built: >> /gnu/store/0lscmi07b2y0aw6hscbgm2h7nqwc6sb1-bazel-6.4.0.drv > Could you share this derivation file? And the one from Machine A? > > To be precise, on Machine B, you should get: > > $ guix time-machine -q -C channels.scm -- build --no-grafts bazel -d > /gnu/store/dnwdzl84cxgk232cwh8843f3dhqmyd69-bazel-6.4.0.drv > > And on Machine A, you get another one, right? Hi Simon, Bazel is now compiled on both machines, but I have similar issue with tensorflow Both have the same derivation file: Machine_A # guix time-machine -q -C ~/.config/guix/channels.scm -- build --no-grafts tensorflow -d /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv Machine_A # md5sum /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv c7833f974f217ada62b3eb6cdccee11f /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv Machine_B # guix time-machine -q -C ~/.config/guix/channels.scm -- build --no-grafts tensorflow -d /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv Machine_B # md5sum /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv c7833f974f217ada62b3eb6cdccee11f /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv The derivation file and channels are both the same on both machines. But I cannot copy tensorflow from Machine_A to Machine_B: Machine_A # guix package --list-installed | grep tensorflow tensorflow 2.13.1 out /gnu/store/jghvlb5dz4sy1p0cd1qx552r1ldj33wi-tensorflow-2.13.1 Machine_B # guix copy --from=<Machine_A> tensorflow --dry-run substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations would be built: /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv /gnu/store/g90vfnx128ifhgy0n1zmlscjrn57l8xm-tensorflow-2.13.1-bazel-deps.tar.xz.drv /gnu/store/h3zcigb52z7m6yyjl785w3a5ls1cjjc7-python-jax-0.4.20.drv /gnu/store/h9m0ix80glph19k4pfqh130nmkil8f39-python-jaxlib-0.4.20.drv /gnu/store/m4icdavpvbryliz34ai8817bb1d3l3xr-python-jaxlib-0.4.20.drv Without dry-run he would try to recompile tensorflow on Machine_B which results in a memory crash. Am I doing something wrong ? Why 'guix copy' derivation is /gnu/store/4g2whbzgn5nqs55x9iqgg23jdapf1srk-tensorflow-2.13.1.drv instead of /gnu/store/s6fm43503ra6yxclqvk80gfiw4zxbp91-tensorflow-2.13.1.drv ? Cheers, Emmanuel > For instance, run this command on both machines: > > cp \ > $(guix time-machine -q -C channels.scm -- build --no-grafts bazel -d) \ > /tmp/machine-X.drv > > where X is A or B, respectively. > > These files track exactly how the item is built (derived). Therefore, > since the hash of the output differs, you should differ somewhere. > Previously, you checked about the inputs, now we need to compare the > complete derivation. > > > Cheers, > simon > > PS: Please note that the content of two store items might be bit-to-bit > identical with different store item paths (hash). > > Consider the example with the exact same source where the difference > is just one comment somewhere in the code. Then, their hashes are > different. However, once compiled the binaries are identical > (compiler usually removes comments). > > Since the hash of one input (source) differs, then the store item > paths are different but the content of these both store items are > bit-to-bit identical. > > The machinery to track down the origin of the difference is all > these derivation .drv files.
Hi Emmanuel,
> Machine_B # guix copy --from=Machine_A bazel --dry-run
> The following derivation would be built:
> /gnu/store/0lscmi07b2y0aw6hscbgm2h7nqwc6sb1-bazel-6.4.0.drv
Could you share this derivation file? And the one from Machine A?
To be precise, on Machine B, you should get:
$ guix time-machine -q -C channels.scm -- build --no-grafts bazel -d
/gnu/store/dnwdzl84cxgk232cwh8843f3dhqmyd69-bazel-6.4.0.drv
And on Machine A, you get another one, right?
For instance, run this command on both machines:
cp \
$(guix time-machine -q -C channels.scm -- build --no-grafts bazel -d) \
/tmp/machine-X.drv
where X is A or B, respectively.
These files track exactly how the item is built (derived). Therefore,
since the hash of the output differs, you should differ somewhere.
Previously, you checked about the inputs, now we need to compare the
complete derivation.
Cheers,
simon
PS: Please note that the content of two store items might be bit-to-bit
identical with different store item paths (hash).
Consider the example with the exact same source where the difference
is just one comment somewhere in the code. Then, their hashes are
different. However, once compiled the binaries are identical
(compiler usually removes comments).
Since the hash of one input (source) differs, then the store item
paths are different but the content of these both store items are
bit-to-bit identical.
The machinery to track down the origin of the difference is all
these derivation .drv files.
Le 15/03/2024 à 15:37, Emmanuel Medernach a écrit :
>
> Le 15/03/2024 à 15:10, Andreas Enge a écrit :
>> Hello,
>>
>> Am Fri, Mar 15, 2024 at 02:58:23PM +0100 schrieb Emmanuel Medernach:
>>> Now on both machines guix and guix-daemon used are the same, here
>>> are both
>>> paths:
>>> /gnu/store/m79ld7h62wjbx6kc2jip73lmh8lfc8qs-guix-command
>>> /gnu/store/z642sncd5jgj4bc3p18rdqwdkq30p833-guix-daemon
>>> When I try a guix copy the requested hash is still different from
>>> the one on
>>> Machine_A (and it wishes to recompile it):
>> just a wild guess, but could it be that you did a "guix gc" on Machine A
>> and that there are grafts in play? In that case the ungrafted package
>> may
>> have been deleted, and will then be recomputed.
>>
>> Maybe you could try the same operation adding --no-grafts to the
>> command.
>
> Thanks for your idea, here is the result:
>
> Machine_A # guix package --manifest="$HOME"/manifests/bazel.scm
> --no-grafts --no-substitutes
> Machine_A # guix package --list-installed | grep bazel
> bazel 6.4.0 out
> /gnu/store/8xmcsk5jrkxb06whgj0fif0mrxvhyvj6-bazel-6.4.0
>
> The hash has changed but is still not the one requested by Machine_B
> with guix copy (same message there)
>
> I cannot publish from Machine_A to Machine_B (but I don't know if that
> would be better or not)
>
Ok for the time being I give up and will compile bazel on Machine_B, but
I am curious why the hash requested from Machine_B is not the one built
on Machine_A ?
The problem is that I will have many machines like Machine_B and I would
like to avoid recompilation of packages on all of them if possible.
Emmanuel
Le 15/03/2024 à 15:10, Andreas Enge a écrit : > Hello, > > Am Fri, Mar 15, 2024 at 02:58:23PM +0100 schrieb Emmanuel Medernach: >> Now on both machines guix and guix-daemon used are the same, here are both >> paths: >> /gnu/store/m79ld7h62wjbx6kc2jip73lmh8lfc8qs-guix-command >> /gnu/store/z642sncd5jgj4bc3p18rdqwdkq30p833-guix-daemon >> When I try a guix copy the requested hash is still different from the one on >> Machine_A (and it wishes to recompile it): > just a wild guess, but could it be that you did a "guix gc" on Machine A > and that there are grafts in play? In that case the ungrafted package may > have been deleted, and will then be recomputed. > > Maybe you could try the same operation adding --no-grafts to the command. Thanks for your idea, here is the result: Machine_A # guix package --manifest="$HOME"/manifests/bazel.scm --no-grafts --no-substitutes Machine_A # guix package --list-installed | grep bazel bazel 6.4.0 out /gnu/store/8xmcsk5jrkxb06whgj0fif0mrxvhyvj6-bazel-6.4.0 The hash has changed but is still not the one requested by Machine_B with guix copy (same message there) I cannot publish from Machine_A to Machine_B (but I don't know if that would be better or not) Emmanuel > Andreas >
Hello,
Am Fri, Mar 15, 2024 at 02:58:23PM +0100 schrieb Emmanuel Medernach:
> Now on both machines guix and guix-daemon used are the same, here are both
> paths:
> /gnu/store/m79ld7h62wjbx6kc2jip73lmh8lfc8qs-guix-command
> /gnu/store/z642sncd5jgj4bc3p18rdqwdkq30p833-guix-daemon
> When I try a guix copy the requested hash is still different from the one on
> Machine_A (and it wishes to recompile it):
just a wild guess, but could it be that you did a "guix gc" on Machine A
and that there are grafts in play? In that case the ungrafted package may
have been deleted, and will then be recomputed.
Maybe you could try the same operation adding --no-grafts to the command.
Andreas
Le 15/03/2024 à 10:21, Emmanuel Medernach a écrit : > > Le 15/03/2024 à 10:14, Emmanuel Medernach a écrit : >> Hello, >> >> I have problems with guix copy: I have 2 machines Machine_A and >> Machine_B. They both have the same channels. Machine_B is slow (I >> don't want to recompile there, I would like to reuse the same >> packages from Machine_A). Machine_A and Machine_B have limited >> connectivity, Machine_A has only ssh access (I cannot use it as a >> substitute with guix publish) and Machine_B has nothing. >> >> I installed bazel on Machine_A: >> >> > If that could help, here is a minimal manifest and command I use to > install it in an extra profile: > > (specifications->manifest > '("glibc-locales" > "bazel" > )) > > # guix package --manifest="$HOME"/manifests/bazel.scm > --profile="$GUIX_EXTRA_PROFILES"/bazel/profile > > >> Machine_A # guix build bazel >> /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0 >> Machine_A # readlink -f $GUIX_EXTRA_PROFILES/bazel/profile/bin/bazel >> /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0/bin/bazel >> >> I tried guix copy, but I have 2 problems: >> >> First, Machine_B asks for a different hash that the one I have on >> Machine_A (even if both have the same channels): >> I tried a guix pull as a user and as root on both machines. Now on both machines guix and guix-daemon used are the same, here are both paths: /gnu/store/m79ld7h62wjbx6kc2jip73lmh8lfc8qs-guix-command /gnu/store/z642sncd5jgj4bc3p18rdqwdkq30p833-guix-daemon When I try a guix copy the requested hash is still different from the one on Machine_A (and it wishes to recompile it): Machine_B # guix copy --dry-run --from=Machine_A bazel The following derivations would be built: /gnu/store/0lscmi07b2y0aw6hscbgm2h7nqwc6sb1-bazel-6.4.0.drv /gnu/store/gssvcsrhq6j2pifavjzw00h8wqlx05km-java-commons-compress-1.21.drv /gnu/store/l8z82vbw16nq70w3fnjj4jkwk389lkbh-java-xz-1.9.drv /gnu/store/h03jjkqcps6xw0x4hgxph4rwynzg7n07-bazel-6.4.0-dist.tar.xz.drv /gnu/store/var9aniprgbyg2w0i1fhgzsmjbqdv5cp-bazel-6.4.0-dist.zip.drv /gnu/store/ggg0r1jxp8vvk3sfva6kgc0vsrrlzzb1-zipbomb-bazel-6.4.0-dist.zip.drv 681.5 MB would be downloaded: /gnu/store/anzqriqq31ai85ifmn2iiisqyqrs2388-openjdk-11.0.22-jdk /gnu/store/qjnlrsvp0j04hhbxh8a4xi7d76bg1s47-openjdk-9.181-jdk /gnu/store/ng26zmv0w15cq6zg8v13604labaxllz2-gtk+-2.24.33 /gnu/store/gab2vx6lrncbpb8w351rwhjwfd30496w-icedtea-3.19.0-jdk /gnu/store/wjg1al20skmbczzmli1q8zg6ayq0dhnn-grpc-1.34.0 What am I missing ? Thanks for your help Best regards, Emmanuel Medernach >> Machine_B # guix copy --from=Machine_A --dry-run bazel >> guix copy: error: no such item on remote host 'Machine_A': >> /gnu/store/6n69a11yjydwhb7p8kb6qg20nj5cxrg1-bazel-6.4.0 >> >> Second, when I try to copy the package with the hash from Machine_A I >> get an error: >> >> Machine_B # guix copy --from=Machine_A --dry-run >> /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0 >> retrieving 1 store item from 'Machine_A'... >> guix copy: error: implementation cannot deal with > 32-bit integers >> >> How to use guix copy to transfer the same packages from one machine >> to another ? >> >> Here are my current channels: >> >> (list (channel >> (name 'guix-science) >> (url "https://github.com/guix-science/guix-science.git") >> (branch "master") >> (commit >> "61836bfd9c3a01b696142aabb625b0851d6fd536") >> (introduction >> (make-channel-introduction >> "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc" >> (openpgp-fingerprint >> "CA4F 8CF4 37D7 478F DA05 5FD4 4213 7701 1A37 8446")))) >> (channel >> (name 'guix) >> (url "https://git.savannah.gnu.org/git/guix.git") >> (branch "master") >> (commit >> "7319b4d5286d31a9c6a889e81af72308efdaab41") >> (introduction >> (make-channel-introduction >> "9edb3f66fd807b096b48283debdcddccfea34bad" >> (openpgp-fingerprint >> "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) >> >> Thanks for your help >> >> Best regards, >> >> Emmanuel Medernach >> >
Le 15/03/2024 à 10:14, Emmanuel Medernach a écrit : > Hello, > > I have problems with guix copy: I have 2 machines Machine_A and > Machine_B. They both have the same channels. Machine_B is slow (I > don't want to recompile there, I would like to reuse the same packages > from Machine_A). Machine_A and Machine_B have limited connectivity, > Machine_A has only ssh access (I cannot use it as a substitute with > guix publish) and Machine_B has nothing. > > I installed bazel on Machine_A: > > If that could help, here is a minimal manifest and command I use to install it in an extra profile: (specifications->manifest '("glibc-locales" "bazel" )) # guix package --manifest="$HOME"/manifests/bazel.scm --profile="$GUIX_EXTRA_PROFILES"/bazel/profile > Machine_A # guix build bazel > /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0 > Machine_A # readlink -f $GUIX_EXTRA_PROFILES/bazel/profile/bin/bazel > /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0/bin/bazel > > I tried guix copy, but I have 2 problems: > > First, Machine_B asks for a different hash that the one I have on > Machine_A (even if both have the same channels): > > Machine_B # guix copy --from=Machine_A --dry-run bazel > guix copy: error: no such item on remote host 'Machine_A': > /gnu/store/6n69a11yjydwhb7p8kb6qg20nj5cxrg1-bazel-6.4.0 > > Second, when I try to copy the package with the hash from Machine_A I > get an error: > > Machine_B # guix copy --from=Machine_A --dry-run > /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0 > retrieving 1 store item from 'Machine_A'... > guix copy: error: implementation cannot deal with > 32-bit integers > > How to use guix copy to transfer the same packages from one machine to > another ? > > Here are my current channels: > > (list (channel > (name 'guix-science) > (url "https://github.com/guix-science/guix-science.git") > (branch "master") > (commit > "61836bfd9c3a01b696142aabb625b0851d6fd536") > (introduction > (make-channel-introduction > "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc" > (openpgp-fingerprint > "CA4F 8CF4 37D7 478F DA05 5FD4 4213 7701 1A37 8446")))) > (channel > (name 'guix) > (url "https://git.savannah.gnu.org/git/guix.git") > (branch "master") > (commit > "7319b4d5286d31a9c6a889e81af72308efdaab41") > (introduction > (make-channel-introduction > "9edb3f66fd807b096b48283debdcddccfea34bad" > (openpgp-fingerprint > "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) > > Thanks for your help > > Best regards, > > Emmanuel Medernach >
Hello, I have problems with guix copy: I have 2 machines Machine_A and Machine_B. They both have the same channels. Machine_B is slow (I don't want to recompile there, I would like to reuse the same packages from Machine_A). Machine_A and Machine_B have limited connectivity, Machine_A has only ssh access (I cannot use it as a substitute with guix publish) and Machine_B has nothing. I installed bazel on Machine_A: Machine_A # guix install bazel Machine_A # guix build bazel /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0 Machine_A # readlink -f $GUIX_EXTRA_PROFILES/bazel/profile/bin/bazel /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0/bin/bazel I tried guix copy, but I have 2 problems: First, Machine_B asks for a different hash that the one I have on Machine_A (even if both have the same channels): Machine_B # guix copy --from=Machine_A --dry-run bazel guix copy: error: no such item on remote host 'Machine_A': /gnu/store/6n69a11yjydwhb7p8kb6qg20nj5cxrg1-bazel-6.4.0 Second, when I try to copy the package with the hash from Machine_A I get an error: Machine_B # guix copy --from=Machine_A --dry-run /gnu/store/5i872l0ijm7vd9vk2knn67ai3daa6q68-bazel-6.4.0 retrieving 1 store item from 'Machine_A'... guix copy: error: implementation cannot deal with > 32-bit integers How to use guix copy to transfer the same packages from one machine to another ? Here are my current channels: (list (channel (name 'guix-science) (url "https://github.com/guix-science/guix-science.git") (branch "master") (commit "61836bfd9c3a01b696142aabb625b0851d6fd536") (introduction (make-channel-introduction "b1fe5aaff3ab48e798a4cce02f0212bc91f423dc" (openpgp-fingerprint "CA4F 8CF4 37D7 478F DA05 5FD4 4213 7701 1A37 8446")))) (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (branch "master") (commit "7319b4d5286d31a9c6a889e81af72308efdaab41") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) Thanks for your help Best regards, Emmanuel Medernach
>mar. 12 mars 2024 at 09:59, Pascal Quach <pascal.quach@centralesupelec.fr> wrote: > Hello, > > I see you tried with both the intel ahd intel_hasvk, have you tried lvp? So now I tried with export VK_DRIVER_FILES=/usr/share/vulkan/icd.d/intel_hasvk_icd.x86_64.json:/usr/share/vulkan/icd.d/intel_icd.x86_64.json:/usr/share/vulkan/icd.d/lvp_icd.x86_64.json julia ... ... same error as always. Here is the full trace: Failed to precompile GLMakie [e9467ef8-e4e7-5192-8a1a-b1aee30e663a] to "~/.julia/compiled/v1.9/GLMakie/jl_5GnWul". ┌ Warning: GLFW couldn't create an OpenGL window. │ This likely means, you don't have an OpenGL capable Graphic Card, │ or you don't have an OpenGL 3.3 capable video driver installed. │ Have a look at the troubleshooting section in the GLMakie readme: │ https://github.com/MakieOrg/Makie.jl/tree/master/GLMakie#troubleshooting-opengl. └ @ GLMakie ~/.julia/packages/GLMakie/QyIWu/src/screen.jl:250 ERROR: LoadError: GLFWError (API_UNAVAILABLE): GLX: No GLXFBConfigs returned Stacktrace: [1] _ErrorCallbackWrapper(code::Int32, description::Cstring) @ GLFW ~/.julia/packages/GLFW/BWxfF/src/callback.jl:43 [2] CreateWindow(width::Int64, height::Int64, title::String, monitor::GLFW.Monitor, share::GLFW.Window) @ GLFW ~/.julia/packages/GLFW/BWxfF/src/glfw3.jl:499 [3] GLFW.Window(; name::String, resolution::Tuple{Int64, Int64}, debugging::Bool, major::Int64, minor::Int64, windowhints::Vector{Tuple{UInt32, Integer}}, contexthints::Vector{Tuple{UInt32, Integer}}, visible::Bool, focus::Bool, fullscreen::Bool, monitor::Nothing, share::GLFW.Window) @ GLFW ~/.julia/packages/GLFW/BWxfF/src/glfw3.jl:344 [4] Window @ ~/.julia/packages/GLFW/BWxfF/src/glfw3.jl:302 [inlined] [5] empty_screen(debugging::Bool; reuse::Bool) @ GLMakie ~/.julia/packages/GLMakie/QyIWu/src/screen.jl:241 [6] empty_screen @ ~/.julia/packages/GLMakie/QyIWu/src/screen.jl:222 [inlined] [7] singleton_screen(debugging::Bool) @ GLMakie ~/.julia/packages/GLMakie/QyIWu/src/screen.jl:329 [8] macro expansion @ ~/.julia/packages/GLMakie/QyIWu/src/precompiles.jl:21 [inlined] [9] macro expansion @ ~/.julia/packages/PrecompileTools/L8A3n/src/workloads.jl:78 [inlined] [10] macro expansion @ ~/.julia/packages/GLMakie/QyIWu/src/precompiles.jl:18 [inlined] [11] macro expansion @ ~/.julia/packages/PrecompileTools/L8A3n/src/workloads.jl:140 [inlined] [12] top-level scope @ ~/.julia/packages/GLMakie/QyIWu/src/precompiles.jl:16 [13] include(mod::Module, _path::String) @ Base ./Base.jl:457 [14] include(x::String) @ GLMakie ~/.julia/packages/GLMakie/QyIWu/src/GLMakie.jl:1 [15] top-level scope @ ~/.julia/packages/GLMakie/QyIWu/src/GLMakie.jl:79 [16] include @ ./Base.jl:457 [inlined] [17] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing) @ Base ./loading.jl:2052 [18] top-level scope @ stdin:3 in expression starting at ~/.julia/packages/GLMakie/QyIWu/src/precompiles.jl:15 in expression starting at ~/.julia/packages/GLMakie/QyIWu/src/GLMakie.jl:1 in expression starting at stdin:3 Thanks, C.
It comes with vulkan-swrast!
Le 12/03/2024 à 13:48, Cayetano Santos a écrit :
>
>> mar. 12 mars 2024 at 09:59, Pascal Quach <pascal.quach@centralesupelec.fr> wrote:
>
>> Hello,
>>
>> I see you tried with both the intel ahd intel_hasvk, have you tried lvp?
>
> I tried with what I have under /usr/share/vulkan/icd.d.
>
> No idea on how to handle lvp, though.
>
> C.