bug#18701: Intermittent build failures for man-pages

There are intermittent build failures for man-pages. See: http://hydra.gnu.org/job/gnu/master/man-pages-3.69.x86_64-linux http://hydra.gnu.org/job/gnu/master/man-pages-3.69.i686-linux The failures are the same: --8<---cut here---start->8--- starting phase

bug#18702: libsodium fails to build on i686

Hydra has never successfully built libsodium on i686, though it succeeds on both x86_64 and mips64el. See: http://hydra.gnu.org/job/gnu/master/libsodium-1.0.0.i686-linux http://hydra.gnu.org/job/gnu/master/libsodium-0.5.0.i686-linux The configure script apparently hangs here: --8<--

bug#18703: chicken fails its test suite on x86_64

chicken fails its test suite on x86_64, though it succeeds on both i686 and mips64el. See: http://hydra.gnu.org/job/gnu/master/chicken-4.8.0.3.x86_64-linux The problem is always the same: --8<---cut here---start->8--- SRFI 69 procedures HT - No Parameters H

bug#18704: nss-mdns home-page and source URL no longer valid

Like libdaemon , the home-page and source URL for nss-mdns has vanished, so all the builds on hydra are failing. I found the following alternate URLs to download the source. http://ftp.de.debian.org/debian/pool/main/n/nss-mdns/nss-mdns_0.10.orig.tar.gz http://pkgs.fedor

bug#18704: nss-mdns home-page and source URL no longer valid

Fixed in 0546393164d30c6722ddbf17fc05c424a57e71a4. Mark

bug#18706: python2-pyicu fails to build on all platforms

python2-pyicu fails to build on all platforms since we updated icu4c to version 53.1 from 52.1 in early June. See: http://hydra.gnu.org/job/gnu/master/python2-pyicu-1.5.x86_64-linux/all http://hydra.gnu.org/job/gnu/master/python2-pyicu-1.5.i686-linux/all http://hydra.gnu.org/job/gnu/master/

bug#18524: Guix unable to download from github due to TLS fatal alert

l...@gnu.org (Ludovic Courtès) writes: > I had managed to bork ‘set-session-server-name!’ in GnuTLS (which > addresses this bug), so this is fixed in commit 5186158 and upstream: > . > > Sorry about that! No worr

bug#18740: xf86-video-openchrome fails to build on all platforms

xf86-video-openchrome fails to build on all platforms. See: http://hydra.gnu.org/job/gnu/master/xf86-video-openchrome-0.2.906.x86_64-linux http://hydra.gnu.org/job/gnu/master/xf86-video-openchrome-0.2.906.i686-linux Mark

bug#18741: xf86-video-ati fails to build on all platforms

xf86-video-ati fails to build on all platforms. See: http://hydra.gnu.org/job/gnu/master/xf86-video-ati-6.14.4.x86_64-linux http://hydra.gnu.org/job/gnu/master/xf86-video-ati-6.14.4.i686-linux Mark

bug#18742: gnunet intermittently fails its test suite on all platforms

gnunet intermittently fails its test suite on all platforms. The failures are not consistent. See: http://hydra.gnu.org/build/122625/log/raw http://hydra.gnu.org/build/82158/log/tail-reload http://hydra.gnu.org/build/121802/log/tail-reload Failures seem to be very rare on i686, occasional

bug#18814: ffmpeg 2.4.2 upgrade broke vlc

Jason Self writes: > commit 7947a05439cc26d93bd93300f38d216dbb93c76d > Author: Jason Self > Date: Mon Oct 20 12:32:42 2014 -0700 > > gnu: ffmpeg: Update to 2.4.2. > > * gnu/packages/video.scm (ffmpeg): Update to version 2.4.2. This broke the vlc build with the following error:

bug#18706: python2-pyicu fails to build on all platforms

Mark H Weaver writes: > python2-pyicu fails to build on all platforms since we updated icu4c to > version 53.1 from 52.1 in early June. See: This was fixed by updating python2-pyicu to version 1.8, done in commit 569ac04681aa6f1d63fd9fa7b2bd844f67685d28, thanks to Andreas Enge. I

bug#18814: ffmpeg 2.4.2 upgrade broke vlc

Mark H Weaver writes: > Jason Self writes: > >> commit 7947a05439cc26d93bd93300f38d216dbb93c76d >> Author: Jason Self >> Date: Mon Oct 20 12:32:42 2014 -0700 >> >> gnu: ffmpeg: Update to 2.4.2. >> >> * gnu/packages/video.scm (ffmp

bug#18838: zsh test suite failures, possibly due to 'noatime' mount flag

Twice recently, once on x86_64 and once on i686, zsh has failed its test suite while being built by hydra. Here's the output in both cases: --8<---cut here---start->8--- Test ./C02cond.ztst failed: bad status 1, expected 0 from: print -u $ZTST_fd 'This test t

bug#18935: gexp->derivation test failure

On my i686 standalone Guix system, using Guix v0.7-642-g3b50925 to build its 'guix' package (0.7.14e84b2) fails, due to a failed test. Here's the relevant section from gexp.log: --8<---cut here---start->8--- Test begin: test-name: "gexp->derivation" source-

bug#18935: gexp->derivation test failure

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > [...] >> actual-error: (srfi-34 #> "path >> `/tmp/nix-build-guix-0.7.14e84b2.drv-0/source/test-tmp/store/ry17r3hm48ckcchz9ls6yhd00alyiipx-foo' >> is not valid" status: 1] a587d68>)

bug#18935: gexp->derivation test failure

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> The same failure happened to me in two consecutive build attempts: >> once when running "guix system build", and then again when running >> "guix build -K guix" so that I co

bug#19128: Problems with transmission-gtk

transmission-gtk launches, but attempting to "open" a file causes the program ato exit ungracefully with the following output: --8<---cut here---start->8--- mhw:~$ transmission-gtk ** (transmission-gtk:10588): WARNING **: Error retrieving accessibility bus ad

bug#19321: evince fails to build, attempts to evaluate: ()

evince fails to build. This is the entire build output: --8<---cut here---start->8--- ice-9/boot-9.scm:700:29: In procedure map: ice-9/boot-9.scm:700:29: Syntax error: unknown location: unexpected syntax in form () --8<---cut here---end-

bug#19332: atk fails to build

atk fails to build. See: http://hydra.gnu.org/build/172242 The problem was introduced between 427476d (works) and 5a4753a (fails), probably one of these two commits: 5a4753a * gnu: gobject-introspection: Define search path for typelib files. 6671724 * gnu: gobject-introspection: Update to 1.4

bug#19332: atk fails to build

Mark H Weaver writes: > atk fails to build. See: > > http://hydra.gnu.org/build/172242 > > The problem was introduced between 427476d (works) and 5a4753a (fails), > probably one of these two commits: > > 5a4753a * gnu: gobject-introspection: Define search path for

bug#19332: atk fails to build

Mark H Weaver writes: > It turns out that upgrading 'gobject-introspection' broke lots of > libraries that use it. Updating 'atk' to the latest version fixed it. > Ditto for 'pango'. I'm currently working on updating the affected > packages.

bug#19364: search-patch fails to consult GUIX_PACKAGE_PATH

Tomáš Čech reported on IRC that 'search-patch' failed to find a patch he had put into DIR/gnu/packages/patches/, where DIR was in $GUIX_PACKAGE_PATH. Adding DIR to GUILE_LOAD_PATH fixed the problem. Also, it would be good to improve the error message when 'search-patch' fails. This is what he r

bug#19138: Emacs crashes

l...@gnu.org (Ludovic Courtès) writes: > Andreas Enge skribis: > >> With current emacs-24.4 of git 0276f69, the following crash occurs: >> >> I start emacs, which seems to launch a gtk version. >> Then I click on the first icon in the upper left, labelled >> "Specify a new's file name, to edit th

bug#19138: Emacs crashes

Mark H Weaver writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Andreas Enge skribis: >> >>> With current emacs-24.4 of git 0276f69, the following crash occurs: >>> >>> I start emacs, which seems to launch a gtk version. >>> Then

bug#19402: Already-applied patches in 'origin' are automatically reversed

Currently, if a patch that we carry in Guix is taken upstream, and then we update the package, Guix will automatically reverse the patch without error. This behavior delayed my xorg-update work for several hours today (I was stumped and took a break), and I worry that patches that aren't needed fo

bug#19402: Already-applied patches in 'origin' are automatically reversed

l...@gnu.org (Ludovic Courtès) writes: > Done in commit 9426440, thanks! Thanks for fixing it! The new strictness has already borne fruit. Turns out we've been reverse applying m4-readlink-EINVAL.patch to our m4 since at least 1fa49a2c4 (September 2013). Fixed in 6ac8aa3d7. Mark

bug#18033: Add support for 'search-path-specifications' referring to files

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Commit af07095 extends ‘search-path-specification’ with a ‘file-type’ > field, which can be 'regular. > > Then, commit 7b21fe5 adds a ‘file-pattern’ field, to look for files > matching a pattern recursively. > > Lastly, commit 2a8d440 uses thes

bug#19598: Failure to build gcc-cross-mips64el-linux-gnuabi64-4.8.4.i686-linux

This is on core-updates: http://hydra.gnu.org/build/196225/nixlog/4/tail-reload --8<---cut here---start->8--- mips64el-linux-gnuabi64-gcc -mabi=64 -nostdlib -nostartfiles -r -o /tmp/nix-build-glibc-cross-mips64el-linux-gnuabi64-2.20.drv-0/build/libc_pic.os

bug#19599: strace test suite failures

The strace builds on both x86_64 and i686 intermittently fail, apparently based on 'uname' output which in turn depends on which build slave was used. See: http://hydra.gnu.org/build/196334/log/tail-reload --8<---cut here---start->8--- starting phase `check'

bug#18702: libsodium fails to build on i686

Mark H Weaver writes: > Hydra has never successfully built libsodium on i686, though it succeeds > on both x86_64 and mips64el. See: > > http://hydra.gnu.org/job/gnu/master/libsodium-1.0.0.i686-linux > http://hydra.gnu.org/job/gnu/master/libsodium-0.5.0.i686-linux > >

bug#19600: Broken source URI for teckit

The upstream source URI for teckit no longer works. http://scripts.sil.org/TECkitDownloads still points to the same places as we're trying to download from, but the upstream subversion repo links all fail now. Mark

bug#19610: decoding-error while retrieving brasero build outputs

What do you suppose went wrong here? http://hydra.gnu.org/build/201789 It seems to have happened twice in a row. Mark

bug#19600: Broken source URI for teckit

Mark H Weaver writes: > The upstream source URI for teckit no longer works. > http://scripts.sil.org/TECkitDownloads still points to the same places > as we're trying to download from, but the upstream subversion repo links > all fail now. Fixed in e478a9ecc2 by adding

bug#18702: libsodium fails to build on i686

Mark H Weaver writes: > Mark H Weaver writes: > >> Hydra has never successfully built libsodium on i686, though it succeeds >> on both x86_64 and mips64el. See: >> >> http://hydra.gnu.org/job/gnu/master/libsodium-1.0.0.i686-linux >> http://hydra.gnu.org

bug#19671: Raw binary data in build log from substitute-binary

While trying to install 'racket' using substitutes, several lines of the form "substitute-binary: " were output. See the attachment for the precise output, captured via Emacs' shell mode. This was when running guix from git commit 2dfed64 on an i686 GSD system. Any ideas what would cause this?

bug#19666: Bad URL in netpbm

Fixed in 7d8379a767. Thanks! Mark

bug#19677: Libgcrypt warning: missing initialization

On both my GSD and Guix-on-other-distro machines, /var/log/messages has many occurrences of the following warning: guile: Libgcrypt warning: missing initialization - please fix the application Mark

bug#19708: Bowtie fails to build

Fixed in 241e12219. Thanks to Ricardo and Andreas for sorting this out! Mark

bug#19686: Bad source checksum in netpbm

Since the netpbm update was reverted in 836223f74, I'm closing this bug. Mark

bug#19749: orpheus does not build on mips64

Andreas Enge writes: > the orpheus package fails to build on mips64 with the following message: > > checking build system type... ./config.guess: unable to guess system type > This script, last modified 2001-07-12, has failed to recognize > the operating system you are using. It is advised that y

bug#19764: Downgrade reported as an ugprade

l...@gnu.org (Ludovic Courtès) writes: > As seen during a ‘guix package’ demo at FOSDEM, downgrades are reported > as upgrades as of 0.8.1. I don't know about this one, but another problem with our upgrade command is that it mishandles outputs other than "out", at least in the console output. It

bug#19778: file-system: (title 'uuid) is documented but not implemented

Section 6.2.3 (File Systems) of the manual documents (title 'uuid), but it is not yet implemented. Mark

bug#19779: dmd: service definition errors cause kernel panic

When I first wrote 'wicd-service', I mispelled 'make-forkexec-constructor'. This caused a kernel panic whenever the service was included in my OS config. I don't know whether dmd printed a helpful error message, but if so, it was followed immediately by a kernel call trace that caused earlier mes

bug#19749: orpheus does not build on mips64

Andreas Enge writes: > On Tue, Feb 03, 2015 at 01:04:38AM -0500, Mark H Weaver wrote: >> The config.guess problem can be easily worked around by passing >> --build= to configure. I would suggest something similar to >> what I did in the gmp package to get it working on ar

bug#19797: hydra: drvs deleted by GC, leads to aborted unrestartable builds

Here are three examples in evaluation 102697 (the latest) of packages that aborted because the garbage collector deleted their .drv files. These builds cannot be restarted. http://hydra.gnu.org/build/237336 http://hydra.gnu.org/build/237342 http://hydra.gnu.org/build/237338 In all three cas

bug#19671: Raw binary data in build log from substitute-binary

Mark H Weaver writes: > While trying to install 'racket' using substitutes, several lines of the > form "substitute-binary: " were output. See the > attachment for the precise output, captured via Emacs' shell mode. > > This was when running guix from gi

bug#19806: substitute-binary --query busy for 36 minutes with no output

While updating my profile with "guix package -c1 -u", "substitute-binary --query" hung for 36 minutes with ~90% CPU utilization without any active network connections and without printing any output. Here was the relevant excerpt from 'ps auxwwf' after about 30 minutes of CPU time: --8<--

bug#19811: Attempt to graft texlive times out after one hour

On my i686 Libreboot X60, two consecutive attempts to run "guix package -u" have failed with the following message: --8<---cut here---start->8--- grafting '/gnu/store/i8iiv9qd1jndwxxr2h563fwwn0997xkx-cups-2.0.1' -> '/gnu/store/nrdr51fkncjm5nqkx70576g25l4ka5na-c

bug#19811: Attempt to graft texlive times out after one hour

Mark H Weaver writes: > * I later discovered the --timeout option for 'guix build' (also > supported by 'guix package') but the manual claims that "By default > there is no timeout". This seems to be incorrect. I proceeded to try explicitly passin

bug#19803: gstreamer-0.10 fails tests

Andreas Enge writes: > currently, gstreamer-0.10.36 fails its tests on all three platforms. As we > have the latest version 1.4.5 and nothing depends on the old version any more, > I think we can safely remove it (together with gst-plugins-base-0.10). In fact, this was my motivation for commit 7

bug#19811: Attempt to graft texlive times out after one hour

Mark H Weaver writes: > Mark H Weaver writes: > >> * I later discovered the --timeout option for 'guix build' (also >> supported by 'guix package') but the manual claims that "By default >> there is no timeout". This seems to b

bug#19795: Allow for stateless users and groups in GuixSD

Andreas Enge writes: > I agree, it is rather surprising that removing a user does not remove it. > So I think it should be fully stateless (as long as the user's home > directory is not erased, of course; so this should remain as a state and > be reactivated once the user is available again, whic

bug#19811: Attempt to graft texlive times out after one hour

Mark H Weaver writes: > I guess that my machine and rotating disk are too slow to graft texlive > within an hour. I was able to do it by passing "--max-silent-time=36000". It ended up taking just under 2 hours (real time) to graft texlive on my i686 Libreboot X60 system. Mark

bug#19805: Numpy failures

l...@gnu.org (Ludovic Courtès) writes: > Federico Beffa skribis: > >> At some point we should fix the support for '#:substitutable?' on hydra > > That probably means that #:substitutable? should be propagated–i.e., > that anything depending on ATLAS should not be substituted. As I just wrote in

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

Ricardo Wurmus writes: > 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-mdametap

bug#19973: Grafts break debug outputs

Grafts break debug outputs, or at least that's my guess. Here's what I see: mhw@jojen:~$ guix build guile guix build: warning: ambiguous package specification `guile' guix build: warning: choosing guile-2.0.11 from gnu/packages/guile.scm:110:2 /gnu/store/3lhr8q28q6f59774di9av7ncy09jd55d-guile-2.0.

bug#19973: Grafts break debug outputs

Mark H Weaver writes: > Grafts break debug outputs, or at least that's my guess. > Here's what I see: > > mhw@jojen:~$ guix build guile > guix build: warning: ambiguous package specification `guile' > guix build: warning: choosing guile-2.0.11 from gnu/pack

bug#19976: Cannot install texlive

l...@gnu.org (Ludovic Courtès) writes: > This is telling us that this is chunked encoding, and that the first > chunk’s size is #x76634478 B = 1986217080 B = 1.9 GiB. Ouch! > > You could buy more RAM. ;-) Or add more swap. In this case, although the memory needs to be allocated, but it is not

bug#19976: Cannot install texlive

Mark H Weaver writes: > l...@gnu.org (Ludovic Courtès) writes: > >> We’ll fix <http://bugs.gnu.org/19939>, see whether we can backport it >> in Guix, and also see if we can ask nginx to provide reasonable >> chunks. > > 'sendfile_max_chunk' might be

bug#19979: vlc install failed with backtrace

l...@gnu.org (Ludovic Courtès) writes: > Axel skribis: > >> and guix crashed with trace: >> >> Backtrace: [...] >> I just installed guixsd 0.8 and updated it with `guix pull`. Other >> packages installed without problems. > > I cannot reproduce it now just after running ‘guix pull’. > > However,

bug#20081: patch-source-shebangs crashes on broken symlink

Andreas Enge writes: > On Wed, Mar 11, 2015 at 04:02:11PM +0100, Tomáš Čech wrote: >> I'm trying to create package for taskwarrior. >> Source tarball contain symlinks to nonexisting file `task': > > I would argue that this is not a bug in guix, but in the tarball. > You can remove the link with a

bug#20102: Problem with ld.so RUNPATH on armhf

I recently tried rebuilding Guix on armhf, specifically master since the recent core-updates merge, and have run into a snag. I'm able to build a lot of stuff, including our full 'emacs' package (with Gtk+), but I'm unable to build 'glibc-utf8-locales', which means I can't build any profiles at al

bug#20163: substitute-binary fails when attempting to reconfigure

Running "guix system reconfigure" with substitutes enabled now consistently fails for me with the following backtrace: --8<---cut here---start->8--- root:~# ~mhw/bin/guix system reconfigure ~mhw/jojen.scm substitute-binary: Backtrace: substitute-binary: In ice-9

bug#20188: [wishlist] avoid unnecessary calls to substitute-binary

It would be good to avoid unnecessary calls to 'substitute-binary' when the needed items are already in the store, e.g.: --8<---cut here---start->8--- mhw@jojen:~$ guix build qt substitute-binary: updating list of substitutes from 'http://hydra.gnu.org'... /gnu/

bug#20042: python-2: Dangling .so references

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > (See the first "Dangling .so references" bug report for more > information.) > > /gnu/store/2fn7myy7bvkqvfx9fksgygj2wi24yzqa-python-2.7.6/ > > > /gnu/store/2fn7myy7bvkqvfx9fksgygj2wi24yzqa-python-2.7.6/lib/python2.7/lib-dynload/

bug#20053: python3: Dangling .so references

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes: > (See the first "Dangling .so references" bug report for more > information.) > > /gnu/store/hcg2g6bbmyhld7f3gb16jks3rgi40l1k-python-3.3.5/ > > /gnu/store/hcg2g6bbmyhld7f3gb16jks3rgi40l1k-python-3.3.5/lib/libpython3.so > lib

bug#20239: [wishlist] Add build hook to build for other platforms using qemu

It would be great if we had a build hook to enable guix-daemon to natively build packages for any system supported by qemu, by running the build processes within qemu. Mark

bug#20261: (mount-points) returns bogus values within the build environment

Within the guix-daemon build environment, tests/syscalls.scm consistently fails on my i686 Libreboot X60 running linux-libre-3.19.3. Outside of the build environment the test passes. Here's the relevant except from syscalls.log: --8<---cut here---start->8--- Te

bug#20261: (mount-points) returns bogus values within the build environment

retitle 20261 mount-points test failure within build environment in linux-libre-3.19.3 thanks Mark H Weaver writes: > Within the guix-daemon build environment, tests/syscalls.scm > consistently fails on my i686 Libreboot X60 running linux-libre-3.19.3. > Outside of the build enviro

bug#20261: (mount-points) returns bogus values within the build environment

Andy Wingo reported running into the same problem on Linux-4.0-rc6. Mark

bug#20255: 'search-paths' should respect both user and system profile.

宋文武 writes: >> [...] >>> >>> The idea to generate profile from search-paths is not new, >>> I heard it from you IIRC. >>> I think it's the time to do it. >> >> Agreed, the plan makes sense and I think we have all the bits. >> >> A related question is whether to encode search path environment >> v

bug#20102: Problem with ld.so RUNPATH on armhf

l...@gnu.org (Ludovic Courtès) writes: > Could you send the output of: > > $(guix build -e '(@ (gnu packages commencement) gcc-final)' | grep -ve > -lib)/bin/gcc -dumpspecs > > It could be that the patching of config/gnu-user*.h ends up adding > -rpath in the wrong place. Here it is: --8<

bug#20102: Problem with ld.so RUNPATH on armhf

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > > The difference between ‘glibc-final’ and (@ (gnu packages base) glibc) > (used to build glibc-utf8-locales) is that the latter is built with > ‘gcc-final’, and ‘gcc-final’ always passes “-rpath $libc/lib” when >

bug#20102: Problem with ld.so RUNPATH on armhf

Mark H Weaver writes: > l...@gnu.org (Ludovic Courtès) writes: > >> Could you try the same on armhf? > > I've done so. Here's the transcript: > > mhw@novena:/tmp/nix-build-glibc-2.21.drv-0$ source environment-variables > mhw@novena:/tmp/nix-build-glibc-2

bug#20102: Problem with ld.so RUNPATH on armhf

Mark H Weaver writes: > and here's the corresponding line in the strace log: > > 13440 > execve("/gnu/store/p70wvylq6xdrlxblnk76k3ljgkrmvpnq-ld-wrapper-0/bin/ld", > ["/gnu/store/p70wvylq6xdrlxblnk76k3ljgkrmvpnq-ld-wrapper-0/bin/ld", > "--eh-fr

bug#20102: Problem with ld.so RUNPATH on armhf

l...@gnu.org (Ludovic Courtès) writes: > With a bit of additional debug, I can print the value of ‘libs’ in the > ‘ld-wrapper’ procedure: > > ;;; (libs > ("/gnu/store/fbdjazgwy3zyx8qc5z4ag0j78k2d7raw-glibc-2.21/lib/ld-linux-armhf.so.3")) > > This one comes from the -dynamic-linker flag, which is

bug#20394: Guix 44fd6ef built within guix fails to create /etc/bash_completion.d

I attempted to update guix-devel to 44fd6ef, but got this error during the install phase: --8<---cut here---start->8--- /gnu/store/7an2gbwqav1pv9kk4xkslrb45qn44j7w-coreutils-8.23/bin/mkdir -p '/etc/bash_completion.d' /gnu/store/7an2gbwqav1pv9kk4xkslrb45qn44j7w

bug#20394: Guix 44fd6ef built within guix fails to create /etc/bash_completion.d

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I attempted to update guix-devel to 44fd6ef, but got this error during >> the install phase: >> >> /gnu/store/7an2gbwqav1pv9kk4xkslrb45qn44j7w-coreutils-8.23/bin/mkdir -p >> &#

bug#20394: Guix 44fd6ef built within guix fails to create /etc/bash_completion.d

Mark H Weaver writes: > l...@gnu.org (Ludovic Courtès) writes: > >> diff --git a/gnu/packages/package-management.scm >> b/gnu/packages/package-management.scm >> index 131cbcd..5340d42 100644 >> --- a/gnu/packages/package-management.scm >> +++ b/gnu/package

bug#20757: "unable to fork" on armhf

Efraim Flashner writes: > I have an armhf marsboard that I'm trying to run guix on top of debian. I > started by flashing a debian wheezy image, stripping out most of the > packages, and upgrading to jessie. I installed using the 0.8.2 armhf binary. > `guix pull` failed with the error "unable to

bug#20402: guix cannot download via an http proxy

Claes Wallin (韋嘉誠) writes: > Would support for $ftp_proxy as well require the implementation of new > functionality, or would it be a case of just letting the environment > variable through? It would require new functionality. Our FTP client would have to be enhanced to support proxies.

bug#20102: Problem with ld.so RUNPATH on armhf

In March 2015, Mark H Weaver wrote: > I recently tried rebuilding Guix on armhf, specifically master since the > recent core-updates merge, and have run into a snag. I'm able to build > a lot of stuff, including our full 'emacs' package (with Gtk+), but I'm > una

bug#20757: "unable to fork" on armhf

Any update on this? Did you try rebuilding your kernel with the needed configuration options enabled? Thanks, Mark

bug#20816: Excessive negative cache time for DNS lookups

On my GuixSD system, DNS lookup failures (due to lack of network) are cached for at least 4 minutes, and possibly much longer (I've not had the patience to wait until it expires). Even after restarting nscd, the negative cache entry persists for about another 20 seconds. I run into this problem q

bug#20824: configure --disable-daemon no longer works

It appears that --disable-daemon has become broken in our build system. I have periodically built guix from git on hydra with --disable-daemon, but this now leads to the following error in fef3cfa: --8<---cut here---start->8--- CXXLDguix-daemon g++: no inp

bug#20856: [core-updates] lame and jemalloc compile failures with gcc-4.9.2

On i686, both 'lame' and 'jemalloc' fail to compile with very similar errors when compiled with gcc-4.9.2: http://hydra.gnu.org:3000/build/528901/log/tail-reload http://hydra.gnu.org:3000/build/531046/log/tail-reload In both cases, the errors are of the form: /gnu/store/0cp1i7q70ip8py0mks6sb

bug#20856: [core-updates] lame and jemalloc compile failures with gcc-4.9.2

Mark H Weaver writes: > On i686, both 'lame' and 'jemalloc' fail to compile with very similar > errors when compiled with gcc-4.9.2: > > http://hydra.gnu.org:3000/build/528901/log/tail-reload > http://hydra.gnu.org:3000/build/531046/log/tail-reload >

bug#20965: qemu non-deterministic test failures

I've seen at least two occurrences of a non-deterministic test failure in qemu for x86_64 on hydra. Both are essentially the same, except for the random seed. Here's the relevant log tail of the most recent one: --8<---cut here---start->8--- GTESTER check-qtes

bug#21019: ifconfig doesn't allow mac change for devices

a...@gnu.org (Alfred M. Szmidt) writes: > That is correct, GNU ifconfig does not support setting the MAC > address. Guix also includes the 'iproute2' package, which includes a program called 'ip' that can do the same kinds of jobs as 'ifconfig'. I've successfully used it in the past to se

bug#21097: verify-store test failure on armhf-linux

When building the guix-0.8.2.72cd8ec package on armhf-linux (using guix from git b56724e), tests/store.scm fails. Here's the relevant excerpt from store.log: --8<---cut here---start->8--- Test begin: test-name: "verify-store" source-file: "tests/store.scm"

bug#21097: verify-store test failure on armhf-linux

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> actual-error: (srfi-34 # "invalidating path > `/tmp/nix-build-guix-0.8.2.72cd8ec.drv-0/source/test-tmp/store/pp8ls5jri3l8x8y24g1x3h6lkj0lr4gv-bash-light-4.3.39-guile-builder' > in database: FOREIGN K

bug#21142: Sshfs-fuse requires fuse

Claes Wallin (韋嘉誠) writes: > On 27-Jul-2015 5:06 pm, "Andreas Enge" wrote: >> >> Hello, >> >> when trying to execute sshfs from the sshfs-fuse package, I obtain >> fuse: failed to exec fusermount: No such file or directory >> >> I think that fuse should be a propagated input of sshfs-fuse. > > M

bug#21224: guix system init --no-grub doesn't work

I'm in the early stages of adding GuixSD for the Lemote Yeeloong, and so for now would like to avoid getting grub working on the Yeeloong. So, I tried running "guix system init config.scm /target --no-grub", and this is what happens: /gnu/store/...-system initializing operating system under

bug#21318: Only the first 8 characters of passwords are significant

yenda on #guix reported that when typing user passwords, only the first 8 characters need to be typed correctly to successfully log in. DusXMT on #guix mentioned that [GNU/]Linux From Scratch instructs users to change "#ENCRYPT_METHOD_DES" to "ENCRYPT_METHOD_SHA512" in etc/login.defs: http://ww

bug#21224: guix system init --no-grub doesn't work

Mark H Weaver writes: > I'm in the early stages of adding GuixSD for the Lemote Yeeloong, and so > for now would like to avoid getting grub working on the Yeeloong. So, > I tried running "guix system init config.scm /target --no-grub", and > this is what happens:

bug#21610: FreeBSD compilation problem (errno_location)

l...@gnu.org (Ludovic Courtès) writes: > Janus Troelsen skribis: > >> I know FreeBSD is not officially supported, but I don't see why it shouldn't >> be? Many GNU tools work on FreeBSD. > > Guix depends on the availability of the GNU C Library, with either the > Linux-libre kernel or the Hurd.

bug#21288: Qt's bundled libraries must not be used

Hi Andreas, Andreas Enge writes: > Commit bc554b4 compiles qt-5 with the system harfbuzz and removes a bundled > copy from our source code (the one called harfbuzz-ng; strangely, there is > another one, called harfbuzz, without which the package does not compile). > > Commit 9c32e1f removes the

bug#21620: tests/mpz/reuse intermittently fails on armhf-linux-gnu

[removed t...@gmplib.org and gmp-b...@gmplib.org from the CC list] l...@gnu.org (Ludovic Courtès) writes: > t...@gmplib.org (Torbjörn Granlund) skribis: > >> This is most surely a hardware problem. The most common such problem is >> a bad RAM chip. > > OK, I’ll see if I can reproduce it on anoth

bug#21620: tests/mpz/reuse intermittently fails on armhf-linux-gnu

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> t...@gmplib.org (Torbjörn Granlund) skribis: >>> >>>> This is most surely a hardware problem. The most common such problem is &g

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