IRC channel logs

2013-11-13.log

back to list of logs

<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
<mark_weaver>djbclark: what did you hear about it?
<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>yes, I think that's probably true (about gentoo).
<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.
<jxself> https://www.fsf.org/blogs/community/libreplanet-2014-dates-announced-session-proposal-deadline-extended
<mark_weaver>I think this would probably make a good build machine for Guix MIPS: http://www.loongson.cn/product_info.php?id=36
<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.
<mark_weaver>Thanks for the tip about the remailer!
<civodul>Hello Guix!
<jmd>Hi Ludo
<civodul>hey
<jmd>Which package provides nl_langinfo ?
<civodul>jmd: libc
<civodul>or are you talking of the same-named Guile feature?
<civodul>(provided? 'nl-langinfo)
<jmd>No. I was talking about the libc one.
<civodul>ok
<jmd>I think it's behaving badly in guix, but need to do some more experiments to be sure.
<civodul>hmm nl_langinfo in Guix?
<civodul>jmd: what makes you think something's wrong with nl_langinfo in Guix?
<civodul>Guix doesn't explicitly use it
<civodul>hey jmd
<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>ok
<civodul>the chroot environment uses the C locale, FWIW
<jmd>Yeah, nl_langinfo (LC_PAPERSIZE) seems to be undefined in the C locale.
<civodul>LC_PAPERSIZE, didn't know that one
<civodul>indeed, the GNU libc has LC_PAPER but not LC_PAPERSIZE AFAICS
<jmd>I meant LC_PAPER
<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>hmm
<jmd>The manuel version of guix: http://www.manuguix.com/
<civodul>LC_PAPER is not in POSIX 2008
<civodul>in Guile i can do:
<civodul>scheme@(guile-user)> ,m (ice-9 i18n)
<civodul>scheme@(ice-9 i18n)> (nl-langinfo LC_PAPER)
<civodul>$1 = "upper"
<civodul>so it's a string
<civodul>though i'm not sure what "upper" means
<civodul>oh, found a bug
<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>Thanks.
<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"
<civodul>terminology... ;-)
<jmd>ok.
<jmd>Is there a list of packages which comprise the GNU system ?
<jxself> http://www.gnu.org/software/guix/package-list.html has a nice list.
<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>or "guix package --list-available"
<jxself>er; has
<civodul>yes
<civodul>well in practice, you could take a free distro like Trisquel, and we'd probably want to have the same set of packages
<jxself>GNU Python! ;)
<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
<civodul>nowadays, things are different
<jxself>Yeah. I'm just being silly.
<civodul>you chose the right example ;-)
<jmd>gtg
<jmd>How can I clean the old build directories
<jmd>??
<zacts>hello
<jxself>Ahoy there.
<zacts>which gui programs are you guys trying to port?
<jxself>Everything free? :)
<jxself>There's a discussion on guix-devel for version 0.5: http://lists.gnu.org/archive/html/guix-devel/2013-11/msg00011.html
<zacts>yeah, I saw that
<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>has i3wm been ported?
*zacts git clones the tree
<zacts>but when I get home
<zacts>I'm @ the cafe now
<jmd>In most cases there is no "porting" to be done.
<zacts>ok
<jmd>Its just specifying dependencies and trying to get one's head around the guix language and philosophy.
<zacts>I see
*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"
<civodul>good evening a_e!
<a_e>Good evening!
<civodul>congrats for IceCat
<civodul>for some reason it died again after 3600 seconds of silence: http://hydra.gnu.org/build/26060
<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>jxself: 2 GiB of RAM :-/
<civodul>but it's a VM, maybe we can ask for more
<jxself>Ah, that might be way...
<jxself>er; why
<civodul>jmd: it'll delete anything that's unused
<civodul>jmd: you could run "guix gc -C4GiB" for instance, to set a limit
<jxself>civodul: https://developer.mozilla.org/en-US/docs/Simple_Firefox_build
<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
<jxself>A billion gigabyte? :)
<jxself>er bytes
<civodul>as much as they can ;-)
<civodul>last time i asked them to double disk space, and they said "yes, sure"
<civodul>so we'll see ;-)
<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?
<civodul>a_e: right
<civodul>it doesn't clean 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>mark_weaver: yes, good progress!
<civodul>a lot of new stuff to do
<civodul>mostly due to GCC's switch to C++
<civodul>"Linux From Scratch" helps a lot
<civodul>i'm positively surprised by that project :-)
<mark_weaver>yes, I found it very helpful and educational.
<jmd>Someone should write a C compiler in guile
<mark_weaver>heh, I confess I've occasionally entertained that idea.
<civodul>you cwazy people ;-)
*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.
<civodul>all in Scheme
<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?
<mark_weaver>yes, although it only supports USTAR format.
<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>civodul: I like the idea of udevd in scheme :)
<mark_weaver>but yeah, we could definitely investigate implementing more in Guile and thus reducing the set of needed bootstrap binaries.
<mark_weaver>and the hardest parts of tar are already done.
<civodul>yeah tar seems doable
<zacts>hi
<mark_weaver>hi zacts!
<zacts>@ home. let me git clone guix
<civodul>gcc is getting on my nerves
<zacts>civodul: how so?
<zacts>and I wonder about adding clang/llvm to guix..
<jxself>Clang/LLVM?
*jxself hides in fear
<zacts>jxself: http://clang.llvm.org/
<jxself>Yeah.
<civodul>argh
<zacts>sorry
<civodul>zacts: i was just talking of bootstrapping issues
<civodul>np ;-)
<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?
<jxself>That one? :)
<zacts>hm..
<civodul>jxself: it already has its own proprietary extensions
<civodul>and so does NVIDIA
<zacts>civodul: really?
<civodul>yeah
<zacts>clang/llvm has proprietary extensions?
<civodul>of course, that's the whole point
*zacts searches the web..
<civodul>the OpenCL front-end, for instance
<civodul>and the NVIDIA back-ends
<civodul>the "interesting stuff"
<zacts>oh wow
<zacts>didn't know that