bug#26791: Attempt to apply a string as a procedure during Hydra evaluation

l...@gnu.org (Ludovic Courtès) writes: > Danny Milosavljevic skribis: > >> I think it always works (also without compilation) when I move the >> boot-parameters record definition up in gnu/system.scm (so it comes before >> its clients). > > Yeah I just pushed that as 8e815c5b6903a545c46b674c1cd

bug#26791: Attempt to apply a string as a procedure during Hydra evaluation

Leo Famulari writes: > On Sun, May 07, 2017 at 11:35:39AM +0200, Ludovic Courtès wrote: >> Hi, >> >> Danny Milosavljevic skribis: >> >> > I think it always works (also without compilation) when I move the >> boot-parameters record definition up in gnu/system.scm (so it comes >> before its clie

bug#26877: building fonts: fontcache must be updated regulary

ng0 writes: > The problem: Right now after just installing fonts, they do > not become available. This can lead to some applications > appearing "broken", etc. Other operating systems solve this > by having a post-install hook which roughly does just this. > > A possible solution: > Our fictional

bug#26901: During offload, in procedure send-files, '=' applied to #false

Any idea what went wrong with this aborted build? https://hydra.gnu.org/build/2043652 Nix error output: --8<---cut here---start->8--- these derivations will be built: /gnu/store/7myxmyy4q8jx8fqfz8y13vvynx31vf9m-spice-0.12.8.drv process 13271 acquired build

bug#26936: grub_cmd_set_date test sometimes fail

Maxim Cournoyer writes: > I've been encountering this test failure a couple times (3 out of 4 last > build I've tried) recently on my GuixSD x86_64 system when building grub > version 2.02. I've encountered the same problem on my x86_64 system. Mark

bug#26975: Frequent errors in guix publish on Hydra

Here's a recent excerpt of the console output from guix publish running Hydra. Is this expected? Mark --8<---cut here---start->8--- GET /ggy44sk2w47j0dpbghpb9ipr6kik6vsm.narinfo GET /qnpsdhgiabvr89i9vdcmhzkggs79i0pc.narinfo GET /zgzvzsbhvyinb3vdsgswkqh2b

bug#26976: On Hydra, offload crashes while trying to build linux-libre source

On Hydra, the builds of linux-libre-4.11.1's source code aborted on all three hydra-supported-systems: https://hydra.gnu.org/build/2071337 (x86_64) https://hydra.gnu.org/build/2071533 (i686) https://hydra.gnu.org/build/2071510 (armhf) The failure output on x86_64 and i686 are roughly the sa

bug#26976: On Hydra, offload crashes while trying to build linux-libre source

Mark H Weaver writes: > On Hydra, the builds of linux-libre-4.11.1's source code aborted on all > three hydra-supported-systems: > > https://hydra.gnu.org/build/2071337 (x86_64) > https://hydra.gnu.org/build/2071533 (i686) > https://hydra.gnu.org/build/2071510

bug#26976: On Hydra, offload crashes while trying to build linux-libre source

l...@gnu.org (Ludovic Courtès) writes: > I’ve stopped the queue-runner while investigating. To be continued… For now, I would suggest downgrading the 'guix' on Hydra to be based on guile-2.0 again, so that it can be building things while we sort this out. What do you think? Mark

bug#27090: Frequent errors from 'guix publish' on Hydra

On Hydra, 'guix publish' is printing many errors to its stdout/stderr. See below for an excerpt of its recent output. I killed it and restarted it. Mark --8<---cut here---start->8--- GET /2x7d43qilhp39njy0s2qh7cqv1wqqcy3.narinfo In ice-9/boot-9.scm: 16

bug#26948: gnutls errors on multiple guix commands

l...@gnu.org (Ludovic Courtès) writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> It seems that the problem is caused by the file: >> "/etc/ssl/certs/AC_Ra\303\255z_Certic\303\241mara_S.A.:2.15.7.126.82.147.123.224.21.227.87.240.105.140.203.236.12.p". This reminds me of a bug that I found in

bug#26948: gnutls errors on multiple guix commands

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> This reminds me of a bug that I found in the Guile binding in GnuTLS a >> while ago, but forgot to report. Maybe it's related: >> >> In 'set_certificate_file' in

bug#27069: LUKS partition ruined by guix init

Marius Bakke writes: > some...@selfhosted.xyz writes: > >> Hi, >> >> I have several times over tried to install to a LUKS-partition with >> btrfs and failed but last time I almost had success. guix init command >> complained that the bios_grub flag wasn't set after many hours of >> compiling pack

bug#27138: guix publish "mutex already locked by thread"

Here's an excerpt of recent 'guix publish' output on Hydra. This new "mutex already locked by thread" error message is now occurring quite frequently. Mark --8<---cut here---start->8--- GET /wvv490g2abml39arfsw38il1xh3xxyrm.narinfo GET /rj4f18rg66bwrkhj

bug#27157: Building Guile 2.2 "times out"

Ricardo Wurmus writes: > Hi Maxim, > >> I'm not sure where this timeout value can be configured, but clearly it >> shouldn't be 1 hour since 2 cores of an i5 intel class processor can't >> manage to build it under 1 hour. > > for the guile-2.2 package I see that this is part of the package > defi

bug#27152: deprecation warnings with Guile 2.2.2

Maxim Cournoyer writes: > On Wed, May 31, 2017 at 2:00 PM, Ludovic Courtès wrote: > > Ricardo Wurmus skribis: > > > I get a couple of deprecation warnings with Guile 2.2.2, for example > > > > Import (ice-9 threads) to have access to `current-processor-count'. > > `_IOFBF' is deprecated. U

bug#27152: deprecation warnings with Guile 2.2.2

Maxim Cournoyer writes: > Mark H Weaver writes: > >> Maxim Cournoyer writes: >> >>> Why not let good old sed have a run at it? Seems like a simple find >>> and replace operation, and 'block looks nicer than _IOFBF to my >>> eyes. >> &g

bug#27152: deprecation warnings with Guile 2.2.2

Maxim Cournoyer writes: > Mark H Weaver writes: > >> Maxim Cournoyer writes: >> >>> Mark H Weaver writes: >>> >>>> Maxim Cournoyer writes: >>>> >>>>> Why not let good old sed have a run at it? Seems like a simple

bug#27242: Fail to load LUKS encrypted rootfs, attempts to open luks device before it's ready.

. Mark >From b7c1947d050a944937b983532d940491821fa75f Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Tue, 28 Mar 2017 05:52:28 -0400 Subject: [PATCH] DRAFT: Cope with delayed appearance of LUKS source. --- gnu/system/mapped-devices.scm | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff -

bug#27261: guix package -u should warn about non-existent packages

In order to guard against users unwittingly using old software with unpatched security flaws, "guix package -u" should issue a warning if any packages in the profile that match the provided patterns are not found in the set of available packages. Mark

bug#27262: guix package -r FOO -u . should not upgrade FOO

When removing and upgrading packages in a single invocation of "guix package", removed packages should be automatically excluded from the set of packages to upgrade. Mark

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

On my x86_64-linux system running GuixSD, on my first attempt to update my system since 'staging' was merged, GNOME Shell consistently fails to start. If I switch to tty1 (text console), I see this error message: --8<---cut here---start->8--- (.gnome-shell-real

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

Roel Janssen writes: > Ludovic Courtès writes: > >> Hi, >> >> Mark H Weaver skribis: >> >>> (.gnome-shell-real:11698): Gjs-WARNING **: JS ERROR: Error: Requiring Rsvg, >>> version none: Typelib file for namespace 'Rsvg' (any versi

bug#27242: Fail to load LUKS encrypted rootfs, attempts to open luks device before it's ready.

Adam Van Ymeren writes: > Mark H Weaver writes: >> >> I ran into the same problem at one point, and have applied the following >> patch to my private branch of Guix. Perhaps it should be applied to >> master. > > Thanks, this patch works for me. Something l

bug#27157: Building Guile 2.2 "times out"

Ricardo Wurmus writes: > Mark H Weaver writes: > >> I think we should further increase the 'max-silent-time' value for >> Guile-2.2. I've had to restart that build several times on ARM. 3 >> hours might be enough on a machine that's not doing anyt

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

Marius Bakke writes: > Mark H Weaver writes: > >> I have a question: Does GNOME 3 work for *anyone* in Guix now? If so, >> that would be useful information. If not, I wonder why this got merged >> into master. > > I'm sorry, I don't actually us

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Hi Mark, > > Mark H Weaver skribis: > >> I have a question: Does GNOME 3 work for *anyone* in Guix now? If so, >> that would be useful information. If not, I wonder why this got merged >> into master. > &g

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

Marius Bakke writes: > Marius Bakke writes: > >> Mark, others: Can you try these patches and see if they work for you >> (extracted from Keis patch). > > Actually, I just pushed them to 'master' since geoclue rebuilds > 'webkitgtk' and Kei had already verified that gnome-shell now starts. The p

bug#27287: gnome-tweak-tool fails to start

Chris Marusich writes: > I recently did a "guix pull" and upgraded the software installed in my > profile. Since then, gnome-tweak-tool has failed to start. Before > that, it started up successfully. > > Here's the error: > > --8<---cut here---start->8--- > $

bug#27264: gnome-shell-3.24.2 consistently dies during initialization

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I'm annoyed that I've been forced to either use a different desktop >> environment in the meantime or else sacrifice security updates. I would >> never consider pushing suc

bug#26976: On Hydra, offload crashes while trying to build linux-libre source

l...@gnu.org (Ludovic Courtès) writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> Mark H Weaver skribis: >> >>> l...@gnu.org (Ludovic Courtès) writes: >>>> I’ve stopped the queue-runner while investigating. To be continued… >>> >>> Fo

bug#26976: On Hydra, offload crashes while trying to build linux-libre source

Mark H Weaver writes: > l...@gnu.org (Ludovic Courtès) writes: > >> I’ve installed ‘guile2.0-guix’ on hydra.gnu.org, and it’s now running it >> for guix-daemon and ‘guix publish’. Let’s see… > > We're now seeing many builds aborting with errors like this: > &g

bug#27429: Stack clash (CVE-2017-1000366 etc)

Leo Famulari writes: > This is a place to discuss the "stack crash" bugs as they apply to our > packages. > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000366 > https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt I pushed commit 91c623aae0f10992aa46957b9072679534e4cd28 w

bug#27429: Stack clash (CVE-2017-1000366 etc)

d them. In particular, you are right to add (replacement #f) in the places where you've done so. > diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm > index 1b41feac1..42892bbe8 100644 > --- a/gnu/packages/commencement.scm > +++ b/gnu/packages/commencement.scm

bug#27429: Stack clash (CVE-2017-1000366 etc)

Leo Famulari writes: > On Wed, Jun 21, 2017 at 07:52:27PM -0400, Leo Famulari wrote: >> On Wed, Jun 21, 2017 at 12:50:45PM +0300, Efraim Flashner wrote: >> > Had to make a small change to the patch, it turns out it couldn't build >> > the source for glibc@2.21, so I changed the source to inherit

bug#27437: Source downloader accepts X.509 certificate for incorrect domain

l...@gnu.org (Ludovic Courtès) writes: > The behavior of the source download is on purpose as noted in (guix > download): > >;; No need to validate certificates since we know the >;; hash of the expected result. >#:verify-cert

bug#27429: Stack clash (CVE-2017-1000366 etc)

Leo Famulari writes: > On Wed, Jun 21, 2017 at 12:50:45PM +0300, Efraim Flashner wrote: >> Subject: [PATCH] gnu: glibc: Patch CVE-2017-1000366. >> >> * gnu/packages/base.scm (glibc/linux)[replacement]: New field. >> (glibc-2.25-fixed): New variable. >> (glibc@2.24, glibc@2.23, glibc@2.22, glibc@

bug#27429: Stack clash (CVE-2017-1000366 etc)

Leo Famulari writes: > On Fri, Jun 23, 2017 at 02:36:41PM -0400, Mark H Weaver wrote: >> Most packages are linked with 'glibc-final' in (gnu packages >> commencement), and we should expect them to now be linked with *its* >> replacement. Try this to find the e

bug#27467: Xfce broken, because it propagates two different versions of gtk+

I just tried to update my GuixSD system to commit c57b56722f6c167c5a285f47802047de85a356ae on master. "guix system build" failed with the following error: guix system: error: profile contains conflicting entries for gtk+:out guix system: error: first entry: gtk+@2.24.31:out /gnu/store/901ify6f

bug#27429: Stack clash (CVE-2017-1000366 etc)

Mark H Weaver writes: > Leo Famulari writes: > >> On Fri, Jun 23, 2017 at 02:36:41PM -0400, Mark H Weaver wrote: >>> Most packages are linked with 'glibc-final' in (gnu packages >>> commencement), and we should expect them to now be linked with *its

bug#27467: Xfce broken, because it propagates two different versions of gtk+

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I just tried to update my GuixSD system to commit >> c57b56722f6c167c5a285f47802047de85a356ae on master. "guix system build" >> failed with the following error: >> >> guix syste

bug#27489: glibc fails to build on i686

Ricardo Wurmus writes: > Since commit 665d6a59161769e10b52ffcbcd5cd2db22f32681 I have to build > glibc from source. Unfortunately, this fails with the following error: > > … > i686-guix-linux-gnu-gcc ../sysdeps/i386/i686/multiarch/strcspn-c.c -c > -std=gnu11 -fgnu89-inline -O2 -Wall -Werror -W

bug#27489: glibc fails to build on i686

Mark H Weaver writes: > Ricardo Wurmus writes: > >> Since commit 665d6a59161769e10b52ffcbcd5cd2db22f32681 I have to build >> glibc from source. Unfortunately, this fails with the following error: >> >> … >> i686-guix-linux-gnu-gcc ../sysdeps/i386/i686/mul

bug#27489: glibc fails to build on i686

Mark H Weaver writes: > Ricardo Wurmus writes: > >> Since commit 665d6a59161769e10b52ffcbcd5cd2db22f32681 I have to build >> glibc from source. Unfortunately, this fails with the following error: >> >> … >> i686-guix-linux-gnu-gcc ../sysdeps/i386/i686/mul

bug#27489: glibc fails to build on i686

Mark H Weaver writes: > The problem is that glibc-CVE-2017-1000366-pt2.patch introduces a > reference to 'strcspn' in rtld.c. This causes the glibc build system to > automatically add 'rtld-strcspn.os' and 'rtld-strcspn-c.os' to the list > of objects

bug#27489: glibc fails to build on i686

I believe this problem is fixed by commit ffc015bea26f24d862e7e877d907fbe1ab9a9967. I was able to build a grafted 'hello' for i686-linux, and it worked correctly. Can you try it and report back? Mark

bug#27429: Stack clash (CVE-2017-1000366 etc)

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I tried to copy the .drv files for the grafted 'glibc-final' and >> 'glibc-final-with-bootstrap-bash' from my machine to Hydra, in order to >> ask Hydra to build it, but

bug#27489: glibc fails to build on i686

Adonay Felipe Nogueira writes: > NOTE: This message isn't meant to sound aggressive, it's just a question > from a novice Guix user. > > Here is my situation: > > - I'm using Guix in a foreign distribution (Trisquel 7). > > - In 2017-06-12, I pulled and upgraded Guix and packages successfully as

bug#27429: Stack clash (CVE-2017-1000366 etc)

l...@gnu.org (Ludovic Courtès) writes: > As discussed yesterday on IRC, here’s a patch that applies the glibc > patches for CVE-2017-1000366 in ‘core-updates’. > > That’s a rebuild-the-world change but we still have work to do in > ‘core-updates’ anyway, notably regarding the Perl dot-in-@INC issu

bug#27467: Xfce broken, because it propagates two different versions of gtk+

Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Another option (perhaps slightly less intrusive) would be to implement >> the ‘xfce’ meta-package using ‘union-build’ instead of >> ‘propagated-inputs’. > > Yes, that’s better. I pushed two commits: > > gnu: libxfce4ui: Do not propagate gt

bug#27489: glibc fails to build on i686

Adonay Felipe Nogueira writes: > Removing the "~/.config/guix/latest" symbolic link as was suggested by > Mx. Weaver worked, now my root user can pull and also upgrade the "guix" > package. Thank you all for the suggestion. :) I'm glad to hear that it solved your problem. I'll close this bug no

bug#27621: Poppler's replacement is ABI-incompatible with the original

retitle 27621 Poppler's replacement is ABI-incompatible with the original severity 27621 important thanks Ben Woodcroft writes: > Currently Inkscape fails to start as the poppler shared library changes from > libpoppler.so.66 to libpoppler.so.67 upon grafting. Is this the correct way > to fix th

bug#27621: Poppler's replacement is ABI-incompatible with the original

Leo Famulari writes: > On Sat, Jul 08, 2017 at 06:04:37PM -0400, Mark H Weaver wrote: >> Here's what we need to do: instead of replacing 0.52.0 with 0.56.0, we >> need to find backported fixes for poppler-0.52.0 (or possibly some newer >> version that has the same ABI a

bug#27621: Poppler's replacement is ABI-incompatible with the original

Leo Famulari writes: > On Sun, Jul 09, 2017 at 05:25:07PM -0400, Mark H Weaver wrote: >> They did, however, cherry-pick an upstream patch to fix a null pointer >> dereference bug in 0.52.0. I'll look into adding this patch to our >> poppler. > > Thanks! Let

bug#27636: /dev/kvm went missing on i686, Linux 4.12

Ricardo Wurmus writes: > Since the update to Linux 4.12 my i686 machine no longer has /dev/kvm. > I ran “modprobe kvm” successfully, and “lsmod” shows “kvm”, but the > device node does not exist. > > Running “modprobe kvm-intel” prints: > > modprobe: ERROR: could not insert 'kvm_intel': Input

bug#27729: guile-2.2.2 fails to build on armhf in core-updates (timeout)

On core-updates, apparently all of the armhf builds are dependency-failed due to a failure to build an early guile-2.2.2 (/gnu/store/z3h8q7qrv20vc361q1ry7j1izbmrvrjh-guile-2.2.2.drv). The reason is that the 'max-silent-time' being used for that build is 1 hour, although it should be 10 hours. In

bug#27636: /dev/kvm went missing on i686, Linux 4.12

Ricardo Wurmus writes: > Mark H Weaver writes: > >> Ricardo Wurmus writes: >> >>> Since the update to Linux 4.12 my i686 machine no longer has /dev/kvm. >>> I ran “modprobe kvm” successfully, and “lsmod” shows “kvm”, but the >>> device node does n

bug#27780: guix environment to build guile from git required excessive CPU time

I just ran the following command on my Thinkpad X200 running GuixSD: ./pre-inst-env guix environment guile --ad-hoc autoconf automake libtool flex gettext Using the guix client from a git checkout at v0.13.0-1496-gcfd6a3b1e, and using guix-daemon from guix-0.13.0-3.b547349. This command took

bug#27778: Changing package source URLs from git:// to https://

Leo Famulari writes: > On Thu, Jul 20, 2017 at 06:06:31PM -0400, Leo Famulari wrote: >> Let's change these packages to use HTTPS or HTTP! > > Well, I don't know any benefit to using HTTP over GIT, so I'm not going > to change the packages whose sources are not available over HTTPS. One benefit i

bug#27820: guix package -u: order of argument is significant

Hartmut Goebel writes: > I'm try upgrading from guix-0.12.0-10.ba2260d but the profile is not updated. > > I used "guix pull" to get the latest version. > > "guix package -u" is loading substitutes, fails with this and recommends > using --fallback. > > "guix package -u --fallback" when run the f

bug#27820: guix package -u: order of argument is significant

Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Ricardo Wurmus skribis: >> >>> Ludovic Courtès writes: >>> >>>> Mark H Weaver skribis: >>>> >>>>> I agree that this is quite confusing. Perhaps we should issue

bug#28193: tome4 tiles are nonfree?

Hi Chris, Christopher Allan Webber writes: > I was excited to see tome4 packaged for Guix since that game is > *incredible*. However, I'm not totally sure about the music, but as for > the tiles, there's this message in tome4's COPYING-MEDIA which says: > > All the medias located in all the "

bug#28211: Grafting fails for latest Go release candidate

l...@gnu.org (Ludovic Courtès) writes: > Marius Bakke skribis: > >> Most likely just lucky, new grafting failure today. >> >> I've noticed they are more likely to occur when the host system is busy. >> Grafting a large package such as 'texlive' is almost guaranteed to fail >> on a fully-utilized

bug#22123: python-statsmodels: Non-deterministic build failures on x86_64

I haven't seen this problem occur on Hydra since November 2016, so I'm closing this bug. Mark

bug#22122: {python, python2}-statsmodels on i686: "SVD did not converge"

I analyzed Hydra's database, and discovered that these "SVD did not converge" test failures on i686 depend only on which machine attempts the build, and are otherwise deterministic. hydra.gnunet.org fails 100% of the time. It has *never* passed this test on i686. chapters.gnu.org also fails 100%

bug#28284: GCC 4.7.4 fails to build since April 2017

GCC 4.7.4 fails to build since April 2017: https://hydra.gnu.org/job/gnu/master/gcc-4.7.4.x86_64-linux https://hydra.gnu.org/job/gnu/master/gcc-4.7.4.i686-linux Mark

bug#28352: stale cache in ~/.cache/gstreamer-1.0

l...@gnu.org (Ludovic Courtès) writes: > Ricardo Wurmus skribis: > >> The gstreamer cache in ~/.cache/gstreamer-1.0 goes stale and must be >> manually deleted after changing what gstreamer plugins are installed. >> This can be dangerous as old plugins might be referenced long after they >> have b

bug#28393: Sound output broken in Audacity

Sound output is broken in Audacity on my Thinkpad X200 running GuixSD, at least within GNOME 3 (I haven't tried it anywhere else). It worked in the past. I see the following error messages in Audacity's stdout/stderr: (audacity:893): Gtk-WARNING **: Unable to locate theme engine in module_path:

bug#28393: Sound output broken in Audacity

Hi, Florian Paul Schmidt writes: > what ALSA pcm device have you configured Audacity to use? For some reason, it was using "hw:0,1" by default, which is the digital output of my sound device. > Does using "hw:0,0" work if set as pcm device in the audacity config? When I switched it to "hw:0,0"

bug#28445: match-error in 'device-sexp->device' while building system

I just started getting this error while trying to build my x86_64 GuixSD system: --8<---cut here---start->8--- mhw@jojen ~$ guix system build -K /etc/config-new.scm Backtrace: 14 (primitive-load "/home/mhw/guix/scripts/guix") In guix/ui.scm: 1331:12

bug#28446: linux-libre@4.1 should select 4.1.x, not 4.13.x

Currently, the package specification "linux-libre@4.1" selects version 4.13. It should instead select version 4.1. Mark

bug#28445: match-error in 'device-sexp->device' while building system

Mark H Weaver writes: > I just started getting this error while trying to build my x86_64 GuixSD > system: > > mhw@jojen ~$ guix system build -K /etc/config-new.scm [...] > gnu/system.scm:238:4: In procedure device-sexp->device: > gnu/system.scm:238:4: Throw to key `m

bug#28445: match-error in 'device-sexp->device' while building system

Hi Marius, Marius Bakke writes: > I have an identical setup, and the problem is that the parameters file > contains "(store (device #f))". You can confirm this by `cat > /var/guix/profiles/system-9-link/parameters`. Indeed, I discovered that as well. > This patch fixes the parameters generati

bug#28445: match-error in 'device-sexp->device' while building system

For now, to allow me to apply security updates to my system, I reverted the following commits: 96da5d629 system: Add gexp compiler for . 45bba4751 store: 'run-with-store' has a #:target parameter. fc2de6ce1 guix system: Pretty-print device UUIDs. 7940188eb system: Fix typo in 'read-boot-pa

bug#28445: match-error in 'device-sexp->device' while building system

I wrote: > For now, to allow me to apply security updates to my system, I > reverted the following commits: To be clear, I reverted these commits only on a private branch in my local git repo. Mark > 96da5d629 system: Add gexp compiler for . > 45bba4751 store: 'run-with-store' has a #:

bug#28393: Sound output broken in Audacity

I'm closing this bug, since no one else has reported anything similar, and it was easily fixed by configuration. Thanks to everyone who responded with their ideas. Mark

bug#28479: icecat-52.3.0-gnu1 includes Google in search engines

Hi, ng0 writes: > Is this an upstream bug? Should we patch to remove Google? > > I've just compared a completely new system (and Icecat profile) > with my default profile, both include Google in search engines. > > There's also Bing and Yahoo, I'm not sure if all 3 were present > before this ver

bug#28490: Unable to abort 'make' with Ctrl-C while building .go files

It used to be that I could Ctrl-C to abort 'make'. Now I find that it only aborts compiling one file and then moves on to the next. Here's a partial transcript within shell mode in Emacs. Mark --8<---cut here---start->8--- GUILEC gnu/services/lirc.g

bug#28479: icecat-52.3.0-gnu1 includes Google in search engines

ng0 writes: > Mark H Weaver transcribed 0.4K bytes: >> >> ng0 writes: >> >> > Is this an upstream bug? Should we patch to remove Google? >> > >> > I've just compared a completely new system (and Icecat profile) >> >

bug#28445: match-error in 'device-sexp->device' while building system

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> At least for some transition period, it would be good to find a way to >> cope with (store (device #f)) in some older system generations. >> >> What do you think? > > I think the

bug#28479: icecat-52.3.0-gnu1 includes Google in search engines

ng0 writes: > Mark H Weaver transcribed 1.1K bytes: >> ng0 writes: >> >> > Mark H Weaver transcribed 0.4K bytes: >> >> >> >> ng0 writes: >> >> >> >> > Is this an upstream bug? Should we patch to remove Google? >

bug#28446: linux-libre@4.1 should select 4.1.x, not 4.13.x

Hi Ricardo, Ricardo Wurmus writes: >> Currently, the package specification "linux-libre@4.1" selects version >> 4.13. It should instead select version 4.1. > > We consider everthing following the “@” a version string prefix. Since > versions are arbitrary strings “4.1” is considered a valid pr

bug#28629: Add cc as a symlink to gcc

Mohammed Sadiq writes: > Some packages seems to rely on cc as the C compiler. So within some > environment, > let cc be symlinked to the default gcc of the environment. This has been discussed before, and it was decided that in such cases, we should do what's needed to make the build system use

bug#28479: icecat-52.3.0-gnu1 includes Google in search engines

Mark H Weaver writes: > ng0 writes: > >> With a completely new system (had to set this up for testing Mate) >> and guix package -i icecat (for the recent release) and no pre-existing >> configuration, the default was Google, not DuckDuckGo. > > On my GuixSD syst

bug#24445: GNOME desktop session crash when re-arranging dock

l...@gnu.org (Ludovic Courtès) writes: > Mohammed Sadiq skribis: > >> This crash appears to happen on dragging anything on gnome-shell. >> >> Eg: >> 1. If a window is dragged in shell overview >> 2. if a window in desktop list (in the right side) is dragged. >> 3. if some icon from Application li

bug#28445: match-error in 'device-sexp->device' while building system

Hi, Sorry for the delayed response. l...@gnu.org (Ludovic Courtès) writes: > Andy pushed the first half of the fix as > 96bc6518002c3b2ad9f15cf36991b20bebcbbe8a. Could you check whether the > ‘ensure-not-/dev’ part below solves the rest? I see that you've pushed the 'ensure-not-/dev' part, and

bug#29186: building guile-emacs fails: required libaries not found: libjpeg

Jan Nieuwenhuizen writes: > guix build guile-emacs fails with > > checking jerror.h usability... yes > checking jerror.h presence... yes > checking for jerror.h... yes > checking for jpeg_destroy_compress in -ljpeg... yes > configure: WARNING: libjpeg found, but not version 6b or later > checking

bug#29516: Maxima fails to build

Diego Nicola Barbato writes: > Leo Famulari writes: > >> On Fri, Dec 01, 2017 at 11:53:01AM +0100, Diego Nicola Barbato wrote: >>> `guix build maxima' fails during the `check' phase with the following >>> output: >> >> Thanks for your report! FYI, the Maxima builds started failing after the rec

bug#29546: Intermittent test failures in 'git'

On Hydra, the following intermittent test failure in 'git' has occurred twice in the last two days, and twice about a month ago: --8<---cut here---start->8--- not ok 3 - git svn branch tests # # test_must_fail git svn branch a && #

bug#29596: [wishlist] On Guix package list, use 'file-name's of patches

On the list of patches for IceCat currently looks like this: Patches: snippet, icecat-avoid-bundled-libraries.patch, d13e3fefb76e, f822bda79c28, fbb0bdb191d5, fbddb5cdd3c7, 76c25987a275, 32eec29a85a5, ecef71fa933f, 68a444daf85b, c9cafc4e, d

bug#29621: Guix 0.14.0-1.ad4953b failed to build for x86_64 on Hydra

Leo Famulari writes: > On Fri, Dec 08, 2017 at 10:44:34PM -0500, Leo Famulari wrote: >> From the log at : >> >> [...] >> FAIL: tests/guix-register.sh >> PASS: tests/guix-gc.sh >> PASS: tests/guix-daemon.sh >> ==

bug#29621: Guix 0.14.0-1.ad4953b failed to build for x86_64 on Hydra

Mark H Weaver writes: > Leo Famulari writes: > >> It failed a second time :/ Unfortunately I can't reproduce it. > > I restarted it again. The third build attempt succeeded. Mark

bug#29634: Hydra fails to honor 'max-silent-time' for early guile build

An early 'guile' build on armhf-linux consistently fails on Hydra, because the 'timeout' and 'max-silent-time' properties are not honored. For example: https://hydra.gnu.org/build/2391845 This is a longstanding issue. In past core-updates cycles, I have worked around the problem by rebuilding

bug#29634: Hydra fails to honor 'max-silent-time' for early guile build

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> An early 'guile' build on armhf-linux consistently fails on Hydra, >> because the 'timeout' and 'max-silent-time' properties are not honored. >> For example: >&

bug#29634: Hydra fails to honor 'max-silent-time' for early guile build

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Mark H Weaver skribis: >>> >>>> An early 'guile' build on armhf-linux consistently fails on Hydra, >>>>

bug#29769: Hydra evaluation failed

Here's the tail of the evaluator's output: --8<---cut here---start->8--- ;;; compiled /home/hydra/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/rachfrd3vfbxc4kqbb4lbyjmnjh80xj6-git-export/gnu/tests/version-control.scm.go ;;; compiling /gnu/store/rachfrd3vfbxc4kqb

bug#29771: Package list no longer being updated

The package list on the website was last updated on 7 Dec 2017. Its cron job was disabled when the website was updated. It would be good to get that working again at some point. Mark

bug#29776: [core-updates] gawk fails test suite on armhf

On core-updates, 'gawk' fails to build on armhf: https://hydra.gnu.org/build/2392045 Here's the tail of the build log: --8<---cut here---start->8--- make[2]: Entering directory '/tmp/guix-build-gawk-4.1.4.drv-0/gawk-4.1.4/test' 1 TESTS FAILED make[2]: *** [M

bug#29776: [core-updates] gawk fails test suite on armhf

Marius Bakke writes: > Mark H Weaver writes: > >> On core-updates, 'gawk' fails to build on armhf: >> >> https://hydra.gnu.org/build/2392045 > > I tried restarting this (again), and it succeeded: > > https://hydra.gnu.org/build/2392045 > &

bug#29794: [core-updates] Another Hydra evaluation failed

In the last hour or so, another Hydra evaluation failed, this time on core-updates. Here's the tail of the evaluator.log: --8<---cut here---start->8--- ;;; compiled /home/hydra/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/sr851pk6c79l5x8yz76zcvm802q7wr5p-git-exp

<    1   2   3   4   5   6   7   8   9   10   >