IRC channel logs
2015-08-10.log
back to list of logs
<yenda>xentrac: did you activate substitutes ? <xentrac>yenda: I didn't do anything explicitly to activate substitutes, but I did notice that it talked a bit about fetching things from hydra.gnu.org <xentrac>but my objective was to avoid substitutes <mark_weaver>ACTION is running GuixSD on a non-Intel machine for the first time, namely on his Lemote YeeLoong (MIPS based). <mark_weaver>(previously I'd been running Guix on top of my home-grown MIPS distro) <yenda>the sinkhole flow puts the proprietary is a good thing to advocate for open source drivers <cehteh>the memory sinkhole thing cant be countered by any os/bootloader once its loaded .. but luckily one needs quite high privileges to install it (loading a kernel module or otherwise running some ring-0 code at least) <sprang>I'm trying to build guix from source on a GuixSD system... when running ./bootstrap I see "possibly undefined macro: GUILE_MODULE_AVAILABLE" <sprang>I have ACLOCAL_PATH set to the share/aclocal in my profile <sprang>hmm, looks like I also needed the path to the system profile's share <mark_weaver>sprang: run "guix environment guix" to spawn a shell that has everything needed to build guix from source. <mark_weaver>also, make sure to pass --localstatedir=/var to configure <mark_weaver>the error you reported was probably because guile.m4 was not found in ACLOCAL_PATH <mark_weaver>ah yes, adding the system profile's share would have fixed that problem <sprang>I think I need to finish reading the user's guide :-) <yenda->is there a way to install a program that is not yet packaged on guix in some kind of isolated manner for easy uninstalling ? <DusXMT>yenda-: what I like doing: stage-installing the compiled package somewhere, like /tmp/stage; creating a list of files (and links) the package contains (find /tmp/stage -type l -print > /path/to/pkg.mf; find /tmp/stage -type f -print >> /path/to/pkg.mf), using that to create a tarball of the package (tar -C /tmp/stage -cjvf /path/to/pkg.tar.bz2 $(cat /path/to/pkg.mf), and then just installing that tarball (tar <DusXMT> -C / -xjvf /path/to/pkg.tar.bz2). When you need to remove it, just cd /; rm -v $(cat /path/to/pkg.mf) <DusXMT>(That's the way I manage my packages on MinGW :), I have a script that does all the dirty work though) <yenda->I would like to install leiningen to use clojure, I'll try your solution <DusXMT>yenda-: good luck. Just a reminder, to stage-install something using Automake: make DESTDIR=/path/to/stage install <DusXMT>s/automake/The GNU build system/ <amz3>DusXMT: you use a package definition, or you use the makefile directly <DusXMT>amz3: The configure make install dance :) <amz3>okay, I did not know it was possible to do that with guixsd, it seems more complex that building the recipe; <DusXMT>amz3: The biggest problems will probably be shebangs. There's /bin/sh, so that's taken care of, but if a script in the build system uses /usr/bin/perl, for example, it _will_ fail <DusXMT>so while it _is_ possible, certain packages will be a bit more painful to compile than others, since you'll have to fix up the shebangs in the scripts <DusXMT>ACTION will probably get shot by the Guix people for explaining how to do such nasty things on GuixSD... whoopsie <yenda->Is guix import elpa suppose to work ? <yenda->I get "guix import: error: (quote gnu): currently not supported" <alezost>yenda-: Yes, "guix import elpa" suppose to work, and you are probably using it wrong <alezost>You probably tried "guix import elpa gnu <pkg>" while it should be "guix import elpa -a gnu <pkg>" <alezost>oh, I see: if an archive is not specified, that "currently not supported" message is raised. Then it's a bug <alezost>yenda-: thanks for reporting; "guix import elpa -a gnu <pkg>" should still work <alezost>it should be (repo . gnu), not (repo . 'gnu) <yenda->I'm glad I help find a bug alezost. Tbh I just didn't use man properly and just did guix import elpa mypackage after assuming guix import -h was telling me all I had to do <alezost>there is also "guix import elpa -h" (it doesn't tell about available repos though) <yenda->by "it's the bug" you mean the message should be different ? <alezost>yenda-: I mean it should work when you do "guix import elpa ack" but currently you have to do "guix import elpa -a gnu ack" <alezost>I hope people wouldn't object that I didn't send the patch to guix-devel since it is trivial <yenda->is there a particular reason for paredit to not use emacs build system ? <davexunit>yenda-: I don't know what the emacs build system does, but our paredit package existed long before it. <yenda->there is also duplicated imports in emacs.scm, I wonder if it something that happens often in the code base and if we have some tool to find it <davexunit>I think Guile should issue a warning in those cases <alezost>and currently there is an issue with emacs-build-system: along with *.el[c] files you will get other "uninteresting" files from the upstream tarball. <alezost>Try for exmaple "guix build emacs-dash" and look at /gnu/store/ic22a0y8v5hs8m2vinb9wqig10rjpfgl-emacs-dash-2.11.0/share/emacs/site-lisp/guix.d/dash-2.11.0/ directory <alezost>yenda-: what "duplicated imports" do you mean? <yenda->(gnu package linux) for instance is there 2 times <alezost>yenda-: indeed, thanks again :-) they were added by mistake <yenda->an emacs script to check duplication would be nice I might do that someday but I have to learn some emacs lisp first :D <alezost>yes, I think something should be done here as we fix such things from time time <davexunit>I think it would be best if Guile could tell us about such things <alezost>yenda-: by the way, do you still prefer your dvorsak.fr email over the gmail one? <alezost>I have just noticed that "git shortlog -se" produces duplicate lines for you and Andy Wingo. I'm going to fix it <amz3>maybe it's the job of guix lint <amz3>it can be the job of guix lint <amz3>it would be nice to have something similar to flake8 or pylint <amz3>there is a guile module that does build an ast representation of the code with col and line number? <davexunit>amz3: define-module is a special form, and thus Guile can print out syntax issues at compile time. <amz3>yes, maybe, but it does not lint code <amz3>anyway I don't have time for this <davexunit>to answer your other question, Guile tracks the source location for objects <ifur>amz3: yeah, i have guixsd up on my laptop now <ifur>slowly getting into a useable state :) <ifur>but why wicd instead of just using wpa_supplicant? its quite userfriendly actually <yenda->do you also have the horrible beep bell by default on guixsd ? <ifur>rmmod pcspkr takes care of that tho <yenda->or is there use cases for which it is usefull ? besides making a joke to a friend and turning him deaf <ifur>well, it makes sense for a physical terminal... <ifur>alarms and whatnot... but yeah <yenda->it doesn't seem like the emacs build system is handling the dependencies well <taylanub>elisp libraries tend to just call (require 'dependency-lib-name) and expect the user to arrange for the library to be found in the load-path, right? no pathname that we could patch to point to /gnu/store. the simplest solution would be to propagate all elisp library inputs I suppose. <taylanub>a more involved solution might patch (provide 'foo) calls to (provide 'foo "/gnu/store/...") since apparently provide takes an optional file name <yenda->forget what I said it was actually guix import that imported a non existing library <taylanub>heh, ok :) I do wonder how this issue is handled so far though. <yenda->I'm using (use-package) in my emacs conf to manage the packages and trying to add some to guix to manage them makes me wonder if there's a point doing it <alezost>taylanub: right now elisp dependencies are propagated <davexunit>that's the (unfortunate) solution for most non-C languages <davexunit>luckily we have profiles and 'guix environment' that make it less of an issue. <ifur>i get module-lookup: Unbound variable: lsh-service... any points to what i need to do to my config.scm to be able to configure the service? <davexunit>or with our use-service-modules syntax: (use-service-modules ssh) <ifur>davexunit: IT worked when i replace netowrking with just ssh etc <ifur>seems the base and desktop services are ther ejust to get started? <davexunit>and yes, the base services satisfy common use-cases <davexunit>but you may need to build your own service list <phant0mas>mark_weaver: I have an issue in nix/libstore/build.cc with the macro CHROOT_ENABLED <phant0mas>in hurd HAVE_UNSHARE && HAVE_SYS_MOUNT_H are not defined so CHROOT_ENABLED isn't getting defined <phant0mas>so at build.cc:1768 the part that creates the chrooted envs isn't used. <phant0mas>I have worked around it by only checking for HAVE_CHROOT because from what I see we only need chroot support in that part. <phant0mas>so my question is: is this an acceptable fix? <davexunit>phant0mas: nix does more than just chroots, it uses namespaces in Linux to isolate mount points and other things <yenda->I'm trying emacs interface to manage guix package, it looks like the packages I defined and installed in GUIX_PACKAGE_PATH are not present in package_list <davexunit>phant0mas: though I think we'd agree that getting just a simple chroot to work for now is reasonable. <phant0mas>davexunit: I know it does much more than that, but I am only talking about that specific part <davexunit>if that's all that CHROOT_ENABLED means, then it sounds fine. <davexunit>I'm not intimately familiar with the implementation <phant0mas>at that file chroot_enabled is used for other checks as well <phant0mas>just bypass it for now, for the code inside that if in 1768 <phant0mas>maybe I should just send a patch to the list and continue the discussion there :-) <alezost>yenda-: emacs interface should respect GUIX_PACKAGE_PATH. Could you switch to *Guix REPL* buffer and check %load-path variable there <alezost>for me, my GUIX_PACKAGE_PATH dir is the first entry in %load-path list <yenda->for me it is not but I only added the path this session <alezost>yenda-: oh wait, do you mean "M-x getenv" doesn't have GUIX_PACKAGE_PATH var? <alezost>you may M-x setenv this var for the current emacs and then restart Guix REPL <alezost>by restart I mean quit it and "M-x guix-…" again <daviid>mark_weaver: ot, is there a benchmark comparison for the lemote, like passmark, for comparing to intel/amd cpu ? <mark_weaver>but the loongson2f is quite slow by today's standards. <daviid>hum, too bad. i'm looking for a full free machine, but i need a bit of power :) [image processing...] <mark_weaver>the ASUS KFSN4-DRE is the fastest machine supported by libreboot <mark_weaver>it has two sockets for AMD quad-core processors, and some variants of the board support <mark_weaver>hex-core processors, so you can have 12 cores total. <daviid>so you'd have to mount the machine yourself ? buy cpu, ssd ... ? <mark_weaver>the best fully-free laptop is the Libreboot X200, which is a reflashed Thinkpad X200 with its Intel wireless card replaced by an Atheros one. <mark_weaver>you can buy them directly from the Libreboot developer at minifree.org <mark_weaver>highly recommended. I have one of those, and am quite happy with it. <mark_weaver>if you have further questions, #libreboot is the best place to ask <daviid>Ministry of Freedom has a beautifull, and beautifully ironic logo! <mark_weaver>the libreboot developer also hangs out on this channel: francis7 <daviid>yesterday I assisted citizenfour ... <daviid>i ment watched, docu film festival here, not assisted indeed [i'm mixing with portuguese] <daviid>and portugueese is not my mother tongue either! :) <daviid>yes, fantastic, amazing guy really <daviid>I did live in the us for a while ... <daviid>ACTION is also a helicopter commercial pilot/instructor, and workded in Miami for almost 3 years ... <mark_weaver>before the snowden leaks, I was considered paranoid. now, thanks to snowden, I now know that I was not nearly paranoid enough, and that the situation is actually far worse than I imagined. <daviid>yeah, he is a real hero for me too .. <mark_weaver>oh, nice! I came *very* close to having a private VFR license for piloting a Cessna airplane, long long ago. <daviid>francis7: maybe I'm wrong, but because for us, european, the eagle is a symbol of non freedom <daviid>i don't represent all european though <francis7>And I'm a European (Minifree is in the UK). <mark_weaver>I was at the point of flying solo, but then had to stop for a while for business reasons and never picked it up again. <daviid>mark_weaver: helicopter too? or plane <mark_weaver>daviid: no, just a small plane. I've never flown a helicopter, although I find those much more compelling actually. <amz3>(I think the eagle is a memory of old germany, but not sure either. It's mixed with "made in US" thing; I prefer the liberty thing) <mark_weaver>my university had a "flying club", i.e. a Cessna 150 and a flight instructor, and so I took advantage. <mark_weaver>but I don't think they had anything similar for helicopter. <daviid>mark_weaver: i see. if/when i go to boston, i'll invite you for a helicopter flight <xentrac>so now I have another build problem under Guix 0.8.1 <xentrac>output path `/gnu/store/dlay97p0qxmas1sz9ag1wys9hvwj3f5l-sqlite-autoconf-3080704.tar.gz' should have sha256 hash `1v2rhgsx27in6dcvxk0pkxc0zrbl38biimjg6c1zxz85jh9hydw6', instead has `04cvydhfrxxjbc8q07k3b3m5hymibrvk9cyizy5zzcbdwyl6d1bg' <mark_weaver>xentrac: why are you using such an old version of Guix? <xentrac>because when that old version of Guix tried to compile the current version of Guix, it failed <mark_weaver>they must have changed the file in place without changing the name. <xentrac>it seems like SF served me an HTML file actually <xentrac>maybe there's an error message buried in here somewhere <xentrac>is there a way to try to get the same SQLite tarball from somewhere else? <xentrac>I mean if SourceForge has gone evil or just lost the file <mark_weaver>xentrac: I think it would be much better to get the newest guix release working. <mark_weaver>unfortunately, many projects don't provide stable URLs for their sources. <mark_weaver>many of them delete the old sources, or move them somewhere else <xentrac>yeah, but SF has historically been really good abou tthat <xentrac>but yeah, we need to have a story fo rhow to handle that <mark_weaver>if you can find a copy of the file, you can download it yourself manually with "guix download <URL" <mark_weaver>and then it will be in your store and you can just restart the build. <xentrac>it sure looks to me like it does with tar tzvf <mark_weaver>also, in cases where 'guix download' doesn't work for whatever reason, you can download with a different program and then pass a file URL to 'guix download' to add it to the store, like 'guix download file:///home/mhw/foo.tar.gz' <mark_weaver>0.8.1 is so ancient, I don't know if 'guix pull' with work from that old version to the current one. <mark_weaver>also, that old software will be full of known security flaws. <xentrac>well, I can tell you! 'guix pull' doesn't work from that old version to the current one! But that version was released in January, so this seems unreasonable to me :) <xentrac>I downloaded 0.8.1 because 0.8.3 doesn't compile on my oldstable Debian system <mark_weaver>well, everything will be compiled starting our binary bootstrap tarballs, I'm afraid. <xentrac>Yes, I'm not trying to solve the fixpoint bootstrap binary problem yet with xz and tar and so on. <xentrac>hmm, this copy of guix download can't do https. good thing I can use file:// :) <mark_weaver>downloading https URLs depend on a working gnutls guile extension on your system. <mark_weaver>well, I can tell you that you've got a lot of compilation ahead of you. you'll have to bootstrap all of the old toolchain and utilities from 0.8.1, and then you'll need to bootstrap everything again to update to the latest versions of everything. <mark_weaver>and each of those bootstraps is roughly analogous to what happens in Cross [GNU/]Linux From Scratch. <xentrac>yeah, but the problem isn't the compilation time; that's not really a concern <xentrac>the problem is that guix refuses to handle the 0.8.3 tarball for some reason that I don't understand <xentrac>in the meanwhile I'm trying to install IPython and NumPy in 0.8.1 :) <xentrac>and I'm not concerned that NumPy will have security holes in it :) <xentrac>maybe I could get guix 0.8.1 to upgrade to 0.8.2 somehow? <xentrac>(sorry if I'm asking embarrassingly basic questions; I should finish reading the manual today) <mark_weaver>here's what you can do: run "guix environment guix" to build/install everything needed to build guix from source code, and spawn a subshell that's ready to build it. <mark_weaver>and then use it to build a copy of guix from a git checkout of our latest 'master' branch. <mark_weaver>it takes a bit more work up front, but it's vastly faster to update henceforth, and perhaps more importantly it allows me to make arbitrary modifications to guix, by keeping my own private git branch which I periodically rebase onto upstream master. <xentrac>I will give that a try as soon as I finish installing old IPython. Or give up :) <mark_weaver>and please make sure to update your system to the latest software ASAP, because there really are lots of critical security holes that have been fixed since january. <xentrac>I'm mostly using apt-get upgrade for that though <xentrac>I don't have, for example, a browser or terminal emulator built under guix <mark_weaver>apt-get upgrade will patch the Debian-installed software, but it has no effect whatsoever on the guix-installed software. <xentrac>I think my 10GB /gnu/store is probably going to be exhausted and need to be expanded! <xentrac>it's somewhat amusing that it's building Ruby and Perl in order to install IPython, although it kind of makes sense in that IPython lets you write and run code in those languages <mark_weaver>yes, I don't think 10GB will be enough, given that you are bootstrapping entirely from source code. <mark_weaver>but maybe that's more than is actually needed, I don't know. <xentrac>hmm, now it got ruby but is erroring on tcsh: <xentrac>starting download of `/gnu/store/slc7941p4psvpqg6j80iiv6q576zk4y9-tcsh-6.18.01.tar.gz' from `ftp://ftp.astron.com/pub/tcsh/tcsh-6.18.01.tar.gz'... <xentrac>ERROR: Throw to key `ftp-error' with args `(#<input-output: socket 6> "RETR tcsh-6.18.01.tar.gz" 550 "tcsh-6.18.01.tar.gz: No such file or directory\\r")'. <xentrac>I think we need a more reliable package repository! <mark_weaver>well, hydra.gnu.org plays that role for those who have substitutes enabled, which is almost everyone I think. <xentrac>but that's for binaries, not for source code, no? <mark_weaver>which includes sources, both before and after patching. <mark_weaver>so in practice, almost all guix users download their sources from hydra.gnu.org and don't notice when the URLs go stale. <xentrac>oh awesome! is there a way I can get guix to get sources from there but build its own binaries? (again, this is maybe a question I should already know the answer to?) <mark_weaver>I'm afraid not. we don't distinguish between the two in the software. <xentrac>is there a way I can manually fetch a tarball by hash from hydra? <mark_weaver>but I can tell you that you don't get the raw tarballs from hydra. instead you get a nar file (nix archive). <davexunit>xentrac: 'hydra.gnu.org/<hash-goes-here>.narinfo' will get you some metadata <xentrac>thank you so much for all your help! <mark_weaver>xentrac: a sort of crude way would be to enable substitutes but then make sure to pass --no-substitutes to almost all operations that would result in builds. <mark_weaver>but to leave substitutes enabled when downloading the source code. <mark_weaver>but it's a bit messy because "guix build -S <package>" will build/download the source code *after* patching and snippets, which means that you still have to trust our build farm. <mark_weaver>I guess what you really want is to just download the original sources, which are the ones whose sha256 hashes are embedded in the guix package definitions. <mark_weaver>and in some cases, it turns out to be important that we don't make it easy to get that, because in some cases that original software contains non-free software in it, and making it easy to get that would jeopardize our fully-free status with the FSF. <xentrac>That's an interesting consideration! <mark_weaver>but also the pre-patched software often has security holes in it, which I'd like to avoid putting in the hands of users <xentrac>It seems like reproducibility is in peril when it's not practical to find copies of previous versions of software. <bavier`>xentrac: you can use `guix build --sources=transitive <package>` to fetch just the sources from hydra, then follow up with `guix build <package> --no-substitutes` to build a package locally <bavier`>but as mark_weaver points out, you still have to trust hydra <mark_weaver>bavier`: does that download the pre-patched/snippeted sources, or the post-patched/snippeted? <xentrac>bavier`: you don't have to trust hydra if guix is checking the hashes of what it downloads! <xentrac>I mean you do have to trust hydra's availability, but not its correctness <bavier`>mark_weaver: it fetches the patched source. but you can get it to fetch the unpatched source if you combine --sources=transitive with --no-substitutes <mark_weaver>bavier`: but then it will get the sources from upstream, not hydra, right? <mark_weaver>xentrac: I suspect that's in NAR format, but I confess I'm not sure. I've never looked at that part of the system in detail. <xentrac>It seems like "not putting previous versions of software in the hands of users" is kind of inevitably going to conflict with reproducibility, isn't it, mark_weaver? After all, reproducibility is more or less exactly "putting previous versions of software in the hands of users" <xentrac>mark_weaver: yes, it does seem to be <mark_weaver>xentrac: you make a good point, although I'm not sure it needs to be our job to keep an archive of every version of every tarball we ever downloaded. <mark_weaver>we provide the tools you need, and recent pre-compiled binaries. <xentrac>mark_weaver: I agree. I feel fortunate that hydra happens to have this one (although I'm still not sure it really does...) <mark_weaver>the post-patched source tarballs always end with ".tar.xz", so if it's a .gz then it must be the original upstream one. <mark_weaver>and now it's just a matter of knowing how to import that nar file manually. <mark_weaver>it might be as simple as using "guix archive --import" <xentrac>that would be pretty cool, because the nix procedure on that page is a bit NARly <xentrac>hold on, guix has decided it wants to compile texinfo again <mark_weaver>civodul is the principal author of guix, who knows all the little corners that the rest of us don't know, but he is on an extended vacation now. <xentrac>after it finishes I'll try `guix archive --import` <xentrac>I should send him flowers because this is pretty awesome <mark_weaver>xentrac: during the bootstrap, some things are compiled more than once. <xentrac>fwiw at the moment I'm just running `guix package -i python-ipython python-numpy` <mark_weaver>sometimes there is a circular dependency, but one of the deps is optional, and so the circularity can be broken by building a minimal version of one of the packages first and then once you have the other package, build the full version. <xentrac>yeah, that makes sense. so you have two separate packages that build the same tarball with different configurations? <mark_weaver>and also, when bootstrapping the system, we need some preliminary versions of tools/libraries that were built against the old bootstrap tarballs, and then later we build another one that's built/linked with the newer versions of those tools/libraries. <xentrac>but will `package -i` cause it to bootstrap the system? <ifur>im trying to add slock binary from suckless mdoule to setuid-programs, any pointers :/ guile doesnt make sense quite yet <mark_weaver>ifur: see section 6.2.8 (Setuid Programs) in the guix manual. <ifur>mark_weaver: and ive tried putting slock in there somehow... butall i get is source expression failed to match any pattern <mark_weaver>ifur: can you show me your OS config that failed with that error? <ifur>i know its wrong, but after trying the example with #~( i did this.. (setuid-programs (suckless "/bin/slock") %setuid-programs) ... should get the same result <mark_weaver>you want something like (setuid-programs (cons* #~(string-append #$slock "/bin/slock") %setuid-programs)) <xentrac>hmm, `bzip2 -dc ~/Downloads/slc7941p4psvpqg6j80iiv6q576zk4y9-tcsh-6.18.01.tar.gz | guix archive --import` fails with `guix archive: error: build failed: input doesn't look like something created by `nix-store --export'` <xentrac>so I guess I'll see if I can try the nixos approach <xentrac>it seems like that's not going to be verifying the hash, though <mark_weaver>xentrac: it might want the bzipped version piped into it <xentrac>I suppose in `xzcat $largenar | nix-store --restore $storepath` the $storepath should be `/gnu/store/slc7941p4psvpqg6j80iiv6q576zk4y9-tcsh-6.18.01.tar.gz`? <mark_weaver>I've been told by civodul that the hash gets checked somewhere along the way, but if you have doubts you can always run 'guix hash <filename>' manually and check it. <xentrac>although I guess guix doesn't have a nix-store command <xentrac>guix archive says `restore: unrecognized option` <xentrac>yeah, that hash definitely doesn't match, but that's presumably because it's the hash of the original tarball rather than the nar file containing either it or things imported from it <xentrac>so you wouldn't expect the hash of the bzipped nar file to match <mark_weaver>I would try typing the full tarball filename into a search engine <xentrac>they've apparently been deleted from the tcsh site and its mirror <xentrac>I think I've found them maybe on some dodgy Chinese site <ifur>when in need to got a gentoo mirror :) <ifur>argh, just go to a gentoo mirror and look at distfiles :/ <ifur>yeah... useful distro, hehe <xentrac>I never did seem to get the Chinese equivalent of MegaUpload to give me the file <xentrac>now that I have tcsh it's compiling flex (‽)