bug#57878: Emacs native compilation on startup can crash the system
After updating to a commit after the introduction of native compilation in Emacs, I cannot start Emacs any more. It launches an ever increasing number of async processes for native compilation, which rapidly makes kswapd the main CPU user on my machine, and ultimately crashes the kernel. Some experiments showed that it's loading the site-lisp/site-start.el that causes this avalanche of processes: emacs -Q --batch --eval="(print load-path)" works fine. As does: emacs -Q --batch --load=~/.guix-profile/share/emacs/site-lisp/guix-emacs.el --eval="(print load-path)" But not: emacs -Q --batch --load=~/.guix-profile/share/emacs/site-lisp/site-start.el --eval="(print load-path)" which starts the avalanche of compilation. Possibly related: in my user-dir (~/.emacs.d/) I have a directory "eln-cache" containing a directory "28.1-f1a30909", but that directory remains empty. Perhaps all native compilation attempts fail and that's what causes the problem. Just guessing! Cheers, Konrad.
bug#57878: Minimal reproducible setup
My understanding of site-start.el is that it actually loads all the Emacs packages that are listed in my Guix profile. Which means that my package list matters. Here is a minimal containerized example that creates a process avalanche: guix shell -C emacs emacs-ido-completing-read+ \ -- emacs --batch --eval="(print load-path)" ido-completing-read+ is a rather small Emacs package, and I don't see anything obvious in it that could cause trouble with native compilation. But more importantly, I think no package should be able to cause the behavior that I observe. Cheers Konrad.
bug#57867: Tealdeer build fails
I have also run into this build failure.
The relevant error message from the build log appears to be:
Compiling openssl-macros v0.1.0
error[E0659]: `parse_quote_spanned` is ambiguous (`macro_rules` vs
non-`macro_rules` from other module)
-->
/tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:859:67
|
859 |
proj_generics.make_where_clause().predicates.push(parse_quote_spanned! { span =>
|
^^^ ambiguous name
|
note: `parse_quote_spanned` could refer to the macro defined here
-->
/tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/utils.rs:22:1
|
22 | / macro_rules! parse_quote_spanned {
23 | | ($span:expr => $($tt:tt)*) => {
24 | | syn::parse2(quote::quote_spanned!($span =>
$($tt)*)).unwrap_or_else(|e| panic!("{}", e))
25 | | };
26 | | }
| |_^
note: `parse_quote_spanned` could also refer to the macro imported here
-->
/tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:7:5
|
7 | *,
| ^
= help: use `self::parse_quote_spanned` to refer to this macro
unambiguously
bug#57853: “inappropriate ioctl for device” when running in RStudio Server
merge 57853 57095
thankyou
(I hope this works.)
Ricardo Wurmus writes:
> When running “guix” in RStudio Server the “terminal-window-size”
> procedure triggers an error. (You can ignore the cause of the error,
> because I’m running this in a container where
> /var/guix/profiles/per-user/rekado doesn’t exist.)
>
>> system("/bin/guix pull")
> guix pull: error: while creating directory
> `/var/guix/profiles/per-user/rekado': Permission denied
> hint: Backtrace:
> 18 (primitive-load "/bin/guix")
> In guix/ui.scm:
>2263:7 17 (run-guix . _)
> 2226:10 16 (run-guix-command _ . _)
> In ice-9/boot-9.scm:
> 1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
> 1747:15 14 (with-exception-handler # …)
> 1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/store.scm:
>656:37 12 (thunk)
> In guix/status.scm:
> 815:4 11 (call-with-status-report _ _)
> In guix/store.scm:
>1318:3 10 (_)
>1295:8 9 (call-with-build-handler # …)
> In guix/scripts/pull.scm:
> 526:3 8 (_)
> In guix/profiles.scm:
>2300:6 7 (ensure-profile-directory)
> In ice-9/boot-9.scm:
> 1685:16 6 (raise-exception _ #:continuable? _)
> 1685:16 5 (raise-exception _ #:continuable? _)
> In guix/ui.scm:
>827:16 4 (_ _)
>311:42 3 (display-hint "Please create the @file{/var/guix/profi…" …)
> In ice-9/boot-9.scm:
> 1747:15 2 (with-exception-handler # …)
> In guix/build/syscalls.scm:
> 2287:35 1 (_)
>2276:8 0 (terminal-window-size _)
>
> guix/build/syscalls.scm:2276:8: In procedure terminal-window-size:
> In procedure terminal-window-size: Inappropriate ioctl for device
>
> Here yousee that the call to terminal-window-size fails because the
> RStudio Server IDE in the web browser is not a true TTY.
> “terminal-window-size” should fail gracefully.
I think this is a duplicate of 57095.
bug#57867: Tealdeer build fails
On 17-09-2022 13:55, Daniel Sockwell via Bug reports for GNU Guix wrote: --> /tmp/guix-build-tealdeer-1.4.1.drv-0/tealdeer-1.4.1/guix-vendor/rust-pin-project-internal-0.4.22.tar.gz/src/pin_project/derive.rs:859:67 In antioxidant, I noticed that rust-pin-project-internal@0.4 doesn't build so I replaced it with rust-pin-project-internal@1 (and likewise for rust-pin-project). Maybe the same issue was present in the original cargo-build-system using code, and a similar fix would work? Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
bug#57882: [Gajim]: Crashes upon start.
Hello Guix! Gajim crashes with an error "Missing dependency: Namespace GtkSource not available for version 4", upon its start. I'm currently working on a patch. Regards, RG. OpenPGP_signature Description: OpenPGP digital signature
bug#57882: Acknowledgement ([Gajim]: Crashes upon start.)
Fixed at commit c54ef97c80f98fba77304efc560945fe78a4bafb. OpenPGP_signature Description: OpenPGP digital signature
bug#57878: Minimal reproducible setup
Konrad Hinsen writes: > Here is a minimal containerized example that > creates a process avalanche: > > guix shell -C emacs emacs-ido-completing-read+ \ >-- emacs --batch --eval="(print load-path)" I went through all my emacs packages. The only one that starts the process avalanche is emacs-ido-completing-read+. Cheers Konrad.
bug#57878: Minimal reproducible setup
Am Samstag, dem 17.09.2022 um 17:45 +0200 schrieb Konrad Hinsen: > Konrad Hinsen writes: > > > Here is a minimal containerized example that > > creates a process avalanche: > > > > guix shell -C emacs emacs-ido-completing-read+ \ > > -- emacs --batch --eval="(print load-path)" > > I went through all my emacs packages. The only one that starts > the process avalanche is emacs-ido-completing-read+. I think you can prevent native-compilation entirely by setting no- native-compile to t in your early-init.el (I'm playing with the idea of doing this anyway, because I'm annoyed by the clutter that falls through the cracks). That being said, this looks like a real breakage in the emacs-ido-completing-read package, does it not? Should we add "no-native-compile" to some local variables? WDYT?
bug#57899: emacs-jsonrpc hash mismatch
Hi, After I did a guix pull emacs-jsonrpc fails to build. Getting this: ---✀ building /gnu/store/gbcl55whjaxbvipa8jk7k4jbihnccn2a-jsonrpc-1.0.15.tar.drv... \sha256 hash mismatch for /gnu/store/6x4d5gd3hlml4kcgj9xcqwpjrgq3059f-jsonrpc-1.0.15.tar: expected hash: 1hx378rg12jz2zm105cvrqk0nqyzsn04l59d903l98d6lbd96rsw actual hash: 0biwvkvd48xqvigzs00yz4mk847xzyzm7p0lkns58fxph9nkg4h5 hash mismatch for store item '/gnu/store/6x4d5gd3hlml4kcgj9xcqwpjrgq3059f-jsonrpc-1.0.15.tar' build of /gnu/store/gbcl55whjaxbvipa8jk7k4jbihnccn2a-jsonrpc-1.0.15.tar.drv failed View build log at '/var/log/guix/drvs/gb/cl55whjaxbvipa8jk7k4jbihnccn2a-jsonrpc-1.0.15.tar.drv.gz'. cannot build derivation `/gnu/store/j5vdxaxnh92qvf931axizfabk5y7x1k6-emacs-jsonrpc-1.0.15.drv': 1 dependencies couldn't be built guix home: error: build of `/gnu/store/j5vdxaxnh92qvf931axizfabk5y7x1k6-emacs-jsonrpc-1.0.15.drv' failed After some investigating it doesn't look like the emacs-jsonrpc package description has changed. Odd thing is that the source doesn't seem to have changed either, I diffed it against the emacs-jsonrpc derivation I currently have installed and both source files match. I downloaded the source from elpa and checked the hash: ---✀ $ wget https://elpa.gnu.org/packages/jsonrpc-1.0.15.tar $ guix hash jsonrpc-1.0.15.tar 0biwvkvd48xqvigzs00yz4mk847xzyzm7p0lkns58fxph9nkg4h5 And it matches the hash guix get as well and not what is in the package definition. I'm using: guix ee0768c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: ee0768c7924134f7b4b215670c2a3ae481268fab Not sure what is going on. Or what is the best approach forward. Any ideas what could be wrong? -- s/Fred[re]+i[ck]+/Fredrik/g
