IRC channel logs

2014-12-19.log

back to list of logs

***erdic_ is now known as erdic
***svetlana is now known as gry
<rekado_>I'm trying to package R and have reached a point where I'd like to manually run "make check" to see what's going on and what I need to do to fix it.
<rekado_>What's the recommended way to do this?
<rekado_>I see that there's guix environment, but I'm not sure how to use it.
<bavier>rekado_: would building the package in `guix environment` help?
<bavier>ah, ok
<rekado_>Also, I can't just go to /tmp/nix-build..../ and run make there, because that's owned by a guix-builder user.
<bavier>if you have root access you can chown /tmp/nix-build.../ to yourself
<rekado_>well, I could do that, but ... I thought this is a very common scenario and wondered if there's a more elegant way.
<bavier>there's an "environment-variable" file that you can source that can get your environment to something like the builder's
<rekado_>bavier: thanks. I'll try that.
<bavier>that's typically what I do, but others might have different strategies
<davexunit>alternatively, you can use guix environment
<davexunit>grab the source package with 'guix build -S foo', unpack it, cd within, and then 'guix environment foo'
<davexunit>or rather, 'guix environment --pure foo'
<rekado_>davexunit: thanks
<davexunit>I debugged guile-sdl build problems that way
<davexunit>helped a lot
<bavier>rekado_: sometimes failures are chroot-related, so they may not be reproducible from outside.
<bavier>just something to keep in mind
<rekado_>hmm, one error in building R is that in a later make step a previously built library is linked:
<rekado_>ld-wrapper: error: attempt to use impure library "/home/rekado/code/R-3.1.2/lib/libRblas.so"
<rekado_>Is this only a side-effect of using "guix environment --pure r"?
<rekado_>the recipe target is "recommended-packages" --- they all depend on the previously built R libs.
<davexunit>I don't know what that error is
<bavier>rekado_: not related: is there a way to have R use an external blas library?
<rekado_>bavier: do you suggest building these libraries separately and then add them as inputs?
<rekado_>(I don't know what this library does and if I can build it separately, yet)
<bavier>rekado_: no, I was thinking about using the lapack or atlas libraries we already have packaged
<bavier>using those as inputs
<rekado_>oh, I see.
<bavier>not sure that it would solve the problem you're seeing, but from a packaging perspective it would be nice
<rekado_>I see that R also builds its own bzip2; will check the configure switches to see if I can just use externals instead.
<rekado_>yes, I can configure it to use the system versions. Thanks, bavier!
<bavier>np, thanks for working on it!
<rekado_>hmm, using altas as blas does not seem to work:
<rekado_>unable to load shared object '/home/rwurmus/code/R-3.1.2/library/stats/libs/stats.so': /home/rwurmus/code/R-3.1.2/library/stats/libs/stats.so: undefined symbol: cblas_dsyrk
<rekado_>will have to continue next week
<bavier>rekado_: I wonder if there are some other link flags that need to be given?
<rekado_>it passed these: -fopenmp -llapack -lf77blas -latlas -L/gnu/store/d4w...-gfortran-4.8.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.8.3 -L/gnu/store/d4w...-gfortran-4.8.3-lib/lib -lgfortran -lm -lquadmath
<civodul>Hello Guix!
<bavier>hello civodul!
<bavier>rekado_: I think the cblas_* symbols should be in -latlas
<rekado_>-latlas is passed as a link flag.
<bavier>does it find that library in atlas's store directory?
<rekado_>it does seem to find something; when I run ./configure with all flags including --with-blas (which makes it use system libs for BLAS) I see the store directory of atlas in the output.
<rekado_>and I see this: "checking for ATL_xerbla in -latlas... yes"
<rekado_>The configure summary tells me: "External libraries: readline, BLAS(ATLAS), LAPACK(generic), lzma"
<rekado_>which seems right.
<rekado_>I'll resume work on this with a fresh set of brain cells after the weekend.
<bavier>rekado_: sounds good. good luck!
<rekado_>thanks :)
<mark_weaver>civodul: I recently finished the xorg update work, and am currently running that system. Everything that depends on the X libraries will have to be rebuilt.
<mark_weaver>remaining to be done: split the one huge commit into a bunch of smaller commits
<nkar>there's been a git vuln published recently, has guix updated yet?
<mark_weaver>nkar: I looked at it, but it only affects case-insensitive filesystems.
<mark_weaver>there's no issue on GNU systems.
<nkar>ah, right
<mark_weaver>civodul: do you think I should make an "xorg-updates" branch for this, or apply it to core-updates and plan to build+merge that soon?
<mark_weaver>also, hydra is currently unable to evaluate jobsets, at least for subset "all".
*mark_weaver goes afk for a bit
<civodul>mark_weaver: you can push it all at once on master if you've already tested it
<civodul>there shouldn't be any big surprises
<mark_weaver>civodul: okay, sounds good. I've built everything I used, and all of the packages I modified.
<mark_weaver>s/used/use/
<mark_weaver>I'm undecided on how finely to break this commit up.
<mark_weaver>right now it's almost all in a single 150 KB commit that updates almost everything in xorg, plus mesa, dbus, cairo, pixman, glib, poppler, and inkscape. some of those other things I updated to fix problems caused by other updates.
<mark_weaver>I think breaking it up probably makes sense, but it should be noted that some things would be broken in the intermediate commits.
<mark_weaver>I was thinking of putting updates for xorg-server and all of its modules in a single commit, and otherwise to put the individual package updates in one commit each.
<mark_weaver>where "modules" means the input and video drivers. not sure about the *proto packages.
<civodul>woow, lots of updates, indeed :-)
<civodul>sounds good
<civodul>i think the glib family of libraries can be updated in a separate commit
<mark_weaver>agreed
<civodul>but yeah, since there are also libs, it would actually make sense to have an xorg-updates branch
<civodul>so that hydra can catch up
<mark_weaver>I refrained from updating the other gnome libraries.
<mark_weaver>(for now)
<civodul>heh, ok :-)
<mark_weaver>speaking of hydra, how should we fix the timeout issue? (did you get my email?)
<mark_weaver>it's been a couple of days since it last completed an evaluation.
<civodul>oooh, bad
<civodul>i haven't checked email yet
<mark_weaver>in other news, my Novena should arrive on Tuesday, at which point I'm going to start working on the ARM port.
<davexunit>wooooo!!!!
<mark_weaver>:)
<davexunit>exciting. my version should be coming in a month or so, I guess.
<mark_weaver>indeed!
<davexunit>it will be cool to have a dedicated guix hacking machine.
<civodul>yay!
<mark_weaver>So far I've split the xorg-updates into 94 patches, and there are about 20 more to go (one per package).
*mark_weaver goes afk for a while
<civodul>mark_weaver: ninety-four!
<civodul>woow
<davexunit>civodul: what do you mean by "avoid IoC" in the "avoiding threads in the daemon" thread? I'm curious because the solutions mentioned were FRP and monads, and that piqued my interest. :)
<civodul>:-)
<civodul>i mean if you do an event loop in C or OO-style, you end up with lots of callbacks
<davexunit>yes
<civodul>that's inversion of control (IoC)
<civodul>that's terrible
<davexunit>agreed
<civodul>so the solution IMO is either FRP, as you know very well :-)
<civodul>or monads, to "hide" the CPS
<davexunit>I was familiar with inversion of control from working with "dependency injection" frameworks in OO languages
<civodul>ok
<davexunit>but I think it might mean something different there
<civodul>i never completely understood what "dependency injection" is
<davexunit>it's OO speak for "higher order functions", basically.
<civodul>oh, said this way, it's much clearer
<davexunit>rather than class Foo knowing about a concrete class Bar, Foo is parameterized by Bar, so it could be swapped out by anything.
<civodul>ok, i see
<civodul>oops
*civodul might have just done something very silly
<civodul>guix-commits is going to explode, i'm afraid
<civodul>remote: Sending notification emails to: guix-commits@gnu.org
<civodul>remote: *** Too many new commits (3549), not sending commit emails.
<civodul>better this way :-)
<davexunit>anyway, thanks for explaining. I'm trying to reconcile these two meanings of IoC in my head.
<davexunit>phew, there was an upper bound!
<civodul>yup
<civodul>maybe "IoC" isn't appropriate in this context?
<civodul>i could have said "callback hell" or something like that ;-)
<davexunit>I think it's appropriate.
<davexunit>it's one of those cases of only hearing a term in one context, so it's hard to think about it in another.
<civodul>yeah
<davexunit>"callback hell" is a good term. I was in callback hell today.
<davexunit>debugging nasty js on the FSF donation pages.
<davexunit>fun, fun.
<civodul>ouch
<civodul>and it's the kind of web page that *has* to work ;-)
<davexunit>yup!
<davexunit>it can be scary. a big codebase that I didn't write.
<davexunit>fixed with a 2 line patch, so I can sleep tonight.
<davexunit>anyway, I'll go back to work for a bit more now. haven't had a chance to wrap up guix publish yet. hopefully soon.
<davexunit>oh, btw. my libreplanet talk proposal about guix was not accepted.
<davexunit>we got 119 proposals, so not a big surprise.
<tadni_>davexunit: That's a bummer.
<civodul>davexunit: oh bummer
<civodul>but yeah, that's a lot of proposals
<civodul>i haven't heard back from my FOSDEM proposal
<tadni_>Maybe 2016's once Guix is 1.0 and the distro is in Beta or-so, people will be a bet more eager.