bug#68988: All arm64/aarch64 platforms disabled in linux-libre 6.7.x!
Hi Vagrant,
Vagrant Cascadian writes:
> [[PGP Signed Part:Undecided]]
> The linux-libre 6.7.x package contains ... as far as I can tell, no
> supported arm64/aarch64 platforms! This is a pretty significant
> regression from the linux-libre 6.6.x packaging!
I'll generate a new arm/arm64 config for the 6.7.x series that doesn't
fall behind the 6.6.x series config; and will test it on my pinebook pro
at least before sending in a patch.
Although I have yet to pin down why this happened in the 6.7.x update as
I didn't do anything significantly different than while preparing the
6.6.x series (e.g. copying the old config, running makeconfig and
enabling as much support as possible in the prompts).
So far as a quick rundown:
λ rg -f <(rg --pcre2 -o '.*(?=\=y)' 6.6-arm64.conf | awk '{print $0 ".*not
set"}') 6.7-arm64.conf | wc -l
678
678 config options that previously have been set aren't set anymore.
> I am not sure that all the previous platforms were intentionally added,
> but at the very least SUNXI, ROCKCHIP, BCM2835 and probably quite a few
> others should be added back. I am currently running Guix System in a
> virtualized environment, but in the past I've run it on a sunxi systems
> such as pinebook and pine64+... and rockchip systems such as
> pinebook-pro, rock64-rk3328 and rockpro64-rk3399.
I hacked together a simple script based on the 6.6.x series platform
selection to use with new releases to check, that all platforms that
have been enabled before stay enabled. But maybe a better way would be
to use #:extra-options in the *-arm-generic package definitions to
ensure there, that the options will stay enabled at least for the ones
mentioned above. WDYT?
> I don't have the time at the moment to come up with a patch, but 6.7.x
> should probably not become the default linux-libre until this is
> at least partly fixed...
Agreed.
--
Kind regards,
Wilko Meyer
w...@wmeyer.eu
bug#53423: [fix] nncp: Fails to build (renamed file not found)
On 2024-02-07, Vagrant Cascadian wrote: > On 2023-06-24, Alan & Kim Zimmerman wrote: >> I took a look at this, and the problem seems to be that the cwd ends up >> different from before, so all the file operations fail. >> >> It needs (chdir "../nncp-7.5.0") in the 'go-unpack section. >> >> Attached is a patch that does this, if it works via gmail. FWIW, nncp appears to be quite out of date in guix; might be good to explore getting current upstream working... live well, vagrant signature.asc Description: PGP signature
bug#53423: [fix] nncp: Fails to build (renamed file not found)
On 2023-06-24, Alan & Kim Zimmerman wrote:
> I took a look at this, and the problem seems to be that the cwd ends up
> different from before, so all the file operations fail.
>
> It needs (chdir "../nncp-7.5.0") in the 'go-unpack section.
>
> Attached is a patch that does this, if it works via gmail.
Thanks for the patch! Miraculously, it still applies after all this
time, and it does allow the build to proceed further, but still fails in
tests:
starting phase `check'
do test
# _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-cfgdir
cmd/nncp-cfgdir/main.go:91:4: unknown field 'AllowMinusZero' in struct
literal of type hjson.EncoderOptions
ok _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src37.407s
?
_/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-bundle[no
test files]
? _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-call [no
test files]
? _/tmp/guix-build-nncp-7.5.0.drv-0/nncp-7.5.0/src/cmd/nncp-caller
[no test files]
do: test: got exit code 2
error: in phase 'check': uncaught exception:
%exception #< program: "contrib/do" arguments: ("-c" "test")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `check' failed after 44.5 seconds
command "contrib/do" "-c" "test" failed with status 1
CCed the members of the go team who may have a better idea of, well,
packaging go programs. :)
live well,
vagrant
> From f2cc08e9cd657717049936938077a210773ab193 Mon Sep 17 00:00:00 2001
> Message-Id:
>
> From: Alan Zimmerman
> Date: Fri, 23 Jun 2023 23:57:48 +0100
> Subject: [PATCH] nncp: set directory so build succeeds
>
> ---
> gnu/packages/uucp.scm | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/gnu/packages/uucp.scm b/gnu/packages/uucp.scm
> index e10de59aa2..65e71c1b1a 100644
> --- a/gnu/packages/uucp.scm
> +++ b/gnu/packages/uucp.scm
> @@ -98,6 +98,7 @@ (define-public nncp
> (assoc-ref go:%standard-phases 'setup-go-environment))
> (add-after 'unpack 'go-unpack
> (lambda* (#:key source #:allow-other-keys)
> + (chdir "../nncp-7.5.0")
> ;; Copy source to GOPATH.
> (copy-recursively "src" "../src/go.cypherpunks.ru/nncp/v7")
> ;; Move bundled dependencies to GOPATH.
>
> base-commit: f25529b08e356f89ca7cecc44295085531a8faba
> --
> 2.40.1
signature.asc
Description: PGP signature
bug#68988: All arm64/aarch64 platforms disabled in linux-libre 6.7.x!
The linux-libre 6.7.x package contains ... as far as I can tell, no supported arm64/aarch64 platforms! This is a pretty significant regression from the linux-libre 6.6.x packaging! This appears to have been introduced in 95a3aaf7ad37bb0717f2c9e3faf6f636b586d133 Unfortunately it is all too easy to drop features with non-x86 platforms... especially if you run make *config from an x86 machine. For example: diff -u /gnu/store/dnism9x21x0x15k91ngis54w6pcf7gmi-linux-libre-6.6.12/.config /gnu/store/a6xc9aad9kv8xpy7i94ga74h6hs7gdvk-linux-libre-6.7.3/.config | grep -A20 '# Platform selection' # Platform selection # # CONFIG_ARCH_ACTIONS is not set -CONFIG_ARCH_SUNXI=y +# CONFIG_ARCH_SUNXI is not set # CONFIG_ARCH_ALPINE is not set -CONFIG_ARCH_APPLE=y -CONFIG_ARCH_BCM=y -CONFIG_ARCH_BCM2835=y -# CONFIG_ARCH_BCM_IPROC is not set -CONFIG_ARCH_BCMBCA=y -# CONFIG_ARCH_BRCMSTB is not set +# CONFIG_ARCH_APPLE is not set +# CONFIG_ARCH_BCM is not set # CONFIG_ARCH_BERLIN is not set -CONFIG_ARCH_BITMAIN=y +# CONFIG_ARCH_BITMAIN is not set # CONFIG_ARCH_EXYNOS is not set # CONFIG_ARCH_SPARX5 is not set # CONFIG_ARCH_K3 is not set # CONFIG_ARCH_LG1K is not set There are basically no CONFIG_ARCH platforms enabled! I am not sure that all the previous platforms were intentionally added, but at the very least SUNXI, ROCKCHIP, BCM2835 and probably quite a few others should be added back. I am currently running Guix System in a virtualized environment, but in the past I've run it on a sunxi systems such as pinebook and pine64+... and rockchip systems such as pinebook-pro, rock64-rk3328 and rockpro64-rk3399. This also makes me wonder what other more subtle features got dropped along the way, as well as platform support for other architectures... :/ I don't have the time at the moment to come up with a patch, but 6.7.x should probably not become the default linux-libre until this is at least partly fixed... live well, vagrant signature.asc Description: PGP signature
bug#68948: highlight error, cannot open filetypes.conf: No such file or directory
Sergey, I believe you intended a related message for the debbugs service, but only sent the message to my mail address. I am unsure and want to avoid showing impoliteness, I rephrased your message a bit below. Thank you, Chris --- the highlight error goes away after copying the conf file this way ``` cp $(guix build highlight)/etc/highlight/filetypes.conf ~/.highlight/ ``` strace shows that the conf is searched in wrong place: --8<---cut here---start->8--- newfstatat(AT_FDCWD, "/home/user/.highlight/filetypes.conf", 0x7ffcd0778130, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/gnu/store/9mdd4ba8ri4j07acmbc2vhkiipbz9l63-highlight-4.8/share/highlight/filetypes.conf", 0x7ffcd0778130, 0) = -1 ENOENT (No such file or directory) newfstatat(AT_FDCWD, "/gnu/store/9mdd4ba8ri4j07acmbc2vhkiipbz9l63-highlight-4.8/share/highlight/config/highlight/filetypes.conf", 0x7ffcd0778130, 0) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "filetypes.conf", O_RDONLY) = -1 ENOENT (No such file or directory) futex(0x7f2c4827e1f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(2, "cannot open filetypes.conf: No s"..., 53cannot open filetypes.conf: No such file or directory) = 53 --8<---cut here---end--->8--- but it is installed to /gnu/store/...-highlight-.../etc/highlight/highlight.conf the package recipe has to be fixed
bug#68764: ASDF can't load sbcl-clx-truetype installed through Guix
I am running into this same issue on other cl packages as well.
bug#68982: Ren'py 8.2.0 Crash on startup
When starting the ren'py launcher on version Ren'Py 8.2.0.24012702, currently my guix channel is on commit 5d2302a1959d09e6d5a5f02ac199458095847a82, the program crashes with the following error: Full traceback: File "/gnu/store/2m851i42kc8i929rfhrn6w545w6a94lz-python-renpy-8.2.0/lib/python3.10/site-packages/renpy/bootstrap.py", line 354, in bootstrap renpy.config.logdir = renpy.__main__.path_to_logdir(basedir) AttributeError: module '__main__' has no attribute 'path_to_logdir'
bug#53005: cryptsetup-static aborts opening LUKS2 volume with Argon2i PBKDF
This issue was fixed with commit 6b6fb7872486, "gnu: glibc: Build with '--strip-debug' instead of '--strip-all'." -- Simon South si...@simonsouth.net
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#68968: system reconfigure ignores incorrect --on-error flag value
In the guix/scripts/system.scm file we do not check the value while parsing the
flag:
--8<---cut here---start->8---
(option '("on-error") #t #f
(lambda (opt name arg result)
(alist-cons 'on-error (string->symbol arg)
result)))
--8<---cut here---end--->8---
and then blindly pass it to load*:
--8<---cut here---start->8---
(load* file %user-module
#:on-error (assoc-ref opts 'on-error))
--8<---cut here---end--->8---
and load* uses it in a case that only gets called when an actual error occurs
and treats the correct symbols but has a default clause that silently ignores
values other than debug and backtrace:
--8<---cut here---start->8---
(case on-error
((debug)
...)
((backtrace)
...)
(else
#t))
--8<---cut here---end--->8---
meaning that for example a typo such as `--on-error=stacktrace`, gets treated
as if the flag was not passed at all.
Minimum replication:
--8<---cut here---start->8---
guix system build <(echo x) --on-error=stacktrace
guix system build <(echo x) --on-error=backtrace
--8<---cut here---end--->8---
I'm not sure where the check should be done, nor what would be an acceptable
way to not duplicate the list of valid values between guix/ui.scm and
guix/scripts/system.scm
bug#68967: guix import: Issues handling Unicode
"guix import" seems to have issues when importing text encoded in some non-ascii characters (or at least in Chinese). As an example to reproduce, this is the output generated by "guix import pypinyin": ``` (package (name "python-pypinyin") (version "0.50.0") (source (origin (method url-fetch) (uri (pypi-uri "pypinyin" version)) (sha256 (base32 "1yw075j7hjp1kc1jdihp4yq3jd5jpp7grzm5mh1d3fkqkd5prrvj" (build-system pyproject-build-system) (propagated-inputs (list python-enum34 python-typing)) (home-page "https://github.com/mozillazg/python-pinyin;) (synopsis "æ±åæ¼é³è½¬æ¢æ¨¡å/å·¥å ·.") (description "æ±åæ¼é³è½¬æ¢æ¨¡å/å·¥å ·.") (license license:expat)) ```
bug#43049: Add the ability to install Guix System offline
Hi Josselin, first of all, sorry for the confusion: I'm still learning... and I'm probably still using bad terminilogy from a Guix/Guile developer POV. Josselin Poiret writes: > Giovanni Biscuolo writes: > >> Sorry I don't understand the problem, could you expand please? >> >> The guix (and daemon) versione are those of the channel used when >> creating the install .iso image; booting the 1.40 installer we get a >> "guix version" and "guix describe" value of 989a391... > > Not exactly, to include Guix inside the installer image, it somehow > needs to refer to itself. The way it used to be done was by using the > `guix` package, which necessarily is older than the current commit. OK, in fact I checked starting the guix-1.4 install image in a VM and I got an older guix in the install system (forgive me for the missing the details, but this is not important in this context), but the verion installed on the target was 1.4.0 (so I guess its subsitute was downloaded from one of the build farms). > However, we also implemented the `current-guix` hack that basically uses > a guix checkout at the current guix version as the source for the guix > package. So, since some commit, now the guix version used to build the target system image is the one checked-out by the person/agent running the install image build script: did I understand it correctly? > In both cases though, we shouldn't see any differences in other > package's derivations… Does this mean you consider possible to pre-populate the /gnu/store install system (the one started using the install image) with a substet of substitutes possibly needed in the target system? I'm wondering if it's possible to create a custom build image (info "(guix) Building the Installation Image") to do something like this. Thanks! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
