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

Andreas Enge writes: > On Wed, Oct 07, 2015 at 08:45:09AM -0400, Mark H Weaver wrote: >> When used as a build slave, the Novena is prone to overheating. The >> best solution is to add a fan. In the meantime, I've disabled 2 out of >> the 4 cores on hydra-slave1 us

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

Andreas Enge writes: > On Wed, Oct 07, 2015 at 10:32:43PM +0200, Ludovic Courtès wrote: >> Do you think it’s a likely problem? Andreas, could you try again on >> your Novena with 2 cores turned off? > > I have trouble believing the explanation of overheating. The gmp test > suite is carried out

bug#21694: 'clone' syscall binding unreliable

l...@gnu.org (Ludovic Courtès) writes: > Looking at (guix build syscalls) though, I see an ABI mismatch between > our definition and the actual ‘syscall’ C function, and between our > ‘clone’ definition and the actual C function. Good catch! However, please see below. > This leads to the attach

bug#21694: 'clone' syscall binding unreliable

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: > > [...] > >>> ;; The libc interface to sys_clone is not useful for Scheme programs, so >>> the >>> -;; low-level system call is w

bug#21924: "make check" fails: "guix package: error: socket: Protocol not supported"

close 21924 thanks Chris Marusich writes: > 2abcc93 This was a failed first attempt to report the same bug as . Closing this one. Thanks, Mark

bug#21987: Version 0.9 Fails to Compile on Raspbian

l...@gnu.org (Ludovic Courtès) writes: > (Please keep 21...@debbugs.gnu.org Cc’d.) > > Martin Vahi skribis: > >> checking build system type... armv6l-unknown-linux-gnueabihf >> checking host system type... armv6l-unknown-linux-gnueabihf > > [...] > >> checking for the Guix system type... armhf-li

bug#22088: Non-deterministic daemon protocol errors

Since updating my guix client (but not yet my server) to include the recent commits related to the protocol update, I'm seeing these errors non-deterministically while building things. Retrying usually results in success. mhw@jojen:~/guix$ guix build -K openssl --cores=1 substitute: updating list

bug#22049: Test failure of ilmbase-2.2.0 on i686-linux (testBoxAlgo.cpp)

[added 22...@debbugs.gnu.org to the CC list] Leo Famulari writes: > Greetings from Guix! [0] > > We're having trouble building ilmbase-2.2.0 for the i686 architecture on > Linux, with gcc-4.9.3. > > The build process fails during testing. Specifically, it fails > testBoxAlgo, like this: > > Imat

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

In the last month, 'python-statsmodels' has failed its test suite 5 times in the same place: --8<---cut here---start->8--- statsmodels.regression.tests.test_lme.TestMixedLM.test_r(False, False, 8) ... ok statsmodels.regression.tests.test_lme.TestMixedLM.test_r(F

bug#22126: wireless-regdb: non-deterministic build failures on armhf

In the last three weeks, wireless-regdb has failed to build 4 times on armhf, although after restarting, the same derivations have later been built successfully. The last two failures were for the following derivation, which finally succeeded on the third try: http://hydra.gnu.org:3000/build/86

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

Both python-statsmodels and python2-statsmodels sometimes fail on i686 during the "statsmodels.tsa.tests.test_arima.test_start_params_bug" test with the error "LinAlgError: SVD did not converge". Here's an excerpt of one such error: --8<---cut here---start->8--

bug#22125: bless: non-deterministic failure on x86_64

The following build of 'bless' on x86_64, the most recent at the time of this writing, failed by timeout after 1 hour of silence: http://hydra.gnu.org/build/864760#tabs-buildsteps Here's the tail of the failed build log: --8<---cut here---start->8--- startin

bug#22124: libical: Non-deterministic build failures

In the last month, libical has non-deterministically failed twice, once on i686 and once on mips64el, with the same error in the same place: --8<---cut here---start->8--- [ 19%] Building C object src/libicalss/CMakeFiles/icalss-static.dir/icalcalendar.c.o cd /t

bug#22129: python-matplotlib: Non-deterministic build failures on armhf

Over the last month, the 'python-matplotlib' build on armhf has failed non-deterministically 4 times due to timeout (1 hour of silence) in the same place: --8<---cut here---start->8--- phase `install' succeeded after 71.4 seconds starting phase `install-doc' Run

bug#22130: dmd: respawn test failures

In DMD, the "respawn.sh" test fails quite consistently on armhf, and has sometimes failed on mips64el and x86_64 as well. Here's a copy of test-suite.log from a recent failure on armhf: --8<---cut here---start->8--- === GNU dm

bug#22131: gtk-doc fails to build on all platforms

The gtk-doc builds started failing on all platforms when the following security updates were added: --8<---cut here---start->8--- * 3470fe0..: Mark H Weaver 2015-11-16 gnu: libsndfile: Add fixes for CVE-2014-9496 and CVE-2015-7805. * b4a88dc..: Mark H

bug#22251: ghc-memory test suite fails on i686

The ghc-memory test suite has failed several times in a row on i686 with the same errors: http://hydra.gnu.org/build/893578 memory [...] encoding Bytes [...] BASE32 [...] decode-KAT [...] 11: FAIL

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

Christopher Allan Webber writes: > I recently installed GuixSD on the laptop I got fresh from Minifree. I > was happy to see how much worked, but I've noticed a bug that occurs in > GuixSD but not in Debian. > > In Debian I can set the hardware clock (with `hwclock -w`) and if I > reboot back in

bug#22408: wget rejects Let's Encrypt certs, although Icecat accepts them

On recent GuixSD, IceCat accepts the Let's Encrypt certificate from https://git.dthompson.us/, but 'wget' rejects it: mhw@jojen:~$ wget https://git.dthompson.us/presentations.git/blob/HEAD:/guix-blu-2016-01-20.pdf --2016-01-19 09:23:23-- https://git.dthompson.us/presentations.git/blob/HEAD:

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

Christopher Allan Webber writes: > From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 > From: Christopher Allan Webber > Date: Sun, 17 Jan 2016 20:34:25 -0800 > Subject: [PATCH] gnu: Add linux-libre-4.2.5 > > This older version of linux-libre is being added because it was fou

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Christopher Allan Webber writes: >> >>> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >>> From: Christopher Allan Webber >>> Date: Sun, 17 Jan 2016 20:34

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

Hi, Christopher Allan Webber writes: > Ludovic Courtès writes: > >> Mark H Weaver skribis: >> >>> Christopher Allan Webber writes: >>> >>>> From e60db8323c57ec5c44de7c99cee8e4e353ff Mon Sep 17 00:00:00 2001 >>>> From: Christop

bug#22548: Kernel panic after system reconfiguration

Albin writes: > Hi again, > > I got rid of the kernel panic by removing the following from the config > and reconfiguring (as suggested by Mark Weaver): > >> (swap-devices '("/swapfile")) > > It would be nice to be able to enable swap again though. On my system it > needs to be done with a swap f

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

gnupg-2.1.11 on x86_64 failed its tests many times on Hydra: http://hydra.gnu.org:3000/build/990803#tabs-buildsteps On all other architectures (i686, armhf, mips64el) it succeeded on the first try. So far, we've heard no reports of it failing for anyone else on x86_64. Ludovic built it 3 time

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

Mark H Weaver writes: > gnupg-2.1.11 on x86_64 failed its tests many times on Hydra: > > http://hydra.gnu.org:3000/build/990803#tabs-buildsteps > > On all other architectures (i686, armhf, mips64el) it succeeded on the > first try. So far, we've heard no reports of it

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

Eric Bavier found this: https://bugs.gnupg.org/gnupg/issue2229 Title: "make check 14 0f 35 tests failed" Mark PS: It doesn't load in our IceCat with the error "Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)", b

bug#22274: GuixSD resets hardware clock (on Lenovo x200 with libreboot)

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Christopher Allan Webber writes: >> >>> Ludovic Courtès writes: >>> >>>> Mark H Weaver skribis: >>>> >>>>> Christopher Allan Webber writes: >>

bug#22572: Handling of system 'locale' field needs improvement

Multiple users on #guix have been bitten by the following error message: guix system: error: system locale lacks a definition and even several seasoned developers on #guix didn't know the answer. At minimum, the error message should be improved to point to the relevant documentation. Better y

bug#22588: root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

I've been bitten by this once before, and a user on #guix did as well. When there are problems in the root filesystem that fsck doesn't want to fix automatically, the user is dumped into a guile prompt where PATH is not set, and it's very inconvenient to run fsck manually. This is what I just sugg

bug#22588: root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I've been bitten by this once before, and a user on #guix did as well. >> When there are problems in the root filesystem that fsck doesn't want to >> fix automatically, the user is dumped

bug#22588: root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> l...@gnu.org (Ludovic Courtès) writes: > > [...] > >>> Currently there’s no Bash in the initrd. Should we add one? Our >>> ‘bash-static’ package takes 1.4 MiB (I don’t think we can make

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

d now they have a fix in their repo. I've attached a patch to Guix which adds this upstream patch. Eric, would you be willing to test it and see if it fixes the problem for you? Mark >From bd025179efca777678f39a782f851e07719db05f Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date:

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

Leo Famulari writes: > On Fri, Feb 12, 2016 at 06:22:46PM -0500, Mark H Weaver wrote: >> l...@gnu.org (Ludovic Courtès) writes: >> >> > Eric Bavier skribis: >> > >> >>> > * With 14 test failures. This happened at least twice, on >> >

bug#22558: gnupg-2.1.11 on x86_64 failed its tests many times on Hydra

Leo Famulari writes: > On Fri, Feb 12, 2016 at 10:02:32PM -0600, Eric Bavier wrote: >> But I had to add "#:use-module (gnu packages)" to the >> gnu/packages/gnupg.scm before it would build, otherwise "could not >> find symbol search-path". > > Weird, that did not happen to me when building from 3

bug#22653: Vigra fails to build, needed for Libreoffice

Vigra, required libreoffice, now consistently fails to build on hydra: http://hydra.gnu.org/job/gnu/master/vigra-1.10.0.x86_64-linux http://hydra.gnu.org/build/1008323 Mark

bug#22659: Collision of /bin/ld

Leo Famulari writes: > Invoking `guix environment guix`, I found this collision alarming. Do > you think it's a problem? > > I ran `guix pull` yesterday or the day before. Is there a way to > determine the git commit that corresponds with this version of Guix? > > I added the line breaks. > > war

bug#22753: Shepherd: Problem reconfiguring from bare-bones to desktop

Recently, I temporarily switched to a minimal text-only configuration of GuixSD (in order to avoid using glibc without the CVE-2015-7547 fix). When I later build a full desktop system and reconfigured, several errors were reported by shepherd while attempting to update the running services, and so

bug#22809: qemu-image builds failing

The qemu-image builds are failing on Hydra in a different way than I've seen before. http://hydra.gnu.org/build/1045494 http://hydra.gnu.org/build/1045589 Here's the tail of the x86_64 failure log: --8<---cut here---start->8--- ERROR: In procedure copy-fil

bug#22826: gnupg test failure

Danny Milosavljevic writes: > gnupg fails its tests: > > ... > note: keeping build directory `/tmp/guix-build-gnupg-2.1.11.drv-0' > builder for `/gnu/store/p91ba6zl4d8gr5ixfqxn8ixhrv13kdv9-gnupg-2.1.11.drv' > failed with exit code 1 > cannot build derivation > `/gnu/store/ixcbdqm2xvclfnz4d25nv5

bug#22826: gnupg test failure

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Danny Milosavljevic writes: >> >>> gnupg fails its tests: >>> >>> ... >>> note: keeping build directory `/tmp/guix-build-gnupg-2.1.11.drv-0' >>> build

bug#22876: Python can't use https with recent grafts

In brief, I believe this is fixed by commit 03a0e682a8 on master. See below for details. Christopher Allan Webber writes: > Christopher Allan Webber writes: > >> Most of Guix seems to be working just fine with the grafts support and >> grafting of openssl. However, unlike most grafts that will

bug#22990: Grafts leads to inefficient substitute info retrieval

l...@gnu.org (Ludovic Courtès) writes: > Alex Kost skribis: > >> Ludovic Courtès (2016-03-11 19:52 +0300) wrote: >> >>> As of right now (v0.9.0-2007-g66a30a3), ‘graft-derivation’ works either by: >>> >>> 1. Fetching substitute info about the things being built so that it >>> can determine

bug#23132: Grafted system retains references to original store items

While testing my preliminary work on grafting improvements, I discovered that my current system is retaining references to the original flawed openssl-1.0.2f. One path of references goes like this: /gnu/store/pnbljdp1hpsvnbgqfl8bws7lpj7pm8cb-system -> /gnu/store/bzdhckvz4sms136fw64pvyhajawdb8r

bug#23132: Grafted system retains references to original store items

I should have also included the guile-builder used by the gnome-session grafting derivation. Here it is: /gnu/store/60a5vinj56nhxzszfyayjjy61b303c8r-gnome-session-3.18.1.2-guile-builder contains: (begin (use-modules (guix build graft) (guix build utils) (ice-9 match)) (define %output (getenv "

bug#23132: Grafted system retains references to original store items

Here's how to reproduce exactly what I'm seeing: Checkout commit ffc13e753b37adb694de1d26f3ea51cf0796a8a2, which is the commit on 'master' immediately before the merge with 'security-updates'. >From that commit, build 'gnome-session'. In my case, I'm doing this on i686-linux, and here's what I s

bug#23132: Grafted system retains references to original store items

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> The gnome-session store item above was created by a grafting derivation, >> and all of the ones that follow (starting with glib-2.46.1-bin) are >> ungrafted derivations. The grafting derivation for gn

bug#23364: python-statsmodels build failures

python-statsmodels builds have been failing consistently on Hydra since about February 10. http://hydra.gnu.org/job/gnu/master/python-statsmodels-0.6.1.x86_64-linux/all http://hydra.gnu.org/job/gnu/master/python-statsmodels-0.6.1.i686-linux/all http://hydra.gnu.org/job/gnu/master/python2-statsmode

bug#23433: Timeout in grafts

Leo Famulari writes: > On Tue, May 03, 2016 at 03:13:32PM +0200, Andreas Enge wrote: >> Hello, >> >> when grafting texlive-texmf on my Novena, the build times out after an hour, >> even when I add "--timeout=7". This is even more annoying since the >> package cannot be substituted any more.

bug#23811: shepherd: tests/respawn-throttling.sh fails sporadically

On core-updates, both shepherd and dmd failed on i686 and armhf in the same test: tests/respawn-throttling.sh in shepherd: http://hydra.gnu.org/build/1241860 (shepherd-i686) http://hydra.gnu.org/build/1246005 (shepherd-armhf) and tests/respawn.sh in dmd: http://hydra.gnu.org/build/1245596

bug#24026: librecad and dealii depend on relocated muparser source code repo

The dealii, dealii-openmpi, and librecad packages are now failing due to a missing dependency: svn: E160013: Unable to connect to a repository at URL 'http://muparser.googlecode.com/svn/trunk' svn: E160013: '/svn/trunk' path not found It seems that the muparser developers have switched to gi

bug#24027: update-package-list script no longer running on hydra

The package list and package issues pages are no longer being updated, since the hydra RAID array failure. Mark

bug#24026: librecad and dealii depend on relocated muparser source code repo

Leo Famulari writes: > On Tue, Jul 19, 2016 at 12:42:57PM -0400, Mark H Weaver wrote: >> The dealii, dealii-openmpi, and librecad packages are now failing >> due to a missing dependency: >> >> svn: E160013: Unable to connect to a repository at URL >> 'ht

bug#24053: guix download file:// fails with a ~2 GB file on i686

On my i686 GuixSD machine, the following command consistently fails: mhw@jojen:~$ guix download file:///home/mhw/texlive-20160523b-texmf.tar.xz guix download: error: sendfile: Broken pipe The file is 2071190200 bytes, which is about 73 MiB less than 2 GiB. I have 2 GiB of RAM and 4 GiB of swa

bug#24053: guix download file:// fails with a ~2 GB file on i686

Mark H Weaver writes: > On my i686 GuixSD machine, the following command consistently fails: > > mhw@jojen:~$ guix download file:///home/mhw/texlive-20160523b-texmf.tar.xz > guix download: error: sendfile: Broken pipe > > The file is 2071190200 bytes, which is about 73 M

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

Danny Milosavljevic writes: > Hi, > >> I know more people than just me are using libreboot here, do you have >> any problems with suspend and recovery? > > I have a X200 and some time after waking up from suspend on the first > larger disk access it hangs, losing all the dirty sector payload in >

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

ng0 writes: > 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? >>

bug#24194: GUIX gc - add warning

"J. Eppler" writes: > I used GUIX for the first time and invoked: guix gc. The command deleted > all my bootstrap files (gcc, binutils, findutils etc.). There should be > a warning added to the manual page: > > https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-gc.html > > I was act

bug#23881: System building failure

l...@gnu.org (Ludovic Courtès) writes: > Kooda skribis: > >> Running `guix system build /etc/config.scm` fails with the following error: >> >> Backtrace: [...] >> In guix/scripts/system.scm: >> 404: 1 [#] >> In unknown file: >>?: 0 [string-append "--root=" ...] >> >> ERROR: In procedure stri

bug#24279: Bug in xterm and/or fontconfig

Alex Kost writes: > John Darrington (2016-08-21 16:18 +0300) wrote: > >> In GuixSD: >> >> guix package -i xterm strace >> strace xterm >> >> xterm starts as it should, however observe many failed calls similar to: >> >> open("/gnu/store/b484nvn9nnr3ddclpz2fma9yxmimg2jj-fontconfig-2.11.94/lib/l

bug#24703: fontconfig keeps obfuscated reference to itself, not grafted

After running "guix gc", I've found that my fonts are broken. Gnome-terminal, Xfce4-terminal, and xterm are no longer able to find my preferred "Dejavu Sans Mono" font. IceCat also uses a different selection of fonts. Of the programs I've tried, only Emacs is able to find them. The failing prog

bug#24703: fontconfig keeps obfuscated reference to itself, not grafted

Mark H Weaver writes: > It turns out there's an obfuscated self-reference to fontconfig's store > directory. Here's an excerpt of the output of "hexdump -C > libfontconfig.so.1.9.0": > > cca0 00 48 b9 2f 67 6e 75 2f 73 74 6f c6 40 48 00 45 |.H./gnu

bug#24703: fontconfig keeps obfuscated reference to itself, not grafted

Mark H Weaver writes: > Mark H Weaver writes: > >> It turns out there's an obfuscated self-reference to fontconfig's store >> directory. Here's an excerpt of the output of "hexdump -C >> libfontconfig.so.1.9.0": >> >> cca0 00 48

bug#24703: Store references in 8-byte chunks in compiled code

Mark H Weaver writes: > Mark H Weaver writes: > >> Mark H Weaver writes: >> >>> It turns out there's an obfuscated self-reference to fontconfig's store >>> directory. Here's an excerpt of the output of "hexdump -C >>> libfontc

bug#24703: Store references in 8-byte chunks in compiled code

The 8-byte chunks may appear out of order. For example, in 'bash-static' we have this reference to: /gnu/store/7z3hpynjsbidxkq78xi5qi6lbcm8ndhp-glibc-intermediate-2.23 where the chunks are found in the following order: 1_/gnu/sto 2_ynjsbidx 3_re/7z3hp 4

bug#24703: Store references in 8-byte chunks in compiled code

Here's a complex example of a reference to: /gnu/store/80m11l8km7bwi9iljfyr82hmscaq4xk2-unixodbc-2.3.4/etc This also illustrates what can happen near the end of a reference. In this case, the last two characters are found at the end, within a 'mov' instruction, and the previous 4 characters ar

bug#24703: Store references in 8-byte chunks in compiled code

Here's what happens with a variant of 'unixodbc' with one character removed from its name, to make an odd number of characters. The last character 'c' is all by itself. The chunks of the reference /gnu/store/il1bn7n0l4yj3idrii23fhvzg4nn939i-unxodbc-2.3.4/etc are found in the following order:

bug#24703: Re: bug#24703: Store references in 8-byte chunks in compiled code

Török Edwin writes: > On 2016-10-16 22:04, Ludovic Courtès wrote: >> Mark H Weaver skribis: >> >>> When grafting, how will we achieve confidence that we've found the >>> correct occurrence of the last character? I think we will have to give >>>

bug#24712: Grafting of multiple-output dependencies is mishandled

l...@gnu.org (Ludovic Courtès) writes: > l...@gnu.org (Ludovic Courtès) skribis: > >> Mark reported on IRC that gnome-session, as of v0.11.0-1639-g34f9582, >> refers to the grafted “out” of glib, but at the same time refers to the >> *ungrafted* “bin” output of glib: >> >> $ ./pre-inst-env guix bu

bug#24703: Store references in 8-byte chunks in compiled code

l...@gnu.org (Ludovic Courtès) writes: > Török Edwin skribis: > >> On 2016-10-16 22:04, Ludovic Courtès wrote: >>> Mark H Weaver skribis: >>> >>>> When grafting, how will we achieve confidence that we've found the >>>> correct occu

bug#24832: Hydra generates faulty derivation for gettext-boot0 on MIPS

Almost all of the derivations being generated on Hydra for MIPS on the 'core-updates' branch differ from what is generated locally by guix on a mips64el-linux machine. The differences go at least as far back as 'gettext-boot0', where Hydra generates: /gnu/store/yzsx42kva1pgj96n9yir7j6xx0ndp7is-

bug#24832: Hydra generates faulty derivation for gettext-boot0

Mark H Weaver writes: > Almost all of the derivations being generated on Hydra for MIPS on the > 'core-updates' branch differ from what is generated locally by guix on a > mips64el-linux machine. The differences go at least as far back as > 'gettext-boot0', w

bug#24833: Hydra ignores MIPS-specific patch for Mesa on core-updates

Commit f1267c872fcaed6c53d43b3ff51abb726f7418d6 on core-updates added a patch to Mesa on MIPS only, in order to prevent unnecessary rebuilds on other systems. 'guix' running on a MIPS system generates a derivation that applies the patch, but the derivation generated for MIPS on Hydra omits the pat

bug#24703: Store references in 8-byte chunks in compiled code

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Unfortunately, it is too widespread. As I just pointed out in >> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24712#13 >> >> Among the many packages that include these obfuscated stor

bug#24832: Hydra generates faulty derivation for gettext-boot0

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > The bug stems from ‘ld-wrapper-boot0’ and was introduced in > d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that > ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine > that builds the derivation i.e., hydra.gnu.org

bug#24833: Hydra ignores MIPS-specific patch for Mesa on core-updates

l...@gnu.org (Ludovic Courtès) > Mark H Weaver skribis: > >> Commit f1267c872fcaed6c53d43b3ff51abb726f7418d6 on core-updates added a >> patch to Mesa on MIPS only, in order to prevent unnecessary rebuilds on >> other systems. 'guix' running on a MIPS system gene

bug#24948: Illegible GRUB menu

Hi Leo, Leo Famulari writes: > On my Thinkpad x200s running GuixSD, the graphical GRUB menu is > scrambled and illegible. I've attached a photograph of the problem. [...] > This is not a recent regression; I've been working around it with the > diff below for a few months now. A few months ago w

bug#25080: When removing a user, 'guix system reconfigure' does not remove the user's home directory

Hi, Chris Marusich writes: > If you add a user to your operating system configuration file, > reconfigure, remove the user, and reconfigure again, then the user's > home directory will remain. I expected it to be deleted when I > reconfigured the second time. > > Is this expected behavior? I th

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

l...@gnu.org (Ludovic Courtès) writes: > Here’s a proposed patch that follows your suggestion, Mark, but places > an upper bound on the number of directory entries loaded in memory. > > On my laptop, which has ~500k entries in /gnu/store/.links, the result > is something like this (notice the inod

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

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> I think we should sort the entire directory using merge sort backed to >> disk files. If we load chunks of the directory, sort them and process >> them individually, I expect that this will in

bug#25192: guix-0.11.0 fails to compile on modern GuixSD system

I tried to compile a freshly unpacked guix-0.11.0 tarball on my x86_64 GuixSD system, which is running recent 'master'. Here's what happens: --8<---cut here---start->8--- mhw@jojen:~/guix-0.11.0$ ./configure --prefix= --with-libgcrypt-prefix=/gnu/store/4pnp5sc

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

Do as you wish. I don't have time to continue discussing this. Mark

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

l...@gnu.org (Ludovic Courtès) writes: > I did some measurements with the attached program on chapters, which is > a Xen VM with spinning disks underneath, similar to hydra.gnu.org. It > has 600k entries in /gnu/store/.links. I just want to point out that 600k inodes use 150 megabytes of disk sp

bug#25192: guix-0.11.0 fails to compile on modern GuixSD system

l...@gnu.org (Ludovic Courtès) writes: > Does it succeed if you run “make” again? Sorry, I forgot to mention in my previous message that I ran 'make' four times. Search for "$ " in the transcript to find the prompts. Since then, I've tried twice more, and it failed each time. > That sounds to m

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

I apologize for losing my patience earlier. Mark

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

l...@gnu.org (Ludovic Courtès) writes: > Linux-libre 4.9.0 triggers this problem on i686 (quoting > ): > > loading kernel modules... > [6.085552] libahci: disagrees about version of symbol mcount > [6.085978] libahci: Unknown symbol mcount

bug#25631: epiphany: Ad blocker does not work.

Ricardo Wurmus writes: > “g_file_new_for_uri” triggers the download via dbus, so it must be made > aware of the dbus session. When running “dbus-launch epiphany” the > error changes to > > ** (WebKitWebProcess:30867): WARNING **: Error retrieving adblock filter: > HTTP Error: TLS/SSL suppor

bug#25953: [PATCH] gnu: mesa: Build LLVM Gallium drivers.

Ricardo Wurmus writes: > Fixes . > > * gnu/packages/gl.scm (mesa)[inputs]: Add llvm. > [arguments]: Build LLVM Gallium drivers. I'm uncomfortable adding llvm as a requirement for our most minimal X11 system, for several reasons. Can we find a way to make this optiona

bug#25852: Users not updating their installations of Guix

l...@gnu.org (Ludovic Courtès) writes: > Leo Famulari skribis: > >> In my opinion, the recent bug #25775 (Can't install packages after guix >> pull) [0] exposed a sort of meta-bug: there are a significant number of >> users who were still using the guix-daemon from 0.10.0. >> >> It seems unlikely

bug#25953: [PATCH] gnu: mesa: Build LLVM Gallium drivers.

Ricardo Wurmus writes: > Mark H Weaver writes: > >> Ricardo Wurmus writes: >> >>> Fixes <https://bugs.gnu.org/25953>. >>> >>> * gnu/packages/gl.scm (mesa)[inputs]: Add llvm. >>> [arguments]: Build LLVM Gallium drivers. >> >

bug#25852: Users not updating their installations of Guix

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> We could simply issue a warning if the version of guix currently in use >> is more than N hours old, on the assumption that after N hours it's >> likely to be stale. The default value of N might

bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos

l...@gnu.org (Ludovic Courtès) writes: > Hi again! > > Until now hydra.gnu.org was using Hydra (the software) to serve not only > the Web interface but also all the .narinfo and /nar URLs (substitute > meta-data and substitutes). > > Starting from now, hydra.gnu.org directs all .narinfo and corres

bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos

Hi, Tobias Geerinckx-Rice writes: > On 23/03/17 19:36, Mark H Weaver wrote: >> One question: what will happen in the case of multiple concurrent >> requests for the same nar? Will multiple nar-pack-and-bzip2 processes >> be run on-demand? > > I think this used to be

bug#26407: test.dicod fails after ~20 hours of failed connection attempts

Recently, test.dicod has started failing after taking ~20 hours of build-slot time, mostly filled with "Connection refused" errors: https://hydra.gnu.org/job/gnu/master/test.dicod.x86_64-linux Here's a build that recently failed after 20 hours: https://hydra.gnu.org/build/1974589 and here's

bug#26598: coreutils: 'patch-cut-test' phase now failing on armhf

l...@gnu.org (Ludovic Courtès) writes: > civodul pushed a commit to branch core-updates > in repository guix. > > commit d1e3f59c9b8d1be79eded04fe23cceb56b4372f0 > Author: Ludovic Courtès > Date: Sat Mar 25 23:28:54 2017 +0100 > > gnu: coreutils: Patch 'cut' unit test on ARM. > > F

bug#26705: guix publish daemon on Hydra became dysfunctional; needed restart

While trying to update my GuixSD system in the last hour, I found that every attempt by the substituter to download NARs resulted in a 500 "Internal Server Error": --8<---cut here---start->8--- mhw@jojen ~$ guix package -u substitute: ^Msubstitute: updating list

bug#26201: hydra.gnu.org uses ‘guix publish’ for nars and narinfos

Reviving an old thread... Tobias Geerinckx-Rice writes: >> IMO, the best solution is to *never* generate nars on Hydra in response >> to client requests, but rather to have the build slaves pack and >> compress the nars, copy them to Hydra, and then serve them as static >> files using nginx. > >

bug#26734: Snippets (even empty ones) of tar sources reset the timestamps of all files

l...@gnu.org (Ludovic Courtès) writes: > BTW, what timestamps to we put on the modified files? We want that to > be deterministic so we cannot use the build time. We cannot use a date > in the future, either. We cannot use Jan. 1 1970 either because that > means that modified files may now be o

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

The error message is: ERROR: In procedure GNU with Linux-Libre 4.11 (beta): ERROR: Wrong type to apply: "GNU with Linux-Libre 4.11 (beta)" Here's the head and tail of the output of the evaluator. Unfortunately, the relevant git commit is not printed. Mark --8<---cut here

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

Mathieu Othacehe writes: > Hi Mark, > > This problem should be resolved by make clean-go && make, see here : > > https://lists.gnu.org/archive/html/guix-patches/2017-05/msg00152.html As far as I know, *every* evaluation on Hydra is a clean build from scratch, so I'm not sure how to proceed. In

bug#26809: 08/09: services: nscd: Create /etc/resolv.conf if it does not exist.

l...@gnu.org (Ludovic Courtès) writes: > civodul pushed a commit to branch master > in repository guix. > > commit 49f9d7f697d19870f01104cdb6a90a32aea87679 > Author: Ludovic Courtès > Date: Tue May 2 12:21:31 2017 +0200 > > services: nscd: Create /etc/resolv.conf if it does not exist. >

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