bug#67944: Broken package: emacs-mu4e-conversation
Hi guix, As for the project readme, "Warning: As of 2021-01-06 this package is broken since mu4e has made changes to its protocol." We should probably remove it from guix. C.
bug#53211: Fixed
bug#63986: Julia is very slow
>mer. 20 sept. 2023 at 17:57, Simon Tournier wrote: > Hi Efraim, > Any idea? I have no idea and it is blocking the merge because ~20 > packages are then broken. Well, if we have no idea, I will push the fix > for “Julia is slow” and we will fix later these ~20 failures. WDYT? Sounds good to me. C.
bug#63986: Fixed.
bug#63986: Julia is very slow
>jeu. 14 sept. 2023 at 13:33, Efraim Flashner wrote: > [[PGP Signed Part:Undecided]] > On Sun, Aug 20, 2023 at 10:53:44PM +0200, Ludovic Courtès wrote: >> Hi! >> >> Friendly ping. :-) >> >> https://issues.guix.gnu.org/63986 >> >> Ludo’. >> >> Ludovic Courtès skribis: >> >> > Hi there! >> > >> > What’s the status? Sounds like we have a couple of fixes already. >> > >> > Maybe you can submit one of them to guix-patc...@gnu.org so qa.guix can >> > pick it up. And if one of them is more intrusive (more rebuilds), then >> > submit it separately so it gets merged later? How does that sound? >> > >> > Ludo’. > > I've attached a diff to adjust openblas64 and to use it for x86_64 in > julia. I don't know if it's faster than the current openblas. I have applied the patch in a freshly cloned guix repo, and build julia within a shell as for the instructions under ’Contributing’. I get the 13 ms when running the original test, so I guess the issue is solved (other than thinking about the feasibility of performance tests to avoid this kind of situations). Thanks a lot ! C.
bug#65524: Fixed.
bug#65524: errors in pack symlink
>ven. 25 août 2023 at 16:33, Hilton Chain wrote: > Hi Cayetano, > > On Fri, 25 Aug 2023 15:50:53 +0800, > Cayetano Santos via Bug reports for GNU Guix wrote: >> >> >> Hello guix, >> >> I’m doing a simple >> >> guix pack -S /.guix-profile/bin=bin mg >> >> with no issue. >> >> However, when I replace ’bin’ by ’sbin’, ’libexec’ or ’src’ I get an >> error. >> >> guix pack -S /.guix-profile/libexec=libexec mg >> >> This used to perform correctly. Is that an expected behaviour ? >> >> I’m using "738b0e4" from yesterday. > > I don't know about the previous state, but currently mg and the > produced profile used by guix pack don't contain sbin, libexec or src: > > $ ls /gnu/store/m11qlw60b4chz37cysqxg6kpixnqjld5-mg-20221112/ > bin/ etc/ share/ > > $ ls /gnu/store/5qn8s8qdlvxv1aj9dsh4bffbxqd9xbjn-profile/ > bin@ etc/ share/ manifest You’re right. This is probably the reason, I have misunderstood the way it is done. Thanks, C.
bug#65524: errors in pack symlink
Hello guix, I’m doing a simple guix pack -S /.guix-profile/bin=bin mg with no issue. However, when I replace ’bin’ by ’sbin’, ’libexec’ or ’src’ I get an error. guix pack -S /.guix-profile/libexec=libexec mg This used to perform correctly. Is that an expected behaviour ? I’m using "738b0e4" from yesterday. Best, Cayetano Santos
bug#65127: Python-pytorch slow
>lun. 07 août 2023 at 16:50, Cayetano Santos wrote: > Hi guix, > > I just noticed that the following line (latest guix, as for today) > > guix shell -C --emulate-fhs --network python python-pytorch > python-torchvision -- python3 quickstart_tutorial.py > > with > > > https://raw.githubusercontent.com/pytorch/tutorials/main/beginner_source/basics/quickstart_tutorial.py > > is noticeably slower than the version of the torch suite provided by > conda, for example. By this I meant when only using CPU, not GPU. C.
bug#65474: Bug in python-notebook
Hi guix, I have just updated by local copy of guix with guix pull At this point, a simple guix pack python-notebook gives me an error message related to a failed compilation in /gnu/store/8wf5h68zm5lf9n157qbwdfmqz8dfpczq-texlive-font-maps.drv The compilation journal gives the following Backtrace: 3 (primitive-load "/gnu/store/4msdwzccfp51zhmnkr61vvpdllz?") In ice-9/eval.scm: 619:8 2 (_ #f) In ice-9/boot-9.scm: 140:2 1 (dynamic-wind # ?) In unknown file: 0 (chdir "/tmp/texlive/share/texmf-dist") ERROR: In procedure chdir: In procedure chdir: No such file or directory Thanks, Cayetano Santos
bug#61967: Fixed.
bug#58993: Closing. Issue fixed.
bug#65127: Python-pytorch slow
Hi guix, I just noticed that the following line (latest guix, as for today) guix shell -C --emulate-fhs --network python python-pytorch python-torchvision -- python3 quickstart_tutorial.py with https://raw.githubusercontent.com/pytorch/tutorials/main/beginner_source/basics/quickstart_tutorial.py is noticeably slower than the version of the torch suite provided by conda, for example. Thanks, Cayetano Santos
bug#63986: Julia is very slow
> Looks like it should be "LIBBLAS=-lopenblas" > > It might need some tuning anyway, currently we have julia for i686 and > switching to solely openblas-ilp64 we'd lose 32-bit support. > > I also noticed the julia expects the 64-bit openblas to be libopenblas64 > (which happens to be what Debian¹ has). Would we need to adapt anything > in stdlib/OpenBLAS_jll/src/OpenBLAS_jll.jl? > > Also, are we supposed to build lapack with our openblas as an input? Being used to Arch, it seems to me the way they do things is the way to go, or at least, a good reference (other than the support for 32-bit) https://archlinux.org/packages/?sort==blas== https://gitlab.archlinux.org/archlinux/packaging/packages/julia/-/blob/main/PKGBUILD C.
bug#63986: Julia is very slow
>mer. 21 juin 2023 at 22:39, Cayetano Santos wrote:
>>mer. 21 juin 2023 at 16:36, Ludovic Courtès wrote:
>
>> Hey!
>>
>> The benchmark you posted, Cayetano, is:
>>
>> julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N =
>> 1000; A = rand(N, N); B = rand(N, N); @btime $A*$B'
>>
>> This is a matrix multiplication that gets delegated to the underlying
>> BLAS right. Running it under ‘perf record’ confirms it:
>>
>> Samples: 139K of event 'cycles:u', Event count (approx.): 99624880590
>> Overhead Command Shared Object Symbol
>> 35.27% .julia-real libblas.so.3.9.0[.] dgemm_
>>3.99% .julia-real libjulia-internal.so.1.8[.] gc_mark_loop
>>2.60% .julia-real libjulia-internal.so.1.8[.] apply_cl
>>1.06% .julia-real libjulia-internal.so.1.8[.] jl_get_binding_
>>
>> We’re using libblas.so (presumably from the ‘lapack’ package) and not
>> OpenBLAS, so no wonder it’s slow.
>>
>> Could it be that:
>>
>> "LIBBLAS=-lopenblas"
>> "LIBBLASNAME=libopenblas"
>>
>> is ineffective? I think we have a lead!
>
> Are we following all instructions here ?
>
>
> https://docs.julialang.org/en/v1.8/devdocs/build/distributing/#Notes-on-BLAS-and-LAPACK
>
> I’m thinking about the variables LIBLAPACK and LIBLAPACKNAME.
To complete my previous comment, I just realised that
Base.USE_BLAS64
gives "true" when running fast. Guix julia gives "false".
C.
bug#63986: Julia is very slow
>mer. 21 juin 2023 at 16:36, Ludovic Courtès wrote:
> Hey!
>
> The benchmark you posted, Cayetano, is:
>
> julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N =
> 1000; A = rand(N, N); B = rand(N, N); @btime $A*$B'
>
> This is a matrix multiplication that gets delegated to the underlying
> BLAS right. Running it under ‘perf record’ confirms it:
>
> Samples: 139K of event 'cycles:u', Event count (approx.): 99624880590
> Overhead Command Shared Object Symbol
> 35.27% .julia-real libblas.so.3.9.0[.] dgemm_
>3.99% .julia-real libjulia-internal.so.1.8[.] gc_mark_loop
>2.60% .julia-real libjulia-internal.so.1.8[.] apply_cl
>1.06% .julia-real libjulia-internal.so.1.8[.] jl_get_binding_
>
> We’re using libblas.so (presumably from the ‘lapack’ package) and not
> OpenBLAS, so no wonder it’s slow.
>
> Could it be that:
>
> "LIBBLAS=-lopenblas"
> "LIBBLASNAME=libopenblas"
>
> is ineffective? I think we have a lead!
Are we following all instructions here ?
https://docs.julialang.org/en/v1.8/devdocs/build/distributing/#Notes-on-BLAS-and-LAPACK
I’m thinking about the variables LIBLAPACK and LIBLAPACKNAME.
C.
bug#63986: Julia is very slow
Hi guix,
I just noticed that the following line
julia -e 'using Pkg; Pkg.add("BenchmarkTools"); using BenchmarkTools; N =
1000; A = rand(N, N); B = rand(N, N); @btime $A*$B'
gives around 530 ms in my laptop when using guix provided julia. Same
behavior when running within a guix container.
This very same code, using the binary one may download from the julia
site gives 15 ms.
I’m using here an up to date guix. As a reference, julia binary
provided by archlinux takes also 15 ms.
Thanks,
Cayetano Santos
bug#61967: guix pack error with python packages
Hello guix, I’m trying to deploy a test set of python packages to a remote server, using the following guix pack command (latest guix, as for now) guix pack -R --compression=xz --save-provenance \ -S /.guix-profile/bin=bin -S /.guix-profile/share=share \ -S /.guix-profile/etc=etc -S /.guix-profile/lib=lib \ -S /.guix-profile/include=include The resulting file.tar.xz is sent to the server with scp file.tar.xz server:/dir1/dir2/. Then, when I ssh server cd /dir1/dir2 I do a tar xf file.tar.xz At this point, a ’ls /dir1/dir2’ shows, as expected .guix-profile gnu file.tar.xz Now, when I just (PYTHONPATH is empty at this point) /dir1/dir2/.guix-profile/bin/python3 -c \ "import sys; print(sys.path)" I get /dir1/dir2/hj...python... /dir1/dir2/hj...numpy... /dir1/dir2/hj...matplotlib... instead of /dir1/dir2/gnu/store/hj...python... /dir1/dir2/gnu/store/hj...numpy... /dir1/dir2/gnu/store/hj...matplotlib... so that when I /dir1/dir2/.guix-profile/bin/python3 -c "import numpyt" I get an error ModuleNotFoundError: No module named 'numpy' If, however, I export GUIX_PROFILE=/dir1/dir2/.guix-profile source $GUIX_PROFILE/etc/profile export PYTHONPATH=$GUIX_PYTHONPATH and then /dir1/dir2/.guix-profile/bin/python3 I have Error processing line 1 of /dir1/dir2/.guix-profile/lib/python3.9/site-packages/matplotlib-3.5.2-py3.9-nspkg.pth: Trying to ’import numpy’ gives Traceback (most recent call last): File "", line 1, in File "/dir1/dir2/.guix-profile/lib/python3.9/site-packages/numpy/__init__.py", line 110, in import warnings ModuleNotFoundError: No module named 'warnings' Am I doing something wrong ? Is this a bug ? Thanks, Cayetano Santos
bug#58993: Duplicity BackendException: No module named b2sdk
Context: Using latest guix as a package manager under a foreign up to date archlinux distribution. Problem: When using duplicity to backup to a sftp server, I get this error message BackendException: Could not initialize backend: No module named 'b2sdk' As a reference, see https://issues.guix.gnu.org/49979.
bug#53940: Wrong gcc path ?
Hello Guix, I'm building a container with 'guix shell --container', and including gcc-toolchain. Under /gnu/store I get gcc 11.2 as well as gcc 10.3, both with -lib directories. Problem is I get an error about GLIBCXX_3.4.29 missing. My software compiles (and finds) the wrong gcc 10.3 lib, and not the correct 11.2. How can I set the correct gcc libs ? I have located the folder, but the random hash makes it unusable. I mean, setting LD_LIBRARY_PATH solves the problem, but, how to guess the right one ? To reproduce the problem, I have created an example repository here: https://gitlab.in2p3.fr/csantos/examples/guix-issue Is that related to guix ? Thanks, Cayetano Santos
bug#52347: Shell: error when -m manifest is removed
mar. 07 déc. 2021 at 12:02, Maxime Devos ... What's the error message? Output to ’guix shell --container -- python3’ gives guix shell: avertissement : aucun paquet spécifié ; création d'un environnement vide guix shell: erreur : python3: command not found Backtrace: 16 (primitive-load "/usr/local/bin/guix") In guix/ui.scm: 2206:7 15 (run-guix . _) 2169:10 14 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 13 (with-exception-handler _ _ #:unwind? _ # _) 1752:10 12 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 658:37 11 (thunk) 1320:8 10 (call-with-build-handler _ _) 1320:8 9 (call-with-build-handler # g…> …) In guix/status.scm: 800:4 8 (call-with-status-report _ _) In guix/scripts/environment.scm: 951:12 7 (_) In guix/store.scm: 2119:24 6 (run-with-store # 7fbb2132ccd0> …) In guix/scripts/environment.scm: 627:17 5 (_ _) 576:23 4 (validate-exit-status _ _ 32512) In guix/utils.scm: 954:4 3 (string-closest _ _ #:threshold _) In guix/combinators.scm: 46:32 2 (fold2 # guix/utils.scm:954:…> …) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure car: Wrong type argument in position 1 (expecting pair): #f
bug#52347: Shell: error when -m manifest is removed
mar. 07 déc. 2021 at 11:35, zimoun ... Hi, On Tue, 7 Dec 2021 at 11:25, Cayetano Santos wrote: Is it expected to fail when I remove the ’-m manifest’ flag and I just run ’guix shell -C -- python3’ ? The command "guix shell -C -- python3" fails. It cannot work, because the environment (new shell) is empty. You need to provide what this shell has to contain, via command line package list or via manifest. To my understanding, in this blog entry https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/ they claim that "guix shell automatically loads guix.scm or manifest.scm, from the current directory" No need to "-m manifest.scm", then. C.
bug#52347: Shell: error when -m manifest is removed
mar. 07 déc. 2021 at 11:18, zimoun ... Hi, On Tue, 7 Dec 2021 at 11:10, Cayetano Santos wrote: Problem is guix shell -C -- python3 Tried after ’guix pull’ and problem remains. Which revision do you use? Because using f43a783, it fails as expected. :-) I’m using guix 05deb26. Is it expected to fail when I remove the ’-m manifest’ flag and I just run ’guix shell -C -- python3’ ? Are you running Guix on foreign distro or Guix System? Foreign, on top of ArchLinux. C.
bug#52347: Shell: error when -m manifest is removed
Problem is guix shell -C -- python3 Tried after ’guix pull’ and problem remains. C. mar. 07 déc. 2021 at 10:26, zimoun ... Hi, On Tue, 7 Dec 2021 at 09:41, Cayetano Santos via Bug reports for GNU Guix wrote: guix shell --container followed by python3 works. It works correctly for me. With Guix f43a783: --8<---cut here---start->8--- $ guix shell -C -m manifest.scm -- python3 -c 'import this' $ guix shell -C -m manifest.scm [env]$ python3 -c 'import this' $ guix shell -C guix shell: warning: no packages specified; creating an empty environment guix shell: warning: no packages specified; creating an empty environment [env]$ python3 sh: python3: command not found [env]$ $GUIX_ENVIRONMENT/bin/python3 sh: /gnu/store/h3al0y1pbr64gcjhmn4wn3v863vhc72a-profile/bin/python3: No such file or directory [env]$ $GUIX_ENVIRONMENT/bin sh: /gnu/store/h3al0y1pbr64gcjhmn4wn3v863vhc72a-profile/bin: No such file or directory $ tree /gnu/store/h3al0y1pbr64gcjhmn4wn3v863vhc72a-profile /gnu/store/h3al0y1pbr64gcjhmn4wn3v863vhc72a-profile ├── etc │ └── profile └── manifest 1 directory, 2 files --8<---cut here---end--->8--- Cheers, simon
bug#52348: Error installing pytorch and tensorflow
Hi guix, By just issuing a guix install python-pytorch tensorflow I get a conflict error with python-protobuf (3.6.1 and 3.12.4). However, when I guix shell --container python-pytorch tensorflow I manage to create an environment with no issue. Finally, with ’guix pack ...’ I get the same error as before. Best, Cayetano Santos
bug#52347: Shell: error when -m manifest is removed
Hi guix, Using latest guix, and considering a local manifest.scm file with only (specifications->manifest (list "python")) Following command works guix shell --container -m manifest.scm -- python3 But guix shell --container -- python3 gives an error. However, guix shell --container followed by python3 works. So, by just removing the ’-m manifest.scm’ flag, I get an error. Regards, Cayetano Santos
