<djbclark>mark_weaver: eh I was wrong, n64 debian didn't turn out as well as I was, for some reason, thinking... ***Infiltra1or is now known as Infiltrator
***Infiltrator is now known as Infiltra1or
***Infiltra1or is now known as Infiltrator
***Infiltrator is now known as Infiltrator[spli
***Infiltrator[spli is now known as Infiltrator[spl]
***Infiltrator[spl] is now known as Infiltrator
<djbclark>mark_weaver: just looking at mailing lists posts and stuff - for some reason I thought it was core supported debian now - but from what I read not so much <djbclark>perhaps gentoo is the (technically) best english-friendly distro for 2f now <mark_weaver>the question still remains: what MIPS box to use for hydra.gnu.org? a server or fuloong-style box based on Loongson 3 would probably be best, but it's not clear how easy it would be to get one outside of China. <mark_weaver>but if need be, I think a YeeLoong 8133 would be sufficient. <jxself>Dates announced, for anyone that is interested in going. <mark_weaver>djbclark: btw, I notice that the HDMI port on the YeeLoong 8133 is blocked with a rubbery plug. Do you know what's up with that? <djbclark>mark_weaver: I'd guess the case was actually designed for another system, but don't know. <djbclark>mark_weaver: You can bbuy whatever from china by using a remailer like ETO. <mark_weaver>well, everything I've read about the YeeLoong 8133 says that it has an HDMI port. <jmd>Which package provides nl_langinfo ? <civodul>or are you talking of the same-named Guile feature? <jmd>No. I was talking about the libc one. <jmd>I think it's behaving badly in guix, but need to do some more experiments to be sure. <civodul>jmd: what makes you think something's wrong with nl_langinfo in Guix? <civodul>jmd: what makes you think something's wrong with nl_langinfo in Guix? <jmd>It's just a hypothesis at the moment, related to the errors that a_e reported with the pspp build. <jmd>But I must do some further investigation... <civodul>the chroot environment uses the C locale, FWIW <jmd>Yeah, nl_langinfo (LC_PAPERSIZE) seems to be undefined in the C locale. <civodul>indeed, the GNU libc has LC_PAPER but not LC_PAPERSIZE AFAICS <jmd>The bizarre thing is, that for all categories *except* LC_PAPER, nl_langinfo returns a string. <jmd>For LC_PAPER it returns a char * which should be cast to an int. <jmd>Now it is not documented, but looking at the implementation, nl_langinfo seems to return the empty string to indicate errors. <jmd>so in the case of LC_PAPER, how do I know if a return value should be interpreted as an int, or as a pointer to an empty string? <civodul>scheme@(guile-user)> ,m (ice-9 i18n) <civodul>scheme@(ice-9 i18n)> (nl-langinfo LC_PAPER) <civodul>though i'm not sure what "upper" means <civodul>so it returns NULL if locale info is missing <jmd>LC_PAPER was never in any released version of Posix. However it was once considered and was in many published drafts. <jmd>Therefore, it found its way into a lot of implementations. <jmd>How can I patch a package before guix builds it? <civodul>jmd: you can add a 'patches' field in its 'origin' <civodul>there are several occurrences of that in gnu/packages/*.scm <jmd>Why is xpdf.scm under gnu/packages ? <jmd>xpdf is not a gnu package. *civodul successfully built gcc-cross-boot0 on x86_64 <civodul>jmd: "gnu" here means "the GNU system", which includes non-GNU packages <civodul>IOW, "gnu/packages" should read as "packages of the GNU system" <jmd>Is there a list of packages which comprise the GNU system ? <jxself>But if a GNU package is a dependency on some non-GNU thing, doesn't that indirectly make the dependency part of the "GNU System"? <civodul>well in practice, you could take a free distro like Trisquel, and we'd probably want to have the same set of packages <civodul>being part of the GNU system != being a GNU package <civodul>30 years ago it was thought that a handful of what makes the GNU system would be non-GNU <jmd>How can I clean the old build directories <zacts>which gui programs are you guys trying to port? <jxself>"More packages, ideally in the GUI/desktop area (you can help! :-))." <jmd>There are a number of gui based apps. <zacts>have you guys ported Xorg yet? *zacts git clones the tree <jmd>In most cases there is no "porting" to be done. <jmd>Its just specifying dependencies and trying to get one's head around the guix language and philosophy. *civodul makes progress on core-updates <jmd>I'm running out of space on /tmp can someone tell me how to delete some of my old build directories? <civodul>jmd: they are automatically deleted when the build completes or fails (unless you passed --keep-failed) <civodul>the build results remain, but can be removed via "guix gc" <jmd>civodul: Yes. I have been passing -K <jxself>Is it RAM? I posted an idea about that to the mailing list. <jmd>won't guix gc also delete all my dependencies? <jxself>In short, how much RAM does Hydra have? <jxself>Mozilla says 4GB of RAM are needed to compile Firefox. I assume similiar requirements for IceCat and that less may result in memory-related errors. <civodul>but it's a VM, maybe we can ask for more <civodul>jmd: it'll delete anything that's unused <civodul>jmd: you could run "guix gc -C4GiB" for instance, to set a limit <jxself>So try for 4GB plus whatever else is needed to run whatever else is running. <jmd>civodul: Ok. Thanks. <civodul>jxself: just emailed the admins asking for more RAM :-) <civodul>we'll definitely need new machines real soon <civodul>last time i asked them to double disk space, and they said "yes, sure" <jmd>guix gc on its own doesn't seem to have done the job. <jmd>Is there an option I need to pass? <a_e>jmd: "guix gc" only works on /nix/store. <a_e>You can simply delete the build directories with "rm -rf /tmp/nix*". <a_e>Concerning paper size, whenever I call "xpdf foo.pdf", I get a warning <jmd>I have to be root to do that. <a_e>Config Error: No paper information available - using defaults <a_e>Maybe that is a related phenomenon. <a_e>Is being root a problem? If you can start the daemon. <jmd>Or at least be in the guix-builder group. <jmd>My daemon is started on boot by init.d <civodul>normally any user can talk to the daemon <civodul>the socket just has to be read/write for everyone <civodul>could you check whether that is the case? <a_e>civodul: But the daemon does not clean /tmp/nix-build for kept build trees, or does it? <mark_weaver>civodul: any progress on getting gcc-4.8 working on core-updates? <mark_weaver>hmm, I wonder if this will require rebuilding the bootstrap tarballs. <civodul>i'm positively surprised by that project :-) <jmd>Someone should write a C compiler in guile <mark_weaver>heh, I confess I've occasionally entertained that idea. *civodul was thinking of doing udevd in Scheme <mark_weaver>well, more specifically, I've thought about implementing a way to bootstrap GNU from an extremely small scheme interpreter. <mark_weaver>such that no precompiled binaries would be needed. nothing too big to audit and understand. <civodul>so you'd need a Bash implementation, Awk, Coreutils, etc. <mark_weaver>starting with a small mini-scheme core, building up more scheme functionality from within mini-scheme, and eventually a C compiler to bootstrap GCC. <mark_weaver>(though now I'd need a C++ compiler, which makes me unhappy. that's part of why I was very unhappy about the GCC people switching to C++) <civodul>mark_weaver: BTW, speaking of bootstrapping, if we had a tar module in Guile, that'd be one thing we don't need a bootstrap binary for <mark_weaver>well, bash/awk/coreutils/etc is only needed to run the build system. so an alternative would be to reimplement the GCC build system in Scheme, which I suspect might be less work. <civodul>i remember you wrote a tar reader some time ago, right? <civodul>it's less work to implement Bash in Scheme, really :-) <mark_weaver>but it probably wouldn't be much work to make it more full-featured. <mark_weaver>well, I suppose we wouldn't need "bash" anyway. we'd just need the minimum required by the build system, which is considerably smaller. <mark_weaver>but yeah, we could definitely investigate implementing more in Guile and thus reducing the set of needed bootstrap binaries. <zacts>@ home. let me git clone guix <zacts>and I wonder about adding clang/llvm to guix.. <civodul>zacts: i was just talking of bootstrapping issues <jxself>You mean that compiler that Apple has convinced people to work on for free until it gets good enough, after which time Apple will fork it and make it proprietary? <civodul>jxself: it already has its own proprietary extensions <zacts>clang/llvm has proprietary extensions? *zacts searches the web..