bug#40316: nss not reproducible
Hi, Christina O'Donnell skribis: > Tangentially, given how long nss takes to build, do you think that > it'd be worth shaving it down to a single test pass? Currently it runs > each test up to 3 times, which takes ~1h on my machine with no other > build running. Running only the standard pass takes 2.5-3x less time, > which is a huge quality of life improvement. Currently we run ./nss/tests/all.sh, which I suppose is what upstream recommends to run tests. For sure I’d be happy if the test suite could run faster, but does upstream offer such an option? When you say “a single pass”, is that something upstream supports? Thanks, Ludo’.
bug#40316: nss not reproducible
Hi, On 06/05/2024 11:12, Ludovic Courtès wrote: Hi, Christina O'Donnell skribis: Tangentially, given how long nss takes to build, do you think that it'd be worth shaving it down to a single test pass? Currently it runs each test up to 3 times, which takes ~1h on my machine with no other build running. Running only the standard pass takes 2.5-3x less time, which is a huge quality of life improvement. Currently we run ./nss/tests/all.sh, which I suppose is what upstream recommends to run tests. For sure I’d be happy if the test suite could run faster, but does upstream offer such an option? When you say “a single pass”, is that something upstream supports? Yes, you can control the tests by setting environment variables NSS_TESTS to a list of tests and NSS_CYCLES to a list of 'cycles' (what I previously called passes). The default is: "standard pkix threadunsafe" * 'standard' runs all of the below tests with default settings: "cipher lowhash cert dbtests tools sdr crmf smime ssl ocsp merge pkits ec gtests ssl_gtests policy" * 'pkix' runs the tests "lowhash libpkix cert tools ssl ocsp pkits ec gtests ssl_gtests policy" with PKIX enabled. * 'thread_unsafe' runs "ssl ssl_gtests" with "THREAD_UNSAFE" enabled. My thinking would be to run the thread_unsafe cycle normally, but to reduce the test overlap between standard and pkix however, I can't say that I'm knowledgeable enough of NSS to claim that that wouldn't leave gaps that might bite us some point down the line. So it might be best to leave it as is unless someone familiar with NSS can confirm that it'd be safe to disable some tests/cycles. Kind regards, Christina
bug#70611: outputs are baked in gexps, cannot be removed in derived packages
Hi,
On sam., 27 avril 2024 at 12:55, Maxim Cournoyer
wrote:
> --8<---cut here---start->8---
> builder for
> `/gnu/store/f2pdg9m5q3bxrlahjvlrdgw41x6kp3zd-llvm-cling-18-20240227-01.drv'
> failed to produce output path
> `/gnu/store/m1z5257hj5vwc2rl47wkpf0wmr6x0bq2-llvm-cling-18-20240227-01-opt-viewer'
> --8<---cut here---end--->8---
Yeah something is unexpected.
--8<---cut here---start->8---
$ ./pre-inst-env guix build llvm-cling -d --no-grafts \
| xargs guix drv-show | recsel -p outputs
outputs:
+
/gnu/store/m1z5257hj5vwc2rl47wkpf0wmr6x0bq2-llvm-cling-18-20240227-01-opt-viewer
[opt-viewer]
+ /gnu/store/bg3xs25xyllpzw322sqcc8ipw9q8lph6-llvm-cling-18-20240227-01
[out]
--8<---cut here---end--->8---
But from ’guix repl’
--8<---cut here---start->8---
scheme@(guix-user)> ,pp (package-outputs llvm-cling-2)
$6 = ("out")
--8<---cut here---end--->8---
And the package arguments reads:
--8<---cut here---start->8---
scheme@(guix-user)> ,pp (package-arguments llvm-cling-2)
$5 = (#:configure-flags
#
#:build-type
"Release"
#:phases
# "/share")))
(mkdir-p opt-viewer-share)
(rename-file (string-append #
"/share/opt-viewer") opt-viewer-share)
gnu/packages/llvm.scm:612:6 7f6a06421090>:out>
(delete (quote install-opt-viewer)))
gnu/packages/llvm.scm:2443:10 7f6a06421060>)
--8<---cut here---end--->8---
Concretely,
/gnu/store/rhb3lmkbp5d92c0x0sxkmfwbpbs4b4hp-llvm-cling-18-20240227-01-builder
reads,
--8<---cut here---start->8---
(define %outputs
(list
(cons "out"
((@
(guile)
getenv)
"out"
(define %output
(assoc-ref %outputs "out"))
(cmake-build
[...]
#:phases
(modify-phases
(modify-phases %standard-phases
(add-after
(quote unpack)
(quote change-directory)
(lambda _
(chdir "llvm")))
(add-after
(quote install)
(quote install-opt-viewer)
(lambda*
(#:key outputs #:allow-other-keys)
(let*
((opt-viewer-share
(string-append
((@
(guile)
getenv)
"opt-viewer")
"/share")))
(mkdir-p opt-viewer-share)
(rename-file
(string-append
((@
(guile)
getenv)
"out")
"/share/opt-viewer")
opt-viewer-share)
(delete
(quote install-opt-viewer)))
--8<---cut here---end--->8---
Therefore, the bug comes from an incorrect derivation (drv) file. It
contains an output that it should not.
Well, I have not investigated further… Probably an issue with code
staging (what is evaluated when).
Cheers,
simon
bug#59361: linux-libre 6 breaks OpenGL on nouveau driver for nvidia 8800 GTS 640 Mo card
That is interesting. Does anybody know which old GPUs will work with linux-libre. On my Talos II, I noticed that even old nvidia GPUs do not work, the POWER9 will shutdown the link to GPU. I guess only AMD and Intel CPUs will work, and maybe also the RK3399 which I was unable to test. Alex On Wed, 2024-05-01 at 12:31 -0400, Maxim Cournoyer wrote: > Hi, > > Maxim Cournoyer writes: > > > Hi, > > > > When booting my Guix System with linux-libre 6.0.8, nouveau > > silently > > fails to render OpenGL. It includes symptoms such as: > > > > 1. Getting stuck on the GDM screen, which makes use of OpenGL > > 2. Not being able to use Qt5 or Qt6 applications, which renders via > > OpenGL. > > 3. the 'glxgears' program from mesa-utils displays frozen gears > > (not > > turning) > > > > My graphic card is an old nvidia 8800 GTS with 640 MiB of video > > RAM. > > > > Workaround: Adding the '(kernel linux-libre-5.15)' to my OS > > definition > > fixes it. > > I tried using linux-libre 6.8.8 today (Guix commit > df3d30819e650a490ef39dd6692740bb13263c75), which has Mesa 24.0.4, and > can no longer reproduce the problem described above. > > I'm thus happily closing this! >
bug#70788: guix pull fails on Talos II
Updating channel 'guix-android' from Git repository at
'https://framagit.org/tyreunom/guix-android.git'...
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from these channels:
guix https://git.savannah.gnu.org/git/guix.git ef8ab6a
guix-
androidhttps://framagit.org/tyreunom/guix-android.git 11f260e
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%
substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'...
100.0%
substitute: updating substitutes from
'https://bordeaux.guix.gnu.org'... 100.0%
building /gnu/store/ja0yiplp0ndf0ix0xnrp84sk9c5rpksf-nss-3.99.0.drv...
| 'check' phasebuild-log 4966 1
\ 'check' phasebuild-log 4966 101
[ OK ] Pkcs11ModuleTest.ListSlots (0 ms)
[ RUN ] Pkcs11ModuleTest.PublicCertificatesToken
| 'check' phaseBacktrace:
14 (primitive-load
"/gnu/store/q1bi8b3cqwaxmrjngp2z8gq2yk0w2sdz-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
2182:24 9 (run-with-store #
# ?)
2010:8 8 (_ #)
In ./guix/gexp.scm:
299:22 7 (_ #)
1205:2 6 (_ #)
1072:2 5 (_ #)
913:4 4 (_ #)
In ./guix/store.scm:
2067:12 3 (_ #)
1405:5 2 (map/accumulate-builds #
# ?)
1421:15 1 (_ #
("/gnu/store/ja0yiplp0ndf0ix0xnrp84sk9c5rpksf-nss-3.99.0.drv") _)
1421:15 0 (loop #f)
./guix/store.scm:1421:15: In procedure loop:
ERROR:
1. &store-protocol-error:
message: "build of `/gnu/store/ja0yiplp0ndf0ix0xnrp84sk9c5rpksf-
nss-3.99.0.drv' failed"
status: 100
guix pull: error: You found a bug: the program
'/gnu/store/q1bi8b3cqwaxmrjngp2z8gq2yk0w2sdz-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"ef8ab6ab66c4d629699d175938ef1912941d4dce"; system: "powerpc64le-
linux";
host version: "1.4.0"; pull-version: 1).
Please report the COMPLETE output above by email to .
uptime
17:04:23 up 8:16, 0 user, load average: 0.77, 1.15, 1.48
bug#40316: nss not reproducible
Building nss on my Talos II takes a long time, I did not test weather it is reproducible. It seems that there are no binaries from the build farm. Alex
bug#70726: guix-bug report
:/tmp $ sudo -i guix pull hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: guix install glibc-locales export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" See the "Application Setup" section in the manual, for more info. Updating channel 'guix' from Git repository at ' https://git.savannah.gnu.org/git/guix.git'... indexing objects 34% [### ] Authenticating channel 'guix', commits 9edb3f6 to d6a6e83 (29,432 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git d6a6e83 substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% libffi-3.3 51KiB 434KiB/s 00:00 [##] 100.0% libgc-8.0.4 214KiB 708KiB/s 00:00 [##] 100.0% libunistring-0.9.10 492KiB 989KiB/s 00:00 [##] 100.0% pkg-config-0.29.2 187KiB 3.7MiB/s 00:00 [##] 100.0% guile-3.0.7 6.9MiB 3.4MiB/s 00:02 [##] 100.0% building /gnu/store/al0d6f30wj4f4w68v2gqdkb367v75f4x-config.scm.drv... building /gnu/store/60h4f5jy7x05bgwjxp41gg5wsypaixn6-git.scm.drv... building /gnu/store/n5w7gbkyyiav73f9yypafvw2n6z5jq8n-hash.scm.drv... building /gnu/store/mjcskqgqppfcbbcrzjq8x8p40dvi7lga-module-import.drv... building /gnu/store/zl24x57fyqvprbj5mswvp18hlvkc9psr-module-import.drv... building /gnu/store/2hzp43qwskbgc7hv89plg1bkybkgn754-module-import-compiled.drv... building /gnu/store/8rsjc2q0070qcf6p82ji3xd9kwcwri1c-module-import-compiled.drv... building /gnu/store/bsjm3p823h9c7llkgbp9v15rb223im9c-compute-guix-derivation.drv... substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% bash-static-5.1.16 700KiB 456.5MiB/s 00:00 [##] 100.0% glibc-2.35 8.5MiB 5.4MiB/s 00:02 [##] 100.0% bash-minimal-5.1.16 588KiB 2.4MiB/s 00:00 [##] 100.0% gcc-11.3.0-lib 4.8MiB 3.2MiB/s 00:02 [##] 100.0% bash-minimal-5.1.16 589KiB 816.8MiB/s 00:00 [##] 100.0% libffi-3.4.4 56KiB 94.6MiB/s 00:00 [##] 100.0% libgc-8.2.2 218KiB 389.3MiB/s 00:00 [##] 100.0% libunistring-1.0 661KiB 1.7MiB/s 00:00 [##] 100.0% pkg-config-0.29.2 209KiB 398.6MiB/s 00:00 [##] 100.0% guile-3.0.9 8.1MiB 4.9MiB/s 00:02 [##] 100.0% guile-3.0.9-debug 7.8MiB 2.4MiB/s 00:03 [##] 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% glibc-utf8-locales-2.35 382KiB 465.7MiB/s 00:00 [### ] 83./Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS guix pull: error: You found a bug: the program '/gnu/store/3pnv8541jms0kyjfg0g3wl504n2nylil-compute-guix-derivation' failed to compute the derivation for Guix (version: "d6a6e832e6e318eec0c4866fdde62ae47f29defa"; system: "
bug#70781: "error: make-custom-binary-output-port: unbound variable" after guix home reconfigure
Hello everyone! I have somehow managed to get my Guix install into an erroneous state. After running a "guix home reconfigure" I now get this error backtraces error everytime I try to to anything with guix except "guix --help". Which also means I can't do a roll-back (or at least I have not managed to do it). I'm running Guix on a foreign distro (Debian container on a Chromebook). dev@penguin:~ $ guix pull Backtrace: 11 (primitive-load "/home/dev/.config/guix/current/bin/guix") In guix/ui.scm: 2312:7 10 (run-guix . _) 2275:10 9 (run-guix-command _ . _) In ice-9/boot-9.scm: 1755:12 8 (with-exception-handler _ _ #:unwind? _ # _) 1749:15 7 (with-exception-handler # …) In guix/store.scm: 662:15 6 (call-with-store #) 575:2 5 (open-connection _ #:port _ #:reserve-space? _ # _) In ice-9/boot-9.scm: 1755:12 4 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 582:19 3 (_) 942:11 2 (buffering-output-port _ _) In ice-9/boot-9.scm: 1676:22 1 (raise-exception _ #:continuable? _) 1674:22 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1674:22: In procedure raise-exception: error: make-custom-binary-output-port: unbound variable This is the third time I have managed to get into this state. The first time I had to uninstall and re-install Guix completely, which fixed it. The second time I had Guix installed in to "~/guix-profile/bin" and could use that to roll-back my home environment. But this time I don't have that. So I would appreciate any guidance on how to diagnose this and if there are way to get my out of this state without having to uninstall and re-install Guix. Best Regards Kristofer
bug#70774: The Artanis pkg issue
Hi Joshua! Have you tried the latest 0.6? Can it work for you? For now, I only tested in Ubuntu 24.04. On Sun, May 5, 2024, 04:33 wrote: > Apologies for top posting...The below email seemed more like a bug. > > Typically guix-devel is for making "large" or complicated changes to guix. > > I'm forwarding your message over to bug-guix@gnu.org. > > Also, do you use Artanis? I've tried to get it to work a few times... > and I can never quite figure it out. My guile web framework is... > guile haunt at the moment. :) > > Joshua > > > Forwarded message --- > > > > From: "Nala Ginrut" > > > To: guix-de...@gnu.org > > > Sent: May 4, 2024 at 11:36 AM > > > Subject: The Artanis pkg issue > > > > Dear Guix folks, I saw the lines in Artanis pkg info: > > -cut- > > (delete-file-recursively "artanis/third-party/json.scm") > > > (delete-file-recursively "artanis/third-party/json") > > > (delete-file-recursively "artanis/third-party/redis.scm") > > > (delete-file-recursively "artanis/third-party/redis") > > -end-- > > > I understand these lines are aiming to unbundle guile-json and > guile-redis, however, recently I've unbundled them in vanilla Artanis. So > there's something changed. > > > You may need to keep third-party/json.scm and third-party/edis.scm in the > next release since they are the wrappers, and it's possible to make further > abstracts then. In addition, there are necessary renaming operations for > compatibility. > > > Best regards. >
