<lfam>Any reason why copy-file would make the copies zero length? <toothbrush0>Ugh, this is so depressing, i still have to create sensible patches out of 89 new packages... <daviid>OT how do we edit a savannah git repo description? <daviid>ok, must send a support request still, sorry for the noise <rekado>bleh, ant cannot be built with GCJ on mips :( <rekado>my recent update to python-scipy broke the build :( Fixing it now. <civodul>as long as you don't break sciguile... <rekado>there are actually two test failures (after fixing it), both because it tries to dlopen lib/libm.so; I'll try to fix those later. <rekado>hmm, this is the actual error: "OSError: /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/libm.so: invalid ELF header" <rekado>the file is just an ld script containing a redirection to libm.so.6 <rekado>not sure if it would be sufficient to swap out "libm.so" with "libm.so.6" in the Python sources. <rekado>font-lock in gnu/packages/python.scm fails for me in the "configure-openblas" section of python-scipy. <rekado>the culprit seems to be the opening bracket of "[atlas]" <rekado>when it's in the first column following expressions are not fontified properly in Emacs. <rekado>adding a space before fixes this. <xd1le>mark_weaver: we were talking about xinit yday but fyi it's apparently a <xd1le>so not sure if it's worth it to support it. <xd1le>although maybe some manual way by using dmd to start X from a tty could be <cpjjl>Hi, does someone know how to build the GuixSD installation image? <cpjjl>the build instructions I saw seem to be for the package manager <cpjjl>guix system disk-image --image-size=850MiB gnu/system/install.scm <cpjjl>didn’t read until the end :) <rekado>cpjjl: note that this is not the way to install GuixSD, just to build the image. <cpjjl>yes rekado, I also have to dd it on a usb key and follow the instructions <cpjjl>but the images already availables are (to me) outdated <cpjjl>that’s why I want to build one <cpjjl>in fact, they don’t contain this patch: <cpjjl>(yes, I’m still trying to use guixsd on an encrypted root…) ***dfh- is now known as dfh
<civodul>cpjjl: ah good, let us know how it goes! <civodul>this might be the first time i submit something to HN, woow! <toothbrush0>I'm about to send a huge amount of patches (roughly the first half) to the ML. My apologies in advance for the copious amount of spam. <ngz>toothbrush0: Isn't there a problem in 1/43, you seem to hard-code "/ghc-7.4.8" <guaraqe>I'm kinda new here, how much would be difficult to make a recipe for ghc 7.10? <toothbrush0>at that point, 'version refers to the version being built, not the bootstrap, hence when the version numbers aren't equal, it fails. <toothbrush0>guaraqe: i've just submitted a patch to include 7.10.2 <ngz>toothbrush0: ok, thank you for the explaination. <civodul>i still don't understand how this works, but it's nice! <cpjjl>but yes, there is a name collision <cpjjl>I also thought it was about tox.chat <civodul>i somehow assumes that Python's tox was the first thing that would come to people's minds <cpjjl>it seems it’s not the case, even though I agree it should <amz3>it's python specific also I'm not sure there is an equivalent in ruby <Steap>We should just call tox "guix-tox" from now on <cpjjl>pksadiq it’s a skype free alternative which has a pretty bad reputation <amz3>there is post about Go+Guix, it would be nice to reply to the person about the state of it <cpjjl>pksadiq I didn’t see its answer! <Steap>amz3: do we even have go packaged ? <amz3>I don't know, but I remember some people working on go <civodul>Steap: we have GCC's Go front-end, but not the "genuine" Go compiler <amz3>Steap: did you have a chat with tox people? <Steap>A chat with the tox devs using tox :) <cpjjl>no idea whether it’s true or not though <bavier1>I have an application (evilwm) that uses the "old" x server font infrastructure, and fails to start because it can't find fonts, any ideas? <civodul>bavier1: in (gnu services xorg), we generate an xserver.conf that contains at least one FontPath entry <civodul>now, we could add more entries in there <civodul>maybe you could try that and run the thing with 'guix system vm'? <bavier1>civodul: thanks, I hadn't thought to look there <civodul>bavier1: do you think you could review the GHC patches that toothbrush0 posted? <toothbrush0>civodul, bavier1: i've just finished the second batch, i'm about to send. they're slightly nicer in that i've strictly added one package per commit. <toothbrush0>It was rather a pain to go through the list of added packages and pick out the dependency-leaves by hand each time :p. <taylan>toothbrush0: you deserve a medal :D <taylan>100+ whopping GHC packages. I don't use Haskell myself, but thanks a ton for the work! <davexunit>good read, perhaps relevant to us in helping steer users towards running systems that are more likely to be safe from NSA and other such orgs <bavier>civodul, toothbrush0: sure, I'll look through the Idris patches <toothbrush0>actually, i should refactor some of those patches... in my laziness last night i grouped 4/5 packages in some of the earlier patches. <toothbrush0>Andreas says that's evil and i should redo them :P so bavier, assume that i'll split the patches when browsing. <keverets>the first feature of mutt on mutt.org is "color support", but though the system (ubuntu in this case) install of mutt renders color by default, my guix install of mutt-1.5.23 does not <keverets>it looks as though they both link against libncursesw which I assumed handled the color munging for the terminal, but now I'm not so sure <keverets>really, I'd avoid all of this and use notmuch in emacs if the guix build of notmuch included notmuch.el <davexunit>keverets: our notmuch package includes notmuch.el <davexunit>ls $(guix build notmuch)/share/emacs/site-lisp <keverets>davexunit: my apologies... I was sure that I looked for it in the past but it didn't come up <paroneayea>ACTION looks at guix/gnu/packages/*.scm and tries to pick a module to dump ring.cx in <daviid>paroneayea: ring.cx looks cool indeed, didn't know about it, tx! <keverets>(autoload 'notmuch "notmuch" "notmuch mail" t) <keverets>but M-x notmuch results in: Cannot open load file: No such file or directory, notmuch <keverets>this may be more of an emacs question than a guix question, but they're both from guix packages so I assumed it would just work as it does in Debian <civodul>iyzsong: thanks for all the package updates! <davexunit>it's important to remember that things aren't just installed into /usr or whatever <keverets>davexunit: yes, "guix package -i notmuch" which installed 0.20.2 into /gnu/store/fszs8vl5sl5hpfs88469ah5b72xcvskx-notmuch-0.20.2 <davexunit>keverets: the important thing is that it's now available in your user profile <keverets>ah, I'm not used to having to configure an extra load path and didn't notice it in the manual <keverets>that shows notmuch.el, .elc, and associates <davexunit>(add-to-list 'load-path (concat (getenv "HOME") "/.guix-profile/share/emacs/site-lisp")) <keverets>being that there's no "/usr" equivalent to guix, would it make sense for the guix package of emacs to include the current guix-profile/share/emacs/site-lisp by default? Or would that be harmful in other ways? <civodul>it turns out there have been changes in this area lately <civodul>if you use the Emacs modes that come with Guix, then things should work out-of-the-box in Emacs <civodul>plus you get a bunch of neat Guix tools in Emacs <civodul>alezost: i think guix.el does not take care of share/emacs/site-lisp tho, only share/emacs/site-lisp/guix.d, right? <alezost>civodul: nope, it should take care of both <civodul>oh but the difference is the autoloads i guess <civodul>for instance, the autoloads for rec-mode (part of recutils) are not loaded <keverets>civodul: I'm using /gnu/store/jl57vx1g559z36lgqby822hphfd6rnbx-emacs-24.5 and the earlier mentioned /gnu/store/fszs8vl5sl5hpfs88469ah5b72xcvskx-notmuch-0.20.2 which required the extra .emacs load-path munging <keverets>oh, is it a matter of adding the guix.el instead of changing load-path? <civodul>keverets: yes, if you follow the "Emacs Initial Setup" thing above, you'll get that plus the other nifty features <keverets>I initially used a binary installation, then subsequently "guix package -i guix" <guaraqe>during installation my hard drive is identified as /dev/sdb, and a such I have to put it on the config file. After reboot, it complains that it cannot find "/dev/sdb1" that is my main partition (because its sda probably) and when I put the partition label "main", it complains it cannot find it, am I doing something wrong? <alezost>civodul: indeed, load-path is augmented only for the packages with …-autoloads.el <civodul>alezost: i wonder what should be done for "hybrid" packages like recutils, notmuch, etc. <alezost>Since all such packages are installed in "~/.guix-profile/share/emacs/site-lisp/", I think this directory just should always be added to `load-path' and that's it. <alezost>The other packages (from "guix.d" dir) should have autoloads anyway <civodul>ideally even things like recutils would have autoloads <alezost>It can be done only manually, because "rec-mode.el" doesn't have ";;;###autoload" cookies, so autoloads cannot be generated for this package. <civodul>ok, this one is a bad example then :-) <alezost>yeah, but I agree: if a package contains ";;;###autoload" cookies, we should use our 'emacs-generate-autoloads' procedure to make …-autoloads.el <toothbrush0>bavier: okay, i've managed to split the patches into one package per patch. i've also added comments wherever tests are disabled, and made sure that they're disabled for a reason (dlist was the only new package where they worked, in the end). <toothbrush0>apparently James Trotter has also got Agda working, so that's really cool :) For me proof-general would be next, but that might be a lot of work too... <civodul>toothbrush0: proof-general is already here :-) <toothbrush0>but anyway, save only a few packages, we're at package-parity with the latest Haskell Platform :D <bavier>toothbrush0: cool. I'll go through the patches later tonight ***JamesJRH_ is now known as JamesJRH