IRC channel logs


back to list of logs

<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_>grantix: thanks.
<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".
<taylanub>is Andreas Enge in this channel?
<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.
<ewemoa>local port-forwarding?
<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.
<rekado_>ewemoa: ok.
<ewemoa>of master that is
<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>rekado_: I did '--no-substitutes'
<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?
<taylanub>out of curiosity
<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?
<grantix>df_: I'm pretty sure.
<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_>great exercise in patience.
<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.
<ph4nt0mas>mark_weaver: could you have a look on this backtrace from the ,@(filter (lambda .....)) you suggested?
<phant0mas>tried map, so it can try each element of the list but still...
*mark_weaver looks
<mark_weaver>phant0mas: can you paste somewhere the entire glibc/hurd recipe that generated this error?
<mark_weaver>phant0mas: ??
<mark_weaver>I suspect that you miscopied the code I wrote
<phant0mas>mark_weaver: sorry I was away from keyboard
<phant0mas>really sorry for the delay, my mother needed some help
<mark_weaver>phant0mas: no worries
<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 :-)
<phant0mas>thank you
<phant0mas>mark_weaver: still the same
<phant0mas>I was thinking I could remove the headers with but had the same problem
<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.
<taylanub>actually, where are those guidelines?..
<bavier`>taylanub: section 6.6.2 in the manual
<bavier`>I don't see the specific convention Anreas is referring to listed there.
<mark_weaver>phant0mas: ah right. bah
<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: can you try this?
<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>(note the dot in between)
<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.
<phant0mas>mark_weaver: building, you did it!! :-D
<phant0mas>you are our hero <3
<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>I also disagree with Andreas on this.
<davexunit>gambit-c is a much more readable name for the package.
<taylanub>heh, good thing I waited
<mark_weaver>taylanub: thanks
***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.
<mark_weaver>Hydra successfully built R on i686, but it failed on x86_64.