IRC channel logs
2015-03-31.log
back to list of logs
<rekado_>civodul: haven't heard of easybuild before. <civodul>mark_weaver: could you look at v2 of the cURL patch by Sleep_Walker? <taylanub>can I find a list of all libc component libraries like m, dl, pthread, rt, etc.? <civodul>taylanub: a simple way is: ls $(guix build glibc)/lib/lib*.so* :-) <rekado_>sounds good. Just need to find a new common name. <bavier>civodul: I've looked at easybuild a bit. <bavier>I don't know of anyone using it on Cray's <civodul>bavier: people are just using "module" with hand-built software? <civodul>i'm asking because HPC people at work are wondering about what packaging tool would suit their needs <civodul>Guix is a possibility, but it requires sysadmin cooperation <bavier>civodul: I do know some create modules for their own software, but frequently site support personnel end up building and creating any custom software <bavier>easybuild seems to address the multiple-supported-compiler-vendor issue fairly well <mark_weaver>has anyone else noticed display update problems with the new xterm (updated a while ago) <mark_weaver>when using a remote emacs via xterm, deleting characters or words in the middle of a line often fails to update the display properly. <mark_weaver>the characters to the right of the deleted bits are not moved to the left, as they should be. <bavier>mark_weaver: I've noticed the same <bavier>specifically, using DEL or BACKSPACE; C-d, etc work fine. <mark_weaver>I see there's a newer version, 317. I guess I'll try that first, else downgrade. <mark_weaver>wow, I pushed the xterm update only 20 minutes ago, and hydra has already built it on all platforms. <mark_weaver>I remember it taking an hour just to generate a new evaluation. <mark_weaver>I wonder if something on hydra has been optimized... <taylanub>mark_weaver: BTW we can also close the samba dangling .so references report, which had been fixed with 2d82880. no others seem to have been fixed by the samba fix though. <mark_weaver>taylanub: would you like to close the samba bug by writing a message to 20048-done@debbugs.gnu.org saying that it was fixed in 2d82880 and that you're closing the bug? <taylanub>didn't realize that I can do that, and that it's that smart :-) <mark_weaver>civodul's work is just to add a phase checking for these problems, right? <mark_weaver>if so, I think it's still worth filing a bug for boost <mark_weaver>sometimes we don't do this because we don't realize it fixed the bug until after commit, but if you happen to know about a bug that is fixed, it's good to add it. <mark_weaver>taylanub: you didn't actually close the bug, because you sent the message to 20048@debbugs.gnu.org instead of 20048-done@debbugs.gnu.org <taylanub>I thought it's smart and will parse my "fixed in XYZ" text :-) <mark_weaver>now I understand your comment "didn't realize that [...] it's that smart :-)" <mark_weaver>If it read the text and tried to guess whether you meant to close a bug, I would judge that to be too smart :) <taylanub>I know that GitHub does something like that... <taylanub>I think it was in commit messages, when the text includes "fixes #<bug_id>" <jxself>Heh, you expect things to be integrated? Ha! <mark_weaver>I'm toying with the idea of making my Novena a build slave for now, until I have time to do something else with it. <mark_weaver>however, it would have to be on the understanding that I'd take it back at some point, so if no other build slave materializes the substitutes for armhf would go away. <jxself>If given the choice between having one temporarily vs. not, I'm for temporarily. :) <mark_weaver>the thing is, almost no one can use guix on arm now, because most people's arm machines aren't powerful enough to build everything from scratch. so no one is actually using the armhf port. <mark_weaver>if we got some users, then maybe they would care about making sure we had a build machine <mark_weaver>so it seems to me that we have a bootstrapping problem <mark_weaver>the lack of continuous integration also caused us to break the armhf port and not notice until much later. <civodul>mark_weaver: if you want to lend your Novena that would definitely be an improvement <civodul>just let us know a bit in advance when you want to take it back <civodul>we should get in touch with the Novena people to see if they'd like to help us on that <civodul>but last i checked it was not simple to see who "the Novena people" are <mark_weaver>it's mostly Bunnie and Xobs, but Jacob Appelbaum is also involved <davexunit>yeah, bunnie and xobs are the folks to get in touch with. <civodul>does anyone have contacts with them? <davexunit>maybe they'd help us out if they like what we're doing <davexunit>I don't know either of their email addresses <civodul>at least you ordered something to them, so that's a first contact ;-) <civodul>good, we won't have to ask the NSA :-) <mark_weaver>civodul: I also seem to recall your name being listed beside Jacob <davexunit>so I'd basically just ask if they'd like to donate a board to use as an armhf build slave, noting that the novena is particularly appealing to us because we require machines to run blob free? <civodul>ISTR that zooko once came to talk about Novenas on this channel, but then disappeared <mark_weaver>davexunit: right, blob-free and also sufficiently powerful. <mark_weaver>(we need a box with a beefy CPU, lots of RAM, and SATA, among other things) <mark_weaver>it might be worth mentioning that we wouldn't need an FPGA for this, if that helps. <mark_weaver>civodul: btw, on the donations page, you mispelled 'librenote' as 'libremote' <mark_weaver>though I suppose it doesn't matter much. in retrospect I regret the name, since the box has freedom issues <mark_weaver>it might be usable as a headless box without that blob, dunno. <Sleep_Walker>I'm not much into English and grammer, but I think it is important and useful <civodul>could you just post a patch against that page? <taylanub>can one prevent a propagated input being propagated to a package, in that package's recipe? <civodul>taylanub: you mean to make it non-propagated without rebuilding the thing? <taylanub>civodul: if X propagates Y, and Z has X as an input, I want to prevent Y being input to Z. <taylanub>ok, will just temporarily make it non-propagated then <civodul>but depending on the effect you want to achieve, you could fiddle with CPATH or whatever env. var. is relevant in the buil <taylanub>hm, not worth the trouble for what I want to test, but good to know; in worst case we could probably fix Qt by hiding libxfixes (or libxshmfence) from its build process. <civodul>taylanub: BTW, while i'm at it, i'll remove all quoting in modify-phases, ok? <taylanub>(meanwhile I still have it on my TODO to patch all alist-* uses...) <Sleep_Walker>hm, either I have memory problems or the page changed since last time I checked - there is HW configuration already... <civodul>i think there's always been something about hardware config <davexunit>civodul, mark_weaver: should I CC you guys on this email? <bavier>civodul: I've been doing some Guix evangelizing in #easybuild <bavier>civodul: ha, no. They were interested <bavier>the usual questions about the relationship with Nix <bavier>which is interesting in the HPC realm where you'd be building on a login node for an application that's destined for a compute node. <bavier>e.g. login node might be AMD Interlagos, and compute nodes AbuDhabi <bavier>or intel login nodes and AMD compute nodes <bavier>the discussion was brought up in terms of build testing <bavier>that it would be neat to be able to still run the 'check' phase e.g. <bavier>something like our current build offloading, but mid-build <civodul>re cross-compilation, i'm not sure "real" cross-compilation is needed in such cases <civodul>because gcc is typically able to generate code for the various ISA variants, no? <mark_weaver>civodul: how hard would it be to support 'guix build --system' for arbitrary systems by running the builds within qemu? <civodul>mark_weaver: we'd need to hack the daemon, but maybe that's not too difficult <bavier>whether you'd be able to run the code being generated on the build machine <bavier>in many cases you'd be able to get by running compute node code on a login node, but at high optimization levels you might not <civodul>mark_weaver: actually no, it's better than this: we can write a "build hook" that does that (like 'guix offload') <mark_weaver>civodul: among other things, it would be useful for debugging one's packages on platforms one does not own. <civodul>damn, i wonder why nobody's done it before