<bavier`>see debbugs.gnu.org/cgi/bugreport.cgi?bug=20722, which has been resolved, but was present in 0.8.2
<ewemoa>ipython notebook seems to work better (no errors on startup) if python-pyzmq and python-tornado are installed
<bavier`>ewemoa: there was discussion on the ML about whether to add those packages as inputs to ipython
<bavier`>they added a lot to the installed size of ipython
<ewemoa>bavier`: ah thanks -- i wonder if there isn't some good way to learn about such tips / hints at install time or via something akin to README.Debian...
<ewemoa>mark_weaver: have been investigating creation of the ca cert db that java expects -- iiuc there's a command line tool that comes w/ java called keytool that can manipulate the jks format file that java expects -- there's also a perl script named generate-cacerts.pl that drives keytool toward the end of generating / updating(?) a jks db
<mark_weaver>so, instead of another package that is based on the NSS set of CAs, it would be much better to have something in a profile hook that generates the JKS from whatever set of CA certificates is present in etc/ssl/certs, which is itself populated from whatever set of certificate packages the user installed in their profile.
<ewemoa>it looks like generate-cacerts.pl is passed a path to the keytool binary and a path to a file with certs (e.g. /etc/ssl/certs/ca-bundle.crt)
<mark_weaver>ewemoa: that's perfect. in our case, that file is in /etc/ssl/certs/ca-certificates.crt
<mark_weaver>that file is created by the profile hook we already have.
<mark_weaver>so I guess maybe this will have to be part of the same hook
<mark_weaver>but it is crucial that we don't require java unconditionally.
<mark_weaver>for one thing, I vaguely recall that our java packages don't work on our non-intel platforms.
<mark_weaver>I don't have time to investigate these details right now though.
<ewemoa>ah, so not using the keytool binary would be better then
<mark_weaver>but even on intel platforms, java is big, and we shouldn't require all users to install it just to create a JKS store that they might not need.
<ewemoa>ah, so you are saying only create the jks db if someone has java installed?
<mark_weaver>well, I'm assuming that it would be difficult to avoid that. at this point, probably the best hack we can do is look at the set of packages in the profile looking for something java related. not great, but so far we don't have a better idea.
<mark_weaver>we do something similar in the ghc hook, which looks for packages whose names start with 'ghc'
<ewemoa>are you referring to ghc-package-cache-file?
<mark_weaver>sounds right. I'm holding a baby and have only one free hand to type
<wwood>I'm new to guix. Very promising, but one problem I have is that often hydra is slow or unavailable. I have therefore resorted to installing without substitutes. But then, this fails due to out of date package definitions. So then I try guix pull, but then that seems to require contacting hydra as well. So I am stuck - any ideas?
<mark_weaver>wwood: an upgrade of hydra is in the works, but in the meantime, most of us find it to be workable.
<mark_weaver>it is possible to avoid hydra completely if you build guix from a git checkout, but you will find that it's quite a lot of software to build to even get started.
<mark_weaver>another thing that's in the works is implementing distribution of binary substitutes using gnunet.
<mark_weaver>well, in this case it will probably be mostly harmless, since what you modified is an old version of guix that you will probably not use again in the future, since we all want to keep our systems up to date.
<mark_weaver>at this point, I would recommend trying 'guix pull' again, and maybe be willing to retry if it fails.
<mark_weaver>guix is occasionally too heavily overloaded leading to timeouts, but my recommendation for now would be to just retry when that happens.
<ewemoa>i had an installation of texlive-texmf fail in the middle of downloading (unfortunately a large download) -- is getting a closure from hydra via something like wget (which can resume may be) a suitable alternative?
<mark_weaver>anyway, it's 4:30am here, and I need to sleep now. happy hacking, guix!
<mark_weaver>I keep my own logs recorded by emacs erc running on a server, but the server in question has some stability issues and so the logs are not complete and broken up into pieces, and they are not "raw" either, they are somewhat formatted. but plain text anyway
<mark_weaver>ewemoa, civodul: unfortunately, asking hydra for a closure makes a lot of work for hydra. if that workaround becomes even a bit popular, hydra will become even more overloaded and probably unusable. I was actually planning to disable that feature on hydra until we have a much better machine.
<mark_weaver>civodul: would it be feasible to download the .nar with wget and then importing that into the store somehow?
<davexunit>civodul: how does the daemon's remounting /gnu/store work? does it happen within the new mount namespace in the build container?
<mark_weaver>"/* Make the closure of the inputs available in the chroot," ...
<mark_weaver>wow, I just learned that there's work being done in "Automotive Linux" to update car software over the air. consider the security implications. I wonder if this functionality is already implemented in other cars. that's something new to keep me up at night.
<mark_weaver>well, in truth I've already been worried about that kind of thing for a while
<bavier>I've not owned a car for 3 years now, but now here's another thing to consider if I ever do buy another.
<mark_weaver>yeah, for me it's been about 15 years, but if I ever buy another, I'll make sure to buy one that's old enough to not have any radios attached to the core computer systems.
<mark_weaver>(e.g. without the wireless tire pressure gauges that are now mandated at least in the US)
<davexunit>electronic everything that you're not allowed to touch.
<mark_weaver>indeed, this trend of using computers in everything and having them remotely upgradable must be *great* for the NSA.
<davexunit>yeah, remotely upgradeable is just a terrible idea for security.
<mark_weaver>or for anyone who wants to murder you in your car and make it look like an accident
<davexunit>oops the digital break pedal stopped working
<mark_weaver>of course, the (valid) argument goes that if the device is network accessible and could be hacked into using security flaws in the software, there needs to be a way to apply security updates.
<mark_weaver>I just like the fact that my bicycle lacks the feature the general purpose computers have of being able to do whatever they are told to do.
*civodul thinks about campaigning for hardware + hosting donations
<civodul>but that's no reason not to use GuixSD ;-)
<davexunit>paroneayea: deb's quote about the cookie company was both funny and useful!
<ewemoa>mark_weaver: thanks for the note about the irc logs -- i'm just after a set that are static so i can store checksums -- the current ones have some info in them about having been processed w/ drupal(?)
<davexunit>mark_weaver: unfortunately bunnie has no spare novenas to donate