<tadni>mark_weaver: Yeah, I was extremely tired when I wrote that. I just took a nap, and ... hopefully I can explain better. Basically, I was trying to install Guix on my Old Compaq desktop and I got to the point where I did "guix system init /mnt/etc/config.scm" -- which I waited two hours with no visible progress besides it saying it accepted the connection. I tried to rewrite my usb install image and try again on the desktop and same <tadni>problem... So, I tried to use the install image on the laptop that I had the GNU distro installed and nothing. <tadni>I can run "guix system init /mnt/etc/config.scm /mnt --no-substitutes" and it will start to grab packages, but it crashes trying to build on both boxes. <tadni>I'm not sure what's the problem now... <mark_weaver>tadni: did you add the hydra key to the list of authorized signing keys? <tadni>mark_weaver: Pre-install? Yeah. <mark_weaver>btw, the "guix system init" command requires another argument: the directory where to install. <mark_weaver>i.e. the mount point of a fresh partition to install on. <tadni>Yeah, I had "guix system init /mnt/etc/config.scm /mnt" sorry. <mark_weaver>hmm, I'm not sure why that didn't work. it works for me. <tadni>Did I miss the info manual in tty2? I didn't notice it in the installer, when I installed it on my spare laptop the day after 0.7s release. <mark_weaver>I've heard that it's there, but I haven't tried booting the USB stick. I used "guix system init" from a debian system where I built guix from git and enabled substitutes. <mark_weaver>tadni: what command did you use to try to build it, and what was the output? <tadni>Is there a difference between gnu-usb-install-0.7.x86_64-linux and gnu-usb-install-0.7.x86_64? <davexunit>tadni: are you talking about the images available on gnu.org? <tadni>So it should be irrelevant which one I use? <tadni>I want to at least get my spare laptop to where it was -- before I nuked it. <tadni>I'm hoping my earlier problems had to do with hydra or something... not sure what really went wrong there. <tadni>I'm probably going to set it and leave it run overnight, hoping for the best. :^P <mark_weaver>you could try running "guix system build /path/to/config.scm" first. <mark_weaver>that should do all of the hard work to build all the components, such that "guix system init" should then be reasonably fast. <tadni>mark_weaver: Yeah, I'll try ... I just don't know why it worked before and won't now. :^P <tadni> mark_weaver: Yeah, I guess hydra was just stalling when I was trying earlier "guix system init" is currently grabbing. \\o/ <xisiqomelir>guix build: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory <mark_weaver>xisiqomelir: is this while running guix compiled from git, within a standalone guix system? <mark_weaver>if so, you need to reconfigure your guix with --prefix= (nothing after the '=') <mark_weaver>xisiqomelir: no. in the guix source tree, run ./configure --prefix= --with-libgcrypt-prefix=$(guix build libgcrypt) <mark_weaver>and then "make", and then try the same command again. <mark_weaver>the issue is that in the standalone guix system, there's a lot of important state (including an sqlite database and other things) in /var/guix <xisiqomelir>checking build system type... Invalid configuration `/gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1-debug': machine `/gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1' not recognized <xisiqomelir>configure: error: /bin/sh build-aux/config.sub /gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1-debug failed <mark_weaver>./configure --prefix= --with-libgcrypt-prefix=/gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1 <mark_weaver>anyway, continuing my explanation: it's important that the new guix you compile will look for the sqlite database and other state in the same place, namely /var/guix <xisiqomelir>checking whether /gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1-debug//lib/libgcrypt can be dynamically loaded... no <xisiqomelir>configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'. <mark_weaver>are you doing this within a standalone guix system, or within some other distro? <mark_weaver>you are probably missing some important packages needed for the build <xisiqomelir>./configure works with --with-libgcrypt-prefix=/var/guix/profiles/per-user/ME/guix-profile <mark_weaver>it should be looking in /gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1/lib/libgcrypt <mark_weaver>but it was looking in /gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1-debug/lib/libgcrypt <mark_weaver>i.e. remove the "-debug" from the --with-libgcrypt-prefix= argument <xisiqomelir>can you have a look at this package.scm I wrote while I do it <mark_weaver>you should do: ./configure --prefix= --with-libgcrypt-prefix=/gnu/store/q5qh7y9l9yyvx7cj18dq4mnyryjid10n-libgcrypt-1.6.1 <mark_weaver>yes, and replace the copyright lines with one with your own name <mark_weaver>and the 'inputs' are wrong. it should be (inputs `(("gnutls" ,gnutls) ("libpcap" ,libpcap) ...)) <mark_weaver>and the double-quotes in the description need to be escaped with backslashes <mark_weaver>commas do not separate elements in a list in scheme. instead they are part of so-called "quasiquotation", which is what the backquote ` is about. <mark_weaver>`(...) means that everything inside is a literal data structure, but things prefixed with commas are evaluated as expressions and the results are spliced into the data structure <mark_weaver>e.g. `(("gnutls" ,gnutls)) is a list containing one list of two elements: the string "gnutls", and the value of the variable 'gnutls', which is bound to a package object (imported from the (gnu packages gnutls) module) <mark_weaver>also please insert line breaks in the description to keep the lines to a reasonable length. in scheme, string literals can contain newlines without any escapes. <mark_weaver>I think there's no need to mention that it's free and open source, since all of the software in Guix is free software. <mark_weaver>probably those double-quotes in the description should simply be removed, rather than escaped. <xisiqomelir>then do I "/pre-inst-env make install" instead of a normal "make install"? <mark_weaver>to make this nicer, I put ~/bin at the front of my PATH, and then ~/bin/guix is a shell script that does: exec $HOME/pre-inst-env guix "$@" <mark_weaver>so, it will use the guix-daemon on the standalone system, which is fine. <mark_weaver>there can only be one guix-daemon running at a time. <xisiqomelir>what is the plan for the gnunet distribution of binaries <xisiqomelir>I watched one of Ludo's talks in...France I think? on Youtube <mark_weaver>there's a thread about it on the guix-devel mailing list. <mark_weaver>search for "GNUnet binary ditribution roadmap" there <mark_weaver>(spelled wrong, but that's what's actually in the subject line) <xisiqomelir>I assume we will slowly build some sort of web of trust? <xisiqomelir>that seems much more secure than a sole repository which provides a lone target to compromise <mark_weaver>well, ultimately the plan is to arrange for builds to be completely reproducible, always generating exactly the same bits, so that anyone can do the builds on their own machine and compare with what other's provide. <mark_weaver>also, you can run the guix-daemon with --no-substitutes, in which case everything other than the bootstrap binaries are built on your own machine from source code. <xisiqomelir>yes I think that's what's making tadni's installs take 5 hours <mark_weaver>but as for the details, I'm actually not sure what the plan is on gnunet. I was busy with other things during those discussions, and haven't yet caught up. <mark_weaver>I run with --no-substitutes on my own machine, fwiw. and yes, it takes a very long time to build everything. <xisiqomelir>on my thinkpad the gcc bootstrap is about an hour and a half <mark_weaver>on my YeeLoong, it takes well over a week, but I've done it several times. <mark_weaver>when we have bit-for-bit reproducible builds, and active independent verification of the binaries happening on a regular basis (build farms run by different people, digitally signing the binaries in a similar way to people signing each other's GPG keys), then I'll probably start using binary substitutes. <mark_weaver>you need to put it in the gnu/packages/ directory of your git working directory, and add it to gnu-system.am <xisiqomelir>build failed because of course no nmap in hydra yet. Trying --with-source= <mark_weaver>it should have built it locally, if there's no substitute on hydra. <mark_weaver>did you put ./pre-inst-env before the build command? <mark_weaver>can you show me a transcript of the command you typed and the output? <mark_weaver>I guess there's no harm in passing --no-substitutes, but it shouldn't be needed. <xisiqomelir>I edited gnu-sytem.am and added the package.scm to GIT/gnu/packages before compiling <mark_weaver>no need to re-run ./configure, but if you did, hopefully you passed the same options as before. <mark_weaver>anyway, you can use the 'script' command to make a transcript of the session. or run it within emacs M-x shell, or within GNU screen. so many options... <xisiqomelir>Geiser is a collection of Emacs major and minor modes that conspire with one or more Scheme interpreters to keep the Lisp Machine Spirit alive. It draws inspiration (and a bit more) from environments such as Common Lisp's Slime, Factor's FUEL, Squeak or Emacs itself, and does its best to make Scheme hacking inside Emacs (even more) fun. <xisiqomelir>So I install Emacs and geiser and then hacking guix becomes easier? <mark_weaver>well, scheme hacking becomes easier, though I'm not sure it makes a noticable difference for writing guix recipes. <mark_weaver>I confess that I'm unusual among Guile power users in that I don't use Geiser, but I do use 'paredit', which has a steep learning curve, but makes editing scheme code vastly easier and more efficient once you get the hang of it. <xisiqomelir>emacs itself will probably be the bigger hurdle since I've used vi for so long <xisiqomelir>WARNING: (gnu packages nmap): `openssl' imported from both (guix licenses) and (gnu packages openssl) <xisiqomelir>and the configure for the package worked, just threw out one compiler error to fix <mark_weaver>change "#:use-module (guix licenses)" to "#:use-module ((guix licenses) #:prefix license:)" <mark_weaver>and then change (license gpl2) to (license license:gpl2) <mark_weaver>the (guix licenses) module exports a binding 'openssl' which refers to a license. (gnu packages openssl) exported 'openssl' referring to a package. <mark_weaver>jmd: if you haven't already gotten them, sneek has some messages for you <jmd>Hmm. Normally it automatically sends them. It seems to be broken recently. <mark_weaver>well, he doesn't send them until you say something. but now you have, and he still hasn't delivered the messages. <mark_weaver>anyway, I fixed gccgo, and hopefully made it easy to fix your gcj package. <sneek>Welcome back waxysubs, you have 1 message. <sneek>waxysubs, mark_weaver says: hello! <mark_weaver>and I think he may have interpreted that as meaning that it should be delivered to "jmd:" <mark_weaver>I wanted to set my nick to "jmd:" to verify this, but it tells me it's an invalid nick. <sneek>waxysubs, you have 1 message. <sneek>waxysubs, mark_weaver says: hello <jmd>I had disk problems recently so haven't touched guix much. <jmd>I dunno. There is a lot of stuff in lost+found - I haven't checked through it all yet. <jmd>It depends on what you mean by recent! <mark_weaver>well, given that your gcj recipe succeeded up to the point of finding the cycle, I'm very confident that the same fix for gccgo would result in a working gcj. <mark_weaver>regarding the disk: fwiw, a couple of years ago I had a similar bad disk corruption. in my case, I was using RAID, so I broke the RAID and kept one copy of the original corrupted filesystem. this turned out to be important, because some important files (like huge mail files) were missing, but I was able to recover them from the original filesystem. <mark_weaver>I used 'debugfs' to recover some files that were missing. <jmd>/Scratch/john/guix-guix/ <svetlana>thought on feature for a package manager: display interactive dependency graph with aggregated sizes of each graph node (eg each package + its dependencies) *svetlana is spending hours trying to do this for another pkg manager; such feature not being scripted already is annyoing <jmd>svetlana: Good idea. A bit like the filelight filesystem viewer. <svetlana>Filelight (I use ncdu for that, if I'm interpreting it right) just shows files recursively, but it, if I read it right, doesn't do packages. <jmd>Right. I said "a bit like" - not "identical to". *tadni` isn't sure if guile-wm works with ttf ... he dosen't think so, but it'd be a lot easier to package proggy over the bitmap one. <tadni`>Yeah, it supports just bitmap now ... darn. :^/ <tadni`>Hm, my git grabbed /guix/bootstrap on my GNU install is telling me "fatal: unable to access 'https://github.com/NixOS/nix.git/': server certificate verification failed. CAfile: none CRLfile: none:" <tadni`>davexunit: What time is it over there in MA (iirc)? It's nearly 7 here. <tadni`>It feels so weird actually being up this early again ... <davexunit>I've got my laptop on the kitchen counter and I'm preparing breakfast :) *tadni` is reseting his sleep schedule for the school semester starting mid-month. He usually goes to bed at 6am and will sleep to 2pm ... <tadni`>Yeah, I'm "still young" but with school and another part-time job on the hosizon ... things need to change sooner than later. :^P <davexunit>I remember being able to stay up until 4AM or something during the summer <davexunit>but that was still in high school, I think. I've worked at least part time since I was 17 <tadni`>davexunit: I have a habbit of staying up to literal exhaushtion... so regurlaly I'll stay up for like, 35-40 hours? Not a good thing, really. <tadni`>Oh yay, this font-proggy module is actually coming together! Yah, prior x11 bitmap examples! <tadni`>davexunit: Nah, I took a LONG break from Guix though. I've gone through like 3 nicks since then, but I've packaged Slim and the related depends. *tadni` still has no idea what he's doing though. :^I <tadni`>What should I do if a package has no version number? Just leave it blank? <davexunit>hmm, we need a version number. what software is this? <davexunit>hmm, I don't know what to do when there is no version number <alezost>tadni`: there are several packages with (version "0") <tadni`>alezost: Is there a way to remove the version from the string-append on the download stage? <tadni`>I'm saying, doesn't it auto-include in string append? <tadni`>When I tried to build, it said if was trying to grab "ProggyClean.pcf0.1.zip" <tadni`>I think I may have it done ... can't test on this box though until I figure ;ut the deal with the certificates. <tadni`>Hm, trying to delay me need for the git repo on this box and playing with the 0.7 tarball ... and it appears, that I have gcc but checking "checking whether the C compiler works... no" <Steap>tadni`: can you take a look at config.log, search this message and see what compilation failed ? <tadni`>davexunit: Well, it was not installed ... but it appears it did nothing of noticable effect. :^P <tadni`>Steap: It didn't even get to the compilation stage, just checking. Am I misunderstanding you? <Steap>tadni`: usually in config.log <Steap>like gcc is not in the PATH, you can't write on the partition, you're out of space... <Steap>it does that by trying to compile a dummy C file iirc <tadni`>which: no as in (/run/setuid-programs:/run/current-system/profile/sbin:/home/tadni/.guix-profile/bin:/run/current-system/profile/bin)" <Steap>yes, that would be the issue <Steap>it should be installed somewhere <Steap>so either it is installed in a location that is not in your $PATH, or there is a huge issue with your gcc installation <Steap>funny, it's not a dependency of gcc ? <tadni`>Still need to figure out certs at somepoint via git, but this gives me awhile. <tadni`> davexunit: Hm, I tried building my module and it's still trying to append a version number. "******************************-font-proggy-clean-0.1.drv" <tadni`>Hm, weird. Yeah, excluding 'version' seems irrelevant. <davexunit>I should have mentioned that one to you as well when I mentioned glibc <tadni`>We rally should have a guix-devel package or something to trivialize the process of setting guix up on GNU as-much as possible. :^P <tadni`>I'm sure it will come at somepoint though. <davexunit>yeah, it's a convenience, we don't have a lot of those yet :) *tadni` is at a loss what to do at this point to get rid of the version number. I even tried leaving the version string null and I still got a "-" after the package name, before the .zip <tadni`>davexunit: Isn't alpha software lovely. :^) <tadni`>Still appears as ProggyClean.pcf0.zip ... <tadni`>Hm, it's not trying to grab it now. <tadni`>It's using older versions of proggy-fonts which has the 0 or 0.1 suffix. *tadni` also needs to figure out how to use a *.zip. He thought you just listed it... but it tries to read it as a tar. <tadni`>davexunit: I mean, ProggyClean only comes in a *.zip and if I list that under uri -- it tries to read it as a tar and fails. <davexunit>url-fetch doesn't care about the type of archive *tadni` looks for examples of modules that use *.zip. <tadni`>I really need to learn more unix basics, to search these files easier. I know the tools exist, just not h;w to use them. :^/ <davexunit>that's probably not what you want, does proggy-fonts have a configure script and makefile? <tadni`>I just used adobe's font expressions as a base. <davexunit>then the gnu-build-system isn't what you want. <davexunit>mark sent you an example of the dejavu font package awhile ago <tadni`>I had a feeling it wouldn't be "this easy: but yeah, makes sense. <tadni`>Man, I really need to start SICP again. It'd be nice to implement a ttf-builg-system and x11-font-build-system. <tadni`>davexunit: Well, thanks for the advice. I'll certainly look into it a bit more, but time for some errands now. ***guest1001 is now known as oitofelix