bug#19630: error message when referencing non-existing output not helpful

When a package recipe specifies as input a non-existing output of a package, the build process fails with a rather unhelpful late error message. The following is the output of building a package that depends on the "bin" output of libtool, which has since been removed. ~ [rwurmus@workstation:

bug#19686: Bad source checksum in netpbm

Andreas Enge writes: > This is a tricky error. I still had the svn checkout of the previous version > on my disk: >/gnu/store/4a6ck86ap94m397vmycxy98bmhws7h6a-svn-checkout > So the recipe worked for me, since the hash and the file name corresponded to > the package recipe. However, instead of

bug#19708: Bowtie fails to build

Andreas Enge writes: > bowtie currently fails to build on all three architectures on hydra. > > On i686, the error message is: > Makefile:146: *** bowtie2 compilation requires a 64-bit platform . Stop. > > Surprisingly, the same error message is shown on mip64el (!). > From its description, I do

bug#19708: Bowtie fails to build

Andreas Enge writes: > Clearly, only x86_64 is supported. Citing from Makefile: > BITS=32 > ifeq (x86_64,$(shell uname -m)) > BITS=64 > endif > # msys will always be 32 bit so look at the cpu arch instead. > ifneq (,$(findstring AMD64,$(PROCESSOR_ARCHITEW6432))) > ifeq (1,$(MINGW))

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

Hi Guix, installing the gcj or the gfortran package, my profile's /bin directory gets a gcc link. If I use Guix as a package manager on top of another system that has a working installation of the GNU C compiler and my profile bin path has preference to all other items in PATH, then I end up with

bug#19439: guix download fails with "bad qstring header component"

Eric Bavier writes: > I've encountered the same issue while attempting to upgrade the > python-pillow package. For the newer versions 2.6.2 and 2.7.0, the > following errors are reported when downloading the source:: [...] > I don't have any ideas on how to work around this issue in general.

bug#18698: Our WindowMaker wrapper pollutes PATH in the entire X session

The fix may have resulted in unintended side-effects. On a fresh installation of the System Distribution v0.8.1 WindowMaker is installed by default, but it is not completely functional. For example, the attempt to change the style via the menu results in this error to be displayed: Could not

bug#19780: 13 failing tests

Ludovic Courtès writes: > What architecture is it? It's x86_64-linux. ~~~ $ uname -a Linux guix-builder 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux ~~~ > There are a lot of these: > > --8<---cut here---start--

bug#19780: 13 failing tests

Ludovic Courtès writes: > Hmm. Could you try: > > ./test-env guix build guile-bootstrap ~~ [rwurmus@guix-builder:/localhome/rwurmus-tmp/guix] (720) $ ./test-env guix build guile-bootstrap accepted connection from pid 2187, uid 22840 substitute-binary: warning: authentication and

bug#19780: 13 failing tests

Ludovic Courtès writes: >> [rwurmus@guix-builder:/localhome/rwurmus-tmp/guix] (720) $ ./test-env guix >> build guile-bootstrap > > [...] > >> @ build-started >> /localhome/rwurmus-tmp/guix/test-tmp/store/m1cbz6gmyv2f5551j7zpm99d7mgy2zp9-guile-bootstrap-2.0.drv >> - x86_64-linux >> /localhome/r

bug#19830: cannot use snippets with zip source

Snippets cannot be used when the source archive is not supported by tar. For example, when building HISAT with snippets (instead of patching in a build phase), guix determines the decompression type to be "xz" and then fails as follows: ~~~ The following derivations will be built: /gnu/sto

bug#19780: 13 failing tests

Ludovic Courtès writes: > When you see the message, run this from another terminal: > > $ gdb > (gdb) attach 1234 > (gdb) set detach-on-fork off > (gdb) continue > > Normally GDB will stop when the child process receives SIGSEGV. At that > point, you should be able to type “bt” to get the

bug#19840: "Bad uri header component" when downloading from gitorious.org

Downloading archives from gitorious fails: ~/dev/guix $ ./pre-inst-env guix download https://gitorious.org/lv2-synths/lv2-mdametapiano/archive/0.0.1.tar.gz starting download of `/tmp/guix-file.gqYdZs' from `https://gitorious.org/lv2-synths/lv2-mdametapiano/archive/0.0.1.tar.gz'... ER

bug#19780: 13 failing tests

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> Yes, with my system guile (2.0.11) it returns my full user record. >> >> scheme@(guile-user)> (getpw (getenv "USER")) >> $1 = #("rwurmus" "*" 12345 12345 "Wurmus, R

bug#19934: Failed run of make check

Peter Baumgarten writes: > The OS was Fedora 21 x86_64, attached is the log This looks similar to this bug report: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19780 Failures there are also caused by segfaults and the OS is CentOS 7, which is rather close to a recent Fedora. ~~ Ricardo

bug#19780: 13 failing tests

Ludovic Courtès writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> Ricardo Wurmus skribis: >> >>> 17814 >>> execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", >>> ["nakn26p520psw7ja

bug#19976: Cannot install texlive

After a network interruption while downloading the binary substitute for texlive I can no longer install it. ~~~ ~/dev/guix $ ./pre-inst-env guix package -i texlive The following package will be installed: texlive 2014/gnu/store/za7kilci43in8dfdrrhq9

bug#19780: 13 failing tests

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> 17814 >> execve("/localhome/rwurmus-tmp/guix/test-tmp/store/nakn26p520psw7jawgfv74wm34dn6kxj-bash", >> ["nakn26p520psw7jawgfv74wm34dn6kxj"..., >> "/localhome/rwurmus-tmp/guix/test&qu

bug#20428: git-fetch does not always validate hash

I'm currently playing with the elogind package recipe and I'm occasionally updating my clone of the elogind git repository. Whenever I do I update the value of "commit" in the package definition: (define-public elogind (let ((commit "18ee7abc9a")) (package (name "elogi

bug#20888: matplotlib broken

I'm afraid I cannot reproduce this. This doesn't mean things just work for me. It rather means that I'm getting a different error: $ GI_TYPELIB_PATH=$HOME/.guix-profile/lib/girepository-1.0/ PYTHONPATH=$HOME/.guix-profile/lib/python2.7/site-packages/ python Python 2.7.6 (default, Jun 16 2015,

bug#20381: Interacting with a remote daemon

I just tried the socat idea[1] with some success. On the guix-builder host where guix-daemon is running and the NFS share holding ‘/gnu’ (with $localstatedir set to ‘/gnu/var’) is mounted as read-write I executed this: /root/.guix-profile/bin/socat TCP4-LISTEN: UNIX:/gnu/var/guix/daemon-

bug#20381: Interacting with a remote daemon

Ludovic Courtès writes: > What about installing Guix in /gnu/bin (say) and sharing it over NFS? > > I would avoid installing Guix in a profile, because if things go wrong, > you may find yourself unable to do anything. In practice, you can > always roll-back by hand (it’s simply a matter of swi

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

Commit 5f6887e8 fixes this for GCJ, but we still have this problem for all variants of gfortran, gcc-objc, and gccgo, all of which are built using the ‘custom-gcc’ procedure. It’s probably safe to add a build phase like this to ‘custom-gcc’: (add-after 'install 'remove-broken-or-conflicting-f

bug#19780: “User has no home directory” (was: bug#19780: 13 failing tests)

Hi Ludo, I can confirm that the error disappears when nscd is running. Emacs no longer tells me Error (initialization): User rwurmus has no home directory when starting it as long as nscd is running. I would like to note that the version of Emacs that is available through Fedora repositori

bug#20765: Python .egg files must not be compressed

I stumbled upon a similar problem when building other Python packages. For ‘python-patsy’, for example, I found that an egg archive is produced no matter what I put in ‘setup.cfg’. As far as I can tell, “zip_ok” defaults to “0” in recent versions of setuptools, so I don’t think the fix you used on

bug#20765: Python .egg files must not be compressed

Ludovic Courtès writes: >> I could only coerce the build system to install plain files by adding a >> build phase like this: >> >> (add-after 'unpack 'prevent-generation-of-egg-archive >> (lambda _ >> (substitute* "setup.py" >> (("from setuptools impo

bug#21909: Segfault with eigen in R

Kyle Meyer writes: > With R 3.2.2 built from r in statistics.scm (guix 0.9.0), I'm seeing a > segfault when eigen is called with a matrix over some size. I can > trigger the error with the following code [1]: > > > M <- 50 > > N <- 500 > > eigen(crossprod(matrix(rnorm(M * N), M, N))

bug#21978: tbb broken on mips64el but tests always pass

The “tbb” package appears to be broken on mips64el but both the build phase and the check phase always pass. This means that “tbb” is built “successfully”, which results in downstream build failures. Debian patches the sources of “tbb” such that the build fails on bad tests: https://sources

bug#22013: python2 versions of packages failing as inputs

Efraim Flashner writes: > Guix build python2-cryptography builds fine, guix build python2-oauthlib > rebuilds python2-cryptography, and fails to build. Python2-cryptography has > an additional input of python2-ipaddress which doesn't get carried along when > python2-cryptography is an input and

bug#22024: [PATCH] openssh: install ssh-copy-id.

This fixes bug #22024. >From 65c9863898e1ddc2a1443b557003f0cbc25442d8 Mon Sep 17 00:00:00 2001 From: Ricardo Wurmus Date: Fri, 27 Nov 2015 10:57:03 +0100 Subject: [PATCH 1/2] gnu: openssh: Use modify-phases syntax. * gnu/packages/ssh.scm (openssh)[arguments]: Use modify-phases syntax. ---

bug#22024: [PATCH] openssh: install ssh-copy-id.

Ludovic Courtès writes: >> From baf260ebda0a70ec3c7d6f35e1c1bb64a37f0aac Mon Sep 17 00:00:00 2001 >> From: Ricardo Wurmus >> Date: Fri, 27 Nov 2015 11:35:50 +0100 >> Subject: [PATCH 2/2] gnu: openssh: Install ssh-copy-id. >> >> * gnu/packages/ssh.scm (opens

bug#22024:

Fixed in commit 36f26211bbb.

bug#22094: jack2: jack_control uses wrong python version

I’m pretty sure that this was fixed with commit bc8bf605fcef7d9e8a7732caa0fd54604304635b. Are you using the latest version? ~~ Ricardo

bug#22209: name resolution failures in installer image

Leo Famulari writes: > On Sat, Dec 19, 2015 at 09:04:41AM +0100, Florian Paul Schmidt wrote: >> After booting the installer image, doing the ifconfig/dhclient dance, >> preparing the target fs, mounting it and starting the guix system init >> invocation at some point in time, though not predicta

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

Ludovic Courtès writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> Ricardo Wurmus skribis: >> >>> Commit 5f6887e8 fixes this for GCJ, but we still have this problem for >>> all variants of gfortran, gcc-objc, and gccgo, all of which are built

bug#22242: Help constructing source URL

Leo Famulari writes: > Our tinyproxy package needs to be updated to use the current source URL. > > The current URL is: > https://download.banu.com/tinyproxy/1.8/tinyproxy-1.8.3.tar.gz > > I don't know how to abstract the "1.8" directory to account for other > versions. How about this: (string

bug#22273: “guix download” fails with “bad-response”

Downloading the source archive for the Groovy language with “guix download” fails: ~~~ $ ./pre-inst-env guix download https://bintray.com/artifact/download/groovy/maven/apache-groovy-src-2.4.5-incubating.zip Starting download of /tmp/guix-file.tllvrl >From >https://bintray.c

bug#22304: Build for Julia is not reproducible

When building “julia” twice we get different binaries for $out/lib/julia/sys.so and $out/lib/julia/sys-debug.so I could not determine the exact differences, because instead of a diff I just see something like this: --- /gnu/store/6njfyp46b22b0wb0r0ccg2wdzjx7066g-julia-0.4.2/lib/julia/sys.s

bug#20433: Keyboard not working on laptop with guixSD

While comparing the output of dmesg I found it interesting that on GuixSD the keyboard is identified as “USB HIDBP”: input: USB HIDBP Keyboard 05ac:820a as /devices/pci:00/:00:14.0/usb1/1-3/1-3.1/1-3.1:1.0/input/input5 whereas it is just a regular HID device on Trisquel: input:

bug#20433: Keyboard not working on laptop with guixSD

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> So, using HIDBP is probably wrong and might very well be the cause. >> Looking at the module names again I searched the logs for “usbkbd” and, >> yes, the GuixSD logs contain this line: >> >> usbc

bug#22304: Build for Julia is not reproducible

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> When building “julia” twice we get different binaries for >> >> $out/lib/julia/sys.so >> >> and >> >> $out/lib/julia/sys-debug.so > > Apparently there’s no __DATE__ and __TIME__ i

bug#22437: Fixing package-with-python2

Efraim Flashner writes: > On Wed, 03 Feb 2016 09:47:15 +0100 > l...@gnu.org (Ludovic Courtès) wrote: > >> l...@gnu.org (Ludovic Courtès) skribis: >> >> > An idea I haven’t taken the time to test yet would be to use >> > ‘properties’: >> > >> > (define python-foobar ;with Python 3 >> > (

bug#22677: guix lint fails with -dc switch missing

Pjotr Prins writes: > When I run lint on a recent ceckout > > ./pre-inst-env guix lint > > or > > ./pre-inst-env guix lint python > > I get > > filtered-port: failed to execute ' -dc ': No such file or directory > This looks like it is a result of an undefined %bzip2, %xz, and/or %gzip va

bug#22687: Online manual not updated automatically

Leo Famulari writes: > I see the value of the online manual matching the version of the Guix > binaries we distribute, but on the other hand, we get a lot of questions > that are answered in the latest version of the manual. Many other projects publish online manuals for both stable and develop

bug#22695: Binary Installation bugs and suggestions

myglc2 writes: > I attempted to perform 'Binary Installation' on Debian 8 following ... > > https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation > > last updated November 04, 2015 I suggest looking at the latest version of the manual in the repository

bug#22687: Online manual not updated automatically

Andreas Enge writes: > On Tue, Feb 16, 2016 at 11:06:40AM +0100, Ricardo Wurmus wrote: >> Many other projects publish online manuals for both stable and >> development versions. As our releases are a little far apart and we’re >> encouraging to do “guix pull” (so

bug#22695: Binary Installation bugs and suggestions

install guix with >> guix. > > "Thompson, David" writes: > [...] >> >> Don't run 'guix package -r guix'. > > Cool, please say that. +1! > Ricardo Wurmus writes: > [...] >>> 5) We should tell root how to verify that th

bug#22707: IBus relies on possibly outdated ~/.cache/ibus/bus/registry

I have an annoying little problem with IBus. IBus creates a binary registry in ~/.cache/ibus/bus on first start(?) which contains the full paths to store items such as /gnu/store/k3r...-ibus-1.5.11/libexec/ibus-dconf The problem is that when updating the “ibus” package this registry is inval

bug#22565: Cannot talk to upowerd over D-Bus

I’m trying to figure out why we cannot use the Xfce menu to shut down or reboot, and while doing that I found that loginctl poweroff (as root on the TTY) does have the intended effect. When run as a user I see a similar error as mentioned above: Failed to power off: Interactive authenti

bug#22740: Freshness check blocks upgrading

Leo Famulari writes: > On Fri, Feb 19, 2016 at 06:12:09PM +0100, Andreas Enge wrote: >> Hello, >> >> when upgrading packages, there is a check for new GNU releases. >> In the presence of network problems preventing to reach the corresponding >> servers, the command "guix package -u" hangs indef

bug#22738: Build failure in vigra

Andreas Enge writes: > On Thu, Feb 18, 2016 at 10:59:11PM -0500, Leo Famulari wrote: >> It looks like we need this module 'vigranumpy': >> https://ukoethe.github.io/vigra/doc-release/vigranumpy/index.html > > This is part of the vigra source code. There should soon be a new vigra > release: >

bug#22835: Autologin

Andreas Enge writes: > I am trying to create a configuration using slim-service with autologin. > > Looking at the code in gnu/services/xorg.scm, I find the following definition: > (define* (slim-service #:key (slim slim) >(allow-empty-passwords? #t) auto-login? >

bug#22836: “guix build -S” fails when “source” is #f

I just did this: guix build -S xfce This resulted in this error message: ~~~ Backtrace: In ice-9/boot-9.scm: 157: 18 [catch #t # ...] In unknown file: ?: 17 [apply-smob/1 #] In ice-9/boot-9.scm: 63: 16 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 15 [eval

bug#22565: Cannot talk to upowerd over D-Bus

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> I’m trying to figure out why we cannot use the Xfce menu to shut down or >> reboot, and while doing that I found that >> >> loginctl poweroff >> >> (as root on the TTY) does have the inten

bug#21909: Segfault with eigen in R

Kyle Meyer writes: > I've opened an issue in the OpenBLAS repo [1]. > > https://github.com/xianyi/OpenBLAS/issues/703 > > I'm trying to answer their questions, but, as is apparent in that > thread, I'm not really familiar with debugging these sorts of problems. > Since others are able to reprod

bug#21909: Segfault with eigen in R

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> We have since removed OpenBLAS from the inputs of R and just use the >> internal BLAS instead. Without OpenBLAS I cannot reproduce this bug >> any more. > > Nice. So we can close? I had already closed it

bug#22907: `guix package -u` fails

Nils Gillmann writes: > niasterisk@khazad-dum ~$ time guix package --substitute-urls=hydra.gnu.org > --dry-run -u *.* “-u” takes a regular expression like '.*' It seems to work for me. ~~ Ricardo

bug#19733: disfunctional gcc binary when GCJ or gfortran is installed

Fixed with 82f145ef7aef8f4d28a144ee8efcadf3fdd4b877

bug#23200: XFCE: selecting a style has no effect

Chris Marusich writes: > I've noticed surprising behavior on a fresh install of GuixSD v0.10.0 > when using XFCE. In XFCE, in the "Appearance" section of the settings, > under the "Style" tab, if you select an alternate style (e.g., > "Xfce-kolors"), the color scheme does not actually get updat

bug#23479: CRAN importer: do not print backtrace when package name is invalid

The CRAN importer (and possibly other importers) print ugly backtraces when a package is to be imported that does not exist. This can happen when the user mistypes the name or when the package is available on Bioconductor rather than CRAN. To fix this we should catch 404 errors in the “fetch-desc

bug#23504: git 2.7.4 fails to clone repositories over HTTPS sources

Dennis Mungai writes: > Hello there, > > I'm using git 2.7.4 from a guix profile, and here is my current environment: > > guix package -p ~/opt/guix-build-system --search-paths > warning: failed to install locale: Invalid argument > export > PATH="/home/lin/opt/guix-build-system/bin:/home/lin/o

bug#23874: duplicates in manifests are “installed” more than once

When there are duplicate references to package variables in a manifest, the same package will appear to be installed into the same profile multiple times. Here’s a manitest: ~~ (use-package-modules admin) ;; so stressed! (packages->manifest (list stress stress stress)) ~

bug#23984: Bug avr-toolchain

Daniel Pimentel writes: > I'd like report a bug in our avr-toolchain. I try compile to Arduino > plataform using Microscheme (installed with: guix package -i > microscheme) on GuixSD, but there are errors. > > I did: > sudo microscheme -m UNO -d /dev/ttyACM0 -au lightom.ms > > Output: > ... >

bug#24087: recovery from suspend is broken with recent libreboot + linux-libre 4.7

Clément Lassieur writes: > Hi, > >> We include older kernel versions: linux-libre-4.4 and linux-libre-4.1, >> which you can select via the 'kernel' field of the OS configuration, >> e.g.: (kernel linux-libre-4.4) >> >> Can you try these and see if the problem persists? > > I tried these kernels

bug#24188: gnucash needs gtk+ in propagated-inputs

Arun Isaac writes: > I installed gnucash with `guix package -i gnucash`. When I attempt to > run it, it fails with the following error message: > > ** > gnc.gui:ERROR:gnc-icons.c:96:gnc_add_stock_icon_pair: assertion failed: > (pixbuf1 && pixbuf2) > fish: 'gnucash' terminated by signal SIGABRT

bug#24192: Gajim fails with locale.Error

Daniel Pimentel writes: > I have a similar problem with locale in Haunt package: > > Backtrace: > In ice-9/boot-9.scm: > 157: 10 [catch #t # ...] > In unknown file: > ?: 9 [apply-smob/1 #] > In ice-9/boot-9.scm: >63: 8 [call-with-prompt prompt0 ...] > In ice-9/eval.scm: > 432: 7 [eva

bug#24288: gnome-maps fails

I just installed “gnome-maps” and tried to start it with disappointing results: $ gnome-maps (org.gnome.Maps:5547): GLib-GIO-ERROR **: Settings schema 'org.gnome.desktop.interface' is not installed Trace/breakpoint trap I’m not using GNOME but Xfce. ~~ Ricardo

bug#24373: “man” cannot find “iconv”

Some man pages cannot be rendered: rekado in dev: LANG=en_US.utf8 man borg man: can't execute iconv: No such file or directory man: command exited with status 127: iconv -c -f ISO-8859-1 -t UTF-8//TRANSLIT | sed -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\

bug#24373: how to reproduce this

The environment variable that triggers the bug is “LC_CTYPE=zh_CN.utf8”, which I have set in Emacs. ~ $ LC_CTYPE=zh_CN.utf8 man borg man: can't execute iconv: No such file or directory man: command exited with status 127: iconv -c -f ISO-8859-1 -t UT

bug#24373: Fixed

Fixed with commit ea55a39530d6604cde07d5b23ba529a07a76ea7b.

bug#24550: Epiphany, errors in terminal, and missing icons

Adonay Felipe Nogueira writes: > I'm using Guix in my copy of Trisquel, and installed Epiphany. > > As per the attachments and subject, Epiphany seems to behave strangely, > almost like what happens with `gnunet-setup` (from "gnunet-gtk" > package). What GTK theme are you using? Does the behav

bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

> dian_ce...@zoho.com writes: > >> I'm just sending this to you since I think I might have figured out what is >> happening, and I don't know how to respond to bugs via the mailing list. >> Instruction on replying to bugs via the mailing list would be quite a help. >> >> Basically, /var/lib/guix/p

bug#24670: bug #24670: Unexpected EOF reading a line (from guix pull)

dian_ce...@zoho.com writes: > When I was looking to try and figure out what was going wrong, I didn't even > think about the fact I have /gnu mounted as a seperate parition, since I'm > installing Guix on Gentoo system and my root partition is rather close to full > for my liking. The perms for t

bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

ng0 writes: > Without adding all of the off-ticket/list email I got: the failure is > very likely caused by /gnu/store being on a separate partition. What makes you say this is “very likely” the cause? I have no problems having /gnu on an NFS share on a remote fileserver with guix-daemon runni

bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

ng0 writes: > Ricardo Wurmus writes: > >> ng0 writes: >> >>> Without adding all of the off-ticket/list email I got: the failure is >>> very likely caused by /gnu/store being on a separate partition. >> >> What makes you say this is “very lik

bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

ng0 writes: > It is impossible to reproduce exactly the system which caused the bug, > but I will try to reproduce it as good as you can with Gentoo. I chuckled a little. It’s ironic because with Guix we actually can reproduce systems with relative ease :) Which is why I suggest trying the of

bug#24670: Unexpected EOF reading a line (from guix pull) [forward]

ng0 writes: > Ricardo Wurmus writes: > >> ng0 writes: >> >>> It is impossible to reproduce exactly the system which caused the bug, >>> but I will try to reproduce it as good as you can with Gentoo. >> >> I chuckled a little. It’s ironic becaus

bug#24670: bug #24670: Unexpected EOF reading a line (from guix pull)

dian_ce...@zoho.com writes: > On Fri, Oct 14, 2016 at 12:06:41PM +0200, Ricardo Wurmus wrote: >> >> There’s nothing wrong with having /gnu on a separate partition. I’m >> doing the same on our HPC cluster at work (/gnu is on NFS). >> >> Have you tried

bug#24988: Guix requests substitute for non-substitutable package

Guix requests a substitute for “texlive-texmf” even though it is marked as not substitutable. This is a problem for many users because hydra does not offer a substitute for this package. Users have to pass “--fallback” to make Guix build the package from source. Only the “texlive-texmf” package

bug#25035: scribus: No module named _sysconfigdata_nd

Adonay Felipe Nogueira writes: > # Steps to reproduce > > Simply try running Scribus. It closes immediatelly. I cannot reproduce this. I just upgraded Scribus; I’m using /gnu/store/5h44li2ansg4mb5kqck44wdzkka3isih-scribus-1.5.2/bin/scribus > # Notes > > * I have attached the raw output of `st

bug#25035: scribus: No module named _sysconfigdata_nd

Adonay Felipe Nogueira writes: > Note: If I'm not mistaken, there was no advise to set $PYTHONPATH to > anything by the documentation (at least not for dailly/normal use) or by > Guix itself (during installation of Scribus). I don’t have PYTHONPATH set and Scribus works for me (I’m using GuixSD

bug#25037: abiword: Not openning file chooser, and GLib-GIO-ERROR error

Adonay Felipe Nogueira writes: > Abiword exits whenever one needs to use a file chooser to open or save > files to be used or saved by AbiWord. > > # Steps to reproduce > > 1. Run AbiWord (with no other instances open, just to make sure). > > 2. Go to: File → Open > * Or to: File → Save as >

bug#24937: "deleting unused links" GC phase is too slow

Ludovic Courtès writes: > Ricardo, Roel: would you be able to run that links-traversal.c from > > on a machine with a big store, as described at >

bug#25205: Guix package is using the GuixSD logo instead of the Guix logo

Luis Felipe López Acevedo writes: > Well, I didn't know it was decided to use GuixSD icon for Guix as well. > I agree with Mathieu and Chris Marusich: use the same icon is fine, but > not the same text. For example: > > ~v~ Guix > ~v~ GuixSD > > If this is OK, then I think we should: > > - Add

bug#23479: CRAN importer: do not print backtrace when package name is invalid

Fixed in commit fdbc84b056683204c5832d3740d9b109f31f7cb9.

bug#25231: Linux-libre 4.9 fails to load modules on i686 (release blocker!)

Ludovic Courtès writes: > Mark H Weaver skribis: >> >> Sounds good. On 'master', I just reverted the 4.9 upgrade, followed >> immediately by an upgrade to 4.8.15. Feel free to cherry-pick to the >> version-0.12.0 branch, but make sure to get both of them. > > Awesome, thanks for the fast repl

bug#25254: [minor] 'About' page says GuixSD is a "GNU/Linux distribution"

Taylan UlrichBayırlı/Kammer writes: > It would be better to be consistent with the home page and make clear > that GuixSD is a GNU distribution, with Linux-libre being the default > kernel for the foreseeable future. > > Background: Wikipedia has a policy to call GNU/Linux distributions > "Linux

bug#25281: rust importer duplicates input

David Craven writes: > Looking at the Cargo.toml file we see this: > > [target."cfg(unix)".dependencies] > libc = "0.2.14" > # Compat with older Cargo versions temporarily > [target.x86_64-unknown-linux-gnu.dependencies] > libc = "0.2.14" > [target.i686-unknown-linux-gnu.dependencies] > libc = "

bug#25314: clisp not reproducible

The build of CLISP is not reproducible. There are three files that differ: diff -r /gnu/store/lf2ybanhxpvbgbxcsxmc733v010g15fp-clisp-2.49 /gnu/store/lf2ybanhxpvbgbxcsxmc733v010g15fp-clisp-2.49-check/ Binary files /gnu/store/lf2ybanhxpvbgbxcsxmc733v010g15fp-clisp-2.49/lib/clisp-2.49/base/lisp.a

bug#25315: diffoscope misses inputs

I just installed diffoscope and ran it on two files and got this error: --8<---cut here---start->8--- diffoscope /gnu/store/lf2ybanhxpvbgbxcsxmc733v010g15fp-clisp-2.49/lib/clisp-2.49/base/lispinit.mem /gnu/store/lf2ybanhxpvbgbxcsxmc733v010g15fp-clisp-2.49-che

bug#25315: more missing inputs

There are many more tools whose availability is checked for at runtime. @tool_required('bzip2') @tool_required('cbfstool') @tool_required('cd-iccdump') @tool_required('cmp') @tool_required('colordiff') @tool_required('cpio') @tool_required('diff') @tool_required('en

bug#25311: guile with details

Gnu Röoty writes: > Hi ! apparently guile has a problem. After installation of guiXSD 0.12.0 > and the started of guixSD the guile display a message : > > the message : Entering a new prompt 'bt' or 'q' to continue > GNU Guile 2.0.12 > sheme@(guile-user). > And I do CTRL+D a kernel panic appears

bug#25310: Can't install Guix

Victory Omole writes: > I've been having problems trying to install guix for the last 48 hrs, and > i'm close to tearing my hair out. I'm trying to do a "guix system init", > but I am getting "guix system: error open-file: No such file or > directory:"/gnu/store/…-guile-bootstrap-2.0.drv". > >

bug#25315: more missing inputs

Fixed with 5dbeccf5b4f534dd5519691dfdf58a6921c9f343, which embeds references for xxd, colordiff, and readelf.

bug#25314: timestamp

The file ./src/constobj.d contains this: --8<---cut here---start->8--- #ifdef __DATE__ LISPOBJ_S(lisp_implementation_version_built_string,__DATE__ __TIME__) #else LISPOBJ(lisp_implementation_version_built_string,"NIL") #endif --8<---cut here-

bug#25401: tcc fails to build (test failure)

The package “tcc” fails to build. The check phase fails: --8<---cut here---start->8--- starting phase `check' make -C tests test make[1]: Entering directory '/tmp/guix-build-tcc-0.9.26.drv-0/tcc-0.9.26/tests' hello-exe ../tcc -B.. ../e

bug#25296: fully functional desktop installation

>> I have no idea how to chat in Gnome. (Of course I will investigate.) > > There’s Pidgin, but maybe it’s not really part of GNOME. The GNOME way is to use Empathy, which depends on the Telepathy framework: https://wiki.gnome.org/Apps/Empathy -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150

bug#25425: lua does not set search paths

The lua interpreter packages do not set native search paths, so they cannot find lua modules. $ guix environment --ad-hoc lua lua-lpeg $ lua > require('lpeg') … ERROR … However: $ guix environment --ad-hoc lua lua-lpeg $ export LUA_PATH="$GUIX_ENVIRONMENT/share/lua/5.3/?.lua;$GUIX_E

bug#25425: cannot express search path

It seems that the “search-path-specification” cannot be used to include placeholders such as “?” as required by LUA_PATH and LUA_CPATH. The search paths in Lua are not directories and they are not actual file names. I suggest adding an optional “placeholder” field to “search-path-specification”,

bug#25425: cannot express search path

Ludovic Courtès writes: > I think this should work: > >(search-path-specification > (variable "LUA_PATH") > (separator ";") > (files '("share/lua/5.3")) > (file-pattern "\\.lua$") > (file-type 'regular)) I tried this very same thing but it do

  1   2   3   4   5   6   7   8   9   10   >