bug#64976: guix build: error: invalid character `~' in name
Certain characters are not allowed in store item[0] names. This restriction was inherited verbatim[1] from Nix. As such there's no bug here, although you could start a separate discussion about relaxing these restrictions if you like. So what to do? url-fetch defaults to the URL's basename as file name, but you can specify a different one. For example: (source (method …) (uri …) (file-name (string-append name "-" version ".tar.gz")) (sha256 …)) Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity. [0]: Top-level file names under /gnu/store. [1]: https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/store-api.cc#n58
bug#64963: guix pull bug
[jordan@hudzen:~]$ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to 5e9db8a (11,054 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git 5e9db8a 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% building /gnu/store/m1c8nf7bqbjdrlnxbfm9xvwalvw842f6-config.scm.drv... building /gnu/store/0xpdpf1az8p2i1zppn4s1w407f5b2ngg-git.scm.drv... building /gnu/store/c70kbbbw6v9vj10fab7jnbjl9yv3s23j-hash.scm.drv... building /gnu/store/dxm514svkzbaqhr6q90155fgi83jn51a-module-import.drv... building /gnu/store/pb1xa93qyfm717scdncmnr2wcvag-module-import.drv... building /gnu/store/7nr0qf2y6jsbz062ka2lc20wmvw48gc9-module-import-compiled.drv... building /gnu/store/nmg28ahn1ay5lz5xxnc9qzfb8c8fp01a-module-import-compiled.drv... building /gnu/store/cksmkzc1njkmfpmm9313fm74r0zf5yjv-compute-guix-derivation.drv... 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://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% 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% guix substitute: warning: while fetching https://ci.guix.gnu.org/nar/lzip/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash: server is somewhat slow guix substitute: warning: try `--no-substitutes' if the problem persists Backtrace: 16 (primitive-load "/gnu/store/hcwd16w004hqm0fw1k0r0xxkmag?") In guix/ui.scm: 2300:7 15 (run-guix . _) 2263: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/scripts/substitute.scm: 854:15 11 (_) 646:2 10 (process-substitution _ _ _ #:cache-urls _ #:acl _ # _ # ?) In ice-9/boot-9.scm: 1752:10 9 (with-exception-handler _ _ #:unwind? _ # _) In guix/scripts/substitute.scm: 463:7 8 (download-nar #< path: "/gnu/store/mzfkrxd4w8?> ?) In ice-9/boot-9.scm: 1747:15 7 (with-exception-handler # ?) 1685:16 6 (raise-exception _ #:continuable? _) 1683:16 5 (raise-exception _ #:continuable? _) 1685:16 4 (raise-exception _ #:continuable? _) 1780:13 3 (_ #<&compound-exception co
bug#64963: guix pull bug
One bit of context about this bug is I was running dnf update at the same time as this ocurred. re-running guix pull later failed to repdroduce the bug.
bug#64455: shepherd: unable to use redefined system/system* in 0.10.1
Hello, Sorry for the late reply, but release 0.10.2 didn't fix the issue. Current workaround: suppressing redefinition of system/system* and suppressing running tests/system-star.sh I am open to suggestions of how to help you debug that. Don't reply to buma2023, it was me, but it's a throw away address no longer valid. >Hi, > >Ludovic Courtès gnu.org> skribis: > >> "buma2023 outlook.fr" outlook.fr> skribis: >> >>> I am using happily shepherd since a few years as my init system on >>> Debian: amd64 (desktop and notebook), armhf (Cubox). >> >> Interesting! I didn’t know of such uses. >> >>> I was using 0.9.1 with guile-3.0.5 and fibers-1.1.1. >>> >>> I recently tried 0.10.1 with guile-3.0.9 and fibers 1.3.1 and >>> encountered a problem with using system and system* in my services: >>> the simple fact to have the symbol system or system* in >>> /etc/shepherd.scm or included files (even if the command is not >>> executed) leads to a misbehaving shepherd, more specifically the >>> shepherd socket disappears; the system boots but with multiple >>> instances of the launched daemons. >>> >>> If a system/system* command is executed while booting, shepherd >>> blocks at the point of its execution. >>> >>> Example of service causing the failure: >>> >>> (register-services >>> (make >>> #:provides '(mytest) >>> #:start (lambda args >>> (system "touch /tmp/somefile") >>> #t) >>> )) >>> >>> The service is not started at boot, I have to do it manually afterwards, >>> but I never can go there, as the shepherd socket is missing. >> >> I can reproduce it like this: >> >> $ cat /tmp/t.conf >> (register-services >> (make >> #:provides '(mytest) >> #:start (lambda args >> (system "touch /tmp/somefile") >> #t))) >> >> (start 'mytest) >> $ shepherd -I -c/tmp/t.conf -s /tmp/sock >> Starting service root... >> Service root started. >> Service root running with value #t. >> Service root has been started. >> Starting service mytest... >> C-c C-z >> [1]+ Stopped shepherd -I -c/tmp/t.conf -s /tmp/sock >> $ bg >> [1]+ shepherd -I -c/tmp/t.conf -s /tmp/sock & >> $ herd -s /tmp/sock status >> herd: error: /tmp/sock: Connection refused >> >> This is both with 0.10.1 and with >> d5ed516e736ce473902cc86b5cf4f61f27ebb642. > >Sorry, the bug is reproducible with 0.10.1 but *not* with >d5ed516e736ce473902cc86b5cf4f61f27ebb642. > >I believe this was fixed by Shepherd commit >2b310bd3b0ba0d7a08c77b456d34369cd6444edb (that is, after 0.10.1). > >I think I’ll release 0.10.2 within a couple of weeks, but it would be >great if you could confirm that current Shepherd ‘master’ works for you. > >Thanks! > >Ludo’. > Sincerely. -- Bernard
bug#64999: emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found
Hi, Since Emacs 29.1 was just released, I tried to install it with: guix install emacs-next --with-commit=emacs-next=emacs-29.1 This builds and installs without error, and it runs, but when Emacs tries to native-compile Elisp libraries at startup, I get these errors in the "*Warnings*" buffer: #+begin_example ⛔ Error (use-package): magit/:catch: Native compiler error: (lambda (&rest arg158) (let ((f #'make-process)) (apply f arg158))), "Compiling /home/me/src/emacs/configs/ap.el/eln-cache/29.1-d107c3ce/subr--trampoline-6d616b652d70726f63657373_make_process_0.eln... guile: warning: failed to install locale ld: cannot find crti.o: No such file or directory ld: cannot find crtbeginS.o: No such file or directory ld: cannot find -lgcc: No such file or directory ld: cannot find -lgcc: No such file or directory libgccjit.so: error: error invoking gcc driver Internal native compiler error: \"failed to compile\", \"/home/me/src/emacs/configs/ap.el/eln-cache/29.1-d107c3ce/subr--trampoline-6d616b652d70726f63657373_make_process_0.eln\", \"error invoking gcc driver\" Error: native-ice (\"failed to compile\" \"/home/me/src/emacs/configs/ap.el/eln-cache/29.1-d107c3ce/subr--trampoline-6d616b652d70726f63657373_make_process_0.eln\" \"error invoking gcc driver\") mapbacktrace(#f(compiled-function (evald func args flags) #-0x19aef44846510ebe>)) debug-early-backtrace() debug-early(error (native-ice \"failed to compile\" \"/home/me/src/emacs/configs/ap.el/eln-cache/29.1-d107c3ce/subr--trampoline-6d616b652d70726f63657373_make_process_0.eln\" \"error invoking gcc driver\")) comp--compile-ctxt-to-file(\"/home/me/src/emacs/configs/ap.el/eln-cache/29.1-d107c3ce/subr--trampoline-6d616b652d70726f63657373_make_process_0.eln\") comp-compile-ctxt-to-file(\"/home/me/src/emacs/configs/ap.el/eln-cache/29.1-d107c3ce/subr--trampoline-6d616b652d70726f63657373_make_process_0.eln\") comp-final1() load-with-code-conversion(\"/tmp/emacs-int-comp-subr--trampoline-6d616b652d70726f63657373_make_process_0-eF2T4W.el\" \"/tmp/emacs-int-comp-subr--trampoline-6d616b652d70726f63657373_make_process_0-eF2T4W.el\" nil t) command-line-1((\"-l\" \"/tmp/emacs-int-comp-subr--trampoline-6d616b652d70726f63657373_make_process_0-eF2T4W.el\")) command-line() normal-top-level() " #+end_example I also have the "emacs" package installed at 28.2, which works flawlessly with native compilation. I wonder if something changed in emacs.git since the 29.0.92 tag that requires a change to the Guix package definition in order to work. Thanks for your work on Guix.
bug#64999: Acknowledgement (emacs-next: emacs-29.1 fails to native-compile libraries, giving a runtime error that ctri.o and other files can't be found)
FYI, I hacked together a new package definition, updating the emacs-next one to build 29.1 from the release tarball, and after installing it, everything seems to work, including native compilation. I don't know enough about Guix to understand why using "guix install" with the package transformation option caused the runtime problem with gcc, but everything does seem to work with the updated definition. So I guess this report can be closed. OTOH, if anyone knows why the transformation option failed in that way, it might be helpful to solve it if possible, so users could use the option to install future releases without having to modify the package definition. (AFAIK, I was able to do that for various Emacs 28 versions without this problem, so I wonder if something's changed.) See also: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65000
bug#64976: guix build: error: invalid character `~' in name
Hello, When running "guix build -f alps.scm" where alps.scm uses url-fetch with (uri "https://exa.phys.s.u-tokyo.ac.jp/archive/MateriApps/src/alps_20220304~r7871.orig.tar.gz";) the following error occurs guix build: error: invalid character `~' in name 'alps_20220304~r7871.orig.tar.gz.drv' Bug was noted at repository URL: https://git.savannah.gnu.org/git/guix.git commit: c173819c8e5235ce02d60b79bd88b10023a7c614 branch: master(define-module (alps) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system cmake) ;;#:use-module (gnu packages cmake) #:use-module ((guix licenses) #:prefix license:) #:use-module (guix build utils) #:use-module (guix gexp) #:use-module (gnu packages boost) #:use-module (gnu packages algebra) #:use-module (gnu packages maths) ) (define-public alps (package (name "alps") (version "7871") (source (origin (method url-fetch) (uri (string-append "https://exa.phys.s.u-tokyo.ac.jp/archive/"; "MateriApps/src/alps_20220304~r7871.orig.tar.gz")) (sha256 (base32 "09klx0samxz9lap2j9q19264bdpydbrfqq1wmwwi9y01cwavkg3l" (build-system cmake-build-system) (arguments (list #:tests? #t #:configure-flags #~(list "-DALPS_BUILD_PYTHON=OFF"))) (native-inputs (list)) (inputs (list boost fftw openblas hdf5)) (propagated-inputs (list)) (synopsis "Algorithms and Libraries for Physics Simulations") (description "The ALPS project (Algorithms and Libraries for Physics Simulations) is an open source effort aiming at providing high-end simulation codes for strongly correlated quantum mechanical systems as well as C++ libraries for simplifying the development of such code. ALPS strives to increase software reuse in the physics community.") (home-page (string-append "https://web.archive.org/web/20210508050408/"; "https://alps.comp-phys.org/mediawiki/index.php/Main_Page";)) (license (license:non-copyleft "file://LICENSE" "See README in the deistribution." alps
bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor
On 2023-08-04 21:21, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: The Guix project does not block Tor. If the datacentre has decided to block Tor like it blocked most of Russia, there is little we can do but ask them to reconsider. Didn't mean to sound quite so fatalistic. We could always migrate issues. to a different machine, like guix.gnu.org was, but it's not very satisfying. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity.
bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor
Hi Altadil, On 2023-08-04 18:57, Altadil via Bug reports for GNU Guix wrote: it is no longer possible to get to the bug database at https://issues.guix.gnu.org/ when using Tor Browser. I forgot to mention this on IRC, but issues. is ‘simply’ a nicer unified frontend to the venerable GNU Debbugs instance. You can use its own[1] interface[2] as a work-around. The result is an error message saying: "The connection has timed out". It looks like a general block of Tor rather than a block of specific IPs, since attempting with different Tor circuits does not change the The Guix project does not block Tor. If the datacentre has decided to block Tor like it blocked most of Russia, there is little we can do but ask them to reconsider. Kind regards, T G-R Sent from a Web browser. Excuse or enjoy my brevity. [1]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix [2]: https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches
bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor
Hi, it is no longer possible to get to the bug database at https://issues.guix.gnu.org/ when using Tor Browser. The result is an error message saying: "The connection has timed out". It looks like a general block of Tor rather than a block of specific IPs, since attempting with different Tor circuits does not change the result. Best regards, Altadil
bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")
Hello, Sorry for the late reply! I removed http_proxy=http://127.0.0.1:9080 https_proxy=http://127.0.0.1:9080 from my "Environment" variable in "guix-daemon.service" and after I restarted the Guix daemon "guix pull" and "guix upgrade" went flawlessly. Thank you for your help. - avp On Fri, 28 Jul 2023 at 20:28, Christopher Baines wrote: > > > Artyom Poptsov writes: > > > Besides, I run GNU Guix on Ubuntu 22.04.2 LTS. > > Please find my SystemD Guix service attached. > > > > As you can see, I'm using a substitution service through Yggdrasil > > network: http://ci.guix.ygg.trop.in > > Also there's a proxy server configured. > > The downloading of the nar will pass through the proxy you've got > configured, so I guess that could be involved. > > I've now pushed a change to the code for downloading these nars so that > it outputs errors that it encounters. If you've got a checkout of > guix.git, you'll need to pull then do: > > ./pre-inst-env guix build -S texlive-hyphen-complete > > or: > > ./pre-inst-env guix build --check -S texlive-hyphen-complete > > Hopefully that output will include information about why the nar > couldn't be downloaded from bordeaux. You could also try configuring > wget to use the same proxy and trying the download that way. -- Artyom V. Poptsov Home page: https://memory-heap.org/~avp/ CADR Hackerspace co-founder: https://cadrspace.ru/ GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898 A02F
