bug#69394: cross-gcc-toolchain for riscv64 doesn't search crt1.o properly
Hello Ekaitz, This problem is also present for other targets such as AVR[1] as when I introduced the cross-gcc-toolchain procedure I didn't add the NATIVE-SEARCH-PATHS and SEARCH-PATHS fields for the toolchains as: 1. SEARCH-PATHS doesn't quite work with shells right now, as it is impossible to create a profile with cross packages. E.g. trying to use gcc-cross-avr-toolchain and unity built for AVR. So it is a bit useless, unless the toolchain is used inside of GNU Guix as a NATIVE-INPUT, but STANDARD-CROSS-PACKAGES takes care of this in GNU-BUILD-SYSTEM by adding cross-gcc and cross-libc as inputs. 2. The other solution is to use NATIVE-SEARCH-PATHS but when using mixed toolchains in a single environment all of the cross compilers will share this environment variable. For example: guix shell gcc-cross-avr-toolchain gcc-cross-i686-w64-mingw32-toolchain Would have the same CROSS_* environment variables and could mix things up. Ideally one should have per target cross variables, like, CROSS_AVR_* CROSS_I686_W64_MINGW32_*, but this is not done right now. Another option is to wrap every binary of the toolchain and set the CROSS_* variables so that they can find the C standard library includes and binaries without adding search paths to avoid collisions with other toolchains for the moment and since profiles don't support cross-packages yet I think it is a fair trade-off. I think I could update https://issues.guix.gnu.org/68058 to use the latter method. [1]: https://www.reddit.com/r/GUIX/comments/18rj84f/arduino_avr_compilation_help/ -- Jean-Pierre De Jesus DIAZ Foundation Devices, Inc.
bug#68953: [PATCH] gnu: opencv: Move python-numpy to propagated-inputs.
* gnu/packages/image-processing.scm (opencv): Move python-numpy from INPUTS to PROPAGATED-INPUTS. Change-Id: If4f0c8fa0cf41594a2c63f3e9f271987aa730af2 --- gnu/packages/image-processing.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gnu/packages/image-processing.scm b/gnu/packages/image-processing.scm index 07ba0297cd..32405fa08c 100644 --- a/gnu/packages/image-processing.scm +++ b/gnu/packages/image-processing.scm @@ -727,6 +727,7 @@ (define-public opencv (sha256 (base32 "16crcca9r4y4rby0dqdhc06qi84hjk6qxy2sql2dhh35hfs856rr")) +(propagated-inputs (list python-numpy)) (inputs (list eigen ffmpeg-4 @@ -749,7 +750,6 @@ (define-public opencv openjpeg protobuf python - python-numpy vtk zlib)) ;; These three CVEs are not a problem of OpenCV, see: base-commit: 10dba10fd6551ab480a38d00301e6f102def674d -- 2.41.0
bug#68953: OpenCV Python package throws error
Hello, I think this can be closed as it was my mistake as some package installed with pip installed OpenCV and Python was picking it up by mistake, sorry for the noise. However, I came up with a patch to propagate python-numpy as it is required by OpenCV. -- Jean-Pierre De Jesus DIAZ Foundation Devices, Inc.
bug#68953: OpenCV Python package throws error
The current OpenCV package (opencv@4.8.0) fails to load on a pure GNU
Guix system, the error reports that some part of OpenCV isn't able to
find the libGL.so.1 library.
My GNU Guix description:
Generation 83Feb 05 2024 16:30:36(current)
guix a3df20d
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: a3df20db8c3b9c819db7ca29bf014e2544e389d4
To reproduce the issue
guix shell python \
python-numpy \
opencv \
--pure \
-- python3 -c 'import cv2'
And shows the following error:
Traceback (most recent call last):
File "", line 1, in
File "/home//.local/lib/python3.10/site-packages/cv2/__init__.py",
line 181, in
bootstrap()
File "/home//.local/lib/python3.10/site-packages/cv2/__init__.py",
line 153, in bootstrap
native_module = importlib.import_module("cv2")
File
"/gnu/store/8s8k2v6b5b7lyf5y5n534cjd9sipgas6-python-3.10.7/lib/python3.10/importlib/__init__.py",
line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
ImportError: libGL.so.1: cannot open shared object file: No such file
or directory
I tried investigating why the error happened without luck as I'm not sure
in what place OpenCV is trying to load libGL.so.1.
--
Jean-Pierre De Jesus DIAZ
Foundation Devices, Inc.
bug#68474: [PATCH] tls: Fix openssl-1.0 check phase.
From: Jean-Pierre De Jesus DIAZ
* modules/past/packages/tls.scm (openssl-1.0): Fix a time bomb in
cms-test.pl due to expired certificates.
---
modules/past/packages/tls.scm | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/modules/past/packages/tls.scm b/modules/past/packages/tls.scm
index cbc9834..a494e1c 100644
--- a/modules/past/packages/tls.scm
+++ b/modules/past/packages/tls.scm
@@ -140,6 +140,20 @@
,@(if (%current-target-system)
'((getenv "CONFIGURE_TARGET_ARCH"))
'())
+ (add-before 'check 'patch-util/shlib_wrap.sh
+ (lambda* (#:key tests? native-inputs inputs #:allow-other-keys)
+ (when tests?
+ (let ((lib (search-input-file (or native-inputs inputs)
+ "lib/faketime/libfaketime.so.1"))
+ (release-date "2019-12-20 13:25:43"))
+ ;; Invoking "faketime make ..." does not work as this script
+ ;; sets its own LD_PRELOAD variable, so re-export it with
+ ;; libfaketime and set the fake time.
+ (substitute* "util/shlib_wrap.sh"
+ (("cmd=\"\\$1\\$\\{EXE_EXT\\}\"" all)
+(string-append "export LD_PRELOAD=" lib ":$LD_PRELOAD\n"
+ "export FAKETIME=\"" release-date "\"\n"
+ all)))
(add-after 'install 'move-static-libraries
(lambda* (#:key outputs #:allow-other-keys)
;; Move static libraries to the "static" output.
@@ -175,7 +189,7 @@
(delete-file-recursively (string-append out "/share/openssl-"
,version "/misc"))
#t))
-(native-inputs (list (S "perl")))
+(native-inputs (list (S "libfaketime") (S "perl")))
(native-search-paths
(list (search-path-specification
(variable "SSL_CERT_DIR")
base-commit: d60a388678098e6de60ca1a65806903b5739da29
--
2.41.0
bug#68474: [Guix-Past]: openssl@1.0.2u does not pass tests
Hi, On Tue, Jan 30, 2024 at 5:29 PM Ludovic Courtès wrote: > > Hi, > > Jean-Pierre De Jesus Diaz skribis: > > > And the from the error file that the test writes: > > > > $ cat /tmp/guix-build-openssl-1.0.2u.drv-0/openssl-1.0.2u/test/cms.err > > Verification failure > > 140737353281920:error:21075075:PKCS7 routines:PKCS7_verify:certificate > > verify error:pk7_smime.c:335:Verify error:certificate has expired > > This is a typically “time trap”. Options are: use libfaketime to run > “make check”, change the certificates so they don’t expire, or skip > those tests. > > Would you like to give it a try? > > Thanks, > Ludo’. I'll give it a try to use libfaketime to keep tests enabled. Thanks, -- Jean-Pierre De Jesus DIAZ Foundation Devices, Inc.
bug#68474: [Guix-Past]: openssl@1.0.2u does not pass tests
The package at the guix-past channel does not pass the tests at `tests/cms-test.pl' file. It fails with the following error: >From the build log: ... CMS consistency test /gnu/store/lj75fc25zx2y9pqvfp95la84rdhlj4f8-perl-5.36.0/bin/perl cms-test.pl CMS => PKCS#7 compatibility tests signed content DER format, RSA key: verify error ``` And the from the error file that the test writes: $ cat /tmp/guix-build-openssl-1.0.2u.drv-0/openssl-1.0.2u/test/cms.err Verification failure 140737353281920:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:335:Verify error:certificate has expired My guix description is: Generation 74Jan 15 2024 12:28:39(current) guix 162d6a2 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 162d6a2fdd6af13272967c77347a54934ecb45e6 guix-past 0e8c1ea repository URL: https://gitlab.inria.fr/guix-hpc/guix-past branch: master commit: 0e8c1eae3efd34ab291fc6a4b69b767683488bb9 -- Jean-Pierre De Jesus DIAZ Foundation Devices, Inc. spxpvzpamzndlggz8xd4d79vis312d-openssl-1.0.2u.drv.gz Description: application/gzip
bug#64571: harfbuzz package has a duplicated definition
Hi, Yes, that fixed the issue. Thanks. On Fri, Aug 18, 2023 at 8:07 PM Simon Tournier wrote: > > Hi, > > On Tue, 11 Jul 2023 at 11:15, Jean-Pierre De Jesus Diaz via Bug reports for > GNU Guix wrote: > > > guix shell harfbuzz > > guix shell: warning: ambiguous package specification `harfbuzz' > > guix shell: warning: choosing harfbuzz@5.3.1 from gnu/packages/gtk.scm:252:2 > > > > It may be as simple as removing harfbuzz-5 package definition but I'm not > > sure if that is correct, > > or if this is intended. > > Done with commit 728ed83188846453f1319ea425847da8200a55a9 by Chris if I > read correctly. Closing? > > Cheers, > simon -- — Jean-Pierre De Jesus DIAZ Software Engineer
bug#64571: harfbuzz package has a duplicated definition
guix describe: Generation 23 jul 06 2023 13:37:00(current) guix 2426e51 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 2426e51688d479042ea115a634c6be2d8b9f3b99 It appears that harfbuzz has been duplicated using the same version, so when creating a shell with guix shell harfbuzz it will show a warning about an ambiguous specification: guix shell harfbuzz guix shell: warning: ambiguous package specification `harfbuzz' guix shell: warning: choosing harfbuzz@5.3.1 from gnu/packages/gtk.scm:252:2 It may be as simple as removing harfbuzz-5 package definition but I'm not sure if that is correct, or if this is intended. -- — *Jean-Pierre De Jesus DIAZ* *Software Engineer* *Foundation Devices*
bug#57109: arm-none-eabi-toolchain atomic support is broken
The following works though. No newlib or anything: guix shell --expression='((@ (gnu packages cross-base) cross-gcc) "arm-none-eabi")' -- \ bash -c "echo '#include ' \ | arm-none-eabi-gcc -x c -o /dev/null -c -" — Jean-Pierre De Jesus DIAZ --- Original Message --- On Wednesday, August 10th, 2022 at 1:14 PM, Jean Pierre De Jesus DIAZ wrote: > The atomic supports for this toolchain is broken: > > A minimal test case: > > guix shell arm-none-eabi-toolchain -- \ > bash -c "echo '#include ' \ > > | arm-none-eabi-gcc -x c -o /dev/null -c -" > > Something similar found online: > > https://sourceware.org/legacy-ml/newlib/2017/msg00150.html > > However no solution. > > This happens with all versions of the arm-none-eabi-toolchain > packages. > > — > Jean-Pierre De Jesus DIAZ
bug#57046: Spanish documentation uses exclusive language
>Please stop putting words in my mouth and arguing in bad faith. My comment is pointing the fact that men (should not) have decision over the language and shouldn't even consider it and that doing so is bad to everyone. >Decisions that affect a group should be made by the group or when that >is not logistically possible then a *representative subset* of the >group. This is very different from what you said before. >Roughly half of the population is female. If you don't think they >should be consulted about decisions that affect them, then you are >taking an undemocratic stance. I think they should and are welcome, said it before and say it again. >Women have to put up with sooo much more bullshit in their daily life >than men, so when free software projects require them putting up with >even more, they will not want to be part of the free software community, >because it demonstrably does not take their concerns seriously. That's right, but haven't seen how GNU Guix makes it difficult to anyone to contribute. Everyone is welcomed, at least from my part and as a newcomer too. — Jean-Pierre De Jesus DIAZ --- Original Message --- On Saturday, August 13th, 2022 at 9:48 AM, Csepp wrote: > Jean Pierre De Jesus DIAZ via Bug reports for GNU Guix bug-guix@gnu.org > writes: > > > > Just a thought, but maybe it shouldn't be a group of men who decides > > > what language is and is not inclusive and whether that's important. > > > We've had some Outreachy interns, maybe some of them wouldn't mind being > > > consulted on this. > > > > Inclusion through exclusion, this is just sending the messages that men > > bad anything else better. That just spreads hate for no particular reason. > > > Please stop putting words in my mouth and arguing in bad faith. > > Decisions that affect a group should be made by the group or when that > is not logistically possible then a representative subset of the > group. > > Roughly half of the population is female. If you don't think they > should be consulted about decisions that affect them, then you are > taking an undemocratic stance. > > Women have to put up with sooo much more bullshit in their daily life > than men, so when free software projects require them putting up with > even more, they will not want to be part of the free software community, > because it demonstrably does not take their concerns seriously. > > I'd like to believe that we can do better and make our communities more > welcoming to the people who need tools that liberate them the most.
bug#57046: Spanish documentation uses exclusive language
>Just a thought, but maybe it shouldn't be a group of men who decides >what language is and is not inclusive and whether that's important. >We've had some Outreachy interns, maybe some of them wouldn't mind being >consulted on this. Inclusion through exclusion, this is just sending the messages that men bad anything else better. That just spreads hate for no particular reason. I doubt that a lot of people translate the Guix manual to Spanish, so, it probably wasn't even discussed or decided by anyone, let them be women, men or non-binary. And yes, language changes through use, but forcing it isn't the way, people use the language and it naturally adapts, and if inclusive language like using the letter "e" to make words neutral is going to be used it has to be justified, I don't think that there's justification to do so, or that anyone complained, there's not even people complaining for other languages that use masculine words. And yes, using "usuarios y usuarias" excludes non-binary people, that's a limitation of the language and nothing can be done about it unless everyday people start using it (read again, using it, not forcing it onto people). And in justification, I mean, real world data, statistics of people using it or willing to do so. To clarify I'm not against change, but I'm against forcing it. Nothing else. Anyway, all people are welcome to discuss this. And the fact that no one started an edit war on Weblate says it all, no men is deciding anything. I personally want to know the reasoning behind it and if it was discussed and not abused for personal reasons or a movement. >I can’t really judge but don’t believe their and Ludo’s proposal “les >usuaries” is really perceived neutral and acceptable. (To Spanish >speakers: What do psychologists say? Does it appear feminine to you?) It doesn't feel feminine or masculine, so I guess it's neutral. But the fact that it makes text hard to read. I'd say that anyone can try doing a Stroop test to feel the same in their own language to. I say this being a neuro-typical person. I don't think forcing the "e" is going to make it easier for neuro-divergent people. — Jean-Pierre De Jesus DIAZ
bug#57109: arm-none-eabi-toolchain atomic support is broken
The atomic supports for this toolchain is broken: A minimal test case: guix shell arm-none-eabi-toolchain -- \ bash -c "echo '#include ' \ | arm-none-eabi-gcc -x c -o /dev/null -c -" Something similar found online: https://sourceware.org/legacy-ml/newlib/2017/msg00150.html However no solution. This happens with all versions of the arm-none-eabi-toolchain packages. — Jean-Pierre De Jesus DIAZ
bug#57046: Spanish documentation uses exclusive language
Hello, As an Spanish speaker too I didn't notice it at first when reading the documentation and feels weird that it's deliberately "usuaria" instead of "usuario". For example, in Argentina, only 8% of the population uses inclusive language: https://www.diariodecultura.com.ar/columna-izquierda/solo-el-8-de-la-poblacion-utiliza-el-lenguaje-inclusivo-con-frecuencia/ Couldn't find more statistics on the matter. Not only using "usuaria" it's exclusive but it's also grammatically incorrect, the proper way would be using "usuario" which includes all genders and "usuario y usuaria", but it is too verbose IMHO. For example: - "Cuentas de usuario" - "Cuentas de usuario y usuaria" The latter one is used a lot by the Venezuelan government when they try to be inclusive, but it's tiring to the reader and doesn't provide additional context. >Swapping masculine forms with their feminine counterpart and pretending >they're neutral creates a problem on top of a problem. Completely agree. — Jean-Pierre De Jesus DIAZ
bug#57046: (No Subject)
FWIW author cites: https://guix.gnu.org/es/manual/es/guix.es.html#DOCF50 As the reason for using feminine words. https://guix.gnu.org/es/manual/es/guix.es.html#FOOT50 Quoting from the manual: >NdT: En esta traducción se ha optado por usar el femenino para referirse a >personas, ya que es el género gramatical de dicha palabra. Aunque las >construcciones impersonales pueden adoptarse en la mayoría de casos, también >pueden llegar a ser muy artificiales en otros usos del castellano; en >ocasiones son directamente imposibles. Algunas construcciones que proponen la >neutralidad de género dificultan la lectura automática (-x), o bien dificultan >la corrección automática (-e), o bien aumentan significativamente la >redundancia y reducen del mismo modo la velocidad en la lectura (-as/os, -as y >-os). No obstante, la adopción del genero neutro heredado del latín, el que en >castellano se ha unido con el masculino, como construcción neutral de género >se considera inaceptable, ya que sería equivalente al “it” en inglés, nada más >lejos de la intención de las autoras originales del texto. >En esta traducción se ha optado por usar el femenino para referirse a >personas, ya que es el género gramatical de dicha palabra. Yes, right, "personas" is feminine, but doesn't mean "usuario" has to be changed to a feminine word just because the word we use to designate people is feminine, it has no relation. An user can not only represent people, but an organization, a team, etc. >la adopción del genero neutro heredado del latín, el que en castellano se ha >unido con el masculino, como construcción neutral de género se considera >inaceptable That's not a fact, it's an opinion, and a very personal one. >nada más lejos de la intención de las autoras originales del texto. This one, here it's written as "autoras" as feminine when "autores" is already a neutral word, it's doesn't refer to a man nor a woman, just a group of people that authored something. So, if Spanish has already gendered words, with masculine, feminine and neutral, and a neutral word is already available, then what's the real intention of the author of that foot note? --- I feel like the guideline for writing using neutral words was taken out of context and abused for personal purposes. — Jean-Pierre De Jesus DIAZ
bug#57037: Package `guile-newt' cannot be cross-compiled
The `guile-newt' package that is used for the installation UI can't be cross-compiled as it tries to load the `newt' dynamic library when the Guile code is compiled. I've tried to find a solution/fix but I don't know much about how Guile byte-code compilation works. The compilation error can be reproduced with (#56536 was pushed a few hours ago, so a git pull may be needed): ./pre-inst-env guix build guile-newt --target=aarch64-linux-gnu I think this is one of the last remaining bits before being able to fully cross compile an installation image. — Jean-Pierre De Jesus DIAZ
