<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:
<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.
<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>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>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>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.
<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?