IRC channel logs
2014-02-16.log
back to list of logs
<usrnix>Hi, anyone know if the fosdem talk is up anywhere yet? <mark_weaver>not the video anyway. the slides are available somewhere. <usrnix>mark_weaver: Ok thanks, will keep an eye open then <davexunit>I've been impatiently checking every day or so. <usrnix>Yea I read that 1.0 doesn't seem all that far off and I'm interested to see what that might require <phant0mas>we use inputs in the recipe for guix to know the dependecies, right? <civodul>i'll look at the patch within a couple of hours hopefully <civodul>currently hacking something for Guile's birthday ;-) <phant0mas>then how do I say I need the gnumach-headers from hurd.scm? <civodul>so you put the recipe for mig in hurd.scm, right? <civodul>then just add an 'inputs' field, like this: <civodul>(inputs `(("mach-headers" ,mach-headers))) <phant0mas>I want to pass to a flag at configure the position of the include folder build from gnu mach <civodul>phant0mas: in the 'arguments' field, use the #:configure-flags keyword <civodul>there are examples of that that you can grep for in gnu/packages <civodul>let me know if that's still unclear :-) <phant0mas>I think I did it , or at least it was succesfully built :-D <phant0mas>civodul: the link to that github repo you once worked on is helping me a lot :-D <mark_weaver>phant0mas: fwiw, the mach includes will automatically be put in CPATH, which might be enough by itself, dunno. <phant0mas>where have you been the whole day mark? I really started worrying that something happened to you :P <phant0mas>I was really starting to believe you were some kind of cyborg :P <davexunit>mark_weaver's hacking stamina is almost superhuman. <civodul>phant0mas: so your first patch is in :-) <mark_weaver>indeed, I'm very excited for guix on hurd! my thinkpad will be donated to that cause, I think. <mark_weaver>(my old thinkpad's screen has issues, and I want to move away from intel anyway, so it's basically a server now) <mark_weaver>*grump* more MIPS page size issues. while trying to run a freshly-compiled xetex (a test as part of the guix build): ./xetex: error while loading shared libraries: libicui18n.so.50: ELF load command alignment not page-aligned <mark_weaver>and indeed, I built 'icu4c' while running a kernel with 16K page size. <mark_weaver>and that library was built using g++, so I guess there's some problem in the toolchain :-( <mark_weaver>and I can't remove the old icu4c build from /nix/store without also removing the emacs that's I'm running running :-( <mark_weaver>lots of stuff is built on that library. what a pain. <mark_weaver>the amount of stuff that I've built on top of this faulty library is almost overwhelming :-( *mark_weaver buries his head in his pillow and cries <phant0mas>something tells me there will be no sleep for you :P <phant0mas>I really wish I could get my hands on a mips based pc <mark_weaver>well, it's a major drag, but I'm just going to have to carry a local modification in my own tree to icu4c, just enough to change its hash, until the next core updates merge. <mark_weaver>there's no way I'm going to delete the emacs I'm using and a bunch of other stuff, just to keep the same hash. <mark_weaver>and I don't want to move back to a 16K kernel, because then I'll be trapped there forever. <mark_weaver>(I won't be able to build things that work on the 64K kernel) <mark_weaver>though I wonder if there are other things broken that I don't know about yet :-( <mark_weaver>of course, I should also try to find the bug in binutils... <phant0mas>guys because I don't have the super human stamina of mark ,I will go to bed <phant0mas>and I have to get some job done in the hardware lab at my univercity tomorrow <mark_weaver>well, I searched my entire /nix/store for alignment problems, and icu4c is the only library that contains an improperly sligned segment. <mark_weaver>and looking at the build system, it seems that they're doing clever things with the link. <civodul>mark_weaver: alignment issues in the ELF file? <mark_weaver>yes, in all of the shared libraries produced by icu4c, there's one segment that's aligned according to the current page size of the kernel, instead of the maximum architecture page size. <mark_weaver>fortunately, I see that there are new versions of icu. we're using 50.1.1, and there's both 50.1.2 and 52.1. <mark_weaver>so I can solve my immediate problem by just upgrading. <mark_weaver>it would be nice to fix the underlying problem, of course, but the fact that it seems limited to icu4c makes me less concerned. <mark_weaver>python, gtk, qt, openldap, and texlive all use icu4c, so I've got some rebuilding to do. <mark_weaver>still, we're improving the state of the art on that front quite a bit :) <mark_weaver>civodul: should icu be upgraded in master? if so, should it be upgraded to 50.1.2 or 52.1? <mark_weaver>(on my system I'm upgrading it to 52.1 for now, and will see how that works out) <civodul>mark_weaver: i guess latest is better? <mark_weaver>improvement in 52 include: CLDR 24, Unicode 6.3, Plurals for fractional values, Islamic Umm al-Qura calendar, DateFormat parse leniency controls and Lao dictionary based word segmentation, short weekday names, new time zone format patterns, display context for date format and locale display names. <mark_weaver>dependencies are: python, gtk, qt, openldap, and texlive. <civodul>mark_weaver: core-updates is probably more reasonably, then