<eru-iluvatar>i believe it's downloading packages, but it might have downloaded everything already <eru-iluvatar>is there some logfile or some way i could check at where it's hanging? <eru-iluvatar>looking at top, it doesn't seem to be doing anything at the moment <bavier`>eru-iluvatar: 'system init' may need to download packages, yes <eru-iluvatar>the last output i have is that it downloaded iso-codes and now it's been stuck for about half an hour <eru-iluvatar>i guess i'll just try again, maybe it's some network issue <eru-iluvatar>could any issues arise from killing system init and rerunning? <bavier`>eru-iluvatar: are you using the 0.8.2 image? <eru-iluvatar>during setup i realized that cryptsetup doesn't seem to be working without first killing udevd <bavier`>you'll need to 'rm -rf' /mnt/gnu/store, /mnt/var, and /mnt/grub <bavier`>and there's a link to the bug-tracker on the Contribute page <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>we will want to support certificate packages besides 'nss-certs' <mark_weaver>most importantly, we will want to support the user adding their own custom CAs. <mark_weaver>so it would be good if the java key store could be populated from something other than NSS's special format. <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 <mark_weaver>there are instructions for how to run the tests in t/README <ewemoa>mark_weaver: ah, hadn't seen that, thanks <mark_weaver>the comment on the license should mention that although the site says gpl2+, the actual code says version 2 only. <mark_weaver>well, as it is, it makes me think "then why doesn't the license field say gpl2+" <mark_weaver>but I agree that it should be gpl2 since that's what the actual code says, which is what really matters. <ewemoa>ah, well, i thought the fact that there is a comment at all and that it says something different was enough, but ok :) <mark_weaver>similarly, the comment about python-2 makes me wonder "what did you find in the grep that made you think that?" <mark_weaver>maybe better to give just one example of some code you found that indicates python-3 incompatibility <ewemoa>he he -- i guess if i didn't think it would clutter the package definition... :) <mark_weaver>anyway, these nit picks aside, it looks great, thanks! <ewemoa>thanks for the feedback will work on improving <mark_weaver>one more stylistic nitpick: it would be better to put: name "-" on the next line, with the rest of the filename. <mark_weaver>also, I wonder if version-control.scm would be a better home for this package. what do you think? I don't really know, as I've never used stgit or quilt or similar tools. <ewemoa>mark_weaver: well, quilt was in patchutils.scm :) <ewemoa>figuring out where to put stuff is challenging :) <mark_weaver>btw, it would also be good to patch wherever 'stgit' runs 'git', to have it use the full absolute pathname to the git executable. <ewemoa>mark_weaver: how about making a wrapper script? <mark_weaver>also, I see that in one place it uses 'gitk' so maybe that should be in the inputs as well, and included in the PATH by the wrapper? <ewemoa>ah, haven't bumped into that functionality before -- will look <mark_weaver>'python-build-system' probably already makes a wrapper, btw. maybe it will already have everything you need, dunno. if not, we'll end up with a two-level wrapper probably, which is fine. <ewemoa>mark_weaver: there is a reference to a file named test.py in t/Makefile, but i am not succeeding in locating it <mark_weaver>ewemoa: bah, it's not in the tarball, but it's in their git repo: git://repo.or.cz/stgit.git <ewemoa>mark_weaver: ah, i looked in a repos, but may be not the right one... <ewemoa>i guess it could be fetched, but it seems like a bug :) <mark_weaver>maybe you should use their git repo with tag (string-append "v" version) as the source origin instead of the tarball. <mark_weaver>and it would be good to report this problem upstream <mark_weaver>but I'm making a lot of suggestions that make work for you, if it's overwhelming feel free to punt on some of this :) <ewemoa>mark_weaver: no worries -- learning mcuh :) <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. <wwood>but today hydra was timing out completely <wwood>when you say a lot of software, what do you mean (roughly) <wwood>in terms of days on say an 8 core desktop <wwood>I first came across guix on the weekend and got all excited. Sad to have practicalities get in the way <mark_weaver>it begins with a bootstrap of the toolchain, using a technique roughly analogous to that described in Cross [GNU/]Linux from Scratch. <wwood>ok. I think I might have gotten that far, today I got up to installing tcsh for instance <wwood>there was a problem with that definition (the source tar.gz moved). It was fixed in the git but not in the release guix <wwood>I resorted to manually patching the package definitions in /gnu/store but I'm guessing that is bad practice <wwood>is there some way to update the package definitions without contacting hydra <mark_weaver>wwood: not only is it bad practice, but it will cause problems that cannot be easily fixed without wiping everything and starting from scratch. <mark_weaver>you must never modify or delete anything in /gnu/store. <mark_weaver>the entire design of guix depends on the assumption that nothing in there will ever be changed. <wwood>I could here someone knowledgeable telling me that in my head as I did it. I am so very sorry. <mark_weaver>on GuixSD we actually make /gnu/store a read-only bind mount, to prevent it in a stronger way. <wwood>this is a non-production thing so I can just restart the entire process <wwood>I could hear*. You get the idea <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! <wwood>thianks good night, what's left of it. *ewemoa wishes mark_weaver good rest <ewemoa>wwood: just addressing the channel :) <amz3>ewemoa: I have an idea, but not experienced it myself. Download the hydra package (or closure?) and then run another guix on your machine as a guix server <amz3>I pretty sure I read on the documentation that guix is able to run as hydra <amz3>(there is not commandline to do it) *amz3 looking in guix manual <ewemoa>amz3: hmm...feeling dense here...not seeing how that would improve things...please elaborate :) <mark_weaver>but we support 'offloading' builds to other machines <amz3>The command I was thinking about is guix publish. <amz3>it requires that you already have the build package... <amz3>I will just go back to my hacking, this is not helpful. <amz3>ewemoa: ok I found something <amz3>there is a permission error <amz3>anyway I tell what I've 'found' <amz3>when you do guix package -i textlive, it says which url it will download the package. It seems like to package is downloaded in /var/guix/substitute/cache/ <amz3>root has access to that directory <ewemoa>amz3: so if i can find the partially downloaded file in there i can resume the download manually? <amz3>no, that directory stores narinfo, not the actually prebuilt <amz3>they are small files anyway <ewemoa>amz3: the /gnu/store/*texlive-texmf-2014 directory grows during guix package -i -- perhaps the whole file is not saved anywhere <amz3>I think that's the file you are looking for <ewemoa>amz3: unfortunately, it is a directory afaict <amz3>it's possible to stream extract an archive? <amz3>when I inspect /gnu/store/*-htop-1.0.3- there is reference to a file /gnu/store/8r96jgjpmf3jk45dnhvzbb18llxc8k0n-htop-1.0.3.tar.gz but it's not in the directory (anymore?) <civodul>amz3: where is the reference you're talking about? <civodul>to extract a source archive, you can run like: tar xf $(guix build -S htop) <civodul>in general, use the 'guix' commands when you want to refer to an item in the store <civodul>easier than typing those looong file names ;-) <ewemoa>amz3: i think can read from stdin guix archive --import <amz3>ewemoa: I was refering to a *tar.gz.drv like sg47hv5wzy2jglv5v7q83jpb4j95071g-htop-1.0.3.tar.gz.drv <amz3>indeed guix archive --import seems to do what you are looking for <amz3>I need to get this day kicking *amz3 reading progress report 1 <civodul>ewemoa: unfortunately partial downloads cannot be resumed <civodul>they are usually downloaded as /tmp/guix-file-* <ewemoa>civodul: for the moment, i'm trying to download a closure from hydra instead -- can nix-prefetch-url be coaxed to work w/ guix's store? <civodul>ewemoa: no, we have 'guix download' instead <ewemoa>civodul: ah great, much more sensible :) <civodul>you can download the closure with that or even wget, and then pass it to "guix archive --import" <ewemoa>thanks -- going to try that...just waiting for it to finish downloading <ewemoa>civodul: the help output of guix download doesn't say about resuming -- i presume it doesn't -- so for large things, it seems wget might be a safer bet <davexunit>rekado_: taking a look at your guix-web patches now, thanks! <ewemoa>is there a way to retrieve raw irc logs for the channel? i know how to get html-formatted versions via gnunet.org <mark_weaver>ewemoa: sorry, those are the only public logs available <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>it creates a private mount namespace, and then creates bind mounts of only the individual store items that are in the closure of the inputs for the build. <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) <civodul>it just makes a read-write bind-mount <davexunit>I was just curious *right now* and didn't have the time to look at the source. <civodul>mark_weaver, ewemoa: oh indeed, downloading the closure from the web ui is not going to help address performance issues <mark_weaver>civodul: in this case, ewemoa wasn't looking for a solution to the performance issues, but rather to the problem of interrupted transfers for large subsitutes like texlive <mark_weaver>I've had similar problems, despite being a short bike ride away from hydra <davexunit>mark_weaver: I drive a car from 2003 and I don't really want to "upgrade" <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 <davexunit>long-lived appliances, such as a microwave oven, don't need to be programmable. <mark_weaver>there's another troubling trend of having everything on the network. even things like televisions and refrigerators <davexunit>civodul: that sounds like a good idea. what would this campaign strategy look like? <davexunit>mark_weaver: the "internet of things". terrible. <davexunit>I am absolutely not going to be buying a "smart tv" or one of those nest thermostats. <davexunit>if I got a smart thermostat, it would be one I could control with my own computers with gnu remotecontrol or something. <mark_weaver>the people I live with are replacing the thermostats with new ones that will be on wifi and can only be controlled via some proprietary app. blah. <civodul>davexunit: i was thinking of an informal campaign to begin with, where everyone just gets in touch with whatever organization could help <civodul>davexunit: speaking of which, is it time to ping Bunnie for the Novena? :-) ***fchmmr is now known as scratchy
***scratchy is now known as fchmmr
<civodul>it doesn't have the beauty of your work, though :-) <alezost>is "nix-env …" like "guix …" for us? <alezost>civodul: oh, so they have different "nix-…" commands, right? <civodul>nix-env doesn't support search though, and installing by package name can take ages *alezost has never used nix(os) but he just blindly believes that guix(sd) is better :-) <bavier>I'm conflicted. Using GuixSD for guix development is great, but it's also nice to support guix as a guest in another OS. <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