bug#38050: Guix fails during downloading a substitute of google-brotli, throws an ugly backtrace

Hi Jan, Jan Wielkiewicz skribis: > Guix fails during downloading a substitute of google-brotli, throws an > ugly backtrace. That's basically it: > > ad-progress > /gnu/store/brvizic3qv469j8fd2xgsgx9p8s5s1j7-google-brotli-1.0.7-checkout > https://ci.guix.gnu.org/nar/gzip/brvizic3qv469j8fd2xgsgx9

bug#38086: RAID installation script with ‘mdadm’ no longer works

Hello, Looks like our RAID installation method no longer works, as can be seen at : --8<---cut here---start->8--- + guix --version guix (GNU Guix) c4de60ac3c6aa5b46519011af89988215c347e9e Copyright (C) 2019 the Gui

bug#38086: RAID installation script with ‘mdadm’ no longer works

Hello Ludo, Ludovic Courtès ezt írta (időpont: 2019. nov. 6., Sze, 11:14): > Hello, > > Looks like our RAID installation method no longer works, as can be seen > at : > > --8<---cut here---start->8--- > + guix --

bug#38087: IceCat: HTTPS Every-where becomes HTTPS No-where :-P

Hello Guix and GNUzilla! P.S. Mark, please don't feel pressured. I am just sumbmitting the issue for awareness and tracking. :-) I was using 'HTTPS Everywhere' add-on, with enabled https-only rule. After v68 upgrade, the icon disappears from the tool bar and https-only rule was not in effect as

bug#36375: [PATCH] Re: ‘guix package’ should lock the profile

Hello! Julien Lepiller skribis: >>From 5d86226f318a111cc1bdf5a6f044c6f540f51b45 Mon Sep 17 00:00:00 2001 > From: Julien Lepiller > Date: Fri, 25 Oct 2019 21:39:21 +0200 > Subject: [PATCH] guix: package: lock profiles when processing them. > > * guix/scripts/package.scm (process-actions): Get a

bug#38088: Guix system becomes unresponsive after backtrace

Hello, I did not know how to get the info better, so here is a screenshot about the situation. This happened when I was trying a pre-inst-env guix build from a core-updates checkout. Previously python3 failed to build, and I was trying to build it again. Best regards, g_bor -- OpenPGP Key Finge

bug#26302: [website] translations

Hi! "pelzflorian (Florian Pelz)" skribis: > From 04df1e5ee3fd542776b13eb3a59872e1647eb5f8 Mon Sep 17 00:00:00 2001 > From: Florian Pelz > Date: Tue, 5 Nov 2019 08:08:20 +0100 > Subject: [PATCH 03/13] services: Make it possible to include dynamic modules > in nginx. > > * gnu/services/web.scm (

bug#26302: [website] translations

Hi, "pelzflorian (Florian Pelz)" skribis: > From a5d9180d960d244053bea0d59d6092060fe4c6dd Mon Sep 17 00:00:00 2001 > From: Florian Pelz > Date: Tue, 5 Nov 2019 12:08:54 +0100 > Subject: [PATCH 01/13] doc: Explain more licensing aspects of the '--source' > build option. > > * doc/guix.texi (Add

bug#37931: util-linux dependency on udev

Hi, Marius Bakke skribis: > I had a look at the lsblkd source code, and found that it has an > optional dependency on udev: > > https://github.com/karelzak/util-linux/blob/ccafadb7c58865f73d209fcfc74483be96cdf64d/misc-utils/lsblk-properties.c > > I tried building util-linux with udev support, an

bug#38088: Guix system becomes unresponsive after backtrace

Hi Gábor, On Wed, 6 Nov 2019 15:15:41 +0100 Gábor Boskovits wrote: > This happened when I was trying a pre-inst-env guix build from a > core-updates checkout. > Previously python3 failed to build, and I was trying to build it again. Hmm, sounds like disk corruption. If there's a sudden read-on

bug#38064: Simple Scan: Scanner is not detected

I'm closing this issue as it was not really a bug in Simple Scan, but a missing service in the system configuration provided by the Guix System installer.

bug#38050: Guix fails during downloading a substitute of google-brotli, throws an ugly backtrace

Dnia 2019-11-06, o godz. 10:35:25 Ludovic Courtès napisał(a): > Hi Jan, > > > Could you send the log returned by: > > guix build --log-file > /gnu/store/brvizic3qv469j8fd2xgsgx9p8s5s1j7-google-brotli-1.0.7-checkout > > ? https://ci.guix.gnu.org/log/brvizic3qv469j8fd2xgsgx9p8s5s1j7-google-b

bug#38074: guix pull fails

Le 6 novembre 2019 17:34:01 GMT+01:00, Nathan Dehnel a écrit : >yes > >On Wed, Nov 6, 2019 at 12:38 AM Julien Lepiller >wrote: >> >> Le 5 novembre 2019 23:45:33 GMT+01:00, Nathan Dehnel > a écrit : >> >@ build-started >> >>/gnu/store/pgnp1cmz4f7494i1wm2gz2hsi05k1pwf-texlive-hyphen-occitan-49435-

bug#38088: Guix system becomes unresponsive after backtrace

Hi Gábor, Gábor Boskovits skribis: > I did not know how to get the info better, so here is a screenshot > about the situation. > > This happened when I was trying a pre-inst-env guix build from a > core-updates checkout. > Previously python3 failed to build, and I was trying to build it again.

bug#26302: [website] translations

On Wed, Nov 06, 2019 at 03:49:46PM +0100, Ludovic Courtès wrote: > Nitpick: I’d replace “Should be […] For example:” by “This should be a > list of file names of loadable modules, as in this example:”. > > Otherwise LGTM! > > Ludo’. I agree. Thank you! I copied your wording verbatim and will p

bug#26302: [website] translations

On Wed, Nov 06, 2019 at 03:56:48PM +0100, Ludovic Courtès wrote: > I don’t feel strongly about it, but to me, this is a discussion and thus > not quite in line with the style of this section as a reference of ‘guix > build’ options. > > As far as the discussion goes :-), I’d argue that the Corresp

bug#38087: IceCat: HTTPS Every-where becomes HTTPS No-where :-P

> Obviously these are very severe problems, and I will look into them > as > soon as I can. Would it be better to reverse the version just before 68? I remember you mentioned something about security fix in the 68 release; may be for now, it would be better to use the older version with only the

bug#38055: patchelf: Assertion failed when setting interpreter

Efraim Flashner (2019-11-05 18:18:22 +0200) wrote: > On Tue, Nov 05, 2019 at 03:12:23PM +0100, Ludovic Courtès wrote: > > > > Ivan Vilata i Balaguer skribis: > > > > > Hi, I'm using patchelf 0.8 from Guix commit 7f81cce3 on Debian Sid. > > > When trying to patch the `go` binary from > > >

bug#38093: ‘guix build --target’ crashes

I noticed this: --8<---cut here---start->8--- $ guix build coreutils --target=arm-linux-gnueabihf -n Backtrace: In srfi/srfi-1.scm: 592:29 19 (map1 (("diffutils" #) …)) 592:29 18 (map1 (("patch" #) …)) 592:29 17 (map1 (("findutils" #) …)) 592:29 16 (

bug#37931: Cannot guix refresh -ru util-linux to get updated lsblk

Hi Marius, On +2019-11-03 18:28:40 +0100, Marius Bakke wrote: > Bengt Richter writes: > > > On +2019-10-28 23:29:16 +0100, Marius Bakke wrote: > >> The `lsblk` program requires root privileges in order to detect file > >> systems and UUIDs. I'm guessing your distribution makes it setuid root? >

bug#38088: Guix system becomes unresponsive after backtrace

Hello, Ludovic Courtès ezt írta (időpont: 2019. nov. 6., Sze, 18:42): > > Hi Gábor, > > Gábor Boskovits skribis: > > > I did not know how to get the info better, so here is a screenshot > > about the situation. > > > > This happened when I was trying a pre-inst-env guix build from a > > core-upd

bug#38088: Guix system becomes unresponsive after backtrace

Danny Milosavljevic ezt írta (időpont: 2019. nov. 6., Sze, 16:52): > > Hi Gábor, > > On Wed, 6 Nov 2019 15:15:41 +0100 > Gábor Boskovits wrote: > > > This happened when I was trying a pre-inst-env guix build from a > > core-updates checkout. > > Previously python3 failed to build, and I was tryin

bug#38087: IceCat: HTTPS Every-where becomes HTTPS No-where :-P

Hi Raghav, > P.S. Mark, please don't feel pressured. I am just sumbmitting the issue > for awareness and tracking. :-) I appreciate these reports, thank you! > I was using 'HTTPS Everywhere' add-on, with enabled https-only rule. > > After v68 upgrade, the icon disappears from the tool bar and h

bug#38087: IceCat: HTTPS Every-where becomes HTTPS No-where :-P

Hi Raghav, Raghav Gururajan wrote: > Would it be better to reverse the version just before 68? > > I remember you mentioned something about security fix in the 68 > release; may be for now, it would be better to use the older version > with only the security patch from v68? It's not feasible for

bug#38088: Guix system becomes unresponsive after backtrace

Hello Gabor, Gábor Boskovits writes: [...] >> From the screenshot, it seems that your root file system (or at least >> /tmp and /gnu/store) became read-only, which in turn caused various >> things to fail, including guix-daemon (hence the “broken pipe” when >> ‘guix build’ was talking to it, I

bug#38088: Guix system becomes unresponsive after backtrace

It seems this was a filesystem corruption. Everything seems fine after reboot, so closing. Giovanni Biscuolo ezt írta (időpont: 2019. nov. 7., Cs, 8:36): > > Hello Gabor, > > Gábor Boskovits writes: > > [...] > > >> From the screenshot, it seems that your root file system (or at least > >> /tmp