IRC channel logs
2015-05-28.log
back to list of logs
*davexunit packaged ruby-rspec <davexunit>no choice but to disable tests for it due to circular dependencies, though. <davexunit>in fact, I'm finding *a lot* of circular dependencies among ruby gems <zacts>the US senate voted that humans have no effect on global climate change <zacts>so doesn't look too promising <zacts>to be fair I still personally need to read the actual bill voted on, and the results from a primary source of information <mark_weaver>zacts: yeah, well, that's not surprising. I can't read that article though, since I have no account there. <davexunit>ewemoa: awesome! just make sure all those dependencies are really needed <davexunit>not sure if they're just copied from the ratpoison package. <iyzsong>and many inputs is propagated (eg: if add libxft, then freetype and fontconfig won't need add explicit). <ewemoa>thanks, davexunit and iyzsong -- i'll try to prune out unnecessary pieces <rekado_>I just booted my reconfigured system and noticed that dmd doesn't appear to be running. <rekado_>error: connect: /var/run/dmd/socket: No such file or directory <rekado_>the guix-daemon also is not running. <rekado_>when I want to start dmd as root I get this error: <rekado_>system-error("open-file" "~A: ~S" ("No such file or directory" "/gnu/store/h73wb9cx2ld81k591k0kaxf35cyv6gz5-dmd-0.2/etc/dmdconf.scm") (2)) <rekado_>Any ideas what might have caused this? <rekado_>I now specified a dmd.conf file I found somewhere in the store *rekado_ has to go now, will check this out later. *civodul fearlessly upgrades whole profile, TeX Live included <rekado__>when I installed python-pillow it seemed not to have installed openjpeg. When I did "from PIL import Image" it threw me an error about not finding the openjpeg library. <rekado__>then I ran guix build openjpeg and the error disappeared. <rekado__>also, "guix gc -d" happily deletes openjpeg, even though it should be used by python-pillow. <rekado__>I have this python-pillow installed: /gnu/store/93pyli2rcm90cgcwb3xx8qvlkbqxq8mg-python-pillow-2.7.0 <iyzsong>so I guess, openjpeg is dlopened by PIL, need to be patched? <iyzsong>rekado__: I unpack the egg file, the '_imaging.cpython-34m.so' does have a rpath entry to openjpeg, but python-pillow strip it from runtime deps. <sepi>Hi. Is it possible to somehow use http mirrors instead of ftp? I'm getting PASV not implemented errors when trying to install guixsd behind a firewall <rekado__>when I "strace python3" and then "from PIL import Image" I see that it tries to open libopenjpeg in various directories, including an openjpeg store directory that does not currently exist in my store: <rekado__> /gnu/store/sc26v48d00xs0i3fkyvp719ajdr5p1mx-openjpeg-2.1.0 <sepi>hmm, it seemes that I had some other network issues after all. now it's downloading <iyzsong>rekado__: yes, the runtime depends are filter by some Nix magic, since the egg file is compressed, I guess it fail to add openjpeg as a runtime depend. <rekado__>iyzsong: how can this be? The package definition for python-pillow states that openjpeg is an input. By what magic is this input removed at install time? PIL still knows about the path to openjpeg at runtime as can be seen by its attempt to find the library there. <iyzsong>“Nix detects runtime dependencies automatically by scanning for references”, I don't know the detail though <civodul>it's a conservative GC, it basically scans for all /gnu/store strings in the files <taylanub>and in this case compression messes it up it seems? ouch. <civodul>yes, but i've never seen that happen <civodul>typically the only compressed files that are installed are man and info files <rekado__>I don't understand at what point our explicit input would be dropped. <civodul>once the build has completed, the daemon scans for residual /gnu/store references in the result, and stores that in the database <civodul>ooh, but is python-pillow a .egg file? *civodul looks at taylanub <taylanub><iyzsong> rekado__: yes, the runtime depends are filter by some Nix magic, since the egg file is compressed, I guess it fail to add openjpeg as a runtime depend. <civodul>so does python-build-system asks for compressed eggs? <civodul>iyzsong, mark_weaver: just pushed a fix for the profiles issue <civodul>i'm happy to say that downloading texlive from hydra.gnu.org went like a charm :-) <civodul>there's a saying in French: "we should talk more about trains that are on time" <davexunit>yeah, easy to spend too much time talking about the things that don't work. *davexunit pushes patch for new 'guix environment' option <civodul>davexunit: still, did you gather a backtrace or something from your failed download? <civodul>yeah i think somebody reported it before <davexunit>if it happens again I will be sure to get the backtrace <civodul>sounds like a connection lost or something <davexunit>in other news, I'm learning how to use Chef at work. <davexunit>the amount of effort needed to attempt to make things "idempotent" is quite scary, since it's an imperative system. <davexunit>I think it's a good learning opportunity, though. <davexunit>I told the person that's giving me a crash course in Chef about Guix and he was interested. <civodul>you should get them to allow you some 10% or 20% to work on guix ops ;-) <davexunit>I'll be learning a lot of stuff that will be relevant to 'guix deploy' <davexunit>this has also been motivation to start packaging ruby libraries as fast as I can. <civodul>do you have an idea of how much is missing for your applications? <civodul>it's for web deployments i guess, right? <davexunit>the biggest issues are the javascript, ruby, and java dependencies. <davexunit>the low-hanging fruit right now are system services: percona, redis, nginx, etc. <davexunit>elasticsearch is an example of a large Java application we depend on. <davexunit>I feel like I need to devote my time to marketing to get more people to help with this stuff ;) <rekado__>I'm going to package a machine learning library (libsvm); which of the existing modules do you think is appropriate? <rekado__>not sure if "machine-learning.scm" is a bit too specific. "science.scm" would be too generic. <davexunit>there are a lot of machine learning tools out there <rekado__>I see that shogun actually should belong to that machine learning module as well. <civodul>so machine-learning.scm would make sense <iyzsong>civodul: thanks for fixing 'gtk-icon-themes' hook! for the trouble I caused :-) <civodul>iyzsong: np, that was an easy one ;-) <civodul>and i wanted to upgrade my profile, too :-) <mark_weaver>regarding failed downloads: it's also quite common for me to have large downloads from hydra like texlive outputs fail in the middle, sometimes multiple times before succeeding. <mark_weaver>I wonder if it's related to my ISP's complex packet filtering. in any case, probably the solution is to resume the transfer from where it left off in this case, as supported by 'wget' and other such tools. <mark_weaver>iyzsong: and thank you for the gtk-icon-themes hook! <davexunit>civodul: how "live hackable" is dmd right now? <davexunit>I'm using it as a user services manager, and I find myself wanting to tweak service definitions and restart them frequently. <civodul>mark_weaver: right, i remember we discussed it before <civodul>davexunit: it's not really live hackable, apart from 'deco load' <civodul>one thing we need to do is to add a REPL server <civodul>so that people can easily shoot themselves in the foot ;-) <mark_weaver>davexunit: I would guess that it's possible to live hack it via 'deco load', or by creating a service that starts a REPL server, but the big problem is that if you make a mistake it will bring your system down :-( <davexunit>mark_weaver: the use-case I have in mind is using dmd for a user service manager. <mark_weaver>davexunit: well, in that case, mistakes will only bring down your user session :) <davexunit>also, we could greatly limit what may crash dmd by using the cooperative REPL server in the dmd event loop. *alezost has the same wish (live hacking of "user" dmd) <davexunit>and wrap server polling with the appropriate exception handler <civodul>my idea was to start the REPL server on a named socket so that file permissions apply <mark_weaver>davexunit: yes, the cooperative REPL server would be better. it would be good to avoid threads in dmd so that it can freely fork and run scheme code in the children without exec'ing. <davexunit>mark_weaver: though the threads would still exist for the server and clients. <davexunit>but I guess you mean that the dmd event loop itself does not have to deal with threads <davexunit>mark_weaver: the cooperative server still uses threads <davexunit>but can be integrated into a single threaded event loop <mark_weaver>preserving dmd's ability to fork and run scheme code within the child processes would be very helpful for making dmd more robust. or at least that was my first thought on how to make it more robust. <mark_weaver>the difficulty is in reading from the socket without blocking <mark_weaver>well, it may not matter in this case, because probably the parent process of DMD should be very minimal, and to run user code within children only. or at least that's what I've been thinking about. <davexunit>I'd like to hack on dmd at some point once I have clear idea of an improvement to make. <davexunit>I like using it as a user service manager a lot, though I currently suck at writing stoppable services ;) <mark_weaver>davexunit: that would be great! DMD definitely needs lots of work. <davexunit>I like that I don't have to fiddle much with how every desktop environment uses a different mechanism for automatically launching programs upon log in <davexunit>I just tell it to start dmd and everything is taken care of <DusXMT>Wait, dmd can be ran as a user, as a personal daemon manager? That sounds pretty darn neat <taylanub>FWIW systemd can do that too in recent versions (including the one in Debian 8). I changed my @reboot cron jobs to use user-systemd instead recently, and it wasn't too bad. <mark_weaver>ahhh, all those icons I've been missing are now working properly. thanks iyzsong! :) <davexunit>taylanub: so now we really need a REPL server for dmd so we can have a one-up on systemd ;) <davexunit>I wonder if the ideas around functional reactive programming could be applied to dmd in order to make it more hackable. <mark_weaver>for now, I'd be glad if it had things like socket activation and automount activation to automatically handle dependency ordering, and supported restarting services after 'guix system reconfigure'. <mark_weaver>I'm not quite sure how functional reactive programming could be usefully applied to DMD. what did you have in mind? <taylanub>mark_weaver: basically just a job that is executed when crond is started (which is hopefully once per boot) <davexunit>mark_weaver: I'm not sure, either, but the notion of objects "reacting" to changes of their dependencies could apply. <mark_weaver>using tricks like socket activation, automounts, etc, systemd mostly avoids the need to explicitly specify the dependencies. <davexunit>sounds like we should definitely do the same. <sneek>Welcome back alezost, you have 1 message. <sneek>alezost, civodul says: thanks for the tip about the font! <davexunit>alezost: nice to see --manifest support added to guix.el! :) <alezost>davexunit: I'm glad too :-) (I have not pushed it yet) <mark_weaver>alezost: nice dmd config! btw, do you have a stumpwm package for guix? <mark_weaver>alezost: also, I like your hack to make ~/.config/guix/latest a symlink to your git directory. that's better than my hack. <taylanub>that's a neat hack indeed. the full recompilation of 'guix pull' is always annoying. <davexunit>alezost: yay, I can fix my gpg-agent service thanks to seeing yours! <rekado>on my freshly reconfigured system I have a problem with dmd. <rekado>it's running but I cannot use "deco" because there is no /var/run/dmd/socket file. <rekado>this also means that I cannot halt or reboot the system. <alezost>mark_weaver: no, I don't have stumpwm package, I just compile it using sbcl (thanks to taylanub for this package) <alezost>davexunit: actually I don't use emacs daemon these days, I took that emacs-daemon config from my old systemd user unit; I'm not sure if it still works properly <alezost>rekado: perhaps your dmd uses some other socket for some reason <mark_weaver>rekado: what's the output of: ls -ld / /var /var/run /var/run/dmd ? <mark_weaver>rekado: since dmd is responsible for mounting all filesystems except for the root partition, it creates /var/run/dmd/socket on the root partition. if you then mount another filesystem on /var or /var/run, its socket will be hidden. <mark_weaver>also, we clean up /tmp and /var/run at boot time, also before any other filesystems are mounted. <mark_weaver>and several services try to create things in /var before mounting any other filesystems. <mark_weaver>so, you will have various problems unless /tmp and /var/run are on the root partition. we don't currently support having those on separate partitions. <davexunit>mark_weaver: socket activation seems cool, but each service needs to support it. <mark_weaver>davexunit: ah, indeed that's true. well, thanks to the rise of systemd, I guess such support will become more common <davexunit>so we'd need some extra code to differentiate between a socket activatable service and other services. <rekado>mark_weaver: /var is on the root partition. In fact, everything is. On that machine I only have one partition mounted. <mark_weaver>rekado: okay, and the output of that 'ls' command I suggested? <rekado>mark_weaver: a moment. I don't have network on the machine ... <rekado_>(I only have one LAN cable here, so I just switched to the misbehaving machine.) <rekado_>I now *do* have a socket file and "deco status dmd" gives no errors. <rekado_>I have not changed *anything* except for plugging in a LAN cable and enabling the network interface. <rekado_>In the same shell session further up "deco status dmd" fails with "error: connect: /var/run/dmd/socket: No such file or directory" <rekado_>I experienced this problem two times before, each after a fresh reboot. *rekado_ wonders why he's always experiencing these odd problems... <rekado_>I'll just try a reboot *again*, see if I can reproduce the magic fix. <gnusosa>I'm so confused about guix build and substitutes. Which one do I make use of to avoid any compilation made in a small system? <gnusosa>or there is no way to avoid a minimal compilation by a system? <gnusosa>Sleep_Walker: right, but that means that machine that publishes needs to build the packages(substitutes) before hand right? <rekado_>the paste above is a complete, minimal session in which the problem is demonstrated and fixed --- by running dhclient (wth?) <Sleep_Walker>but if you trust hydra, you can let it build all the packages for you <gnusosa>Sleep_Walker: I just want to have my own <gnusosa>Sleep_Walker: so I do have to do guix build emacs and then publish from that node? <Sleep_Walker>to have binaries you need to either compile on your machine from source or trust some remote source of binaries (hydra in our case) <Sleep_Walker>so yeah, building and publishing emacs on some machine is way to provide it for other machines <Sleep_Walker>when there are substitutions available, they should be used - are you sure that the package which you were building locally was present on your build machine (with the same hash)? <gnusosa>I thought guix would take care of that, so are you saying I have to pass the complete path? or at least hash+package? <Sleep_Walker>ah, you mean that if the package (with the right hash) is missing on local machine and remote build host, it should be built remotely and installed locally as remote substitution <gnusosa>Sleep_Walker: basically, what I want to do is have a guix daemon on two small netbooks, that don't compile anything, and have my big boxes compile and build stuff for them. <gnusosa>Sleep_Walker: so in this case, the two small netbooks should bring down the substitutes through `guix package -i` right? <gnusosa>Sleep_Walker: and never build anything (the small netbooks) <gnusosa>Sleep_Walker: is there any other way to achieve this? <gnusosa>guix offloading and substitutes got me very excited. <gnusosa>but I can't seem to make it work as expected :( <gnusosa>rekado: any experience with that? ^^^ <rekado_>I stopped playing with offloading when I discovered that I would need to set up lsh first. <rekado_>then I noticed that I don't need it so badly. <gnusosa>yeah i had to do that part of setting up lsh <gnusosa>it wasn't as bad when I found what was going <rekado_>"it seems to offload some bits but still compile some components in the machine" <-- what does that really mean? <gnusosa>rekado: for instance, node A which is calling the build, should offload all of the needed pieces to node B (Bigger box), in my case what I saw is that some derivations where being build in node A, and then offloading to Node B. <gnusosa>rekado: not offloading everything to Node B <mark_weaver>gnusosa: what's an example of something that you built that wasn't offloaded? <gnusosa>mark_weaver: for instance openldap? i think that's the correct name. <mark_weaver>okay. I don't know that wouldn't have been offloaded <gnusosa>mark_weaver: ultimately, I might be doing this wrong, in order to achieve want I want. ^^ <gnusosa>I will try with substitutes and build all in Node B, and have Node A call for the substitutes. <mark_weaver>rekado: can you mail bug-guix@gnu.org about it, including that transcript? <rekado>after reconfigure (again) it's fine. <rekado>I only replaced my list of services with %desktop-services and removed a couple of use-service-modules (?) <rekado>my previous configuration was almost identical to the template (before desktop-services were introduced). <mark_weaver>rekado: if you can provide a config and precise guix version (git commit) that causes the problem, we could investigate further. <rekado>I think I'd rather not bind other people's resources on a problem that has disappeared after reconfigure. <rekado>it's unsatisfying that I don't know why it happened, but I think it's not worth spending time on it, especially since only I was affected.