***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? <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 <bavier>that's typically what I do, but others might have different strategies <davexunit>grab the source package with 'guix build -S foo', unpack it, cd within, and then 'guix environment foo' <davexunit>I debugged guile-sdl build problems that way <bavier>rekado_: sometimes failures are chroot-related, so they may not be reproducible from outside. <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. <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>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! <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 <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 <bavier>rekado_: I think the cblas_* symbols should be in -latlas <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_>I'll resume work on this with a fresh set of brain cells after the weekend. <bavier>rekado_: sounds good. good luck! <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>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>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>i think the glib family of libraries can be updated in a separate commit <civodul>but yeah, since there are also libs, it would actually make sense to have an xorg-updates branch <mark_weaver>I refrained from updating the other gnome libraries. <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. <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>exciting. my version should be coming in a month or so, I guess. <davexunit>it will be cool to have a dedicated guix hacking machine. <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 <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>i mean if you do an event loop in C or OO-style, you end up with lots of callbacks <civodul>so the solution IMO is either FRP, as you know very well :-) <davexunit>I was familiar with inversion of control from working with "dependency injection" frameworks in OO languages <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 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. <davexunit>anyway, thanks for explaining. I'm trying to reconcile these two meanings of IoC in my head. <civodul>maybe "IoC" isn't appropriate in this context? <civodul>i could have said "callback hell" or something like that ;-) <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. <davexunit>"callback hell" is a good term. I was in callback hell today. <davexunit>debugging nasty js on the FSF donation pages. <civodul>and it's the kind of web page that *has* to work ;-) <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. <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.