<davexunit>hey everyone. I have a WIP package for Redis (http://redis.io/). 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 127.0.0.1 should work, as well as 'localhost' (via a /etc/hosts entry, no real nameserver) <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. <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>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_>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? <davexunit>sometimes your bashrc or whatever may contain something like 'export PATH="..."' <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>you could try using the --norc --noprofile flags for the hell of it <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.) *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>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. <grantix>Yeah, I can and will add it to my list. The earliest I can start on it would be Wed. *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. <a_e>Qt4 - that is not a sign of active development. <a_e>Nice! Because I wonder if it is worth buying one - according to crowdsupply website, it is still available. <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. <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. <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. <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. <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>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 <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>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>gst-plugins-base-1.4.5 fails tests on armhf, whereas 1.x worked. <a_e>Yes, it would be nice to have some. <a_e>Is this armhf architecture 64 bit? <a_e>Hm , Wikipedia says "no". <a_e>Thanks, I will have a look. <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>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>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. <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 <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>I guess we should just keep using the one from util-linux unless someone can find a reason not to.