IRC channel logs


back to list of logs

<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...
<lfam>That is a lot
<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>np, that happens
<civodul>as long as you don't break sciguile...
<orly_owl>so, arm port yet? (:
<rekado>there are actually two test failures (after fixing it), both because it tries to dlopen lib/; I'll try to fix those later.
<rekado>hmm, this is the actual error: "OSError: /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/lib/ invalid ELF header"
<rekado>the file is just an ld script containing a redirection to
<rekado>not sure if it would be sufficient to swap out "" with "" 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.
<rekado>bug in scheme-mode?
<xd1le>mark_weaver: we were talking about xinit yday but fyi it's apparently a
<xd1le>hack anyway: (if you
<xd1le>don't already know)
<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
<xd1le>possible (i'm not sure)
<toothbrush0>sorry, wrong window
<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>oh got it
<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>upvote time!
<civodul>Steap: ↑
<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"
<ngz>err 7.8.4.
<guaraqe>I'm kinda new here, how much would be difficult to make a recipe for ghc 7.10?
<toothbrush0>ngz: that's the bootstrapping compiler
<toothbrush0>that was actually an existing error in the package
<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.
<toothbrush0>ngz: no stress :)
<guaraqe>toothbrush0: fantastic ;)
<civodul>toothbrush0: yeah, congrats!
<davexunit>civodul: nice!
<davexunit>front page!!
<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
<davexunit>python's tox predates
<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
<pksadiq> /msg fsbot what is
<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
<pksadiq>cpjjl: fsbot is clever enough :-)
<cpjjl>pksadiq I didn’t see its answer!
<amz3>it's no in channel
<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
<civodul>cpjjl: oh, bad reputation?
<amz3>Steap: did you have a chat with tox people?
<Steap>amz3: not yet
<civodul>"a chat with tox"?
<Steap>A chat with the tox devs using tox :)
<cpjjl>civodul: I read that on HN a few months ago (fsbot didn’t tell you that did it pksadiq? :))
<cpjjl>no idea whether it’s true or not though
<civodul>oh, ok
<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>that's an evil WM!
<bavier1>civodul: pun or serious?
<civodul>silly pun ;-)
<civodul>bavier1: in (gnu services xorg), we generate an xserver.conf that contains at least one FontPath entry
<civodul>xlsfonts should show that
<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?
<civodul>not an easy task i admit :-)
<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.
<toothbrush0>but we'll finally have Idris :)
<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!
<Steap>toothbrush0: 105 patches :D
<davexunit>holy hell that's a lot of patches
<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
<cehteh>apropos security:
<toothbrush0>taylan, Steap: thanks :$
<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.
<bavier>toothbrush0: will do, thanks
<Gamayun>cehteh: Heh!
<alezost>rekado: re "opening bracket breaks font-lock": it's a usual thing for all lisp modes. That was the reason for <>
<keverets>the first feature of mutt on 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
<keverets>has that been considered?
<davexunit>keverets: our notmuch package includes notmuch.el
<davexunit>I use it every day.
<davexunit>ls $(guix build notmuch)/share/emacs/site-lisp
<paroneayea>all my friends are hopping on for VOIP
<paroneayea>and it's free software and peer to peer
<paroneayea>time to package for guix
<davexunit>sounds great
<paroneayea>AND they provide autotools based tarballs
<paroneayea>this looks like it might be easy for once
<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 in
<paroneayea>telephony.scm seems as good as any
<daviid>paroneayea: looks cool indeed, didn't know about it, tx!
<davexunit>paroneayea: yeah, sounds fine.
<davexunit>ring looks like a more developed tox
<davexunit>curious what the pros/cons of each are
<keverets>davexunit: in my .emacs I have:
<keverets>sorry bad paste buffer
<daviid>anyone uses ekiga?
<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>keverets: your load path is surely wrong
<davexunit>you did 'guix package -i notmuch' yes?
<davexunit>it's important to remember that things aren't just installed into /usr or whatever
<davexunit>you need to configure load paths
<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
<davexunit>ls ~/.guix-profile/share/emacs/site-lisp
<keverets>that shows notmuch.el, .elc, and associates
<davexunit>(add-to-list 'load-path (concat (getenv "HOME") "/.guix-profile/share/emacs/site-lisp"))
<keverets>davexunit: that did it. thanks muchly
<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>keverets: definitely!
<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>ah ok
<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>yeah, right
<civodul>ideally even things like recutils would have autoloads
<civodul>such that M-x rec-mode would DTRT
<civodul>maybe that's difficult
<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>i've noticed a really weird discrepancy between the packages that are claimed to be in GHC/core: <> versus what is actually provided. notably, haddock, old-time, old-locale, template-haskell aren't provided :(
<toothbrush0>civodul: okay, yay!:)
<toothbrush0>then there's egg on my face: i hadn't tried yet
<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
<toothbrush0>bavier: no rush, and thank you.
***JamesJRH_ is now known as JamesJRH