IRC channel logs

<Sleep_Walker>what tool do you use for DNS queries in Guix?

<Sleep_Walker>I can't find none of dig, nslookup, host

<_`_>Sleep_Walker: is getent(1) present?

<_`_>`getent ahosts domain.tld`

<ijp>does getent require libtolkien?

*davexunit plays rimshot

<Sleep_Walker>_`_: that works, thanks, but I'm not sure it can accept DNS IP address somehow

<_`_>aye, just respects hosts(5) / nsswitch.conf(5) afaik.

<davexunit>hmm, I can't get guix to substitute from my own machine rather than hydra...

<davexunit>I started the daemon like this: ./pre-inst-env guix-daemon --build-users-group=guix-builder --substitute-urls=localhost:8080

<davexunit>ohhh I see why... because I invoked 'guix substitute-binary' by hand

<davexunit>heh, I don't know why but the nars published from my 'guix archive' server apparently ask guix to read files of absurd sizes

<davexunit>one archive is 39MiB, but the nar directs guix to read a 170MiB file!

<twotwenty>I am installing my first Guix system and the instructions instructed me to come say hi. "HI"

<twotwenty>how long til full release ;)

<rekado>I'm getting an ugly error when doing "import gobject" in a python 2.7 session.

<rekado>ImportError: /gnu/store/vd8ij01bq08icp87bz5gs2v4bq53bls6-glibc-2.21/lib/librt.so.1: symbol __shm_directory, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference

<rekado>Updating all my packages now. Hope this will fix it.

<phant0mas>sneek: later tell civodul I managed to make coreutils build succesfully for --target=i686-pc-gnu :-D

<sneek>Will do.

<phant0mas>good morning guys

<civodul>Hello Guix!

<civodul>phant0mas: and do the coreutils binaries run? :-)

<civodul>i think DusXMT reported a failure at that

<civodul>sneek: seen DusXMT

<sneek>DusXMT was here Mar 04 at 08:38 pm UTC, saying: Interesting fact: Did you know that GnuTLS (the maintained version) isn't a GNU project anymore? The maintainers disbanded the GNU version. (this isn't to cause frowns, just an interesting fact).

<phant0mas>will try that now, finished building 5 minutes ago :P

<civodul>neat :-)

<civodul>and when do you sleep? ;-)

<phant0mas>hahaha I just woke up early :P

<rekado>re gobject import error: disappeared after upgrading all packages.

<Sleep_Walker>I have that bind-utils package ready

<Sleep_Walker>for now I have it in dnsmasq.scm

<Sleep_Walker>but maybe we should rename it to dns.scm or should I put it elsewhere?

<civodul>Sleep_Walker: yes maybe rename it to dns.scm first, and then add the package

<Sleep_Walker>OK

<Sleep_Walker>fresh backtrace http://paste.opensuse.org/view/raw/96316611

<Sleep_Walker>I tested that with HEAD on different package and it doesn't seem to be broken

<Sleep_Walker>only adding my package bind-utils cause backtrace

<Sleep_Walker>davexunit: hi

<Sleep_Walker>I'm somehow confused - I didn't care about GnuTLS guile bindings at all on GuixSD

<Sleep_Walker>why does it dies on this package and not on others?

<davexunit>using an https source url?

<Sleep_Walker>aha!

<Sleep_Walker>and do you know how can I fix it?

<Sleep_Walker>in gnutls.scm it looks like it is enabled

<davexunit>install the gnutls bindings?

<davexunit>I don't know specifically what is going on with your guile libraries

<Sleep_Walker>it doesn't seem that they have any other package/output for bindings

<Sleep_Walker>davexunit: ok, I'll try it the other way round - are you on GuixSD?

<davexunit>not currently

<davexunit>can you open a guile repl and type: ,use (gnutls)

<davexunit>what happens?

<Sleep_Walker>fails

<Sleep_Walker>ERROR: no code for module (gnutls)

<davexunit>that's what I expected

<Sleep_Walker>anyone on GuixSD?

<davexunit>did you set your guile load paths properly?

<davexunit>according to 'guix package --search-paths' ?

<Sleep_Walker>does `guix lint automoc4' work for you?

<Sleep_Walker>davexunit: I'm not sure I follow you

<Sleep_Walker>guix package --search-paths returns only SSL_CERT_DIR for me

<davexunit>okay

<Sleep_Walker>I have set it elsewhere

<Sleep_Walker>I have installed /gnu/store/rinlj93m8855l18sfnm423sdfmsb2d10-gnutls-3.3.12 as the only gnutls version in /gnu/store

<Sleep_Walker>/gnu/store/rinlj93m8855l18sfnm423sdfmsb2d10-gnutls-3.3.12/share/guile/site/2.0/gnutls.scm and /gnu/store/rinlj93m8855l18sfnm423sdfmsb2d10-gnutls-3.3.12/share/guile/site/2.0/gnutls/extra.scm is present

<davexunit>but they aren't on the load path, it seems

<Sleep_Walker>guile -L /gnu/store/rinlj93m8855l18sfnm423sdfmsb2d10-gnutls-3.3.12/share/guile/site/2.0/

<Sleep_Walker>with this it works

<davexunit>yeah

<davexunit>was about to suggest that

<Sleep_Walker>gnutls is not part of system configuration

<Sleep_Walker>that is the problem probably

<davexunit>it shouldn't have to be

<Sleep_Walker>it is not part of my profile either

<Sleep_Walker>but one would say it will be loaded as dependency on package management level

<davexunit>I feel that it should "just work"

<Sleep_Walker>exactly

<davexunit>so someone else might be able to comment on that

<Sleep_Walker>probably guix package itself needs to require it

<davexunit>well, it *is* built with gnutls

<davexunit>maybe it should be propagated

<Sleep_Walker>exactly

<davexunit>I leave that up civodul

<davexunit>propagated inputs scare me.

<Sleep_Walker>installing gnutls into my user profile has no influence

<davexunit>did you set the search paths?

<Sleep_Walker>only SSL_CERT_DIR was asked to add

<Sleep_Walker>and I already have it set to elsewhere

<Sleep_Walker>I'm not sure which other paths I should have set

<davexunit>the guile search paths need to be set

<davexunit>install guile to your profile

<davexunit>then it will give you the search paths

<Sleep_Walker>I have guile installed (as dependency) in system profile

<Sleep_Walker>OK, with these paths I don't have problem anymore

<Sleep_Walker>so I have workaround for the issue

<davexunit>bring it up on guix-devel

<Sleep_Walker>but I believe it is something which should be part of system configuration

<Sleep_Walker>yup

<davexunit>well, system configuration is the wrong place for it.

<davexunit>I think we need to do a better job of explaining to people that you really don't want everything to be a part of the global system profile.

<davexunit>having the guix package installed should be all that is needed for 'guix lint' to work.

<Sleep_Walker>apparently it is not

<Sleep_Walker>I agree that everything in system profile is wrong, but there needs to be sufficient minimut which you as user could override

<davexunit>I said the above meaning that it *should* be all that is needed

<davexunit>because it is not currently

<Sleep_Walker>gnutls is _not_ in system profile

<davexunit>it doesn't need to be

<Sleep_Walker>dang

<Sleep_Walker>guix lint required it when it is not available

<Sleep_Walker>I'm afraid I don't follow you again

<davexunit>putting it in the system profile won't change that

<davexunit>I consider it a bug that 'guix lint' doesn't work out of the box without having guile's load path tweaked to include gnutls

<Sleep_Walker>good

<davexunit>gnutls is an input to the guix package, that should be sufficient for making everything work

<davexunit>in guix, most things do not need to be in a profile in order to work

<davexunit>you don't need libgcrypt in a profile for guix to use it.

<Sleep_Walker>for C no (ldd has the information already), but is this information in go (output of scm)?

<davexunit>we modify dynamic-link calls in guile packages to reference the store path of shared libaries

<davexunit>but this is a guile load path issue

<davexunit>which is different

<davexunit>and unsolved, afaik

<Sleep_Walker>I'm starving, I need some food and fresh air - `guix system reconfigure' after adding gnutls really doesn't help

<davexunit>yes, like I said.

<davexunit>please write to bug-guix about 'guix lint' not working out of the box on GuixSD

<rekado_>hmm, I also have the problem of gnutls not working.

<rekado_>I followed the instructions to install guix with guix.

<rekado_>(I'm on Fedora)

<rekado_>my GUILE_LOAD_PATH is set properly and it contains gnutls.

<rekado_>I get the usual ;;; Failed to autoload make-session in (gnutls):;;; ERROR: missing interface for module (gnutls)

<rekado_>trying to download a tarball whose URL is redirected to https.

<rekado_>in a guile REPL ,use (gnutls) works just fine, no errors.

<rekado_>only when using guix I see an error.

<civodul>hello! yes?

<civodul>any problems?

<civodul>i invite you to publicize https://savannah.gnu.org/forum/forum.php?forum_id=8238

<davexunit>civodul: dented/tweeted

<civodul>thanks, davexunit!

<civodul>"dented"?

<davexunit>posted on GNU social

<civodul>ok

<davexunit>back when "the" GNU social (the statusnet) instance was identi.ca, everyone called it "denting" instead of "tweeting"

<davexunit>s/the statusnet/then statusnet

<civodul>ok, didn't know that term

<rekado_>is gnutls supposed to work after installing guix with guix on Fedora?

<rekado_>I set all paths.

<rekado_>what I find funny is that the download works just fine with "guix download" but it fails with "guix build"

<rekado_>unfortunately, with guix download I cannot change the name of the stored file.

<civodul>rekado_: "guix download" uses the (gnutls) that's in $GUILE_LOAD_PATH, whereas build environments use the GnuTLS package from (gnu packages gnutls)

<civodul>the latter should work

<civodul>could you copy/paste the command and error?

<rekado_>ugh, this is frustrating. Now I can no longer reproduce it :(

<rekado_>I recompiled the package module I was working on and ... now it works :-/

<rekado_>I don't know if the old compiled modules are to blame, but maybe I should update the README to state that "make clean" should be run before attempting to install guix with guix.

<rekado_>in other news: Julia does not pass tests with either ATLAS or libpack :-/ The devs recommend openblas which I'm packaging now.

<civodul><rekado_> trying to download a tarball whose URL is redirected to https.

<civodul>rekado_: this ↑ is expected

<civodul>because (guix download) only adds GnuTLS as a dependency when the URL is an https URL

<rekado_>I see

<civodul>so if you use an http URL that redirects to https, it fails

<civodul>usually it's easy to work around it

<civodul>if you find a more complex case, let us know

<rekado_>this makes sense.

<bavier>rekado_: what about the Julia tests would be affected by the BLAS implementation?

<rekado_>bavier: https://github.com/JuliaLang/julia/issues/10457

<rekado_>it seems ridiculous that the BLAS implementation should cause failures like that.

<rekado_>I find this one curious: ERROR: assertion failed: |det(lua) - det(full(A))| <= 1.4210854715202004e-10

<rekado_>there's a sign error making the assertion fail.

<bavier>yes, that seems strange

<Sleep_Walker>GNU Social?

<bavier>I thought ATLAS contained a cblas interface

<davexunit>Sleep_Walker: https://gnu.io/social/

<Sleep_Walker>nice :D

<bavier>rekado_: btw: does Julia bundle umfpack? I just saw a mention of umfpack in the stacktrace.

<rekado_>bavier: it does bundle umfpack. umfpack is part of suitesparse; I packaged it already but haven't been able to make it work with this version, so I'm still using the bundled version.

<bavier>ok

<bavier>I thought I had a suitesprase recipe myself... but now I can't find it...

<bavier>nvm, found it

<bavier>rekado_: not sure if you'd be interested, but I have packages for MUMPS, ScaLAPACK, p4est, primme, feast, slepc, and trilinos as well

<rekado_>bavier: does your suitesparse recipe build so files?

<bavier>rekado_: I don't believe it does

<bavier>I recently ran `guix gc` and I haven't rebased that branch in a while

<Sleep_Walker>civodul: yes, problem is that `guix lint' doesn't work for packages with home-page with HTTPS out of the box

<bavier>I suppose Julia is wanting the so's for its ccall

<Sleep_Walker>civodul: I wrote an e-mail to guix-devel about the workaround but miss the important part - it doesn't work out of the box

<civodul>i think we'll just make (gnutls) a hard requirement

<civodul>otherwise this kind of problem will always resurface

<rekado_>with the bundled suitesparse Julia builds a wrapper to get so files.

<rekado_>building openblas fails at the linking stage: "ld: cannot find -lgfortran" (gfortran is of course in the inputs list)

<rekado_>fixed (I think).

<rekado_>dealing with all these messy makefiles day after day really makes me appreciate good build documentation.

<mark_weaver><rekado_> there's a sign error making the assertion fail.

<mark_weaver>rekado_: can you elaborate on that? where is the sign error?

<rekado_>mark_weaver: actually, it should just take the absolute difference. I wonder why the assertion fails at all.

<rekado_>this is the assertion: |det(lua) - det(full(A))| <= 1.4210854715202004e-10

<mark_weaver>it looks like it already is taking the absolute value of the difference in value of the determinants

<mark_weaver>which seems sensible to me

<rekado_>det(lua) = 114.00000000000003, det(full(A)) = -114.0

<rekado_>difference = 228.00000000000003 > 1.4210854715202004e-10

<rekado_>that's where it fails.

<rekado_>anyway, I'm building julia now with openblas.

<rekado_>let's see if this makes any difference.

<mark_weaver>oh, I see

<mark_weaver>hmm

<mark_weaver>I'd like to see the matrices 'lua' and 'full(A)'

<rekado_>from the comments on the github issue I think this is a result of not passing USE_BLAS64=0

<rekado_>the test creates matrices of types Float32, Float64, Complex64, Complex128; I suppose it's failing for one of the 64 bit values.

<mark_weaver>sounds like a genuine error. a determinant of a matrix (that's not close to zero) shouldn't flip signs like that

<Sleep_Walker>why do I have two different hashes in the store for tarball? http://paste.opensuse.org/view/raw/66212422

<davexunit>Sleep_Walker: likely the inputs needed to download that tarball have changed

<Sleep_Walker>is it really necessary to mix sources with inputs in this way?

<rekado_>I get the same error with openblas.

<rekado_>need to try again with USE_BLAS64=0.

<civodul>ooh, i upgraded my profile and Evince has all its icons with this fancy GNOME-3ish theme

<civodul>incredible :-)

<Sleep_Walker>heh :)

<davexunit>what a nice surprise :)

<mark_weaver>civodul: nice!

<chil>there is no system installation image for arm?

<mark_weaver>no

<mark_weaver>for now, it can only be run on top of another system

<mark_weaver>and there are no precompiled binaries yet either

<mark_weaver>because we lack an ARM build slave for our build farm

<davexunit>stay tuned! ;)

<chil>ah, so installing on top of a gentoo stage3 will work?

<davexunit>we have some folks that use gentoo as a base, yeah.

<chil>mark_weaver you can still compile locally, right? I don't need precompiled binaries :p

<mark_weaver>yeah, but beware that it's not just a matter of building the packages you want on top of gentoo

<mark_weaver>guix always uses its own packages exclusively for building things

<chil>that means I would need to install gcc and tools using guix to be able to compile the packages?

<mark_weaver>so basically, without precompiled binaries, guix will do the analogue of doing what's described in CLFS (Cross [GNU/]Linux From Scratch)

<mark_weaver>it's a long process of building all that stuff up

<mark_weaver>multiple days, at least

<chil>in compilation time? or in effort?

<mark_weaver>also, beware that there are still many packages broken on arm

<mark_weaver>in compilation time. it's fully automatic, but you have to wait while your machine does all those compiles

<chil>ah, that's no problem. I'm used to loooong compilation times in gentoo :P

<davexunit>if I get 'guix publish' working soon, perhaps we could piggy back off of the builds us ARM users have already done, without needing the build farm

<mark_weaver>a few other caveats: without an ARM build slave in our continuous integration system, things have regressed somewhat on arm since I bootstrapped it in january

<davexunit>of course, core-updates merges would put as back at square one.

<mark_weaver>don't expect everything to work properly. Guix on ARM is still very much a work in progress.

<davexunit>which also means it's a great time to contribute to making it better :)

<mark_weaver>but I recently built a fully-featured Gtk+ Emacs on armhf

<mark_weaver>(in the last week)

<chil>that's all I need almost ;)

<mark_weaver>cool!

<mark_weaver>and finally, your system has to support ARMv7 with hard float, Thumb-2 and, and VFP3D16 coprocessor. Those are the same requirements as the Debian armhf port.

<mark_weaver>(I'm considering adding NEON as a requirement as well, but that's negotiable :)

<chil>hmm...

<chil>Not sure about that thumb-2 and coprocessor

<mark_weaver>chil: what does "uname -m" say?

<chil>I don't have a system installed now. But I can quickly flashing a rpi2 to check now

<mark_weaver>I think the RPi2 probably has what's needed. the older RPis do *not*.

<mark_weaver>how much RAM does the system have?

<chil>1gb, it's the new version2

<mark_weaver>okay, that should probably be enough RAM anyway.

<mark_weaver>but I don't know how fast it is.

<mark_weaver>I wouldn't be surprised if bootstrapping Guix takes on the order of a week, maybe more.

<chil>I was using gentoo with the old rpi, this should be better :P

<chil>mark_weaver what do you guys use to test/devel guix? a VM?

<bavier>chil: I usually run develop Guix running atop Trisquel, but sometimes develop from GuixSD ;)

<bavier>not ARM though.

<rekado_>chil: guix can be used as a standalone package manager on top of an installed system. I run it atop of Fedora / CentOS.

<rekado_>(also not ARM)

<chil>cool

<chil>Can you use dmd when using guix as a package manager only?

<chil>or it requires GuixSD?

<rekado_>I'm not using dmd on Fedora.

<davexunit>chil: dmd doesn't depend on guix.

<davexunit>guixsd depends on dmd.

<iyzsong>chil: yes, you can use dmd along with your init or as a user session manager.

<iyzsong>I think use dmd as a init replacement for other distros is possible, but does require a lot works ;-)

<chil>ok. So better stick with the base distro one for now :P

<chil>mark_weaver uname -m outputs "armv7l"

<mark_weaver>chil: that's a good sign!

<chil>:)

<mark_weaver>chil: and what does "grep vfp /proc/cpuinfo" output?

<mark_weaver>I don't use VMs.

<mark_weaver>I have a Novena, which I used to bootstrap the Guix armhf port.

<chil>half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm

<mark_weaver>looks good. I think that has what you need.

<chil>:)

<mark_weaver>specifically the "vfpd32", which implicitly includes vfpd16.

<mark_weaver>chil: guix-daemon also requires some kernel features that may or may not be in your existing kernel

<mark_weaver>one requirement is CONFIG_DEVPTS_MULTIPLE_INSTANCES=y

<mark_weaver>the kernel that came with the Novena lacked that feature, so I had to recompile it

<davexunit>oh. good to know!

<davexunit>I want to rebase the novena-linux patches on linux-libre sometime

<mark_weaver>yes, that would be good :)

<davexunit>then we can have a novena-linux-libre package

<chil>mark_weaver that requirement isn't documented in the web instructions or INSTALL file?

<davexunit>I guess we could make note of it in the texinfo manual

<civodul>+1

<mark_weaver>yes, we should document the requirements

<chil>well, maybe I missed it

<mark_weaver>chil: no, I think we missed it :)

<chil>I didn't read the docs in much detail yet :P

<davexunit>it's here. :)

<mark_weaver>davexunit: it == ? (Novena?)

<davexunit>yup!

<mark_weaver>sweet!

<davexunit>I'll shut up about it now. I just feel like a kind of christmas.

<mark_weaver>heh :)

<davexunit>whoa, a hackage importer!

<mark_weaver>armhf actually has a major problem right now, probably due to patchelf. although I built 'emacs' in recent master (since the core-updates merge), I can't actually build any profiles right now.

<mark_weaver>here's what happens:

<mark_weaver>Inconsistency detected by ld.so: get-dynamic-info.h: 142: elf_get_dynamic_info: Assertion `info[29] == ((void *)0)' failed!

<mark_weaver>builder for `/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv' failed with exit code 1

<mark_weaver>and I suspect that assertion failure is ultimately due to the buggy patchelf on ARM, although I'm not sure

<mark_weaver>I'm not sure off-hand how best to debug this.

<mark_weaver>the emacs I recently built does work, however, if I run it directly out of the store.

<mark_weaver>chil: so yeah, our armhf port is slightly broken at the moment.

<chil>oh, thx for telling :)

<mark_weaver>we'll get it fixed, of course

<mark_weaver>'localedef' is the executable that's failing here

<mark_weaver>hmm, the problem seems to be that there's a RUNPATH set for ld.so (ld-linux-armhf.so.3), and apparently that's bad

<mark_weaver>I'll have to ask civodul about this

<mark_weaver>I emailed a report of my preliminary findings to bug-guix

<bavier>I'd like to make a new module: (gnu packages language)

<bavier>would solve a circular dependency issue I'm facing

<bavier>could probably put wordnet in there too.

<bavier>ugh, organizing all these perl modules is getting more difficult

<mark_weaver>rekado_: btw, the newest libgnomeprint already works with the newest freetype.

<mark_weaver>however, updating libgnomeprint wasn't as simple as bumping the version number and hash

<rekado>mark_weaver: oh, I had not checked whether there was a new version as the comments told me it was deprecated.

*davexunit boots his novena

IRC channel logs

2015-03-13.log