IRC channel logs


back to list of 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/ symbol __shm_directory, version GLIBC_PRIVATE not defined in file 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>fresh backtrace
<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>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>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
<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>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"
<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
<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
<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>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
<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
<davexunit>civodul: dented/tweeted
<civodul>thanks, davexunit!
<davexunit>posted on GNU social
<davexunit>back when "the" GNU social (the statusnet) instance was, 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_>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
<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>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>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?
<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>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>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>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>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!
<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.
<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
<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>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 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 (, 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