IRC channel logs
2014-09-11.log
back to list of logs
<civodul>Ulrar: maybe you can send the patch as is, with explanations on what's at stake? <Ulrar>You mean just the .patch file ? <civodul>these are modifications to the Lua package, right? <Ulrar>Yes, I just add a patch and patch-argument line in the scm, and a .patch file in patches that add some rules in the Makefile <Ulrar>Shouldn't actually change anything, the package used to only create a .a, now it will also create a .so <davexunit>toxemicsquire: I'm one of the developers, though I don't have deep knowledge of how everything works. I'm not the maintainer. <toxemicsquire>I have a question, what's the progress on the GNU HURD port? <davexunit>toxemicsquire: I think it's still in pretty early stages. there's 1 person who is working towards packaging all of the things needed for the hurd. <Ulrar>civodul: I did change my patch to address their comment, just failed to send it to the list :/ <Ulrar>See the forward from Cyril Roelandt <civodul>but the forwarding mangled the patch <civodul>and please remove those '#' signs in the .patch <phant0mas>after the yesterday's git pull ,after each build , I get either guix build: error: fport_fill_input: Connection reset by peer or guix build: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': Connection refused <civodul>i mean, between the time where it works, and the time where it no longer works <phant0mas>civodul: nothing I just start a build, it finishes succefully and when I use guix build it says the above <phant0mas>this happens only if something is actually built <civodul>phant0mas: if it's reproducible, can you check what happens to guix-daemon in the meantime? does it terminate? how? etc. <civodul>or could it be that there are several daemons trying to listen on that socket? <civodul>actually hydra-server (the web server of hydra.gnu.org) was being DoS'd again <civodul>i've just banned the offending subnetwork <civodul>(it was listed on projecthoneypot.org) <Svetlana>make hydra distributed across few servers ? <civodul>well, compilation is already distributed across a bunch of "build slaves" <civodul>and it turns out to be the weakest machine :-/ <civodul>probably it's just a bot or a spider and doesn't target anything in particular <Ulrar>Mh, no one packaged ruby yet :( <civodul>and i think davexunit was interested into it as well <civodul>perhaps you could ping Pjotr, or take over the patch? <phant0mas>civodul: After I came back from the university, did a reboot and tried to reproduce the error. It didn't reappear yet. I am looking into it but it may actually was another daemon trying to use the same socket. <phant0mas>btw I have already booked the air-tickets for brussels for fosdem 2015 :-D <civodul>i haven't done that yet, but i should be there <DusXMT>Is `no' an actuall command, or is it a misconfiguration? If so, what does it do? <DusXMT>And more importantly, where can I get it if iut's a real command, Debian doesn't seem to know of it <DusXMT>Nevermind, looking at emacs.am, I can see it's supposed to be emacs <Steap_>DusXMT: 'yes' is a real command, never heard of 'no', though :) <Steap_>Maybe it's the output of a configure check <Steap_>what's around line 3905 in the Makefile ? <DusXMT>So yes, it's emacs. I just disabled it in Makefile.am for the time being <Steap_>ok, so $(EMACS) is "no", gotta find out why <DusXMT>I think it's because configure didn't detect emacs and it isn't considered a fatal error, but then it tries to use it <DusXMT>Perhaps emacs modules should be made optional? (i.e. not compiled if emacs is not available) *DusXMT should perhaps look into `configure --help' before editing Makefile.am <Ulrar>Is there a way to get the full path of a dependency ? To compile the tcl plugin in weechat, it needs tclConfig.sh, which apparently is in /gnu/store/...-tcl/lib <Ulrar>it can't find it, so I can specify the full path to the configure but I don't know how to get it <Ulrar>I guess while building it's symlinked somewhere <jxself>Linking directly to something in /gnu/store/whatever seems like a bad idea. <davexunit>Ulrar: yes, you can get the full path by examining the inputs alist <davexunit>jxself: yeah, hardcoding that is a baaad idea. <Ulrar>which won't return something that's in /lib I think, or is it different of the shell one ? <davexunit>Ulrar: you may have seen build scripts that have (which "bash") or something <Ulrar>yeah, I use it to replace sh and file in some files <davexunit>Ulrar: the inputs alist will get you the package root dir <davexunit>(string-append (assoc-ref inputs "foo") "/lib/bar.so") <davexunit>well, you need to write the function that has 'inputs' bound. where are you doing this? <davexunit>only the build process has access to that information <Ulrar>So there is no way to pass to configure the path of tcl's lib ? <davexunit>perhaps you really need to modify a search path <Ulrar>Well I don't know anything about tcl, but it seems strange to put a .sh in /lib <Ulrar>looking at the configure, I believe it does look into lib. don't know why it doesn't find it <bavier>Ulrar: you can use the %build-inputs variable in #:configure-flags <davexunit>or rather, the package macro wraps the code in a lambda? <davexunit>Ulrar: sorry for leading you down the wrong path <Ulrar>davexunit: No problem, thanks for trying :) <Ulrar>So the only missing plugin will be ruby, and that should be as simple as uncommenting the input when ruby package is created <davexunit>Ulrar: I tried packaging Ruby, couldn't get it to build and pass tests. <davexunit>someone else also submitted a not-quite-working ruby package <davexunit>but I really want ruby packaged so we can begin gem->guix importing! <Ulrar>yeah, civodul showed me earlier, I sent an email to him and he said he'd continue working on it when he'll have more time <Ulrar>ruby is pretty much the only weechat plugin I use, all the scripts I made are in ruby :( <davexunit>I should post my package recipe, too, just to have more code out there for whoever finishes it up. <davexunit>ludo will be able to knock it out, for sure. <jxself>Hmmm. A chicken-and-egg problem it seems. I was thinking of packaging up Free Pascal for Guix but it's written in Pascal itself and needs a working Pascal compiler already in order to build it. <davexunit>is there some other free pascal implementation that can build it? <jxself>I've not looked into others yet. <jxself>Perhaps that's the next thing to go do... <davexunit>or if there's a specific free pascal release that can be used for bootstrapping? searching hasn't turned up much for me yet. <bavier>jxself: I encountered the same difficulty with GHC <jxself>They should make it easy for people to get a copy of their software when they don't already have a copy, right? :) *tadni` is strongly considering writing up a blog post about installing GNU on a dedicated box. <tadni`>Okay. That's what all my blog posts default to. <tadni`>Just wrote an introduction and roadmap for the blog series. <jxself>I added Free Pascal to the wishlist instead. <tadni`>Probably not going to publish it till Sat. *civodul runs the whole shebang with LUKS and everything :-) <jxself>Also, since you're back, maybe you'll have an idea of how to package Free Pascal for Guix. <jxself>A chicken-and-egg problem it seems. I was thinking of packaging up Free Pascal for Guix but it's written in Pascal itself and needs an already-working Pascal compiler already in order to build it. <civodul>wasn't there a Pascal-to-C converter? <tadni`>jxself: Pascal itself is not free? <tadni`>And if not, why is Free Pascal dependent on a non-free implemntation? <civodul>but it depends on itself, which is quite common for compilers <tadni`>Man, guix pull really needs some progress reporting. <tadni`>What's it actually do, to notify it's working? <civodul>try it and let me know what you think ;-) *tadni` goes to pull the latest, to get the latest guix pull. <tadni`>That was probably my biggest usability issue with guix actually.