<nkar>azathoth99: have you read the home page? <nkar>it can be used as a package manager or standalone distro <davexunit>users of guix.el: how do you get it to look for modules in your git checkout? <davexunit>I tried setting GUILE_LOAD_PATH in my init.el but it didn't work <davexunit>hmm, unfortunately guix.el cannot read my profile so it thinks that I don't have any installed packages... <gr8>hi. is there a text on how to migrate step by step to Guix on Debian? that means, replacing APT as a package manager <gr8>oh btw. gnunet bot is here? That's exciting (and who is Gavino?) <ijp>gr8: azathoth99 aka republicandevil aka shemalemagic aka gavino aka ... <gr8>just plonk him. that's what I would do. <ijp>where serial = since before 2008 anyay <ijp>gr8: the problem is that newbies don't realise his schtick, and get sucked in <azathoth99>and people like ijp are just needing bigger strapins ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | things to package: http://libreplanet.org/wiki/Group:Guix/Wishlist | contribute to version 0.8! http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00206.html'
<davexunit>guix.el cannot list my installed packages because it can't read my profile directory. has anyone else had this issue? <civodul>do you have an error message or something? <alezost>davexunit: and what's the value of `guix-current-profile' variable? <davexunit>"/var/guix/profiles/per-user/dave/guix-profile" <davexunit>but it says that I have no installed packages... <alezost>davexunit: could you switch to the REPL and eval (package/output-sexps "/var/guix/profiles/per-user/dave/guix-profile" '(name) 'package 'installed '()) there <davexunit>it's strange, i definitely have packages in that profile... <alezost>davexunit: are you sure it's the same path? perhaps /usr/var/guix/… or /var/local/guix/… <civodul>is (guix config) stale or something? <alezost>davexunit: you can set `guix-current-profile' in your emacs config to the proper path <civodul>davexunit: try: guile -c '(pk (@ (guix config) %state-directory))' <alezost>davexunit: I think the problem is "guix.el" doesn't define the path properly. How do you use it? By requiring guix-init? <civodul>so maybe you need to reconfigure it to make sure it uses the right --localstatedir <civodul>be careful with --localstatedir, because it also contains the store db <alezost>davexunit: is it from a git dir or from installed dir? <davexunit>I don't have guix modules installed to my system guile load path <alezost>davexunit: then what you need is set `guix-default-profile' in your init.el. It would be set to the proper path by guix-init.el if it was installed <alezost>davexunit: btw do you require 'guix in your .emacs? <davexunit>I use `setenv' to modify the guile load path so that guix.el will work, then require 'guix <alezost>davexunit: i don't recommend it as it slows down the Emacs start, (require 'guix-autoloads) will be much faster (do you have guix-autoloads.el along with other .el files in your git dir?) <alezost>or even better (require 'guix-autoloads nil t) so that it wouldn't fail if there is no such file <civodul>i have just (require 'guix-autoloads) but later i modify 'geiser-guile-load-path' to refer to my git checkout <civodul>and 'load-path' refers to /git/checkout/emacs <alezost>civodul: davexunit: who is mthl? I think today I'll finish the things for multiple profiles we were talking about yesterday and I would like to mention all of you in a commit message <davexunit>alezost: guix autoloads? okay I'll require that instead. <davexunit>civodul: ah, geiser-guile-load-path. didn't know about that. <civodul>alezost: BTW, what do you think of s/emacs/Emacs/ in node and section names in emacs.texi? <alezost>civodul: I will do it if you don't mind <mark_weaver>davexunit: how did you get guix.el working with guix installed from git? I have the same problem. <mark_weaver>civodul: the bash graft seemed to take almost as long as rebuilding everything. I think maybe we should consider using/writing a C implementation of the grafter, but I haven't looked what how it's currently implemented. <alezost>mark_weaver: my way of using git dir is strange I think: I edited both "scripts/guix" and "emacs/guix-helper.scm" to point to the paths I need <civodul>mark_weaver: until a couple of hours ago, there was a bug that led to more rebuilds than needed <davexunit>mark_weaver: I just tweaked my guile load path and added my guix/emacs directory to the emacs load path. <mark_weaver>civodul: even so, looking at how long each rebuild takes, it seems very slow. <mark_weaver>I haven't tried on my YeeLoong yet, but it would surely be a lot slower than the Loongson 3A machine took. <civodul>Hydra grafts every single package, so say it's 1mn per package (pessimistic), then it takes some time <civodul>but if you do it locally for the packages you care about, it's very fast <civodul>definitely faster than rebuilding everything <alezost>mark_weaver: basically what is needed: 1. (add-to-list 'load-path "/path/to/guix/emacs/") 2. (require 'guix-autoloads) 3. (setq guix-default-profile "/path/to/profile") <mark_weaver>civodul: did you look at the actual build times on hydra? they were over more than half an hour. <mark_weaver>though I don't know how much of that was file transfer times. (although they should have all been doable locally, without offloading) <civodul>"time ./pre-inst-env guix build gobject-introspection" says 16s <mark_weaver>civodul: I've been watching hydra a lot lately, waiting for full reevaluations to finish, and I watched the grafts rebuild also. for whatever reason, it seemed to take on the same order of magnitude of time. <civodul>basically, things with patches or snippets were getting rebuilt instead of just grafted <civodul>so yes, it did rebuild a lot of things in the first evaluation :-) <civodul>also, things are not offloaded because there are no tranfers <civodul>... which explains the builds aborted with "all build users are currently in use" <civodul>should be: "there are no transfers because things are not offloaded" <mark_weaver>sounds great! sorry for the stale problem reports :) <civodul>if that is the case, are you OK with removing "mips64el-linux" from its 'supported-systems' field? <civodul>that will avoid building it pointlessly <davexunit>civodul: does SDL_gfx contain assembly code or something? <davexunit>I wouldn't be surprised if there was such a speed hack in a graphics library. <davexunit>yeah, best to remove mips from supported systems, then. <davexunit>good to know that, though. I use guile-sdl, which depends on SDL_gfx. <davexunit>another reason to get rid of that dependency. *civodul runs "guix system reconfigure" from wip-grafts *civodul wants to be the first one to eat his dog food <davexunit>ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.4-rc1.tar.xz *civodul looks at the patch, woow <davexunit>civodul: so when I was watching your GHM presentation, I noticed that you used many M-x shell buffers. I've always had trouble using M-x shell because it seemed to freak out when dealing with pagers, for example viewing a man page or using less. have you had this issue? <civodul>davexunit: yes, shell is not a terminal emulator <civodul>i use M-x manual-entry for man pages, i don't use 'less', etc. <civodul>term is powerful enough to run Emacs <civodul>however, it's less convenient than shell <civodul>because you have to escape it, say, if you want to switch buffers <civodul>for a long time i used a separate xterm + screen <davexunit>though I suppose there's no substitute for screen <civodul>now i'm happy doing most things in M-x shell <civodul>yeah, well, i resort to several shell buffers <davexunit>I guess I'd need term for attaching screen sessions on remote servers <civodul>switching is not as convenient as with screen <davexunit>guess I won't be replacing my external terminal + screen. <alezost>civodul: "M-x manual-entry"? Why not just "M-x man"? As for me, I have a key binding for that command; also sometimes I use "man foo" in eshell <davexunit>eshell, another tool that I haven't really used <civodul>eshell is nice in many ways, but having no pipes etc. is a problem <alezost>civodul: it is also possible to pipe to a buffer: "ls > #<buffer buf1>" <paroneayea>like, resizing the buffer doesn't inform applications iirc <mark_weaver>regarding emacs-24.4-rc1, I'll package it up. I already have a local patch to upgrade to the pretest <mark_weaver>davexunit: do you think it's intentional that bugs.gnu.org doesn't answer the https port? <mark_weaver>I noticed because civodul included an https link to a ticket on bugs.gnu.org, and it doesn't work. <mark_weaver>I don't remember if it ever did, but it seems like it should <davexunit>we dropped support for sslv3 this week, and there is some amount of fallout associated. <davexunit>send an email to sysadmin@gnu.org about it, nully will know better than I do about that <davexunit>for instance, I just spent my whole day tracking down an issue that turned out to be caused by dropping sslv3 support. <davexunit>only now did I finally get to the end of the rabbit hole. <mark_weaver>davexunit: that's a drag, but it's worthwhile work nonetheless, IMO. <mark_weaver>it's a reminder, though, that it's good when errors are reported early and loudly, rather than trying to muddle through. <davexunit>the problem was that the issue involved a server that I had upgraded earlier this week, so I thought that the upgrade had broken something. <davexunit>so I was lead in the wrong direction for awhile. <mark_weaver>(not sure if that would have helped you track down this particular problem or not) <davexunit>the culprit is an old-ish server with an old libcurl that is doing the wrong thing. <mark_weaver>hopefully there won't be too many more hard-to-track-down issues <davexunit>getting out of the city for a bit and driving to worcester county soon. <mark_weaver>I vaguely recall you did when we first started chatting on #guile *mark_weaver enjoyed a beautiful weather today with a walk in the Middlesex Fells reservation. <davexunit>and walk up to that little tower whose name I can't remember. <mark_weaver>Wright's tower maybe? I was there about 2 hours ago :) <mark_weaver>okay, almost time for me to broadcast Free Speech Radio News <mark_weaver>actually, looks like someone else has got it covered tonight.... <civodul>SDL_gfx and things that depend on it will no longer be built on mips <mark_weaver>civodul: I guess it's sensible to remove mips from the 'supported-systems' field for the packages that consistently fail to build with non-trivial problems. <civodul>there are other candidates but i wasn't sure <mark_weaver>xorg-server might be failing because our mesa is so old <mark_weaver>though it would still need patches to work on the YeeLoong 8101B. <mark_weaver>qemu and qt are two examples of builds that take a long time before failing, iirc. <civodul>well, feel free to throw 'supported-systems' as you see fit :-) <mark_weaver>unfortunately, the patches needed for xorg-server and linux-libre on the yeeloong are not of sufficiently high quality to merge upstream, and I don't think we'd want them in our packages either. <mark_weaver>so they'll probably need dedicated packages just for the yeeloong. <mark_weaver>though maybe we should just forget about the yeeloong. its relevance is probably almost over. <civodul>that seems to be the case, unfortunately <mark_weaver>one big problem that needs to be addressed is that many packages with CVEs don't make new upstream releases. <mark_weaver>I recently discovered that libarchive has a CVE in their last upstream release (early 2013), and then I discovered another unpatched CVE in pulseaudio <mark_weaver>I patched libarchive. I think the pulseaudio one probably isn't serious, but based on these discoveries, which I stumbled upon within 2 days of each other, I suspect that there are many other cases like this. <mark_weaver>the libarchive CVE was patched in their repo in mid-2013, iirc, but they still haven't made a new release :-(