IRC channel logs


back to list of logs

<ewemoa>davexunit: is it this? doesn't look packaged
<davexunit>ewemoa: thanks!
<davexunit>that makes sense.
*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
<davexunit>more than I knew about before.
<davexunit>not good.
<davexunit>bad news :(
<zacts>mark_weaver: that sucks
<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
<zacts>but yeah, New York Times
<mark_weaver>zacts: yeah, well, that's not surprising. I can't read that article though, since I have no account there.
<ewemoa>here's anattempt for fluxbox: -- and a brief summary of steps leading to it:
<iyzsong>ewemoa: look great!
<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>Hello Guix!
*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__>and now I get the error again.
<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?
<rekado__>but openjpeg is in the inputs.
<iyzsong>rekado__: I unpack the egg file, the '' 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>sepi: good to hear :)
<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__>at what point does this happen?
<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>if yes, is it compressed?
*civodul looks at taylanub
<taylanub>compression was mentioned above
<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.
<iyzsong>yes, I unpack it to find that.
<civodul>ah yes, sorry
<civodul>so does python-build-system asks for compressed eggs?
<civodul>it should not, but maybe it does
<civodul>iyzsong, mark_weaver: just pushed a fix for the profiles issue
<civodul>i'm happy to say that downloading texlive from 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?
<davexunit>civodul: I lost it, I'm sorry. :(
<davexunit>it was due to bzip2 getting corrupted data
<civodul>oh, ok
<davexunit>it dumped a big scheme bytevector of 0s
<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>something kills the connection to hydra
<davexunit>when it's overloaded
<davexunit>the download slows down to nothing
<davexunit>then dies after awhile
<civodul>yeah, bah
<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.
<rekado__>we're using puppet here. Same issues.
<davexunit>rampant complexity, too.
<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>in terms of packages and services
<davexunit>a lot.
<civodul>(bugs aside)
<davexunit>non-ruby stuff less so, but still a bunch:
<civodul>it's for web deployments i guess, right?
<civodul>yeah it's true there isn't much yet
<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?
<davexunit>might make sense to make a new module
<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
<davexunit>so over time that module could surely grow.
<rekado__>I see that shogun actually should belong to that machine learning module as well.
<rekado__>rather than bioinof.
<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>civodul: thanks for fixing the profile issue!
<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 :-(
<civodul>(without which it would not be fun)
<mark_weaver>heh :)
<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.
*civodul has to go
<davexunit>mark_weaver: though the threads would still exist for the server and clients.
<mark_weaver>davexunit: hmm? what do you mean?
<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>davexunit: oh, I had forgotten that. hmm.
<davexunit>so perhaps we need another REPL solution
<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>that sounds reasonable to me.
<davexunit>whatever protects pid 1 from crashes
<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>init systems are quite interesting.
<mark_weaver>davexunit: looks nice!
<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
<davexunit>it's wonderful
<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! :)
<mark_weaver>taylanub: reboot cron jobs?
<mark_weaver>what is a @reboot cron job?
<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?
<davexunit>what exactly is "socket activation"?
<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.
<davexunit>but perhaps not in a way that is useful.
<davexunit>just food for thought. :)
<mark_weaver>using tricks like socket activation, automounts, etc, systemd mostly avoids the need to explicitly specify the dependencies.
<davexunit>thanks for the link
<alezost>I believe my dmd user config is the biggest, as I use it to start X servers, window managers, and all other things. If someone is interested (although it's not documented yet):
<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! :)
<mark_weaver>systemd also supports dbus activation
<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.
<davexunit>great idea
<davexunit>I was using an alias :)
<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!
<davexunit>and my emacs daemon!
<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>No /var/run/dmd/socket? Scaring
<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: is /var/run/dmd on the root partition?
<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>(as part of their 'activation' code)
<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
<mark_weaver>I have to go afk
<davexunit>so we'd need some extra code to differentiate between a socket activatable service and other services.
<davexunit>mark_weaver: see ya
<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_>huh, that's weird
<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_>and it's the same after a reboot.
<rekado_>I experienced this problem two times before, each after a fresh reboot.
<mark_weaver>rekado_: strange. I don't know!
*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?
<Sleep_Walker>gnusosa: substitutes are substitutes to compilation :)
<rekado_>I can reproduce the issue:
<gnusosa>Sleep_Walker: right, but that means that machine that publishes needs to build the packages(substitutes) before hand right?
<gnusosa>s/that machine/that the machine/
<rekado_>the paste above is a complete, minimal session in which the problem is demonstrated and fixed --- by running dhclient (wth?)
<Sleep_Walker>gnusosa: sure
<Sleep_Walker>but if you trust hydra, you can let it build all the packages for you
<gnusosa>I do trust hydra
<Sleep_Walker>(unless you modify it)
<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>I'm sensing some misunderstanding here
<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
<gnusosa>Sleep_Walker: yeah I'm kinda confused
<Sleep_Walker>so you need opposite to --fallback (--no-fallback ?)
<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 don't think so
<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
<Sleep_Walker>good news is I finally understand you
<Sleep_Walker>bad news is that I have never tried that :(
<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>or am I messing up again :( ?
<Sleep_Walker>gnusosa: I'd wait for some more experience people :(
<Sleep_Walker>davexunit or civodul
<gnusosa>I hope so
<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: dependencies of emacs
<gnusosa>mark_weaver: for instance openldap? i think that's the correct name.
<mark_weaver>a specific example please
<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.
<gnusosa>Thanks for the help :)
<rekado>I'm now reconfiguring the T60 again with a new config. Let's see if after a reboot I can still reproduce this odd issue (as shown here
<mark_weaver>rekado: can you mail 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.
<mark_weaver>but maybe it's not important
<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.
<mark_weaver>okay, that's fine
<rekado>thank you for your patience!