IRC channel logs

<civodul>Hello Guix!

<Sleep_Walker>good

<Sleep_Walker>morning

<civodul>rekado, bavier: have you heard of http://hpcugent.github.io/easybuild/ ?

<rekado_>civodul: haven't heard of easybuild before.

<civodul>mark_weaver: could you look at v2 of the cURL patch by Sleep_Walker?

<civodul>i think you reviewed v1

<Sleep_Walker>yes, please!

<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_>I need to package argtable (http://argtable.sourceforge.net/), an command line parser library for C. Any suggestions what module would be the most appropriate home?

<civodul>good question :-)

<civodul>there's already popt

<civodul>both could go to the same module

<rekado_>sounds good. Just need to find a new common name.

<rekado_>"argparsers.scm"?

<bavier>civodul: I've looked at easybuild a bit.

<bavier>I don't know of anyone using it on Cray's

<mark_weaver>civodul,

<mark_weaver>civodul, Sleep_Walker: will do!

<civodul>rekado_: sounds good!

<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

<civodul>(which is often a big "if")

<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>which is also suboptimal

<civodul>ok

<bavier>easybuild seems to address the multiple-supported-compiler-vendor issue fairly well

<civodul>yeah

<mark_weaver>Sleep_Walker: review sent!

<mark_weaver>has anyone else noticed display update problems with the new xterm (updated a while ago)

<mark_weaver>?

<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

<mark_weaver>ah, good. I'm glad it's not just me :)

<bavier>specifically, using DEL or BACKSPACE; C-d, etc work fine.

<davexunit>I've noticed that too

<mark_weaver>I see there's a newer version, 317. I guess I'll try that first, else downgrade.

<mark_weaver>upgrading seems to fix it :)

<mark_weaver>update pushed

<bavier>mark_weaver: great

<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...

<Sleep_Walker>mark_weaver: thanks!

<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.

<taylanub>I also just found a new one: boost ( http://sprunge.us/FMaV ). should I report it though, or does civodul's work make my reports/method redundant?

<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>taylanub: also, when making a commit that fixes a bug, it's good to include a line "Fixes <http://bugs.gnu.org/NNNN>." in the commit log, e.g. as done in 4d58122

<taylanub>OK

<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: thanks for you work on this!

<mark_weaver>*your

<taylanub>np :-)

<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>ugh, I see

<taylanub>I thought it's smart and will parse my "fixed in XYZ" text :-)

<mark_weaver>no worries, just send another brief message :)

<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...

<Sleep_Walker>it could also give advices about possible solutions :)

<mark_weaver>:)

<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.

<mark_weaver>civodul: ^^ thoughts?

<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.

<davexunit>I still have yet to use it.

<mark_weaver>if we got some users, then maybe they would care about making sure we had a build machine

<davexunit>still learning the quirks of the novena

<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.

<mark_weaver>we would also need to fix <http://bugs.gnu.org/20102> before we can hope to have any arm users.

<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

<civodul>(apart from Bunnie)

<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>ok

<civodul>does anyone have contacts with them?

<davexunit>maybe they'd help us out if they like what we're doing

<mark_weaver>that would be great!

<mark_weaver>they don't know me

<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>ok

<davexunit>bunnie doesn't specify it on his blog

<davexunit>maybe we should email the company, kosagi

<mark_weaver>I can find their emails in the git repo, hold a bit

<davexunit>ah yeah, it's probably there

<davexunit>I didn't probe too far ;)

<mark_weaver>Sean Cross <xobs@kosagi.com>

<mark_weaver>bunnie <bunnie@bunniestudios.com>

<mark_weaver>civodul: ^^

<davexunit>:)

<civodul>good, we won't have to ask the NSA :-)

<mark_weaver>heh :)

<mark_weaver>civodul: I also seem to recall your name being listed beside Jacob

<mark_weaver>Appelbaum's in a recent paper

<civodul>does one of you want to email them?

<civodul>mark_weaver: i translated https://gnunet.org/mcb so that might be the thing

<civodul> https://gnunet.org/morecowbell

<mark_weaver>I don't usually have good luck with such emails.

<civodul>davexunit maybe?

<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?

<mark_weaver>civodul: yes, that's the paper I was thinking of

<civodul>some more dirty spying...

<civodul>davexunit: yes, exactly

<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.

<davexunit>yes

<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.

<davexunit>okay

<civodul>yeah

<civodul>you can point them to http://www.gnu.org/software/guix/#donations

<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

<civodul>oops

<jxself>Quasilibrenote? :)

<civodul>which issues?

<mark_weaver>a blob is needed in the BIOS to initialize video.

<civodul>oh, right

<mark_weaver>it might be usable as a headless box without that blob, dunno.

<civodul>i fixed the web page

<mark_weaver>thanks!

<Sleep_Walker>civodul: could I add some more details to that page?

<Sleep_Walker>like HW requirements

<Sleep_Walker>I'm not much into English and grammer, but I think it is important and useful

<Sleep_Walker>*grammar

<civodul>Sleep_Walker: sure

<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>or copy/paste somewhere

<Sleep_Walker>OK

<taylanub>(just for testing purposes, for now)

<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.

<civodul>that's not possible

<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

<civodul>*build

<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>civodul: 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>heheh :-)

<civodul>i think there's always been something about hardware config

<Sleep_Walker>sorry then

<civodul>np!

<davexunit>civodul, mark_weaver: should I CC you guys on this email?

<davexunit>I'm about to send it

<civodul>davexunit: if you want, yes

<davexunit>okay

<davexunit>figured it might be good

<mark_weaver>davexunit: sure!

<mark_weaver>thanks :)

<bavier>civodul: I've been doing some Guix evangelizing in #easybuild

<Sleep_Walker>heh

<davexunit>mark_weaver, civodul: sent

<mark_weaver>davexunit: thanks!

<civodul>cool!

<civodul>bavier: what was their reaction?

<civodul>are they hating us now? ;-)

<bavier>civodul: ha, no. They were interested

<bavier>the usual questions about the relationship with Nix

<bavier>cross-compilation came up

<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.

<civodul>oh right

<civodul>but that's mostly for the Phi no?

<bavier>civodul: no, many other cases

<bavier>e.g. login node might be AMD Interlagos, and compute nodes AbuDhabi

<civodul>ooh, i see

<bavier>or intel login nodes and AMD compute nodes

<bavier>for various reasons

<civodul>yeah

<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>but have it offloaded

<civodul>okay

<bavier>something like our current build offloading, but mid-build

<civodul>we're not there yet ;-)

<bavier>that's what I said ;)

<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?

<bavier>it's an ISA issue, yes

<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')

<civodul>bavier: yeah

<mark_weaver>civodul: among other things, it would be useful for debugging one's packages on platforms one does not own.

<civodul>yes

<civodul>damn, i wonder why nobody's done it before

<mark_weaver>heh :)

<civodul>anyway, good night/day!

<mark_weaver>g'night!

IRC channel logs

2015-03-31.log