bug#24737: `guix lint` should not check patch-file-names on inherited sources

After patching 'notmuch', `guix lint -c patch-file-names` does not pass for 'python-notmuch' which inherits the source from 'notmuch'.

bug#24737: `guix lint` should not check patch-file-names on inherited sources

Ludovic Courtès writes: > Marius Bakke skribis: > >> After patching 'notmuch', `guix lint -c patch-file-names` does not pass >> for 'python-notmuch' which inherits the source from 'notmuch'. > > I agree but that’s not quite possible: the “i

bug#24737: `guix lint` should not check patch-file-names on inherited sources

Marius Bakke writes: > Ludovic Courtès writes: > >> Marius Bakke skribis: >> >>> After patching 'notmuch', `guix lint -c patch-file-names` does not pass >>> for 'python-notmuch' which inherits the source from 'notmuch'. >&

bug#25095: Multiple output packages causes noop profile generations

Sorry for the non-descriptive title. It appears that having non-default outputs in the profile always causes a new profile generation even if the package derivations themselves don't change. Here is an example: $ guix package -u The following packages will be upgraded: bind:utils 9.10.4-P4 →

bug#25142: openssl lacks lib/libssl.a

ng0 writes: > In commit 0c69a17efdba0c7c3da0f25800a3c3233200e47b I found out > that our openssl lacks lib/libssl.a ... this should be fixed > somehow with the next update of the openssl package. Did you try the "static" output of OpenSSL? signature.asc Description: PGP signature

bug#25142: openssl lacks lib/libssl.a

ng0 writes: > Marius Bakke writes: > >> ng0 writes: >> >>> In commit 0c69a17efdba0c7c3da0f25800a3c3233200e47b I found out >>> that our openssl lacks lib/libssl.a ... this should be fixed >>> somehow with the next update of the openssl package. >

bug#25177: Test failures don't cause some Python packages to fail [was Re: [PATCH 05/11] gnu: Add python-pygit2.]

Leo Famulari writes: > I noticed while building the package added by ng0's patch (below) that > the test suite fails, but the check phase succeeds: > > [...] > == > ERROR: test_clone_with_credentials (test.test_repository.CloneRe

bug#25177: Test failures don't cause some Python packages to fail [was Re: [PATCH 05/11] gnu: Add python-pygit2.]

Marius Bakke writes: > Perhaps something like this would work (untested)? Oops, here is the patch I wanted to attach: --8<---cut here---start->8--- (define* (check #:key tests? test-target use-setuptools? #:allow-other-keys) "Run the test su

bug#25177: Test failures don't cause some Python packages to fail [was Re: [PATCH 05/11] gnu: Add python-pygit2.]

Leo Famulari writes: > On Mon, Dec 12, 2016 at 12:05:57AM +0100, Marius Bakke wrote: >> Marius Bakke writes: >> >> > Perhaps something like this would work (untested)? >> >> Oops, here is the patch I wanted to attach: > > Can you make it a patch

bug#25177: Test failures don't cause some Python packages to fail [was Re: [PATCH 05/11] gnu: Add python-pygit2.]

Marius Bakke writes: > Leo Famulari writes: > >> I noticed while building the package added by ng0's patch (below) that >> the test suite fails, but the check phase succeeds: >> >> [...] >> ==

bug#25177: Test failures don't cause some Python packages to fail [was Re: [PATCH 05/11] gnu: Add python-pygit2.]

Hartmut Goebel writes: > First of all thanks for spotting this bug. > >>> The bad news is that we have some breakages. >>> >>> 'python-py' fails with: >>> >>> TypeError: py.test.__dict__ is not a dictionary >>> >>> Which seems similar to >>> >>> https://github.com/NixOS/nixpkgs/issues/12565#issue

bug#25177: Test failures don't cause some Python packages to fail

>>> Yikes, I had hoped to avoid addressing that Nix issue and the humongous >>> "fix" for a while longer: >>> >>> https://github.com/NixOS/nixpkgs/pull/12552 >> >> This puill-request is huge, but for setuptools, it comes down that they >> updated from 18.2 to 19.4. > > Sounds like we're going down

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Tue, Dec 13, 2016 at 09:21:44PM +0100, Marius Bakke wrote: >> >> >>> Yikes, I had hoped to avoid addressing that Nix issue and the humongous >> >>> "fix" for a while longer: >> >>> >> >>>

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Tue, Dec 13, 2016 at 09:21:44PM +0100, Marius Bakke wrote: >> >> >>> Yikes, I had hoped to avoid addressing that Nix issue and the humongous >> >>> "fix" for a while longer: >> >>> >> >>>

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Thu, Dec 15, 2016 at 10:26:45AM +0100, Marius Bakke wrote: >> All failures from this run should be fixed, and then some. Can you >> restart it? > > Done, thanks for working on this! Most of the current failures should now be fixed as well. Do yo

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Fri, Dec 16, 2016 at 03:02:20PM +0100, Marius Bakke wrote: >> Leo Famulari writes: >> >> > On Thu, Dec 15, 2016 at 10:26:45AM +0100, Marius Bakke wrote: >> >> All failures from this run should be fixed, and then some. Can you >

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Sat, Dec 17, 2016 at 12:56:21PM -0500, Leo Famulari wrote: >> On Sat, Dec 17, 2016 at 06:38:26PM +0100, Marius Bakke wrote: >> > Leo Famulari writes: >> > > https://hydra.gnu.org/eval/109396?full=1#tabs-unfinished >> > > >

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Sun, Dec 18, 2016 at 12:47:59AM +0100, Marius Bakke wrote: >> Whoops. Fixed in 7b6ff42aa3cf9398213d3c1f0e5f87c45a9730df. > > Thanks! I started a new evaluation. Looks like this one timed out: https://hydra.gnu.org/jobset/gnu/python-tests#tabs-errors

bug#25235: Wrapped python programs get native-inputs in PYTHONPATH

The 'wrap' phase of 'python-build-system' adds native-inputs to PYTHONPATH of the wrapped programs. This causes unnecessary runtime dependencies and may create problems when cross-compiling. Given that all python dependencies are now supposed to be propagated, perhaps we can simply remove the wra

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Sun, Dec 18, 2016 at 07:55:54PM +0100, Marius Bakke wrote: >> Leo Famulari writes: >> >> > On Sun, Dec 18, 2016 at 12:47:59AM +0100, Marius Bakke wrote: >> >> Whoops. Fixed in 7b6ff42aa3cf9398213d3c1f0e5f87c45a9730df. >>

bug#25177: Test failures don't cause some Python packages to fail

Leo Famulari writes: > On Tue, Dec 20, 2016 at 07:49:59PM +0100, Marius Bakke wrote: >> Leo Famulari writes: >> > Bah, I started a new one. >> >> Did this one get cancelled? Perhaps we should merge this to 'staging' >> and deal with any remaini

bug#25421: GHC@8 cannot load libncursesw.so.6

Hello! Kei noticed that the latest GHC package does not work: $ guix environment --pure --ad-hoc ghc [env]$ ghc --help /gnu/store/50gn6ahfc0llldy6ggrnj1hc5wsxyfh9-ghc-8.0.1/lib/ghc-8.0.1/bin/ghc: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such fil

bug#23776: Perl's .pod files include timestamps, making Perl package builds non-deterministic

Ludovic Courtès writes: > Leo Famulari skribis: > >> On Thu, Jun 16, 2016 at 11:39:27AM -0400, Leo Famulari wrote: >>> On Thu, Jun 16, 2016 at 01:33:46PM +0200, Ludovic Courtès wrote: >>> > The problem is described in >>> > : >>> > >>> > --8<---cut here---start-

bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.

Marius Bakke writes: > Danny Milosavljevic writes: > >> * gnu/packages/python.scm (python-sphinx)[version]: Update to 1.4.8. >> [source]: Use pypi-uri. >> [propagated-inputs]: Add python-imagesize, python-sphinx-alabaster-theme, >> python-babel, pyth

bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.

Danny Milosavljevic writes: > Hi, > > I've fixed python-matplotlib locally. It builds fine now. > > The fix itself would be: > > + (substitute* "users/intro.rst" > + ;; Fix reST markup error (see > ) > +

bug#25177: [PATCH v6] gnu: python-sphinx: Update to 1.4.8.

Leo Famulari writes: > On Fri, Jan 13, 2017 at 01:34:21PM +0100, Marius Bakke wrote: >> Leo: I'm unable to reproduce the Hydra failures, so I decided to merge >> master so we can restart this branch. However, Savannah refuses the push >> for no good reason! >>

bug#25177: 'python-tests' merge

>> I wonder if we should update scipy and numpy while at it. Thoughts? > > Ugh. I tried this out (plus matplotlib), but the latest matplotlib > (2.0.0) has a circular dependency on ipython. Great. > > The motivation is that the scipy failure stems from the Sphinx update. > I think I'll add an olde

bug#21879: WeeChat does not start

I noticed this as well on a foreign distro and pushed a workaround in 507809be152049dff26bffdb58e1a90b638f046b. Didn't study the source enough to figure out why the substitution was insufficient, but strace confirmed it was still looking in PATH even though the strings were replaced. signature.a

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Danny Milosavljevic writes: > Hi, > > so we finally got to the bottom of the problem with python-oslosphinx. > It should be fixed now (the main fix is in python-pbr-minimal). Thanks a lot for this! > > @Leo: Can you please start a new evaluation of python-tests? I pushed some other fixes recen

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Leo Famulari writes: >> >>> On Tue, Feb 21, 2017 at 06:30:12PM +0100, Ricardo Wurmus wrote: From 1ac5166df11766b47cd1ac723a464063a89afc96 Mon Sep 17 00:00:00 2001 From: Ricardo Wurmus Date: Tue, 21 Feb 2017 18:28:21 +0100

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Ricardo Wurmus writes: > Ricardo Wurmus writes: > >> Leo Famulari writes: >> >>> On Tue, Feb 21, 2017 at 06:30:12PM +0100, Ricardo Wurmus wrote: From 1ac5166df11766b47cd1ac723a464063a89afc96 Mon Sep 17 00:00:00 2001 From: Ricardo Wurmus Date: Tue, 21 Feb 2017 18:28:21 +0100

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Ricardo Wurmus writes: > Marius Bakke writes: > >> Ricardo Wurmus writes: >> >>> Ricardo Wurmus writes: >>> >>>> Leo Famulari writes: >>>> >>>>> On Tue, Feb 21, 2017 at 06:30:12PM +0100, Ricardo Wurmus wrote: &g

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Marius Bakke writes: > I don't always break packages wittingly, but when I do, it's on > 'master'. Should we do a final Hydra round, or just merge it to the > master branch first? The 'python-tests' branch haven't been synced in a > while, so man

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Leo Famulari writes: > On Mon, Feb 27, 2017 at 12:46:58PM +0100, Marius Bakke wrote: >> Marius Bakke writes: >> >> > I don't always break packages wittingly, but when I do, it's on >> > 'master'. Should we do a final Hydra round, or just

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Leo Famulari writes: > On Tue, Feb 28, 2017 at 05:15:59PM +0100, Marius Bakke wrote: >> It seems the evaluation timed out. Can you give it another go? > > Done! Aaand hydra is out of disk space. :( signature.asc Description: PGP signature

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Marius Bakke writes: > Leo Famulari writes: > >> On Tue, Feb 28, 2017 at 05:15:59PM +0100, Marius Bakke wrote: >>> It seems the evaluation timed out. Can you give it another go? >> >> Done! > > Aaand hydra is out of disk space. :( This branch diverges qui

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Leo Famulari writes: > On Wed, Mar 01, 2017 at 06:44:34PM +0100, Marius Bakke wrote: >> Marius Bakke writes: >> >> > Leo Famulari writes: >> > >> >> On Tue, Feb 28, 2017 at 05:15:59PM +0100, Marius Bakke wrote: >> >>> I

bug#25177: python-tests: python-oslosphinx fixed. Please evaluate.

Leo Famulari writes: >> Anyway, this bug has been a massive pain and I'm going to merge it >> tomorrow so I can get on with life. The 'master' jobset should be >> started afterwards; perhaps you can merge and start the evaluation? > > Okay, let me know when you push the merge and I'll start the e

bug#25953: [Mesa] Very low Gallium performance compared to Trisquel

Leo Famulari writes: > On Fri, Mar 03, 2017 at 02:04:14AM -0600, Matthew Brooks wrote: >> This came up in a help-guix thread, and Ricardo Wurmus asked me to >> post here requesting that Mesa be built with LLVM to improve Gallium's >> performance. >> >> The original post is here: >> https://lists

bug#25961: Compiling new guix on old guix: 'waitpid' -1 failed unexpectedly: No child processes

Hi! Christopher Allan Webber writes: > Hello! I'm getting this error while trying to compile latest guix > master on one of my machines (fortunately, not my main one). I don't > know why I'm hitting this error, since I'm not hitting it on my main > machine. I'm upgrading from a few months bac

bug#26286: python-pexpect 4.2.1 test failure in test_async_utf8

Danny Milosavljevic writes: > python-pexpect 4.2.1 has a test failure on both master and core-updates: [...] > == > ERROR: test_async_utf8 (tests.test_async.AsyncTests) >

bug#26286: python-pexpect 4.2.1 test failure in test_async_utf8

Marius Bakke writes: > Danny Milosavljevic writes: > >> python-pexpect 4.2.1 has a test failure on both master and core-updates: > > [...] > >> == >> ERROR: test_async_

bug#26370: v0.12.0-2730-gfc5b12879 'guix system build' hangs on linux-libre-4.10.8

Leo Famulari writes: > On Wed, Apr 05, 2017 at 10:55:45AM -0400, myglc2 wrote: >> HOSTCC scripts/mod/modpost.o >> HOSTCC scripts/mod/file2alias.o >> HOSTCC scripts/extract-cert >> HOSTLD scripts/genksyms/genksyms >> CC arch/x86/purgatory/purgatory.o >> AS arch/x86/purgat

bug#26370: v0.12.0-2730-gfc5b12879 'guix system build' hangs on linux-libre-4.10.8

myglc2 writes: > On 04/05/2017 at 19:31 Marius Bakke writes: > >> Leo Famulari writes: >> >>> On Wed, Apr 05, 2017 at 10:55:45AM -0400, myglc2 wrote: >>>> HOSTCC scripts/mod/modpost.o >>>> HOSTCC scripts/mod/file2alias.o >>>>

bug#26441: [PATCH] gnu: findutils: Fix make check issues on multi-core machines.

Hi, thanks for working on these! [...] > (define-public findutils >(package > - (name "findutils") > - (version "4.6.0") > - (source (origin > -(method url-fetch) > -(uri (string-append "mirror://gnu/findutils/findutils-" > -ve

bug#26384: linux-libre fails to build with bc 1.07

This should be fixed in f71f29cab2b484ea8e63d29a5766f680d0e800c1. signature.asc Description: PGP signature

bug#26441: [PATCH 1/2] gnu: findutils: Fix make check issues on multi-core machines.

Mathieu Othacehe writes: > * gnu/packages/patches/findutils-gnulib-multi-core.patch: New file. > * gnu/packages/base.scm (findutils)[patches]: Add a reference > to the previous patch. > --- > gnu/packages/base.scm | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) It looks like

bug#26441: [PATCH 1/2] gnu: findutils: Fix make check issues on multi-core machines.

Mathieu Othacehe writes: > Hi Marius ! > >> It looks like you forgot the actual patch :) > > Ha ! You're right :) > >> >> Please also add it to gnu/local.mk. TIA! > > Ok, I'll a new batch, to be applied to core-updates. Applied, thank you! Can this be closed now? signature.asc Description: PGP

bug#26567: guix publish Resource not found

Quiliro writes: > I have run as root: > guix archive --generate-key > guix publish --user=quiliro > But when opening web page: > http://0.0.0.0:8080/ > I get: > Resource not found: / That is expected. Note that "0.0.0.0" just means "listen on all available IPv4 addresses", I'm surprised it works

bug#26558: Opening URLs with xdg-open fails (eg. Gajim, Pumpa)

nd decided to finish it based on this discussion. This tries "gvfs-open" before "gnome-open". @Ben (and others), can you try this patch and see if that works for you? From 6ed7008561eea7b09085a17d6c443ee657a7fc2d Mon Sep 17 00:00:00 2001 From: Marius Bakke Date: Sat, 8 Apr

bug#26558: Opening URLs with xdg-open fails (eg. Gajim, Pumpa)

Hi Maxim, Maxim Cournoyer writes: > Hello Marius, > > Marius Bakke writes: >> [...] >> + (add-before 'build 'locate-catalog-files >> + (lambda* (#:key inputs #:allow-other-keys) >> + (let ((xmldoc (s

bug#26558: Opening URLs with xdg-open fails (eg. Gajim, Pumpa)

Arun Isaac writes: >> Heh, I've had a WIP update for 1.1.1 for some time and decided to finish >> it based on this discussion. > > Oh, good! :-) > > Your patch builds successfully. But, the new version has tests, and you > still need to package them. When I try to run the tests, a few > fail. Set

bug#26558: Opening URLs with xdg-open fails (eg. Gajim, Pumpa)

Ben Sturmfels writes: > On 22/04/17 20:31, Marius Bakke wrote: > >> Ben: Can you confirm whether the latest xdg-utils work for you? It's in >> 'master' now so you should get it after a `guix pull` and update. > > Thanks Marius, working beautifully now! Y

bug#26671: serf package (guix dependency) tests fail

Maxim Cournoyer writes: > Hello Guix! > > While attempting to "guix environment guix" after doing a "git pull" > in my guix checkout (master), it attempted to build many packages > (bash, gcc, etc.) and failed building `serf' due to test failures: > > F.FFF.FFF.FF.F...

bug#26671: serf package (guix dependency) tests fail

Marius Bakke writes: > Maxim Cournoyer writes: > >> Hello Guix! >> >> While attempting to "guix environment guix" after doing a "git pull" >> in my guix checkout (master), it attempted to build many packages >> (bash, gc

bug#26671: serf package (guix dependency) tests fail

Marius Bakke writes: > Marius Bakke writes: > >> Maxim Cournoyer writes: >> >>> Hello Guix! >>> >>> While attempting to "guix environment guix" after doing a "git pull" >>> in my guix checkout (master), it attempted to b

bug#26671: serf package (guix dependency) tests fail

Leo Famulari writes: > On Thu, Apr 27, 2017 at 03:54:13PM +0200, Marius Bakke wrote: >> Maxim Cournoyer writes: >> > >> > While attempting to "guix environment guix" after doing a "git pull" >> > in my guix checkout (master), it attempted

bug#26671: serf package (guix dependency) tests fail

Marius Bakke writes: > Leo Famulari writes: >>> https://svn.apache.org/viewvc?view=revision&revision=1792234 >> >> Rather than using this workaround, which will stop working 2018-09-19, >> we should disable this test. We should also file an upstream bug asking

bug#26695: openssh password-authentication? should be #f by default

Christopher Allan Webber writes: > Maxim Cournoyer writes: > >> +1. Although it means the keys will have to be copied by another mean >> than the "ssh-copy-id" script. Maybe the configuration could accept >> the public key? :) I haven't checked if this is already possible. > > We have discussed i

bug#26714: non-intel systems should use grub-efi

Efraim Flashner writes: > I'm starting to stumble my way through building an install image for > aarch64, and I changed gnu/system/install.scm to use 'grub-efi' in place > of 'grub' in the list of packages (~line 333). Grub-efi builds > successfully on armhf and aarch64 and grub does not, and as

bug#26353: TeX Live

Ludovic Courtès writes: > Hi Danny! > > Danny Milosavljevic skribis: > >> 70 GiB non-home root partition seems also be too small for it all. I have to >> do guix gc quite often - I'll have to repartition somewhen. >> >> texlive finally downloaded correctly *shrugs*. Texlive is really getting o

bug#26797: qemu looks for smbd at /usr/sbin

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> Qemu comes with support for sharing files with a guest via Samba. This >> is done by appending something like this to the qemu-system-* >> invocation: >> >> … -net user,smb=$HOME/Downloads -net nic >> >> Qemu needs to be told *at config

bug#26671: serf package (guix dependency) tests fail

Marius Bakke writes: > Leaving this bug open until the upstream issue is created so it can be > added here as a reference. Filed here: https://issues.apache.org/jira/browse/SERF-184 signature.asc Description: PGP signature

bug#26874: lvm2 build error

ng0 writes: > #lvm on freenode.net says we are on our own and that the method (in general) > to statically build lvm2 is considered fragile. > The comment was that we need to make libm available, statically, as well for > lvm2. > The only person shown by git blame gnu/packages/linux.scm for lvm2-

bug#26874: lvm2 build error

ng0 writes: > lvm2 from bc0e6c9312f5f755e1ccd7d8c43b58974e6f7d38 fails with this: [...] > ../libdm/ioctl/libdevmapper.a(libdm-string.o): In function > `dm_size_to_string': > libdm-string.c:(.text+0x11b6): undefined reference to `nearbyint' > libdm-string.c:(.text+0x11cb): undefined reference t

bug#27003: [PATCH 0/3] Generalized wrap phase for perl, python.

Alex Sassmannshausen writes: > Hello, > > This patch series goes back some time, but the need for it has not > disappeared. > > It implements a general `wrap` phase that can be used in individual build > systems to make sure binaries in those languages have access to all their > propagated inputs

bug#27028: Cannot install packages in USB image

I tried installing 'shadow' on the live USB image, but Guix crashes at the very end. Here's an example: root@gnu ~# guix package -i hello [download/build succeeds, and then..] Backtrace: In ice-9/boot-9.scm: 160: 18 [catch #t # ...] In unknown file: ?: 17 [apply-smob/1 #] In ice-9/boot-9.scm

bug#27028: Cannot install packages in USB image

Leo Famulari writes: > On Mon, May 22, 2017 at 10:48:18PM +0200, Marius Bakke wrote: >> I tried installing 'shadow' on the live USB image, but Guix crashes at >> the very end. Here's an example: > > The USB installer, not the VM image, right? Yes. Have n

bug#27069: LUKS partition ruined by guix init

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 packages and therefore didn't instal

bug#22533: Python bytecode reproducibility

Hello! I stumbled across this bug after re-discovering that Python bytecode is not reproducible (through "glib"). Just sharing some notes.. Nix recently made an effort to fix this. AFAICT the ".pyc" files are still a problem, but at least they got the interpreters building reproducibly: https://

bug#27003: [PATCH 0/3] Generalized wrap phase for perl, python.

Arun Isaac writes: >> I cannot currently make guarantees on when I'll be able to wrap my head >> around the entire problem, so if you come to conclusions for next steps >> on the basis of your testing, we should go with those. >> >> Else I will revisit this issue when I have time (which might be

bug#27069: LUKS partition ruined by guix init

Mark H Weaver writes: > 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 com

bug#27135: /root is world readable by default

Ludovic Courtès writes: > Hi Alex, > > Alex Griffin skribis: > >> After a default install of GuixSD, anybody can read root's home >> directory. I think /root should have permissions 700 instead of 755. > > Fixed in 41db5a756369f5b14d1e67a523ee0940cad56744. > > For the other user accounts, userad

bug#27007: [PATCH 1/2] bootloader: Use menu-entry to define custom bootloader entries.

Mathieu Othacehe writes: > But maybe there are other advantages not to run an initrd. CONFIG_MODULES=n reduces kernel attack surface significantly :-) signature.asc Description: PGP signature

bug#27212: 203a9455c4695152fc5d0085bffeead9ce3216c2 broke system boot

ng0 writes: > Otherwise perfectly working systems I have *all* break after > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=203a9455c4695152fc5d0085bffeead9ce3216c2 > > and the last thing they display before guile repl is the > message in that commit. > > Yes, I use labels. No, I don't us

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

Mark H Weaver writes: > 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 version) not found >>> >>> Lo

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

Mark H Weaver writes: > 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. &g

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

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. Let

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

Leo Famulari writes: >> While it's true that users can boot into an older generation of their >> system in an emergency, and that's a *great* comfort, in general it's >> not an acceptable fallback because it entails sacrificing security >> updates. I'm concerned that our fallback feature has cau

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

Ricardo Wurmus writes: > Mark H Weaver writes: > >> FWIW, I always check digital signatures when they're available, and I >> hope that others will as well, but in practice we are putting our faith >> in a large number of contributors, some of whom might not be so careful. > > I do the same when

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

Danny Milosavljevic writes: > Hi, > > what do you all think of rebuilding the world with "-fstack-check" (either > now or later on) ? > > That would make gcc emit code to always grow the stack in a way that it > certainly touches each 4 KiB (parametrizable by > STACK_CHECK_PROBE_INTERVAL_EXP)

bug#26936: grub_cmd_set_date test sometimes fail

Leo Famulari writes: > On Fri, Jun 23, 2017 at 03:30:10PM -0400, Leo Famulari wrote: >> On Sat, Jun 03, 2017 at 12:54:46AM +0200, Ludovic Courtès wrote: >> > FAIL: grub_cmd_set_date >> >> > All in all, I’m tempted to think this has to do with running the tests >> > in parallel. >> > >> > As a s

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

Leo Famulari writes: > On Mon, Jun 26, 2017 at 10:01:03AM +0200, Ludovic Courtès wrote: >> Could you check whether “guix package -A syncthing” shows it there? The >> warning should appear as soon as we’re upgrading a package that’s >> missing. > > I get no results when I do `./pre-inst-env guix

bug#27515: texlive-texmf-minimal is not reproducible

Danny Milosavljevic writes: > $ guix build texlive-texmf-minimal --rounds=2 > > phase `texmf-config' succeeded after 52.0 seconds > output > ‘/gnu/store/jfs5fsn011w64jgmpc6chcnqr1agfv6h-texlive-texmf-minimal-2016’ of > ‘/gnu/store/72z7v217vd976hlhyjrxzmwpqr4nzwh6-texlive-texmf-minimal-2016.drv’

bug#27593: [PATCH v2] gnu: groff: Remove timestamps.

Danny Milosavljevic writes: > Fixes . > > * gnu/packages/groff.scm (groff)[source]: Remove timestamps. > --- > gnu/packages/groff.scm | 18 +- > 1 file changed, 17 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/groff.scm b/gnu/packages/grof

bug#27593: [PATCH v3] gnu: groff: Remove timestamps.

Danny Milosavljevic writes: > Hi Ludo, > > On Sun, 09 Jul 2017 21:51:08 +0200 > l...@gnu.org (Ludovic Courtès) wrote: >> Debian has a SOURCE_DATE_EPOCH patch: >> >> http://sources.debian.net/patches/groff/1.22.3-9/source-date-epoch.patch/ >> >> Perhaps we could just use that? That way, the d

bug#27593: [PATCH] gnu: groff: Make build reproducible.

Danny Milosavljevic writes: > * gnu/packages/groff.scm (groff)[arguments]: Add phase "setenv". What does this add to the previous patch? Can you add a comment in the code explaining what it's for? signature.asc Description: PGP signature

bug#27732: Changing display manager can render system unbootable

Hello! When changing display manager in the system configuration and invoking `guix system reconfigure`, the existing desktop environment will be killed. If you invoked the command from within said desktop environment, the reconfigure command will be forcefully terminated. If you're unlucky, this

bug#27725: Lapack 3.7.1 hash changed

Maxim Cournoyer writes: > From f69c6bbb8bee804057ccc1dc076311d3cbf5e89c Mon Sep 17 00:00:00 2001 > From: Maxim Cournoyer > Date: Sun, 16 Jul 2017 12:01:59 -0700 > Subject: [PATCH] gnu: lapack: Fix hash of release 3.7.1 > > Apparently the release was modified (cleaned-up) in-place. An issue was o

bug#27809: libidn2 underscore stripping problem

Leo Famulari writes: > It was recently reported that libidn2 can cause issues for domains whose > names contain underscores, and maybe some other characters, too. It > matters to us because we build GnuTLS with libidn2. > > I'm not sure yet what the solution is for us. Help wanted! > > Original

bug#27939: FreeRDP CVE-2017-2834 CVE-2017-2835 CVE-2017-2836 CVE-2017-2837 CVE-2017-2838 CVE-2017-2839

Leo Famulari writes: > The bugs corresponding to CVE-2017-2834 CVE-2017-2835 CVE-2017-2836 > CVE-2017-2837 CVE-2017-2838 CVE-2017-2839 were recently fixed in the > FreeRDP Git repo: > > https://github.com/FreeRDP/FreeRDP/commit/03ab68318966c3a22935a02838daaea7b7fbe96c > > The most serious of thes

bug#27939: FreeRDP CVE-2017-2834 CVE-2017-2835 CVE-2017-2836 CVE-2017-2837 CVE-2017-2838 CVE-2017-2839

Thomas Danckaert writes: > From: Leo Famulari > Subject: Re: bug#27939: FreeRDP CVE-2017-2834 CVE-2017-2835 > CVE-2017-2836 CVE-2017-2837 CVE-2017-2838 CVE-2017-2839 > Date: Fri, 4 Aug 2017 10:56:15 -0400 > >> On Fri, Aug 04, 2017 at 10:34:55AM +0200, Thomas Danckaert wrote: >>> Unfortunately,

bug#28063: Guix manual refers to wrong binary tarball

Hello! I tried installing Guix on a foreign distribution yesterday, and copy-pasted the commands listed here: https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation However, the tarball name it refers to does not exist. I had to manually s/0.13.0.314-a8d0c/0.13.0/ to make the com

bug#28138: bug build python-pygit2 on guix 0.13

Adrien Marin writes: > Hi, > > yesterday ,I updated guix and try to install my package's new version and the > install fail because of pygit2 error. > > I've found a bug with the package python-pygit2 when I tried to build it: > > " #error You need a compatible libgit2 version (v0.25.x)" > >

bug#28326: exiv2 0.26 hash mismatch

Maxim Cournoyer writes: > tl;dr: exiv2 source archive was updated in-place and the verification > below gives us confidence that we can safely update the hash. > > On current master, the following happens: > > $ guix build exiv2 > > Starting download of > /gnu/store/jcapi6vk4a14hch5jgsh5zps958g9

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

"btrfs") > (dependencies mapped-devices)) >%base-file-systems)) 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-

bug#27476: guix pull fails on powerful server

Ricardo Wurmus writes: > Is there another work-around I could try on this machine? Using Guile 2.0 worked for me: guix package -r guix guile-git -i guile2.0-guix guile2.0-git signature.asc Description: PGP signature

bug#28644: Pulseview with modular qt

Theodoros Foradis writes: > Ricardo Wurmus writes: > >> Theodoros Foradis writes: >> >>> My guess (not being familiar with qt), is that somehow, having the two >>> inputs in different prefixes, causes the problem with the package's >>> build system. I gave a look at the cmake files, but couldn't

bug#28692: Emacs fails to display images

Diego Nicola Barbato writes: > Apparently this was a known bug in ImageMagick 6.9.9-15 (and 6.9.9-17) > (https://github.com/ImageMagick/ImageMagick/issues/825). It has been > fixed in version 6.9.9-18. Hello! I just pushed an update to 6.9.9-18, can you verify that it works? Thanks for the rep

bug#28768: guix system vm Failed to install GRUB (EFI)

Oleg Pykhalov writes: > EFI bootloader configuration causes problems to test with 'system vm' > before 'reconfigure'. This is because `guix system vm` is not currently UEFI enabled, so GRUB tries to install for a normal PC BIOS. The fix would be to make the various QEMU invocations in (gnu syst

  1   2   3   4   5   6   7   >