bug#38167: guix pull takes over 8 GiB of memory to finish if there are no substitutes
Danny Milosavljevic writes: > Hi, > > guix pull takes over 8 GiB of memory to finish if there are no substitutes. > > My laptop only takes max 8 GiB of RAM. I've set up swap, but that kind of > memory usage still seems ridiculous. Do you know if the derivations got built in parallel? So, does guix pull --max-jobs=1 use the same amount of memory? signature.asc Description: PGP signature
bug#38167: guix pull takes over 8 GiB of memory to finish if there are no substitutes
Hi, guix pull takes over 8 GiB of memory to finish if there are no substitutes. My laptop only takes max 8 GiB of RAM. I've set up swap, but that kind of memory usage still seems ridiculous. pgpyF4ZirSunm.pgp Description: OpenPGP digital signature
bug#37860: [PATCH v2] gnu: qemu: Add upstream patch for failing test.
Miguel Arruga Vivas writes: > Hi, > > They have solved the problem on qemu's master branch, as the author > kindly told me[1], so I propose this patch to add their patch on top > of our current version. I've tested it on x86_64, WDYT? LGTM, applied! I edited the comment and commit message to refer back to this bug report. signature.asc Description: PGP signature
bug#38050: Guix fails during downloading a substitute of google-brotli, throws an ugly backtrace
On Sun, 10 Nov 2019 17:24:15 +0100 Ludovic Courtès wrote: > Hi Jan, > > How reproducible is it? 100%? > I tried only two times by now. It doesn't happen when I run "./pre-inst-env guix build google-brotli" though. So reproducibility is equal to 100% with 25% chance for error :) (while building Jami). > > Could you try again, this time stracing the process with: > > ./pre-inst-env strace -o /tmp/log -s 300 guix build jami > > ? Yes, but after I finish compiling all Jami dependencies and this takes some time on core 2 duo. If you didn't know - compiling libreoffice takes 7 hours, llvm - 3h, mariadb - 2h, fun! > Once you’ve reproduced the failure above, could you send /tmp/log (or > the tail of that file)? Okay. > Thanks in advance! > > Ludo’. Jan Wielkiewicz
bug#38163: GDK does not return the monitor's refresh rate
I have been developing and testing my GTK app (Zrythm) on many distros and Guix is the only case that the monitor's refresh rate is returned as 0. The API I am using is this: https://developer.gnome.org/gdk3/stable/GdkMonitor.html#gdk-monitor-get-refresh-rate I was developing/testing on Parabola GNU/Linux-libre before and it was giving me a correct rate of 60 Hz. Other distros I have tested this API before on: Various ubuntu versions, debian 9 and 10, manjaro (arch), various fedora versions, plus a few others that users tested on. I suspect GDK is trying to access something that guix doesn't make available to it, but I don't have much knowledge of the internals of GDK or Guix to debug this myself. I will post a package from my guix channel that you can test this on soon. To call the API, one basically calls the following, after including , so any GTK program will do. ``` GdkDisplay * display = gdk_display_get_default (); GdkMonitor * monitor = gdk_display_get_primary_monitor (display); int refresh_rate = gdk_monitor_get_refresh_rate (monitor); ``` signature.asc Description: This is a digitally signed message part
bug#38050: Guix fails during downloading a substitute of google-brotli, throws an ugly backtrace
Hi Jan,
Jan Wielkiewicz skribis:
> Dnia 2019-11-07, o godz. 21:16:44
> Ludovic Courtès napisał(a):
>
>> Hello,
>>
>>
>> Oh actually that’s not helpful, my bad. What we would have need is
>> the output of ‘guix substitute’ (invoked by the daemon), but that is
>> not logged as-is. :-/
>>
>> I’ll take another look at the relevant code (and invite everyone to
>> give it a shot :-)), and in the meantime we can leave this bug open.
>> Do reply if that happens again!
> Okay, this have happened again. Maybe it's caused by something I
> changed in Jami. I'm attaching the most recent changes.
How reproducible is it? 100%?
> Running "./pre-inst-env guix build jami" causes this:
>
> 3583063 14106624
> google-brotli-1.0.7-checkout 22.5MiB
> 770KiB/s 00:26 [### ]
> 86.1%Backtrace: In guix/store.scm: 623:10 19 (call-with-store _)
> In guix/scripts/build.scm:
>927:26 18 (_ #)
> In ice-9/boot-9.scm:
> 829:9 17 (catch _ _ # …)
> In guix/ui.scm:
> 425:6 16 (_)
> In guix/scripts/build.scm:
> 892:5 15 (_)
> In srfi/srfi-1.scm:
>679:15 14 (append-map _ _ . _)
>592:17 13 (map1 ("x86_64-linux"))
>679:15 12 (append-map _ _ . _)
>592:17 11 (map1 (#))
> In guix/scripts/build.scm:
>853:18 10 (_ _)
> In guix/packages.scm:
>948:16 9 (cache! # # …)
> In guix/grafts.scm:
> 323:4 8 (graft-derivation # …)
> 172:4 7 (references-oracle # …)
>182:20 6 (_ _ _)
> In guix/store.scm:
> 1215:15 5 (_ # _ _)
>718:13 4 (process-stderr _ _)
> In unknown file:
>3 (display "@ substituter-succeeded /gnu/store/m18k3ba7y…" …)
> In guix/status.scm:
>691:16 2 (write! _ _ _)
> 605:6 1 (_ (download-progress "/gnu/store/brvizic3qv469j8fd…" …) …)
> In guix/progress.scm:
>219:14 0 (display-download-progress "google@" #f #:start-time _ # …)
>
> guix/progress.scm:219:14: In procedure display-download-progress:
> In procedure =: Wrong type: #f
Could you try again, this time stracing the process with:
./pre-inst-env strace -o /tmp/log -s 300 guix build jami
?
Once you’ve reproduced the failure above, could you send /tmp/log (or
the tail of that file)?
Thanks in advance!
Ludo’.
bug#38162: icedtea "jar" tool could automatically pack reproducible jars
Hi, it would be better if icedtea's "jar" tool automatically packed reproducible jar files instead of us doing some barely safe unzip-then-rezip-with-specific-order in the ant-build-system. It could check the environment variable SOURCE_DATE_EPOCH and then use that as timestamp for the zip entries. Alternatively, it could just leave the DOS timestamp field off of the zip entries. Maven already has support for the former[1]--we might be able to reuse that. [1] https://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html pgpNCqpHBrYfE.pgp Description: OpenPGP digital signature
bug#38161: Guix guided installer should set up printers and scanners
Hi, currently, the Guix guided installer does not set up printers and scanners (see bug# 38064), making those not work after installation. It would be good to extend the Guix installer to also install "cups" and "sane-backends" services, just like it already does for networking services, if applicable. Long term, we could also do the actual configuration, but right now even just the services below would already be a big improvement: The relevant operating-system config snippets are: (services (append (list (service cups-service-type (cups-configuration (web-interface? #t) (extensions (list cups-filters escpr hplip-minimal (simple-service 'custom-udev-rules udev-service-type (list sane-backends)) [...] pgpxuUlBL7zFw.pgp Description: OpenPGP digital signature
bug#38055: none
Hi,
Efraim Flashner skribis:
> From 2db156170a24fea36aced781faf96c839a3b7d15 Mon Sep 17 00:00:00 2001
> From: Efraim Flashner
> Date: Sat, 9 Nov 2019 20:19:11 +0200
> Subject: [PATCH] gnu: patchelf: Update to 0.10.
>
> * gnu/packages/elf.scm (patchelf): Update to 0.10.
> [source]: Remove patches.
> [arguments]: Remove patch/rework-for-arm phase. Add phase to modify
> tests for our modified GCC package.
> [native-inputs]: Add gcc:lib.
> * gnu/packages/patches/patchelf-page-size.patch,
> * gnu/packages/patches/patchelf-rework-for-arm.patch: Remove files.
> * gnu/local.mk (dist_patch_DATA): Remove them.
[...]
> + (modify-phases %standard-phases
> + (add-after 'unpack 'fix-tests
> + ;; Our GCC code ensures that RUNPATH is never empty, it includes
> + ;; at least glibc/lib and gcc:lib/lib.
> + (lambda* (#:key inputs #:allow-other-keys)
> + (substitute* "tests/no-rpath.sh"
> + (("^if test.*") "")
> + (("/xxx") (string-append (assoc-ref inputs
> "gcc:lib")
> +"/lib")))
Could you complement the above comment with something like: “Thus,
disable the test that checks for an empty RUNPATH.”, or whatever is
appropriate? That will clarify the intent because it’s not obvious what
the substitution is doing if you don’t have the file at hand. :-)
Otherwise LGTM, thanks for addressing this issue!
Ludo’.
bug#38159: nm-applet
Hello Guix! After committ "6d18427" (exclusive), there are some issues with nm- applet. 1) The WiFi shows as connected even when the WiFi is turned off. 2) When configured to automatically connect to VPN via 'nm-connection- editor' for WiFi networks, the VPN connects in the background but does not show as connected on the applet. 3) The whole 'VPN Menu' in the applet is gone. Regards, RG. signature.asc Description: This is a digitally signed message part
