IRC channel logs


back to list of logs

<nebbia>mark thanks again
<davexunit>hey everyone. I have a WIP package for Redis ( I have it building successfully, but the tests fail, and I think it may be due to networking issues.
<davexunit>the test suite passes when run via 'guix environment --pure redis'
<davexunit>I know networking is extremely limited in the build container, but I'm wondering if there are any general steps to take to configure the necessary things?
<davexunit>afaict the test suite is *not* reaching out to the internet.
<taylanub>the MIT Scheme package relies on chdir returning non-#f on success, when the return value is unspecified :\\
<mark_weaver>davexunit: the loopback interface is enabled, so should work, as well as 'localhost' (via a /etc/hosts entry, no real nameserver)
<mark_weaver>but that's about it
<mark_weaver>taylanub: yeah, we have a lot of mistakes like that around.
<mark_weaver>on Guile, most of those procedures return the specific object *unspecified* which is always considered true, but it's not good practice IMO
<mark_weaver>for anyone who wants to understand Guix in depth, that paper I cited above is highly recommended. I'm reading it for the first time, and learning quite a lot.
<davexunit>yeah, it's very good.
<ewemoa>mark_weaver: thanks for the link to the paper
<mark_weaver>you're welcome! it's a bit out of date, but still mostly relevant
***user3 is now known as ewemoa
<grantixx>Luis' website mockup looks great!
<grantixx>Also, I decided to go "all in" and am installing GSD on my other primary box! The only non-Guix centric box I have now is my HTPC and I'm slowly working towards Kodi on that front.
<rekado_>how can I get even closer to the build environment under which guix build operates? I cannot seem to find out why this configure step fails under guix build but not under guix environment --pure.
<rekado_>I would like to "see" and explore the actual environment used by guix build and investigate the error there.
<rekado_>it would be helpful if there was a way to reproduce this environment even more faithfully.
<taylanub>I tried launching an interactive shell from a build phase once via system* but it didn't work, probably due to how stdin is handled. maybe one can open some other communication channel
<ewemoa>rekado_: may be "guix environment ..." is relevant?
<rekado_>ewemoa: I *have* been using "guix environment --pure ...".
<ewemoa>rekado_: lol...ah, completely missed that part...sorry :)
<davexunit>rekado_: something wrong with guix environment?
<rekado_>davexunit: nothing wrong. It just doesn't seem to go far enough in my particular case.
<rekado_>I have a package that builds under guix environment but fails in guix build.
<rekado_>the failure is a configure step.
<rekado_>waf tests for a C compiler by generating a test.c file and runs GCC from the store on it.
<rekado_>under guix build it says it cannot find the test.c file (although it is in fact generated).
<rekado_>with guix environment I cannot reproduce this.
<rekado_>there also don't seem to be any env variables that could be blamed.
<davexunit>rekado_: well, the intent of guix environment isn't to reproduce the build container
<davexunit>that build container is much much much more restrictice.
<davexunit>I also have some software that builds fine under guix environment but fails its tests in the build container
<rekado_>I know that. I just hoped to be able to get closer to the exact build environment set up by guix build, so that I can investigate the issue more easily.
<rekado_>had it just been failing tests I'd happily ignore this. But since it's the configure step that's exhibiting this weirdness I'm a little more concerned about fixing it.
<davexunit>your shell environment doesn't reset any env vars does it?
<rekado_>I don't think so.
<davexunit>sometimes your bashrc or whatever may contain something like 'export PATH="..."'
<davexunit>which undoes what guix environment did.
<rekado_>well, my bashrc does add ~/.guix-profile/bin to the PATH.
<rekado_>the failure is a little too odd, though, to be caused by that.
<davexunit>hmm okay
<davexunit>you could try using the --norc --noprofile flags for the hell of it
<davexunit>to see if it reproduces anything.
<rekado_>will try that at home
<davexunit>I'm currently hunting down something similar
<mark_weaver>rekado_: I gave an okay to push 'ganv', but just realized that "Gtk" should be spelled "GTK+" in both the synopsis and description. if you could fix those before pushing, it would be good.
<rekado_>mark_weaver: will do. I'll only be able to push in a couple of hours anyway.
<rekado_>(still in the office, so I'll only do work-related packages.)
<rekado_>mark_weaver: thanks for the review!
<mark_weaver>np, thanks!
*grantix needs to figure out how to tell Slim not to use it's laptop screen as a display. There's some crazy shaking involved, trying to mirror and scale between the two.
<mark_weaver>grantix: you have multiple monitors?
<mark_weaver>I've tried multiple monitors after logging into xfce, and it doesn't seem to work very well. it treats the whole combined screen as a single monitor. but maybe I'm not doing it right.
<grantix>mark_weaver: Yeah, there's a way to turn the whole display off and update it and it works fine iirc -- but I don't know how to set that via Slim.
<grantix>I'm bassically using my Laptop as a desktop, so I'm not using the built-in display.
<grantix>I mean, once you get into the session it's not a big deal because you can have it evaluate a .xsession file.
<mark_weaver>grantix: it may be that you need to modify your xserver.conf somehow. see gnu/services/xorg.scm
<mark_weaver>at least for a way to hack it temporarily for yourself.
<mark_weaver>ultimately, the solution may be to get a better display manager working. I vaguely remember hearing that slim development is not very active, if at all.
<grantix>mark_weaver: Yeah, LightDM is kinda the modernish and activish solution.
*grantix will look into it a bit more, likely. He really isn't even going to touch that box until Wed likely. :^P
<mark_weaver>sure. I've never tried LightDM, but based on what I've heard it would be a welcome addition.
<mark_weaver>and if it's more actively supported and works better, we should just switch to it IMO.
<grantix>mark_weaver: Well, based on release dates -- SLiM last got released at the the end of 2013. LightDM a month ago. Before that, LightDM got released pretty regularly and SLiM had one release in 2013, 3 in 2012, then none between then & 2008.
<mark_weaver>would you like to package it?
<grantix>Yeah, I can and will add it to my list. The earliest I can start on it would be Wed.
<mark_weaver>no rush
*grantix should be studying for a test as we speak ... <_< >_>
<a_e>mark_weaver: Did your novena machine arrive?
<grantix>So it looks like the big depends areP libxlavier, polkit, gtk-doc, intitool qt4.
<mark_weaver>a_e: yes, that's what I used to bootstrap armhf
<a_e>Qt4 - that is not a sign of active development.
<grantix>a_e: It supports QT5 too.
<a_e>Nice! Because I wonder if it is worth buying one - according to crowdsupply website, it is still available.
<a_e>How slow it is?
<mark_weaver>grantix: libxklavier will be in the next core-updates merge
<grantix>I don't remember what's in the repo, so I sided on the side of caution.
<a_e>grantix: We have both, the latest qt4 and 5.
<mark_weaver>a_e: it's a lot faster than my MIPS machines
<grantix>Is "qt5-base" seperate?
<a_e>mark_weaver: Hm, I am not sure if that is a criterion...
<a_e>grantix: What do you mean by qt5-base? There is a package called qt, and one called (internally) qt-4.
<mark_weaver>I could get you some build times soon
<a_e>mark_weaver: That would be interesting!
<grantix>a_e: I typically use Arch's online package interface to list depends (feel free to tell me a better way" and one of the depends are "qt5-base" and I'm not sure if it's just a welrd way they package things or if it's really split like this. That being said, the don't typically move far from upstream.
<a_e>mark_weaver: Then our qt package should work. It should be a superset of qt5-base, logically.
<rekado>hmm, R's tests are failing on hydra but it works just fine on my workstation; see
<rekado>segfault even.
<a_e>Sorry, that was directed at grantix.
<a_e>rekado: Terrible! Just like elfutils.
<rekado>how to debug that? Does this indicate an actual problem with the package?
<mark_weaver>a_e: the build phase of gcc-4.9.2 took 3.27 hours on the Novena
<mark_weaver>a_e: did you notice that elfutils built successfully on one of your wip branches? I think it might have been wip-setuptools
<a_e>mark_weaver: For elfutils, I did not notice. So something non-deterministic...
<a_e>Concerning gcc, it takes about half an hour on hydra for x86_64 (but I do not know on how many cores). And 6h on mips.
<a_e>So 3h is not that impressive.
<mark_weaver>well, ARM is not as fast as modern Intel, that's known.
<a_e>I thought that maybe per MHz, it was not so bad.
<a_e>I suppose you bought just the board?
<mark_weaver>buying into the Novena is about supporting the creation of a laptop that was designed with us in mind, as opposed to Intel, where their modern systems simply cannot be used without huge binary blobs and back doors.
<a_e>mark_weaver: Agreed. On the other hand, it is crucial to have a fast development machine also. So currently, it looks more like an additional machine than one that could replace my laptop I use for almost everything now.
<a_e>rekado: It happens in a bash script. Did you have a look at it?
<mark_weaver>intel looks to be a dead end for the free software movement
<a_e>Something free _and_ fast would be nice!
<rekado>a_e: is the segfault in batch or in R? It seems to me that R is run from within a batch script and then segfaults. I'll look at it tomorrow.
<a_e>rekado: I would agree.
<davexunit>mark_weaver: agreed, intel is a dead end, unfortunately.
*davexunit types on intel machine
*mark_weaver also types on an intel machine
<mark_weaver>I'm very glad to have the Libreboot X60 and X200 in the meantime.
<davexunit>yes indeed
<taylanub>I built Chibi, but it can't find it's own .so now :\\ these super-barebones build systems can be frustrating...
<taylanub>it's just a C program; how can it bypass or be uncooperative with Guix's way of fixing dynamic library paths of executables?
<taylanub>(it works if I export LD_LIBRARY_PATH to /gnu/store/<chibi>/lib where the libchibi .so resides)
<a_e>That is definitely not normal.
<a_e>Normally, the linker writes the correct rpath.
<taylanub>might passing "-L." to gcc mess that up?
<mark_weaver>I doubt it
<mark_weaver>looking at the code, it looks like our ld-wrapper can only add rpaths for libraries linked in that already exist in /gnu/store/
<mark_weaver>and indeed, if you think about it, ld-wrapper doesn't know anything about where the library currently in the source directory is going to be installed.
<mark_weaver>I think the rpath for that library will have to be added in another way
<mark_weaver>I don't know how this is normally supposed to work
<a_e>It can be done explicitly. Look for "augment-rpath" in the package definitions.
<mark_weaver>please, let's not use augment-rpath if we can avoid it. for one thing, it doesn't work properly on arm
<mark_weaver>patchelf is an awful hack
<mark_weaver>adding (string-append "-Wl,-rpath=" out "/lib") to the link line should work
<mark_weaver>maybe adding LDFLAGS=^^ to #:make-flags is the right thing
<mark_weaver>taylanub: ^^
<taylanub>thanks, let me try
<mark_weaver>gst-plugins-base-1.4.5 fails tests on armhf, whereas 1.x worked.
<mark_weaver>we really need some armhf boxes in our build farm
<a_e>Bad luck!
<a_e>Yes, it would be nice to have some.
<taylanub>mark_weaver: worked! :)
<a_e>Is this armhf architecture 64 bit?
<mark_weaver>taylanub: yay!
<a_e>Hm , Wikipedia says "no".
<mark_weaver>a_e: no
<mark_weaver>a_e: here's a more precise article on the problems with modern intel systems that I was alluding to:
<a_e>Thanks, I will have a look.
<mark_weaver>this is the original message that jxself brought to my attention:
<mark_weaver>that message is quoted in this article:
<a_e>Several articles mention the purism librem 15 laptop.
<mark_weaver>it will also require a huge amount of blobs and backdoors to run.
<mark_weaver>even though it won't have this particular problem.
<mark_weaver>the folks on #libreboot can tell you more about this.
<a_e>It speaks about a blob in coreboot, which is a bit confusing.
<mark_weaver>right, coreboot comes with blobs, just like linux
<mark_weaver>most of the modern machines supported by coreboot require those blobs to run at all.
<a_e>Oh, I am confusing coreboot and libreboot.
<a_e>Reading up on libreboot now.
<rekado>I'm just happy to have found my "tribe" of like-minded people when it comes to hackable, libre hardware :)
<rekado>I was never happy among the "Linux" zealots.
<mark_weaver>me too!
<rekado>I noticed that any application with JACK as its input *must* also have libuuid as its input because the JACK headers contain this line: #include <uuid/uuid.h>
<mark_weaver>rekado: then libuuid should be in jack's propagated-inputs
<mark_weaver>would you like to fix it?
<rekado>is it only provided by util-linux?
<rekado>I can fix this. At this opportunity I would also remove the explicit util-linux/libuuid input from packages depending on JACK, if they still build after the change.
<rekado>(patch would go to ML before pushing, of course)
<mark_weaver>rekado: at present, that's where we're getting libuuid from. there's also
<mark_weaver>but debian uses the one from util-linux
<mark_weaver>I guess we should just keep using the one from util-linux unless someone can find a reason not to.
<mark_weaver>(and despite the name, it apparently works on hurd)
<mark_weaver>and kfreebsd