bug#53423: [fix] nncp: Fails to build (renamed file not found)
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. Alan 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
bug#64193: greetd-wlgreet-session dont working
I have the same problem. I have no idea how to debug such kind of errors. -- Anthony
bug#64059: Sudden unexplained error during guix pull: "channel dependency has an invalid introduction field"
Hi Josselin, Thank you so much for your help! Indeed, the .channels.scm files of my custom channels had invalid introduction fields. That's on me --- I should've read the error message more carefully! Best regards, Ning On Tue, Jun 20, 2023 at 9:19 AM Josselin Poiret wrote: > Hi Ning, > > "N. Y." writes: > > > The error is "channel dependency has an invalid introduction field," but > > the introduction fields of my custom channels have the same form as > those I > > use for GNU guix and nonguix channels which I can pull without errors; > and > > the channel introductions and GPG fingerprints are unchanged from the > last > > time I was able to pull successfully (I have the channels.scm file under > > version control). > > I've purposefully added this new error to warn users that their > .guix-channel's introduction forms were erroneous. Previously, they > were silently being dropped. The formats in a channels.scm file and in > the .guix-channel file are *not* the same! Please see "(guix) Declaring > Channel Dependencies" for an example of the format. > > Best, > -- > Josselin Poiret >
bug#64271: libasr is unmaintained upstream
Hello, I'm not a guix user so can't send patches, hope this is the correct way to report issues however. The upstream libasr-portable repository was archived, as the project was unmaintained (and unmaintenable in some sense) for some time: https://github.com/OpenSMTPD/libasr/ OpenSMTPD (its only consumer I guess) doesn't depend on it anymore, it should be built with the bundled version that was updated. The configure script still looks for `libasr' so that it continues to build on OpenBSD, but on other systems it should use the bundled libasr. There's a configure flag --with-bundled-libasr to force the usage of the bundled version. Thanks, Omar Polo P.S.: looking at the recipe for OpenSMTPD I noticed the comment "reccomended, and supports e.g. ECDSA". While it's true that it's reccomended to build with LibreSSL, ec keys should work just as fine with OpenSSL. The only issue is the combo OpenSSL 3.x + LibreTLS 3.7.0 due to a known regression that will be fixed in a upcoming release (I hope) since LibreSSL' tls did it: https://github.com/libressl/openbsd/commit/318ad8e73e
bug#63546: nix-channel error: opening pseudoterminal master: No such device
Perhaps this is a permissions issue with the nix shepherd service? I haven't tried the patch linked above, but found that I could run $ sudo nix-channel --update without running into the issue. Then, I got the same error again when trying to install any package with nix-env. Once again, I could run $ sudo nix-env -i which would successfully install it to the root profile. After doing this, however, I found that I now could run $ nix-env -i to install the package to my user profile, presumably because the nix store was populated by the run with sudo.
bug#63546: (No Subject)
I'm still receiving the same error. I tested a variant of Zhu's patch by
defining my own custom Nix package that sticks very closely to Zhu's, just with
manpages and docs generation disabled. I can confirm Nix is running latest: nix
(Nix) 2.16.0.
This is the first time I've done any kind of Guix hacking so it's a bit rough.
Here's my custom Nix package.
(define-public my-nix
(package
(inherit nix)
(name "nix")
(version "2.16.0")
(inputs (modify-inputs (package-inputs nix)
(append rapidcheck nlohmann-json)))
(source
(origin
(method git-fetch)
(uri (git-reference
(url "https://github.com/NixOS/nix";)
(commit version)))
(file-name (git-file-name name version))
(sha256
(base32 "0jizpci4zspqpqqy3n780m4wh8dzhfywaiz953xv70c7in810dra"
(arguments
`(#:configure-flags '("--disable-doc-gen")
#:phases
(modify-phases %standard-phases
(replace 'check
(lambda args
;; Some tests expect environment variable NIX_STORE to be
;; "/nix/store"
(let ((original-NIX_STORE (getenv "NIX_STORE")))
(dynamic-wind
(lambda ()
(setenv "NIX_STORE" "/nix/store"))
(lambda ()
(apply (assoc-ref %standard-phases 'check) args))
(lambda ()
(setenv "NIX_STORE" original-NIX_STORE)))
Attempting to run devbox shell returns
Error: Command: /run/current-system/profile/bin/nix print-dev-env
/home/worldofgeese/Downloads/projects/little_bits_of_buddha/.devbox/gen/flake/flake.nix
--extra-experimental-features ca-derivations --option experimental-features
nix-command flakes --json: exit status 1
[DEBUG] 2023/06/23 09:38:50
go.jetpack.io/devbox/internal/boxcli/midcobra/debug.go:72: Command stderr: path
'/home/worldofgeese/Downloads/projects/little_bits_of_buddha/.devbox/gen/flake/flake.nix'
does not contain a 'flake.nix', searching up
warning: Git tree
'/home/worldofgeese/Downloads/projects/little_bits_of_buddha/.devbox/gen/flake'
is dirty
error: opening pseudoterminal master: No such device.
Devbox is a Nix package available from the Nixpkgs repositories intended for
local development using Nix flakes.
bug#64223: I just have a install error and make a dump `installer-dump-719ceb08` :)
It failed as "build of /gnu/store/...-gtk-4.8.1.drv failed" Secured by Skiff Mail.
bug#64193: greetd-wlgreet-session dont working
I tryed to use wlgreet with dwl-guile guix system reconfigure error: (greetd-terminal-configuration (terminal-vt "1") (terminal-switch #t) (default-session-command (greetd-wlgreet-session (command (file-append dwl-guile "/bin/dwl-guile"): invalid field specifier config: (greetd-terminal-configuration (terminal-vt "1") (terminal-switch #t) (default-session-command (greetd-wlgreet-session (command (file-append dwl-guile "/bin/dwl-guile")
bug#64193: greetd-wlgreet-session dont working
Hi Yurii, Yurii writes: > I tryed to use wlgreet with dwl-guile > guix system reconfigure error: > (greetd-terminal-configuration (terminal-vt "1") (terminal-switch #t) > (default-session-command (greetd-wlgreet-session (command (file-append > dwl-guile "/bin/dwl-guile"): invalid field specifier > > config: > (greetd-terminal-configuration > (terminal-vt "1") > (terminal-switch #t) > (default-session-command > (greetd-wlgreet-session > (command (file-append dwl-guile "/bin/dwl-guile") This is only a very small snippet of your configuration, can you please post your entire configuration file, possibly redacting personal information you wouldn't like sharing? Best, -- Josselin Poiret signature.asc Description: PGP signature
bug#64223: I just have a install error and make a dump `installer-dump-719ceb08` :)
Hi, "yhm" via Bug reports for GNU Guix writes: > It failed as "build of /gnu/store/...-gtk-4.8.1.drv failed" Secured > by Skiff Mail. The only thing I can gather from that dump is that there was not enough space left on a device, and I assume the device you were installing on. HTH, -- Josselin Poiret signature.asc Description: PGP signature
bug#64280: Editorconfig and dir-locals in guix source tree contradict each other
Hi all, I found my Emacs using a fill-column value of 85 while hacking on the guix source tree. Turns out it's an interaction between the emacs package editorconfig-mode (which I use). Easy workaround: turn this mode off when hacking on guix. A contradiction between .dir-locals.el and the .editorconfig file in guix exists: max_line_length of 85 in .editorconfig for most files in guix vs fill-column of 78 in dir-locals.el for all files in guix I don't know which of these values is supposed to be leading, or whether they configure the exact same thing in all situations. Cheers, Jelle
bug#54944: guix pull hangs in guix-packages-base.drv even with offloading
Csepp writes: > Csepp writes: > >> Csepp writes: >> >>> Maxim Cournoyer writes: >>> Hi! raingloom writes: > It's been at 67% on guix-packages-base for at least an hour now. The > system itself is responsive and with the swap I gave it, it has more > than enough memory. Htop shows three guile processes at the top of the > list when sorted by CPU%, their states are S, D, D. > Both CPUs are practically idling. > This looks like some kind of lockup to me. > > Fresh install based on bare-bones example on a 32 bit netbook, but the > install image used is the latest tagged version, since apparently there > is no 32 bit option for edge. > > I also tried pulling using channel-with-substitutes, since I'm not too > keen on locally building everything on such an old machine. Although > Guix itself should frankly not take this long to build if we want to be > competitive with other distros. Anyways, pulling with that in > channels.scm gives a cert related error, so that's great, means old > images can't easily be used for installation. Have you been able to reproduce this? If so, could you share the commit you are starting from and the CPU architecture, so that we may hopefully reproduce too? Thanks, Maxim >>> >>> CPU architecture is x86, commit it happened on last time is 347733b. >>> Other possibly relevant factors: >>> * spinning rust storage >>> * 1GB RAM >>> * encrypted BTRFS root >>> * 4GB (encrypted) swap >>> * 128MB zswap >>> >>> The last was not there when I originally submitted the bug. >>> >>> The swap is relevant because if it's a timing issue it's very possible >>> some part of the code assumes reads are almost instant, which is not >>> true with swap, and delaying a read might be exposing a race condition. >> >> Happening again. >> pulled to: 8320c0c >> pulled from: 4501a50 >> >> Same system. >> >> The system version is from november of last year due, because trying to >> upgrade takes so damn long and often gets stuck on some package with no >> substitute. >> So... the situation is not great... > > The process status says sleep so it's probably hanging in a syscall? > Maybe a kernel bug? Happening again with offloading. This is getting really annoying. Offload machine is completely idle, there is a process Guile for guix-packages-base-builder running on it, its in sleeping status. Ran for 17 minutes, now the time is not increasing. I'm attaching a GDB backtrace of all the threads. Thread 9 (Thread 0xe4affac0 (LWP 878) "guile"): #0 0xf7fc6579 in __kernel_vsyscall () #1 0xf794685e in __lll_lock_wait () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #2 0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #3 0xf7f1095c in ?? () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1 #4 0xf7f16f98 in scm_gensym () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1 #5 0xf5d3a8ef in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 8 (Thread 0xe5497ac0 (LWP 877) "guile"): #0 0xf7fc6579 in __kernel_vsyscall () #1 0xf794685e in __lll_lock_wait () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #2 0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #3 0xf7f1095c in ?? () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1 #4 0xf7f16f98 in scm_gensym () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1 #5 0xf5d3a8ef in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 7 (Thread 0xe5c98ac0 (LWP 876) "guile"): #0 0xf7fc6579 in __kernel_vsyscall () #1 0xf794685e in __lll_lock_wait () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #2 0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #3 0xf7f1095c in ?? () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1 #4 0xf7f16f98 in scm_gensym () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80ni2m-guile-3.0.9/lib/libguile-3.0.so.1 #5 0xf5d3a8ef in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thread 6 (Thread 0xe6499ac0 (LWP 875) "guile"): #0 0xf7fc6579 in __kernel_vsyscall () #1 0xf794685e in __lll_lock_wait () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #2 0xf794d11a in pthread_mutex_lock@@GLIBC_2.0 () from target:/gnu/store/0hr9jpczkcgpgqkhf4q4868xd57h5a62-glibc-2.35/lib/libc.so.6 #3 0xf7f1095c in ?? () from target:/gnu/store/da6ikq281d235hvb1cil2ls3iq80
bug#63979: bug#64119: [PATCH] services: shepherd: Sanitize 'provision' field.
Bruno Victal skribis: > +(define (sanitize-shepherd-service-provision expr) > + (match expr > +(((? symbol?) ..1) expr) > +(_ > + (raise > + (formatted-message > + (G_ "'provision' must be a non-empty list of symbols")) Actually I figured we could do as in other areas of the code in a way that reports error location, so I came up with a different patch. Ludo’.
bug#64200: Netsurf very frequently freezes when editing text (Harfbuzz issue?)
John Kehayias writes: > Dear Csepp, > > On Thu, Jun 22, 2023 at 12:00 AM, Csepp wrote: > >> >> So, I built Netsurf with --with-latest=harfbuzz, which also affected >> GTK+ and a bunch of other packages along the way, and it worked on my >> first attempt, just needed a stronger machine. >> I copied over the resulting Netsurf to my laptop and have been using it >> all day today, it seems to have shooed that bug away. >> (Don't squash bugs, bugs are good for the ecosystem. They are only a >> problem when they get inside your mainframe and cause a short. UwU) >> BTW there was no log when it caused my system to hang. I had to reboot >> it with sysrq. Probably a kernel bug? >> >> So it looks like Harfbuzz can be updated without any problem. > > Great, that's good to hear and a nontrivial test too! I'll await > comments on this mesa+friends update branch and plan on including the > harfbuzz update there. Stay tuned... > > John Well, now the bug is back somehow??? I haven't updated anything since then. Didn't change fonts either. Still happens in a Harfbuzz call.
