Hello all,
I've attached two patches. The first arranges to make sure that
'pre-inst-env' will be rebuilt when 'pre-inst-env.in' is modified.
The second patch is the main subject of this email. It reworks the
shell script headers at the top of 'guix-package' and the other scripts
to avoid modif
macs and
> paredit as if it were in the main body of the file.
>
> What do you think?
And here are the actual patches (oops :)
Mark
>From 172011c586a96cd15e6401cf813fd6d6ea59b355 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Mon, 11 Feb 2013 19:23:20 -0500
Subject: [PAT
Here's an improved version of the second patch. There's no functional
difference, but the code is easier to read IMO.
Mark
>From b1ea7f6ab01fb5c1ae1638315dad3fc8903682dc Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Mon, 11 Feb 2013 19:13:32 -0500
Subject: [PATCH 2/2]
.
Comments and suggestions solicited.
Mark
>From 3436dd9460e1b7b85584a96df3bb57b022629651 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 12 Feb 2013 01:24:21 -0500
Subject: [PATCH] Implement guix-package --upgrade.
* guix-package.in (%options): Add -u/--upgrade option.
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>> + (upgrade (if (null? upgrade-regexps)
>> + '()
>> + (filter-map (match-lambda
>> +
l...@gnu.org (Ludovic Courtès) writes:
> Honestly, I wouldn’t worry about the propagation of $GUILE_LOAD_PATH &
> co. to subprocesses, because we know there’s none anyway.
That policy will lead to future where libguile-using programs break in
random ways when they happen to be subprocesses of each
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Okay. I was relying on the fact that attempts to install a derivation
>> that's already installed will ultimately be ignored, and my (admittedly
>> simple) tests seem to suggest that it wor
I wrote:
> Would "guix-package -i guile" ever choose guile-1.8.8 over guile-2.0.7
> if the latter was available? Does it not automatically choose the
> newest available version?
Having now looked at the code, I see that it does not.
My latest upgrade implemention assumed that it did, so I'll hav
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>> Honestly, I wouldn’t worry about the propagation of $GUILE_LOAD_PATH &
>>> co. to subprocesses, because we know there’s none anyway.
>>
inherited from one package to another. For example
this happens with the 'gcc-boot0' and 'gcc-4.7' packages in (gnu
packages base).
What do you think?
Mark
>From 1d30931a28af4ed6aa747a05bc3540e335ce1b32 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 12 Feb 2013
Nikita Karetnikov writes:
> w3m raises the following error:
>
> istream.h:23:8: error: redefinition of 'struct file_handle'
The issue here is that glibc started using "struct file_handle", which
conflicts with w3m's prior use of the same name. You shouldn't need a
patch for this. Just replace "
Nikita Karetnikov writes:
> Also, I'm not sure what license should be used. Should we create a new
> one?
>
> This page [2] states that w3m is under MIT, which is an ambiguous name
> of the Expat License [3].
That's incorrect. While it is true that the Expat license is sometimes
ambiguously re
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>> Honestly, I wouldn’t worry about the propagation of $GUILE_LOAD_PATH &
>>> co. to subprocesses, because we know there’s none anyway.
>
ugh I'm not aware of any functional problems with this code, I'm
not entirely pleased with its organization. Nonetheless, I wanted to
make it available for early testing and comments.
I welcome suggestions on how to improve this code.
Mark
>From 16cf486524502c1caebbd8831a8f6802640ae
inary version of my upgrade patch. Here's a fixed
version.
Mark
>From fcb78e4af6d4f7304582fa2ad44eb99236b6ae23 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 12 Feb 2013 20:29:30 -0500
Subject: [PATCH] Inhibit duplicates in fold-packages.
* gnu/packages.scm (fold2):
Sorry, that patch had a problem in guix-build. Here's a fixed version.
Mark
>From c3820d291cdc40cc58abebf8ca10332e51ebead1 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Tue, 12 Feb 2013 01:24:21 -0500
Subject: [PATCH] Build newest versions unless specified, and implement
upgra
Hi Ludovic,
In commit d9d466ddff2091f4b1f94599335b5947a17def2c, you added the
following packages:
guile-reader-for-guile-1.8.8
guile-reader-for-guile-2.0.7
The "1.8.8" and "2.0.7" are actually part of the package names (both of
these packages are at version 0.6).
Unfortunately, this means t
l...@gnu.org (Ludovic Courtès) writes:
> Andreas Enge skribis:
>
>> Additionally, the file matrix.c looks non-free to me:
>> "3. No charge is made for this software or works derived from it.
>> This clause shall not be construed as constraining other software
>> distributed on the
l...@gnu.org (Ludovic Courtès) writes:
> Other than that, please push!
Okay, I incorporated your suggestions and pushed it.
Thanks,
Mark
aking 'guix-FOO' a
symlink to 'guix'.
Then we can move all the scripts into guix/scripts/, and remove the
boilerplate shell code from the top of all them. They become pure guile
modules. No more shell at all.
What do you think?
Mark
#!@GUILE@ -s
-*- scheme -*-
!#
;;;
Andreas Enge writes:
> How about naming them "guile-reader" with a version number of
> 0.6-1.8.8 and 0.6-2.0.7, or the other way round 1.8.8-0.6 and
> 2.0.7-0.6?
We can't do this, because it would break the version-number comparison
logic. One option would be to change the dash to something else
Hi Ludovic,
Thanks for the quick feedback. I've attached a new patch that
incorporates almost all of your suggestions, and also includes a basic
find/replace in the manual (though more work is needed there).
> • Remove the ‘guix-’ prefix from module names, so
> guix/scripts/build.scm inste
l...@gnu.org (Ludovic Courtès) writes:
> Andreas Enge skribis:
>
>> Additionally, the file matrix.c looks non-free to me:
>> "3. No charge is made for this software or works derived from it.
>> This clause shall not be construed as constraining other software
>> distributed on the
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> I asked RMS, and he thinks that this clause is okay because it says a
>> "distribution fee" is okay and does not limit the amount. Thus, what it
>> prohibits is a fee for the right to use the
Wow. This is very exciting work, Ludovic.
You make our lives brighter :)
Mark
Hello all,
In git, the five scripts 'guix-package', 'guix-gc', 'guix-build',
'guix-download' and 'guix-import' have been replaced with the single
script 'guix'. The new usage replaces 'guix-package' with 'guix
package', and more generally 'guix-COMMAND' with 'guix COMMAND'.
After pulling, please
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Andreas Enge writes:
>>> How about naming them "guile-reader" with a version number of
>>> 0.6-1.8.8 and 0.6-2.0.7, or the other way round 1.8.8-0.6 and
>>> 2.0.7-0.6?
>>
Nikita Karetnikov writes:
> This commit is buggy.
I don't see how this could have anything to do with my commit. (gnutls)
needs to be in Guile's load path when (guix build download) is compiled,
and in your case it apparently isn't. That must be a problem with your
specific configuration. I th
Hi Ludovic,
Regarding commit a24b75d8e1753da629ecf945f4022eee4c340aed:
The built texinfo 5.0 packages contain a few uses of 'perl' that are not
pointing to a specific version in /nix/store:
./bin/pod2texi:1:#!/nix/store/777jas1fcgc38hmvq6lq1sa9k67f10kl-coreutils-8.20/bin/env
perl
./bin/texi2dvi
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> The built texinfo 5.0 packages contain a few uses of 'perl' that are not
>> pointing to a specific version in /nix/store:
>
> Yes, I know, but since in ‘core-updates’ we’ll change ‘patch
l...@gnu.org (Ludovic Courtès) writes:
> carl hansen skribis:
>
>> FYI When I recently upgraded to texinfo-5, I had to make a soft link
>> ln -s texi2any makeinfo
>> The link was supposed to be made in the package, but it wasn't. It
>> might be relevant to you.
>
> I just installed (from Guix)
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> The built texinfo 5.0 packages contain a few uses of 'perl' that are not
>> pointing to a specific version in /nix/store:
>
> Yes, I know, but since in ‘core-updates’ we’ll change ‘patch
Hi Andreas,
Andreas Enge writes:
> (has-env (string-suffix? "/env" interp))
I think we might want to make this test more restrictive. I'm looking
at a package (guile-figl) that includes an 'env' script in its build
directory, analogous to 'pre-inst-env' in Guix. This makes me worry
that the te
Nikita Karetnikov writes:
> I'm attaching a patch.
>
> It's a separate file; if I add these lines
>
>#:use-module (guix packages)
>#:use-module (guix store)
>
> to 'guix/build/utils.scm', they will raise the following error on
> 'make'.
Based on the backtrace below, it looks like you tri
On my system, attempts to build hop result in the following error:
output path `/nix/store/l4jyrfyx8nr3sy6j20s8znk2aa2hpw84-hop-2.4.0.tar.gz'
should have sha256 hash `04fhy5jp9lq12fmdqfjzj1w32f7nxc80fagbj7pfci7xh86nm2c5',
instead has `1v2r4ga58kk1sx0frn8qa8ccmjpic9csqzpk499wc95y9c4b1wy3'
I trie
I recently installed a large number of packages in a single "guix
package -i" command, and in the resulting transcript I see download
progress reports interleaved with compile output, e.g.:
--8<---cut here---start->8---
gcc -DHAVE_CONFIG_H -I. -I../include -I .
Mark
>From 60b284848f722f3faa3e1a5e876b712e8b09960c Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Sun, 21 Apr 2013 02:54:56 -0400
Subject: [PATCH] gnu: gprolog: Update to 1.4.3 and download from GNU mirrors
* gnu/packages/gprolog.scm (gprolog): Update to 1.4.3.
Download from GNU mirrors.
---
gnu/packages/gprolog.scm |
Which of these can be done on master, and which should be done only on
core-updates?
gnu/packages/groff.scm:32:3: note: using groff-1.22.1 but groff-1.22.2 is
available upstream
gnu/packages/cdrom.scm:89:3: note: using xorriso-1.2.4 but xorriso-1.2.8 is
available upstream
gnu/packages/wdiff.scm:
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> On my system, attempts to build hop result in the following error:
>>
>> output path
>> /nix/store/l4jyrfyx8nr3sy6j20s8znk2aa2hpw84-hop-2.4.0.tar.
I did a clean rebuild of guix from git master (make clean; ./bootstrap;
make), and then attempted to upgrade all packages. After several
successful builds, the daemon printed this:
guix-daemon: nix/libstore/local-store.cc:526: void
nix::canonicalisePathMetaData_(const Path&, uid_t, nix::InodesSe
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> I did a clean rebuild of guix from git master (make clean; ./bootstrap;
>> make), and then attempted to upgrade all packages. After several
>> successful builds, the daemon printed this
.
What do you think?
Mark
>From 06d670d362c140e46781bc2348fb85d822986d19 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Fri, 7 Jun 2013 21:42:33 -0400
Subject: [PATCH] gnu: subversion: Download from apache archive site.
* gnu/packages/subversion.scm (subversion): Download f
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Could you rebuild the daemon with that patch, relaunch the libtool
> build, and check if it fixes the problem?
Works for me! Thanks :)
Mark
FYI, module-init-tools fails to build from source, because
module-init-tools-3.16 is no longer present on the kernel.org mirror
network. This seems rather strange, given that 3.16 was released over
two years ago, and all the earlier versions are present.
Mark
The 'module-init-tools' recipe tries to download
module-init-tools-3.16-man.tar.bz2 from distfiles.gentoo.org, but it's
no longer there.
Mark
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> This seems rather strange, given that 3.16 was released over
>> two years ago, and all the earlier versions are present.
>
> Indeed. I haven’t found anything mentioning the removal of that
> version
Using guix from git 5d9cd70721aa8256f333f76c76cecc6593b6b293, hop fails
to build from source. Here's the tail of the make transcript:
--8<---cut here---start->8---
bigloo -O2 -fsharing -Wall -wslots -L
/tmp/nix-build-hop-2.4.0.drv-0/hop-2.4.0/lib -srfi enable-
l...@gnu.org (Ludovic Courtès) writes:
> It turns out Hop & Bigloo have to be upgraded in lockstep. I believe
> a new Hop version is around the corner, so I’m tempted to just wait
> for that.
>
> WDYT?
I think we should find a solution that doesn't lead to the 'hop' build
being broken every time
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> It turns out Hop & Bigloo have to be upgraded in lockstep. I believe
>>> a new Hop version is around the corner, so I’m tempted to just
Arne Babenhauserheide writes:
> Am Samstag, 14. September 2013, 14:13:17 schrieb Ludovic Courtès:
>> > I now learned, that with guile I can use
>> >
>> > guile -L .
>> >
>> > which actually does what I need.
>> >
>> > Providing this in guix would be consistent with guile and it would make it
Hello all,
xorg-server fails to build from source. See below for the tail of the
build log. This is with aae4ead8142d4fd7c674a1e6e302f40469f878c6.
Regards,
Mark
--8<---cut here---start->8---
PASS: input
XKB: Failed to compile keymap
Keyboard initi
Mark H Weaver writes:
> xorg-server fails to build from source. See below for the tail of the
> build log. This is with aae4ead8142d4fd7c674a1e6e302f40469f878c6.
Sorry, the build log tail I posted was actually from a slightly modified
xorg.scm, where I uncommented the build inpu
David Thompson writes:
> On 10/16/2013 09:15 AM, Ludovic Courtès wrote:
>> I think you hit the /dev/shm issue described in a footnote (info "(guix)
>> Setting Up the Daemon").
>>
>> (Of course, re-open this bug if this is not the case.)
>
> That is indeed the case. /dev/shm is a symlink to /run/s
Guile 2.0.9 is unable to download:
http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.54.tar.gz
apparently because the HTTP server resets the TCP connection at the end,
instead of closing normally. Here's what I see:
--8<---cut here---start->8---
http:
In Guix, neither w3m nor emacs-w3m warn me when I visit an https URL
that uses a server certificate that is both self-signed and expired.
To make matters worse, if I ask for page information (with the '=' key),
it tells me that the certificate is valid.
On Debian, both w3m and emacs-w3m inform me
This just happened to me on core-updates, on my YeeLoong:
--8<---cut here---start->8---
mhw:~/guix-core-updates$ ./pre-inst-env guix build -S expect lua zip pth bazaar
ocaml
substitute-binary: Backtrace:
substitute-binary: In ice-9/boot-9.scm:
substitute-binary
I should have pasted the output of the 'ps' command I did immediately
after this error. Here it is:
--8<---cut here---start->8---
mhw:~/guix-core-updates$ ./pre-inst-env guix build -S expect lua zip pth bazaar
ocaml
substitute-binary: Backtrace:
substitute-bin
I just realized that my x86_64 and Loongson 3A systems have spent an
enormous amount of time building the new guix master branch based on
outdated bootstrap/*/guile-2.0.9.tar.xz.
The issue is that if you simply "git pull" from a build directory with
older versions of bootstrap/*/guile-2.0.9.tar.xz
I wrote:
> I just realized that my x86_64 and Loongson 3A systems have spent an
> enormous amount of time building the new guix master branch based on
> outdated bootstrap/*/guile-2.0.9.tar.xz.
Upon further investigation, I see that only MIPS was affected by this
problem in the recent merge of cor
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> I just realized that my x86_64 and Loongson 3A systems have spent an
>> enormous amount of time building the new guix master branch based on
>> outdated bootstrap/*/guile-2.0.9.tar.xz.
>>
>>
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> What disturbs me the most is that 'substitute-binary' is being called at
>> all. I'm 100% certain that I passed '--no-substitutes' to guix-daemon.
>> I use a script to star
In recent master, GNU Octave fails to build on my x86_64 system.
Here's the tail of the log.
Mark
--8<---cut here---start->8---
libtool: link: g++ -fPIC -DPIC -shared -nostdlib
/gnu/store/hf5kklv837xbfcv6gc7gpsj36l69j3sj-glibc-2.19/lib/crti.o
/gnu/store
With current master, mailutils fails its test suite on my x86_64
machine. The failures are in imap4d/testsuite/imap4d/fetch.exp:
--8<---cut here---start->8---
Running
/tmp/nix-build-mailutils-2.2.drv-1/mailutils-2.2/imap4d/testsuite/imap4d/fetch.exp
...
FAIL:
With current master, xf86-input-evdev 2.7.0 fails to build on my x86_64
machine. During ./configure it reports:
--8<---cut here---start->8---
checking for UDEV... no
configure: error: Package requirements (libudev) were not met:
No package 'libudev' found
Con
The imagemagick build was broken because 6.8.8-8 is no longer available.
I've upgraded it to 6.8.8-10, but it will continue to break every time
they add a new version.
One option worth considering is to download the source from their
subversion repository.
Mark
I see two 'fcntl-lock' related failures with current master on an i686
Debian Wheezy system with Debian's Guile 2.0.5 package. See below for
the relevant excerpts from utils.log.
Mark
--8<---cut here---start->8---
Test begin:
test-name: "fcntl-flock wai
Mark H Weaver writes:
> In recent master, GNU Octave fails to build on my x86_64 system.
This was fixed in 57e544e8f7f0c907bb1ea3b4432a9a3d3da57365.
I'm closing this bug.
Mark
texlive-2014 contains a copy of luajit which fails its test suite on
MIPS, thus causing the entire build to fail on guix. Here's the tail of
the build log:
--8<---cut here---start->8---
Making check in luajit
make[2]: Entering directory
'/tmp/nix-build-texlive
I found that Guix's own 'luajit' package builds successfully on MIPS,
presumably because it does not run the test suite. The 'luajit' package
in Guix includes "#:tests? #f" in the arguments, with the comment
"luajit is distributed without tests".
Mark
Hi,
During my testing on a ThinkPad X60 (i686), I have found that 'guix
system init' creates /gnu/store with mode 0750, which does not allow
members of guixbuild to write to it. The mode should be 1775.
Thanks!
Mark
'module-init-tools' (with our patch) assumes that LINUX_MODULE_DIRECTORY
ends with a trailing slash. However, 'udev-service' sets
LINUX_MODULE_DIRECTORY to "/run/booted-system/kernel/lib/modules".
One option would be to add a trailing slash:
--8<---cut here---start---
openpty fails for unprivileged users on standalone guix. For example,
running 'script' or 'screen' fails, and running M-x shell within emacs
results in a bash without job control, because emacs uses pipes to
communicate with the subprocess instead of pseudo-ttys, apparently
because it was unable t
I built guix from git master from within a standalone guix install. I
then tried to run 'pre-inst-env guix system reconfigure' using the same
OS configuration, and it failed to install grub.
The error message said "failed to install GRUB on device '/dev/sda'",
which indicates that 'install-grub'
l...@gnu.org (Ludovic Courtès) writes:
> In guix/scripts/system.scm, could you remove ‘false-if-exception’ around
> ‘install-grub’, and report the backtrace?
Here it is:
--8<---cut here---start->8---
root@jojen# ~mhw/guix/pre-inst-env guix system reconfigure ~m
l...@gnu.org (Ludovic Courtès) writes:
> I think it would be best to fix the module-init-tools patch.
> Could you look into it?
Okay.
> (Note that (1) udev uses kmod, not module-init-tools, and (2) it’s
> possible to use ‘kmod load’ instead of ‘insmod’.)
Hmm, yes, I would like to transition to k
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> In guix/build/install.scm:
>> 47: 1 [install-grub # "/dev/sda" "/"]
>> In unknown file:
>>?: 0 [copy-file # "//boot/grub/grub.cfg.new"]
>>
>> ERROR:
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> Commits 906f704 and 4a8b4c2 address both issues. Thanks!
Alas, this seems to have broken the linux-libre builds on all platforms.
Thanks!
Mark
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> populating /etc from /gnu/store/89dn636ibbc2dy8wqaz30ck3dcli44jk-etc...
>> setting up setuid programs in '/run/setuid-programs'...
>> making '/gnu/store/qfacd34rj6v8b9mi21qx9mj3
At the very end of the builds for gccgo, there is an error:
cycle detected in the references of `/gnu/store/*-gccgo-4.8.3-lib'
and that causes the build to fail.
I wonder if this is fallout from when the gcc packages had their libs
split into a different output. Maybe the "lib" and "out" outp
See the aborted build here: http://hydra.gnu.org/build/80150
Here's the Nix error output:
--8<---cut here---start->8---
these derivations will be built:
/gnu/store/jb3wfz0barwb1f959l1ggi75zybs8ayh-gnumeric-1.12.17.drv
process 11125 acquired build slot '/nix/v
I've worked around the problem by disabling tests on MIPS, commit
2f4640e320a8834f618c7be5a7e8dba62da91190. Closing this bug.
Mark
Mark H Weaver writes:
> At the very end of the builds for gccgo, there is an error:
>
> cycle detected in the references of `/gnu/store/*-gccgo-4.8.3-lib'
>
> and that causes the build to fail.
>
> I wonder if this is fallout from when the gcc packages had their lib
Subject says it all...
Mark
l...@gnu.org (Ludovic Courtès) writes:
> m...@netris.org skribis:
>
>> I'm currently unable to compile guix from git, with error messages that
>> suggest cyclic dependencies between the modules.
>
> Indeed. That is fixed by reverting c5d8376. Can you confirm?
Yes, that solves the problem for me
Eric Bavier writes:
> Ludovic Courtès writes:
>
>> As a stop-gap measure, I’ve worked around the problem in commit d759cf6,
>> which removes the dependency from texinfo to gettext.
>>
>> (Éric: I see one test failure in texi2html, which is a priori unrelated
>> to the change. Could you check wha
Andreas Enge writes:
> Hello,
>
> mit-scheme fails to build on mips64el-linux, because specific source is not
> downloaded for this system. Furthermore, I wonder if in the corresponding
> lines
> (match (%current-system)
> ("x86_64-linux" "x86-64")
> ("i686-linux" "i386")
> (_ "c"))
gnome-vfs is intermittently failing its 'test-async-cancel' test. See:
http://hydra.gnu.org/job/gnu/master/gnome-vfs-2.24.4.i686-linux
http://hydra.gnu.org/job/gnu/master/gnome-vfs-2.24.4.x86_64-linux
Mark
I've seen several failed builds on Hydra where the build log ends with
something like this:
--8<---cut here---start->8---
phase `strip' succeeded after 0 seconds
@ build-succeeded
/gnu/store/b20viwrr0h5y2mqdpx9bpi21snb4fv5c-xkeyboard-config-2.6.drv -
/gnu/store
Andreas Enge writes:
> On Sun, Aug 17, 2014 at 05:06:07PM +0200, Ludovic Courtès wrote:
>> Yes, I think that’s what’s needed, so OK to commit.
>
> Done with commit 68dddca.
That commit adds a top-level procedure 'source-directory' that is
specific to mit-scheme. If it's kept at the top-level, i
The icecat build on i686 broke with the last core-updates merge.
See:
http://hydra.gnu.org/build/96557/log/tail-reload
http://hydra.gnu.org/job/gnu/master/icecat-24.0.i686-linux
Some of the notable updates in that merge include:
glibc-2.20
gnutls-3.2.16
libunistring-0.9.4
libgc-7.4.2
retitle 18581 IceCat fails to build on i686 and needs security updates
severity 18581 serious
thanks
Mark H Weaver writes:
> The icecat build on i686 broke with the last core-updates merge.
> See:
>
> http://hydra.gnu.org/build/96557/log/tail-reload
> http://hydra.gnu.org
Andreas Enge writes:
> On Tue, Sep 30, 2014 at 01:37:08PM -0400, Mark H Weaver wrote:
>> More importantly, the version of IceCat we are using is almost a year
>> old, with no security updates applied during that time.
>>
>> We should update to IceCat 31, which is cu
http://0pointer.de/lennart/projects/libdaemon/ no longer exists, and
I've been unable to easily find out what happened to it, or where it
now lives (if at all).
Mark
When a user runs emacs (or any other program that uses fontconfig), a
cache is created in ~/.cache/fontconfig. This cache is not updated
automatically after installing new fonts, and must be manually cleared
out.
I guess this might be related to our use of Jan 1, 1970 as the
timestamps for all fi
Mark H Weaver writes:
> http://0pointer.de/lennart/projects/libdaemon/ no longer exists, and
> I've been unable to easily find out what happened to it, or where it
> now lives (if at all).
In the meantime, here are two places where it can be downloaded from:
http://pkgs.fedorapr
There are intermittent test failures in guile-ssh, see:
http://hydra.gnu.org/job/gnu/master/guile-ssh-0.6.0.i686-linux
http://hydra.gnu.org/job/gnu/master/guile-ssh-0.6.0.x86_64-linux
All of the failures are the same: "FAIL: client-server.scm"
Mark
Somewhere between 74c7af9 and 7239828, all of the Qt builds broke.
See:
http://hydra.gnu.org/eval/100809#tabs-now-fail
Mark
We install a wrapper script around WindowMaker that prepends
/gnu/store/XXX-windowmaker-XXX/bin to $PATH. This setting is propagated
to all subprocesses in the entire X session, which is suboptimal. It
would be nice to find another solution, preferably by using absolute
pathnames when launching s
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Somewhere between 74c7af9 and 7239828, all of the Qt builds broke.
>> See:
>>
>>http://hydra.gnu.org/eval/100809#tabs-now-fail
[...]
> I think this is due to a thinko I overlooked duri
GNU Lightning fails to build on all platforms. See:
http://hydra.gnu.org/job/gnu/master/lightning-2.0.5.x86_64-linux
http://hydra.gnu.org/job/gnu/master/lightning-2.0.5.i686-linux
http://hydra.gnu.org/job/gnu/master/lightning-2.0.5.mips64el-linux
Mark
1 - 100 of 1036 matches
Mail list logo
