<rekado_>I can't see anything unusual in the build log for R that would explain the segfault on hydra. I have not been able to reproduce this on my workstation. <rekado_>I would be grateful if someone else could try to build R on their machine. I simply don't get a segfault here. <rekado_>I'll try to build it on another machine as well, just to see if it makes any difference. <grantix>rekado_: About to attempt to build on i686. <rekado_>I've never actually built it on i686, only on x86_64. <rekado_>Right now I'm building it on a different x86_64 machine. <rekado_>Unfortunately, downloading the dependencies from hydra is very slow. <ewemoa>rekado_: is it worth trying to build it for x86_64 here too? <rekado_>ewemoa: possibly, if you have nothing else to do with your CPU cycles at the moment :) <rekado_>I would only like to see if the segfault can be reproduced on some non-hydra setup. <ewemoa>rekado_: he he -- should be a good test of this machine -- understood <rekado_>Is there some way to specifically direct funds towards improving the bandwidth to hydra? <grantix>rekado: Oh wow, this may take awhile didn't see texlive was a depend... <rekado_>grantix: don't let it take away time you could use productively, e.g. for sleeping ;-) <grantix>Yeah, I have studying to do and a test to take today, but I will get back to you eventually. *rekado_ is building OpenJDK 7 with IcedTea 2.5.4 now. <rekado_>I must admit that I find my choice of names for the icedtea package questionable. <rekado_>IcedTea is the name of the build environment for a liberated OpenJDK. <rekado_>Maybe the package name really should be "openjdk6" rather than "icedtea6". <rekado_>It just occurred to me that in order to give our users freedom to manage their own profiles I just need to give them restricted SSH access to the one server that has guix and guix-daemon installed. <rekado_>no need for RPC over TCP or local deployment of guix on the hundreds of workstations. <rekado_>I would have to set this up on way too many machines. <rekado_>OpenJDK 7 cannot be built, even with OpenJDK 6. Hmm. Same linking-related issue as when I tried to build it with GCJ. <rekado_>hmm, to build R on a new machine guix tells me that it will build *lots* of other packages rather than download them. <ewemoa>rekado_: that's what's happening here, but it's expected here because working off of a recent pull <rekado_>same for "guix pull". Requires lots of packages to be built locally, e.g. bash, ncurses, etc. <ewemoa>rekado_: i also use nixos, and there i switched to working off of stable to avoid a lot of rebuilding <grantix>rekado_: Over line 10,000 of compiling R with no substitues in my buffer. Wowzers. <rekado_>I'm still compiling ncurses and assorted dependencies ... <ewemoa>rekado_, grantix: currently at atlas <grantix>It'd building GCC for somereason, currently. <taylanub>grantix: if you haven't built anything else recently, or did a 'guix gc', then it's normal it'd be bootstrapping the compiler first <taylanub>grantix: you can run guix-daemon with --gc-keep-outputs --gc-keep-derivatives to prevent it from GCing some things like that so they won't be rebuilt every time <rekado_>shouldn't it download the compiler instead of building it? <grantix>taylanub: This is a new install, but I swore I installed GCC. I don't know, maybe I'm thinking of my other box. Eveything but my HTPC is running GSD, to motivate me to package more ... so I'm guessing I'm just mixing them up. <rekado_>or are these packages not yet available as binaries since the latest updates to master? <grantix>Because I thought I had such things. <rekado_>I find that even with using substitutes I have to build lots of stuff myself. <taylanub>if you have them, --no-substitutes won't make a difference <grantix>Too late to back out to be worth it, plus since I'm going afk soon for a few hours ... it shouldn't matter. <grantix>taylanub: Yeah, I'm saying since I must not of had them. <rekado_>for example, on my workstation it's compiling gtk+ right now. <taylanub>I mean, it generally won't make the kind of difference you seem to think it does. it's a purely transparent binary-substitution thing; instead of building something itself it fetches a binary that's the same as the output you'd get from the build anyway; same hash <taylanub>grantix: oh, ok. OOC, why --no-substitutes then? <grantix>taylanub: It was saying libxcb couldn't be used, and I want to see how it built. <grantix>So Wayland requires KVM. Does this eliminate the chance of getting it to run on the Hurd? <taylanub>grantix: it could also be a motivation to implement KVM on Hurd? :) <grantix>taylanub: Yeah, but wouldn't it go against it's ideals in that it would need to run in kernel space? <df_>wayland requires kvm? <taylanub>grantix: AFAIK point of Hurd is that you *can* implement such things outside the kernel <df_>I can't think why it would <grantix>I don't know if that's just a "right now" thing they plan to fix, or just the way thingd will be. <rekado_>pffft, I now know why it was compiling so much stuff: in order to track down a segfault in the guix test suite I replaced gnu/packages/bootstrap/x86_64-linux/bash ... <rekado_>matplotlib's install-doc phase fails here. <grantix>taylanub: Evidently this source is outdated and you can build without KVS. <rekado_>python2-matplotlib cannot be built because python2-pycairo does not exist --- it's called python2-py2cairo. <rekado_>hmm, python2-matplotlib adds python2-py2cairo as a propagated input, but apparantly doesn't remove the automatically added python2-pycairo. <phant0mas>tried map, so it can try each element of the list but still... <mark_weaver>phant0mas: can you paste somewhere the entire glibc/hurd recipe that generated this error? <phant0mas>really sorry for the delay, my mother needed some help <mark_weaver>phant0mas: yes, I can see that I made a mistake in the code I wrote. <mark_weaver>'original-configure-flags' is not the list itself, but rather an expression that evaluates to that list. <mark_weaver>I need to do something else for a bit, but I'll fix it soonish. <phant0mas>in the meantime I will try to fix it myself :-) <taylanub>mark_weaver: hi, Andreas Enge recommended I rename gambit-c back to gambc in conformance with the tarball name (which is apparently in the guidelines). just wanted to get your agreement before I push it. <bavier`>taylanub: section 6.6.2 in the manual <bavier`>I don't see the specific convention Anreas is referring to listed there. <bavier`>taylanub: I personally don't think that convention holds much water <bavier`>I think you'd be able to find at least a handful of other packages where the project chose some silly name for the tarball <mark_weaver>phant0mas: ideally, this should be fixed by having a base 'glibc' package that is inherited by a glibc/linux recipe, so that we don't have to remove those linux-specific things from the base. but in the meantime, I know how to fix it. give me a minute.. <mark_weaver>phant0mas: but no rush. give you mother whatever help she needs... <mark_weaver>bah, so many mistakes. change ("linux-headers" "@DUMMY@") to ("linux-headers" . "@DUMMY@") <mark_weaver>taylanub: I really disagree with Andreas on this one. <mark_weaver>taylanub: please do not push the change that Andreas suggested. He should not have asked you to override my wishes before we discussed it. <mark_weaver>I think civodul deserves that title, but I'll do what I can while he's away :) <mark_weaver>taylanub: I replied to Andreas. Thanks for letting me know. <davexunit>gambit-c is a much more readable name for the package. ***Pastaf_ is now known as Pastaf
<grantix>rekado_: Not sure if you got it under control at this poin, but yeah, R fails to build.