On Tue, Jun 09, 2015 at 05:51:00PM +0200, Ludovic Courtès wrote:
There’s also the fact that it’s using -std=c++0x, whereas current master
uses -std=c++11. Fishy!
Very fishy indeed! I think I did not run autoreconf -vfi correctly, or
it failed and I did not pay attention, and was left with a
Andreas Enge andr...@enge.fr skribis:
On Sat, Jun 06, 2015 at 07:41:42PM +0200, Ludovic Courtès wrote:
Could you run “make V=1”? Normally DEFAULT_CHROOT_DIRS is defined from
the command line (see ‘libstore_a_CPPFLAGS’.)
There is no trace of it on the command line:
g++ -DHAVE_CONFIG_H -I.
Andreas Enge andr...@enge.fr skribis:
On Tue, Jun 09, 2015 at 05:51:00PM +0200, Ludovic Courtès wrote:
There’s also the fact that it’s using -std=c++0x, whereas current master
uses -std=c++11. Fishy!
Very fishy indeed! I think I did not run autoreconf -vfi correctly, or
it failed and I did
On Sat, Jun 06, 2015 at 07:41:42PM +0200, Ludovic Courtès wrote:
Could you run “make V=1”? Normally DEFAULT_CHROOT_DIRS is defined from
the command line (see ‘libstore_a_CPPFLAGS’.)
There is no trace of it on the command line:
g++ -DHAVE_CONFIG_H -I. -I./nix -I./nix -I./nix/libutil -I./nix
Andreas Enge andr...@enge.fr skribis:
I did a make distclean, ./bootstrap, ./configure and make on my mips
‘make’ is usually enough.
machine. It fails with the following message:
CXX nix/libstore/libstore_a-build.o
nix/libstore/build.cc: In member function ‘void
I did a make distclean, ./bootstrap, ./configure and make on my mips
machine. It fails with the following message:
CXX nix/libstore/libstore_a-build.o
nix/libstore/build.cc: In member function ‘void
nix::DerivationGoal::startBuilder()’:
nix/libstore/build.cc:1808:91: error:
Alexander Vorobiev alexander.vorob...@gmail.com skribis:
At first I saw the exact same error in this list:
http://lists.gnu.org/archive/html/bug-guix/2014-12/msg2.html
Oh.
I then pulled again, rebooted the VM just in case, reinstalled guix, and
It’s not necessary to reinstall Guix, it
That fixed tcsh, thanks. Here is the next stop - glib (libgio), seems to be
failing its unit tests:
PASS: defaultvalue 80 /Default Values/GZlibCompressor
PASS: defaultvalue 81 /Default Values/GZlibDecompressor
tap-driver.sh: internal error getting exit status
tap-driver.sh: fatal: I/O or
Alexander Vorobiev alexander.vorob...@gmail.com skribis:
That fixed tcsh, thanks. Here is the next stop - glib (libgio), seems to be
failing its unit tests:
PASS: defaultvalue 80 /Default Values/GZlibCompressor
PASS: defaultvalue 81 /Default Values/GZlibDecompressor
tap-driver.sh:
Yes it is, happens every time I run it (make guix-binary). Could it be
custom store and/or local cache? Or wrong version of something in the
system I am using (latest Arch linux)?
Thanks,
Alex
On Mon, Jun 1, 2015 at 2:58 PM, Ludovic Courtès l...@gnu.org wrote:
Alexander Vorobiev
At first I saw the exact same error in this list:
http://lists.gnu.org/archive/html/bug-guix/2014-12/msg2.html
I then pulled again, rebooted the VM just in case, reinstalled guix, and
now I am seeing an error similar to the second error from that email:
ERROR: gapplication - missing test
Alexander Vorobiev alexander.vorob...@gmail.com skribis:
Pulled, restarted. The next stop is tcsh. The tarball at ftp.astron.com s
gone, replaced with more recent version...
Fixed, thanks.
One observation: apparently coreutils refuses to be built as root so I had
to create a build
Pulled, restarted. The next stop is tcsh. The tarball at ftp.astron.com s
gone, replaced with more recent version...
One observation: apparently coreutils refuses to be built as root so I had
to create a build user/group to give to guix-daemon.
Thanks,
Alex
On Fri, May 29, 2015 at 3:57 PM,
Alexander Vorobiev alexander.vorob...@gmail.com skribis:
I have some good progress finally. I started from scratch and pulled the
latest from git. I am now running guix-daemon as root with only one option
--no-substitutes. The make guix-binary* ran for hours and built a lot of
stuff (bash,
I have some good progress finally. I started from scratch and pulled the
latest from git. I am now running guix-daemon as root with only one option
--no-substitutes. The make guix-binary* ran for hours and built a lot of
stuff (bash, gcc, perl, etc) but stumbled upon openldap which doesn't seem
to
Ok, I have just tried to build the binary tarball on a VM where I
reproduced all the paths I want (basically, instead of /gnu I want
/shared/shape_tier3/common/local/guix) and which has c++11 compliant gcc --
that also failed. I pulled today's git and ran guix-daemon
--no-substitutes. The error
Alexander Vorobiev alexander.vorob...@gmail.com writes:
Doesn't binary distribution have hardcoded /gnu/* paths? I can't use
those unfortunately. We have a standard configuration of RHEL 6.5
installed on hundreds of servers and any modifications of the root
directory (and all other standard
Ludo', Taylan,
Doesn't binary distribution have hardcoded /gnu/* paths? I can't use those
unfortunately. We have a standard configuration of RHEL 6.5 installed on
hundreds of servers and any modifications of the root directory (and all
other standard directories) layout are out of question. Would
Alexander Vorobiev alexander.vorob...@gmail.com skribis:
Doesn't binary distribution have hardcoded /gnu/* paths?
Yes it does.
I can't use those unfortunately. We have a standard configuration of
RHEL 6.5 installed on hundreds of servers and any modifications of the
root directory (and all
Hello!
I have pushed a big update of the daemon code. We were using a copy of
the Nix code from May 2014, and there have been worthwhile changes in
the meantime (thanks for the Nix folks!).
There have also been undesirable changes, such as the gratuitous switch
to multithreading, which entails
Commit 1303a4a fixes a use-after-free in the daemon that manifested when
compiling it with GCC 5.1 (string destructors were called before
‘execve’ calls that used the underlying ‘char *’ pointers.)
The fix is a backport of an upstream commit. I plan to update our copy
of the Nix daemon code
On Tue, Jan 21, 2014 at 11:51:08PM +0100, Ludovic Courtès wrote:
Do you have a way to reproduce it (command line + “will be downloaded” list)?
I tried a few substitutions at random and everything went fine.
Now everything goes well for me, too. No idea what happened.
Andreas
Mark H Weaver m...@netris.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
Commit d43eb49 updates the Nix sub-module that provides the daemon’s
C++ code.
To update, run:
( cd nix ; ./sync-with-upstream )
autoreconf -vfi
./configure ... make make check
A few of us ran into
Hi!
(It took me a while to respond, notably because I was chasing a
web-related bug I had just introduced in Guile. Dog food!)
Andreas Enge andr...@enge.fr skribis:
Now I get messages like
guix build: error: build failed: got unexpected path
Now I get messages like
guix build: error: build failed: got unexpected path
`/nix/store/y7hz3la98sk4lmxmsvzbvjxifz4yrnwz-tzdata-2013d' from substituter
Maybe we need to clear /nix/store on hydra and restart it to fill the store
again?
Andreas
l...@gnu.org (Ludovic Courtès) writes:
Commit d43eb49 updates the Nix sub-module that provides the daemon’s
C++ code.
To update, run:
( cd nix ; ./sync-with-upstream )
autoreconf -vfi
./configure ... make make check
A few of us ran into problems with these instructions. It led
Commit d43eb49 updates the Nix sub-module that provides the daemon’s
C++ code.
To update, run:
( cd nix ; ./sync-with-upstream )
autoreconf -vfi
./configure ... make make check
Please report any test suite failure.
The changes compared to the daemon we had so far include interesting
27 matches
Mail list logo
