bug#43818: [PATCH] packages: Fix a bug in %patch-path.

Hi, Maxim Cournoyer skribis: > Fixes . > > Having the Guix root trailed by a slash in the GUILE_LOAD_PATH would > previously cause %patch-path to not return an entry with the patches > sub-directory, leading to errors such as: > >While executing meta-comman

bug#44194: Cuirass ignoring proc_args on Berlin

Hi Marius, Marius Bakke skribis: > Cuirass is currently evaluating all of 'core-updates': > > https://ci.guix.gnu.org/jobset/core-updates-core-updates > > This is despite (subset . core) in "proc_args". It should be (subset . "core"), with quotes. I’ve changed it now, let’s see! Ludo’.

bug#43850: cuirass: inconsistent SQL queries execution time.

Hi, Mathieu Othacehe skribis: >> I have now copied the database to a tmpfs mounted directory to make sure >> that those inconsistent duration are only caused by the I/O pressure on >> berlin. > > This helps a lot. The Cuirass web service has been running smooth since > two days, without any inco

bug#44104: [patch] guix publish: provide server's signing key.

Hi, "Amar M. Singh" skribis: > From fe0098082289a2350002da4e2438c41f6385b3e2 Mon Sep 17 00:00:00 2001 > From: Amar Singh > Date: Wed, 21 Oct 2020 02:02:02 +0530 > Subject: [PATCH] guix publish: Provide server's signing key. > > Published at $(guix-publish-uri)/signing-key.pub > > Knock yourselv

bug#39260: bug#41409: “guix pull” should show a progress bar for channel updates

Ludovic Courtès skribis: > And now the Guix side of it: > > https://issues.guix.gnu.org/43968 Merged in 298f9d29d6c26e408a90d08d147d926aa6f81ab3, closing! Ludo’.

bug#44196: [PATCH 4/3] system: Fix dependency for grub.cfg generation.

One extra bit :-) * The keymap was depending on the exported package grub, not on the one provided by the bootloader configuration, so e.g. systems that use grub-efi also ended up with grub in their dependency graph. This patch solves that issue. >From ae2d83f91d522b5b0edfe1abbe88dec0a797235c Mo

bug#25305: bug#37851: Grub installation only checks for encrypted /boot folder

Hello! Ludovic Courtès writes: > Does that cause GRUB to mount all the LUKS partitions it was aware of at > installation time, or does it cause it to scan all the partitions in > search of a LUKS signature? > > In the latter case that wouldn’t be great, but in the former case it > sounds like we

bug#40558: (no subject)

elaexuo...@wilsonb.com writes: > With the patch to texlive-amsfonts the above typesets just fine; > however, metafont ends up generating cmmi10.657pk and cmr10.657pk font > files. Is this expected? Typsetting it from the texlive installation > of my foreign distro doesn't call out to metafont at

bug#44196: [PATCH 3/3 v3] system: Do not depend on locale folder generated by grub-install.

This version doesn't modify grub package at all, and it only generates the folder when needed, and fixes a bug in Grub 2.04 that I didn't noticed until I started playing with the installer: https://savannah.gnu.org/bugs/?57889 Happy hacking! Miguel >From 770532b931c312edb9f9a075d86dc132b804dc0b Mo

bug#42941: qgis: plugin installation fails with python error

Fixed in 542dc0ee4f2385c4d71f65fe3a36f4fe9eb68b9a.

bug#44243: problems with cyrillic in games

hi everyone! i cannot type cyrillic chars in games (for example in xonotic). it refuses to print out any chars after i change layout

bug#44244: meson build-system has no cross-compilation support

Hi, meson build-system has no cross-compilation support. $ ./pre-inst-env guix build --target=arm-linux-gnuhf gobject-introspection guix build: error: /home/dannym/src/guix-master/guix/gnu/packages/glib.scm:419:2: gobject-introspection@1.62.0: build system `meson' does not support cross builds

bug#24066: icecat "mailto" handler does not work - and cannot be reconfigured by user

This issue annoys me, so I searched for a workaround which I found :) In Icecat go to about:preferences -> General -> Applications (only a header): Set mailto to `Use other` and set it to `/run/current-system/profile/bin/icedove`. $ grep mailto /gnu/store/3zxx08qfl9q6d9s80p58521y9x3ni3p1-icedove-

bug#43565: cuirass: Fibers scheduling blocked.

Hello! Mathieu Othacehe skribis: >> But does Cuirass create file descriptors as O_NONBLOCK? This has to be >> done explicitly, Fibers won’t do it for us. As it turns out, the answer >> is no, in at least one important case: the connection to the daemon >> (untested patch below). >> >> While GC

bug#44030: guix import pypi foo@1.2.3 breaks

Hi, On Sun, 25 Oct 2020 at 23:50, Lulu wrote: > I just sent in a patch to fix this for the pypi importer, although > ideally we'd want versioning support for all importers with a uniform > syntax. The uniform syntax is ’@’. However, it is importer by importer (case by case) since the external A

bug#44030: [PATCH] guix: import: Add versioning syntax to pypi importer.

Hi, Thank you for working on this. On Sun, 25 Oct 2020 at 23:04, Lulu wrote: > Ah, heck, I used an old revision of the file when I generated the diff. > Sorry about that. Here's the properly working patch: That’s fine. Usually to ease the reading, it is a good habit to increase the version of

bug#43960:

Hi, On Sun, 25 Oct 2020 at 23:33, Miguel Ángel Arruga Vivas wrote: > I'm hitting this while testing some patches too. Well, I do not know if it is related to the initial bug. > [env]$ make check-system TESTS=encrypted-root-and-boot-os > [...] > successfully built > /gnu/store/32qhcfz3amwq9z

bug#43565: cuirass: Fibers scheduling blocked.

Hey! Many thanks for your help, you rock! > But does Cuirass create file descriptors as O_NONBLOCK? This has to be > done explicitly, Fibers won’t do it for us. As it turns out, the answer > is no, in at least one important case: the connection to the daemon > (untested patch below). > > Whil

bug#31302: `guix import json` doesn't handle inputs with the form 'package:output'

Dear, On Sun, 25 Oct 2020 at 20:12, Lulu wrote: > So, it seems like this bug was fixed somewhere along the line. Yep, the bug is fixed. Probably by these: 7cef499bb0 * import/json: json->code: Handle files with more than one definition. c893432320 * import/json: Use json->code. 16dd764691 *

bug#31302: `guix import json` doesn't handle inputs with the form 'package:output'

The version hash of Guix I tried this on was `26f6bd0403ed20c1d26eca9d4f28a0da519a56ac'. I used the example JSON file for the `hello' package provided in "(guix)Invoking guix import". Then, based on the given example of glib, I tried running `guix import json' with `glib', `glib:bin', `glib:doc',

bug#44175: [optimization] Grafting is too slow

Hi, > Yes, you’re right of course. But I think in the example above Lars was > reporting the run time of the ‘guix’ command when the graft itself is > already built. Just the extra code to compute the graft derivation (not > actually building them) leads to x2 wall-clock time or so. yes, Ludo is

bug#44030: guix import pypi foo@1.2.3 breaks

I just sent in a patch to fix this for the pypi importer, although ideally we'd want versioning support for all importers with a uniform syntax. I poked and prodded at the RubyGems API to see if it can do what PyPI can. It's unfortunately much more limited: API v1 provides a method for querying al

bug#44030: [PATCH] guix: import: Add versioning syntax to pypi importer.

Use @ as the unified versioning syntax, as per crate and hackage importers, plus minor spacing fixes. diff --git a/guix/import/pypi.scm b/guix/import/pypi.scm index 15116e349d..add2a7ed7a 100644 --- a/guix/import/pypi.scm +++ b/guix/import/pypi.scm @@ -118,13 +118,15 @@ (define (pypi-fetch nam

bug#44030: [PATCH] guix: import: Add versioning syntax to pypi importer.

Ah, heck, I used an old revision of the file when I generated the diff. Sorry about that. Here's the properly working patch: diff --git a/guix/import/pypi.scm b/guix/import/pypi.scm index 15116e349d..1ec1ecbfa1 100644 --- a/guix/import/pypi.scm +++ b/guix/import/pypi.scm @@ -118,13 +118,15 @@