IRC channel logs


back to list of logs

<mark_weaver>Is there scheme code already in guix to parse *.drv files?
<civodul>Hello Guix!
<viric>ei civodul
<viric>pri eo, ĉu temas pri eo_XX?
<viric>aŭ eo_FR, eo_US...
<civodul>mi ne scias precize
<viric>it's hard to manage about the country
<civodul>estis eo_UY antaŭ
*civodul posts dmd road map
<viric>ah, I never saw eo_UY
<civodul>oh UY is Uruguay actually, nothing special
<davexunit>civodul: where can I see that? the dmd page?
<davexunit>oh, the mailing list. :)
<civodul>yep :-)
<civodul>davexunit: "interesting" that SDL2 is modified-BSD whereas SDL1 is LGPL
<civodul>do you know what happened?
<davexunit>civodul: valve software, I imagine.
<civodul>that's a gaming thing, right?
<davexunit>the lead SDL dev was hired by Valve
<davexunit>and they make great use of SDL2 in their games and Steam
<civodul>ah Steam, ok
<davexunit>yeah, it's just the usual corporate aversion to the (LGPL
<civodul>do i get it right that we have almost everything to build guile-2d now? :-)
<davexunit>civodul: getting there. :)
<davexunit>I still need FTGL and freeimage, unless someone's already packaged those. I can't remember.
<civodul>FTGL yes, freeimage no
<davexunit>I'll work on freeimage next then. :)
<davexunit>and also the SDL extension libraries.
<civodul>good ;-)
<viric>what game do ypu envision to add?
<davexunit>viric: I don't have a game to add
<viric>oh :)
<davexunit>viric: ^ I'm adding my game engine/framework
<jxself>Oh, positive version numbers?
*jxself was kinda hoping to see a zeroth version on the way to positive numbers
<civodul>i decided on a strictly positive number to make it sound like it's "industrial-strength" :-)
<bavier`>I'm having some trouble with the #:test-target argument in python-build-system
<bavier`>'Unrecognized keyword'
<civodul>bavier`: there's actually no such parameter in guix/build-system/python.scm, hence the error
<civodul>but it's an omission, i think
<bavier`>It would be useful to me at present.
<bavier`>I could probably work around it for the time being
<bavier`>it looks like the python-dogtail package could also use a #:test-target argument
<civodul>bavier`: try this:
<bavier`>civodul: that does the trick
<civodul>i'll commit it
<bavier`>also, I have a package recipe for gnu parallel that I can send a patch for
<civodul>excellent, please do!
<civodul>damn, Twitter and Google+ logos at
*civodul asks for advice regarding cross-compilation of GCC 4.8:
<civodul>viric: have you cross-compiled GCC 4.8?
<civodul>bavier`: i pushed Parallel + #:test-target
<civodul>viric: you don't do that for Nanonixos or anything?
<viric>not anymore. It's in a tirkesto. :)
<mark_weaver>FYI, my YeeLoong successfully built 'hello' on the new core-updates (with GCC-4.8), and the Loongson 3A machine has built a whole lot of things on that branch without problems (I have it trying to build almost everything in the repo).
<civodul>mark_weaver: weee!
<civodul>so i think we can merge soon
<civodul>we "just" need to figure out a fix for
<civodul>but that can happen after the merge
<civodul>(it prevents cross building bootstrap-tarballs)
<mark_weaver>on the other hand, my x86_64 box is having some mysterious problem with core-updates. when I try to build 'emacs', it reports "Unbound variable: gnu:gettext" from xorg.scm:1306:6
<mark_weaver>I tried 'make clean' to no avail.
<civodul>'make clean-go && make' succeeds?
<mark_weaver>I didn't try 'clean-go', just normal 'clean', which seemed to clear out the .go files anyway. but 'make' succeeds, yes.
<mark_weaver>I had just deleted a whole bunch of stuff using "guix gc --delete", because my disk was full. not sure it that has anything to do with it.
<civodul>nothing to do with the unbound variable
<mark_weaver>yeah, I can't imagine it would
*civodul tries
<civodul>ok, reproduced
<mark_weaver>ah, good.
<mark_weaver>strange that it didn't happen on the Loongson 3A, which successfully built emacs. but maybe that was a slightly older revision of core-updates.
<mark_weaver>ah yes, the Loongson 3A didn't yet have the latest gettext changes.
<zacts>mark_weaver: are you testing guix on the Loongson?
<mark_weaver>I've ported Guix to Loongson/MIPS, yes.
<mark_weaver>hmm. I notice that gettext.scm is not exporting anything.
<mark_weaver>oh, nevermind.. duh
<mark_weaver>'define-public' does that.
<civodul>i'm looking at the backtrace
<civodul>for the unbound 'guix:gettext' is in acl.scm
<civodul>of course removing the newly-added #:use-module (gnu packages xml) from gettext.scm solves the problem...
*mark_weaver is confused. why does that fix it?
<civodul>it's a circular dependency issue
<civodul>well my guess
<civodul>another workaround: replace all the guix:gettext by (@ (gnu packages gettext) gettext)
<civodul>which hints at the custom-interface modules
<mark_weaver>it would be nice if we had a better way to cope with circular module dependencies, in general.
<mark_weaver>given that syntax (macros) are the only things that are really needed from the dependent modules at compile time, it seems like it should be doable, as long as there are no circular syntax dependencies.
<mark_weaver>s/dependent modules/dependencies/
<civodul>that property actually holds
<civodul>except here, where we have renamers
<civodul>looking at resolve-interface: when there's a #:renamer, we iterate over the used module eagerly, instead of lazily
<civodul>that's related to the comment: "XXX - should use a lazy binder"
<civodul>in boot-9.scm
<civodul>so i suspect that's the problem
<mark_weaver>I think you're right.
<civodul>fortunately, this is easily worked around by renaming "gettext" to "gnu-gettext", say :-)
<civodul>but we should file a bug for Guile, i think
<mark_weaver>renaming 'gettext' to 'gnu-gettext' sounds sensible to me.
<civodul>let's do that
<mark_weaver>I have to go afk for a while. happy hacking!
<zacts>happy hacking!
<zacts>so what all is involved when porting guix to a new architecture?
<zacts>let's say I want to port guix to powerpc, or ARM?
<civodul>zacts: the short story is at
<civodul>in practice, there are platform-specific issues
<civodul>for instance:
<zacts>I see. thanks!
<zacts>how about porting to kFreeBSD?
<zacts>would it be feasible?
<zacts>I guess I'm interested because I would one day be interested in porting gnu to HURD or to the minix3 servers/μkernel.
<zacts>I like not having to rely only on the linux kernel
<zacts>(although linux is great, it supports more devices and more architectures)
<zacts>(this would be probably at least 4 - 5 years from now..)
<civodul>supporting the Hurd is part of the plan
<civodul>we need a glibc release that can actually be used to that end
<jxself>And isn't HURD part of GNU already? So porting GNU to itself seems like a strange idea...
<zacts>jxself: well of course
<zacts>minix3 is already ported to the beagle bone black
<zacts>I think it would be an interesting project to somehow port GNU userland and toolchain to minix3
<zacts>my main interest in minix3 is learning how operating systems work
<zacts>it is currently under a BSD license, but I think that they added exceptions specifically for the purpose of also eventually releasing the servers/μkernel under the GPL
<zacts>just fyi
<jxself>Hmmm. I'm not sure if a GPL exception could be implemented that way...
<zacts>jxself: ?
<zacts>why not?
<civodul>my understanding was that they actually work hard to avoid GPL'd stuff
<zacts>the current license allows for relicensing by the authors
<jxself>I always thought it had to be the other way around, with the copyleft side granting the exception.
<civodul>reusing NetBSD's libc, LLVM, etc.
<zacts>civodul: well yes they are porting NetBSD
<zacts>and use Clang / LLVM
<zacts>but, I've heard chatter about them also releasing core OS components under the GPL also on day
<zacts>no reboots of the OS on core server updates, ultra reliability, security, and relatively fast. targeted for embedded
<zacts>and it has its own book.
<zacts>my goal is to learn from the minix3 book, which is almost identical to Modern Operating Systems by the same author, except that it applies the material to minix3 also..
<zacts>I will probably eventually work on the HURD as it is targeting general purpose desktop systems
<zacts>and I do like the philosophy of gnu, for sure!
<jxself>HURD seems very interesting. In an alternate universe I wonder what things would be like today if everyone run after Linus yelling "OMG Linux! Linux!! Linux!!! Linux!!!! linux!!!!111111"
<jxself>er; if everyone hadn't
<zacts>jxself: well for what it is the Linux kernel is awesome imo
<zacts>but yeah you are correct
<jxself>Although HURD came first, if I remember my history correctly. Then people up & run away...
<jxself>Just wondering how things might have turned out differently if that didn't hapen.
<jxself>I can't spell today...
<zacts>x15/propel seems more promising to me
<zacts>I've looked at the code and from the asthetic aspect of x15. It looks small, simple, and I like the coding style
<zacts>as it stands now gnumach is kind of messy imo
<zacts>I wish rms wasn't so weird.. I won an fsf t-shirt, and he freaked out about it.
<zacts>oh well
<zacts>rms is cool though..
<jxself>Why would RMS care if you got a shirt?
*jxself feels like he's missing part of the picture
<zacts>jxself: there was a contest where you had to guess where rms was in a picture. I guessed correctly and won a t-shirt. I was going to be mentioned in the Gnu newsletter, but when rms found out about the contest he got all upset that he didn't know about it.
<zacts>so, he asked them to not mention it at all in the newsletter
<jxself>Seems strange. I wonder why he'd care.
<jxself>Well, congratulations on winning either way.
<jxself>I remember that contest.
<zacts>jxself: I think he just has that personality, you know
<zacts>it happens
<jxself>I looked at the picture metadata hoping it'd reveal useful info.
<jxself>But couldn't find his schedule going back that far.
<zacts>iirc it was somewhere in mexico one of the pyramids
<zacts>I randomly guessed from pyramids in mexico and south america and got the correct pyramids
<zacts>I think that was it: ^
<jxself>That sounds about right.
<zacts>but it's kind of hilarious, I won a t-shirt and rms got upset about it.
<zacts>anyway, it's something I can brag about to my nerd friends
<zacts>(I wish I could have been mentioned in the gnu newsletter, for nerd cred, but ah well..)
<zacts>one of my friends goes to CMU, and is interested in Machine Learning. I'm trying to get him to get a 100% free gnu/linux box. I think he would like guix.
<zacts>I mentioned thinkpenguin and los alamos computers for a decent free computer, but for the stuff he wants it is out of his price range
<zacts>*free software computer
<zacts>8G of RAM
<zacts>for example.. and an i9 cpu
<mark_weaver>"fully documented" computer is probably the relevant hope at this point.
<mark_weaver>computers based on free designs are somewhat further off, but the milkymist project is working on that.
<mark_weaver>or, at a somewhat less ambitious level, the novena laptop project.
<zacts>I will only purchase my computers from thinkpenguin, I've done business with them before and really like them.
<zacts>although I live like two hours away from los alamos national laboratories
<mark_weaver>if you must have intel-based systems, then thinkpenguin is probably your best bet, yes.
<mark_weaver>I've left intel behind though.
<zacts>mark_weaver: my requirements are >= 500G hard drive, fast virtualization in cpu for qemu-kvm/virtualbox-ose (fast enough to build hurd in like 20min), >= 4G RAM
<zacts>that's really it basically
<zacts>I wouldn't mind using AMD or another CPU manufacturer if it met those needs
<zacts>this is for a laptop
<zacts>for a desktop/home server I would like the same requirements as above, but several hard drives @ least three
<zacts>for data integrity
<mark_weaver>I guess you need Intel or AMD then.
<mark_weaver>so you'll have to cope with the big binary blobs and back doors.
<zacts>I also plan to get a beagle bone black for my ssh + emacs-erc server
<zacts>mark_weaver: what is the best CPU in terms of blob-free?
<mark_weaver>given your requirements, I think there's no good answer for you, unfortunately.
*zacts cries
<jxself>Sometimes you have to give up on the technical requirements.
<mark_weaver>it's a very bad situation. it seems that we will have to design and build our own systems from the silicon up.
<jxself>The ThinkPad X60s can be used without the proprietary microcode for example.
<zacts>jxself: I'm willing to do that, but I also want to do OS level development eventually
<jxself>It just runs the microcode that came in the CPU instead.
<zacts>of the embedded, the beagle bone black seems to be well documented and pretty much blob free afik
<mark_weaver>I'm using the YeeLoong 8101B, the same laptop RMS uses, but it involves a lot of sacrifices in terms of computing power.
<jxself>And battery life.
<civodul>and screen size :-)
<mark_weaver>hey, whose side are you guys on? :)
<zacts>mark_weaver: I wouldn't mind purchasing a YeeLoong or equivalent, and using it as my main laptop
<civodul>mark_weaver: heheh :-)
<zacts>I mainly just use emacs / UXTerm / ssh / iceweasel
<civodul>actually i think free software ought to free users from scheduled obsolescence
<zacts>civodul: for sure
<zacts>jxself: sweet, I will look at purchasing one next semester
<zacts>civodul: I love making old hardware run as new with gnu/linux
<civodul>i have a few old SPARCs that i had grabbed for that purpose
<civodul>my partner has used a UltraSparc for some time
<civodul>but now we're on fairly recent Intels, and the SPARCs are in the basement :-/
<zacts>I've heard that RISC processors are nice
<civodul>they are
<zacts>(from the radio show GNU world order @ least)
<zacts>I listen to those and other radio shows from time to time
<zacts>I want to visit france and spain. I have some friends and family out there.
<zacts>but I've never been
<zacts>I would love to see where bud powell lived and would hang out in france..
<zacts>sorry, I'm listening to some chick corea plays bud powell right now..
*zacts just realized that I flooded the channel with useless chatter. /me is sorry. :|
<zacts>anyway, I gtg for now. I will try to port chibi scheme to guix this week
<civodul>good idea
<mark_weaver>sounds good!
<civodul>we have only 6 scheme implementations IIRC
<civodul>that's definitely insufficient ;-)
<zacts>lol. well gtg
<mark_weaver>6 implementations is apparently too few a number to consider a scheme standard to be a success.
<mark_weaver>(not that I think R6RS is perfect)
<civodul>R6RS was implemented by 6 implementations?
<civodul>maybe more no?
<mark_weaver>yeah, maybe more. depends on how complete the conformance has to be to count them, I guess. but admittedly, I'm getting that "6" from something ijp said recently. I haven't attempted a count in a while.