Andreas Enge 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 not p
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 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. -I./nix
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 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
> nix::DerivationGoal::s
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: ‘DEFAULT
Yes, sorry for too short a snippet:
PASS: gapplication 1 /gapplication/no-dbus
PASS: gapplication 2 /gapplication/no-appid
PASS: gapplication 3 /gapplication/properties
PASS: gapplication 4 /gapplication/app-id
ERROR: gapplication - missing test plan
ERROR: gapplication - exited with status 139 (t
Alexander Vorobiev 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 shouldn’t make any differ
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 pla
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 wrote:
> Alexander Vorobiev skribis:
>
> > That f
Alexander Vorobiev 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: internal error getting ex
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 inte
Alexander Vorobiev 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 user/group to give to guix-daemon.
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, Ludovi
Alexander Vorobiev 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, gcc, perl, etc) but stumble
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
Alexander Vorobiev skribis:
> I modified the files (to use my paths for the cache and store) and ran
> guix-daemon as root. Now it got much, much further! But still failed, it
> seems while building perl. Here is the end of the log file:
>
> In unknown file:
>?: 5 [load-compiled/vm
> "/home/a
Hi,
I modified the files (to use my paths for the cache and store) and ran
guix-daemon as root. Now it got much, much further! But still failed, it
seems while building perl. Here is the end of the log file:
In unknown file:
?: 5 [load-compiled/vm
"/home/alex/.cache/guile/ccache/2.0-LE-8-2.0/ho
Alexander Vorobiev skribis:
> 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.
What failed exactly?
Note that ‘
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 see
Alexander Vorobiev 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 other "standard" director
Alexander Vorobiev 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" directories) layout are
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. Woul
Alex Vorobiev skribis:
> Does it mean it can't be installed on systems with older c++
> compilers?
On these systems, I would suggest installing from the binary tarball.
Not having to build Guile, libgcrypt, and everything on such a system is
already a good incentive to use the binary tarball.
Alex Vorobiev writes:
> Ludovic Courtès gnu.org> writes:
>> bunch of C++11 lambdas here, a bit of ‘auto’ there.)
>
> Does it mean it can't be installed on systems with older c++
> compilers?
FYI Guix can be "bootstrapped" very easily with the new binary tarballs
without needing to compile any
Hi,
Ludovic Courtès gnu.org> writes:
> bunch of C++11 lambdas here, a bit of ‘auto’ there.)
Does it mean it can't be installed on systems with older c++ compilers? I
am on RHEL 6.5 which has gcc-4.4.7 and ironically one of my main reasons to
try guix was to be able to install newer versions
26 matches
Mail list logo
