IRC channel logs


back to list of logs

<azathoth99>so guix is an alternetiv to aptget?
<azathoth99>or a distro?
<azathoth99>ah alpha hmm
<azathoth99>seems innovative
<nkar>azathoth99: have you read the home page?
<nkar>it can be used as a package manager or standalone distro
<azathoth99>yea read a lil
<azathoth99>how new kernel will come?
<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>got it. yay!
<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
<azathoth99>tar everything up
<azathoth99>move to usb disk
<azathoth99>nuke the box
<azathoth99>aw yeh
<ijp>fuck off gavino
<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>ah, alright
<ijp>serial time waster
<gr8>just plonk him. that's what I would do.
<ijp>where serial = since before 2008 anyay
<azathoth99>ijp needs his strapin adjusted
<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 | | things to package: | contribute to version 0.8!'
<civodul>Hello Guix! :-)
<davexunit>morning #guix
<davexunit>guix.el cannot list my installed packages because it can't read my profile directory. has anyone else had this issue?
<civodul>no, that's weird
<civodul>do you have an error message or something?
<civodul>anything in *Guix REPL*?
<alezost>davexunit: what's your profile dir?
<alezost>davexunit: and what's the value of `guix-current-profile' variable?
<davexunit>that's correct
<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>alezost: the empty list
<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/…
<davexunit>ah, it's /usr/var/guix not /var/guix
<alezost>oof :-)
<civodul>is (guix config) stale or something?
<davexunit>hmm, maybe
<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
<davexunit>civodul: (require 'guix)
<civodul>alezost: ↑
<alezost>davexunit: is it from a git dir or from installed dir?
<davexunit>git dit
<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
<davexunit>alezost: okay
*davexunit tries
<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
<civodul>alezost: Mathieu Lirzin
<alezost>civodul: thanks
<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: no objections
<alezost>civodul: I will do it if you don't mind
<civodul>alezost: yes please, thanks!
<mark_weaver>davexunit: how did you get guix.el working with guix installed from git? I have the same problem.
<mark_weaver>or alezost?
<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.
<civodul>you mean on Hydra?
<mark_weaver>davexunit: hmm.
<civodul>or on your machine?
<mark_weaver>civodul: right
<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
<civodul>i mean: order of magnitudes faster
<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>i built things locally
<civodul>but look, is essentially done (mips apart), and i restarted it less than 2 hours ago
<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>including the actual grafting
<civodul>to compare with 5 hours maybe?
<mark_weaver>okay, it might be the file transfers then.
<mark_weaver>well, nevermind, I'll investigate more...
<civodul>and that bug i fixed two hours ago
<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 :-)
<mark_weaver>okay :)
<civodul>the second one is just grafting
<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 :)
<mark_weaver>and thanks for implementing it!
*mark_weaver goes afk
<civodul>mark_weaver: seems SDL_gfx cannot build on mips:
<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
<civodul>there are probably other candidates
<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.
<civodul>yes the log shows assembler errors
<civodul>so i guess it has some asm
<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.
<davexunit>and write pure scheme sdl2 bindings.
<civodul>SDL_gfx is deprecated?
<civodul>compared to SDL2 i mean
<davexunit>there's a new sdl_gfx I believe for sdl2
*civodul runs "guix system reconfigure" from wip-grafts
*civodul wants to be the first one to eat his dog food
<davexunit>emacs release candidate
<davexunit>who wants to build the guix package? :P
<civodul>ah ah! :-)
<davexunit>alezost: you are a coding machine.
*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>so it cannot run less etc.
<civodul>for that, one would use M-x term
<civodul>but that's fine, usually
<davexunit>I think I've had issues with term, as well.
<civodul>i use M-x manual-entry for man pages, i don't use 'less', etc.
<davexunit>different issues, though.
<civodul>term is powerful enough to run Emacs
<civodul>however, it's less convenient than shell
<davexunit>I guess I need to adjust my workflow a bit
<civodul>because you have to escape it, say, if you want to switch buffers
<davexunit>I don't like using gnome terminal
<davexunit>when I have a perfectly good emacs
<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>davexunit: I am not :-)
<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>alezost: good point :-)
<civodul>eshell is nice in many ways, but having no pipes etc. is a problem
<civodul>oh pipes seem to work now
<alezost>civodul: it is also possible to pipe to a buffer: "ls > #<buffer buf1>"
<civodul>i should give it another try
<davexunit>oh neat
<paroneayea>(ansi-)term has always been frustrating to me
<paroneayea>there are a lot of small "not quite" issues
<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 doesn't answer the https port?
<mark_weaver>I noticed because civodul included an https link to a ticket on, and it doesn't work.
<mark_weaver>(included in the guix source code)
<civodul>oh, typo?
<davexunit> mark_weaver: did it used to?
<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 about it, nully will know better than I do about that
<mark_weaver>okay, will do.
<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.
<davexunit>yeah. definitely.
<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>well, I'm glad that problem is behind you now!
<mark_weaver>hopefully there won't be too many more hard-to-track-down issues
<davexunit>yes, time to enjoy the weekend!
<davexunit>getting out of the city for a bit and driving to worcester county soon.
<mark_weaver>you used to live around there, didn't you?
<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>oh cool! I go up there from time to tme.
<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>anyway, OT :)
<davexunit>yeah I think that's it.
<mark_weaver>okay, almost time for me to broadcast Free Speech Radio News
*mark_weaver goes afk
<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
<civodul>Valgrind also
<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.
<mark_weaver>especially for packages that don't fail early
<civodul>yes, that's what i just did
<civodul>there are other candidates but i wasn't sure
<civodul>like xorg-server and linux-libr
<civodul>these ought to build, no? :-)
<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>ditto for linux-libre
<mark_weaver>also qemu
<mark_weaver>and qt
<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>and ocaml
<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.
<civodul>ok, your call
<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 :-(
<civodul>yeah :-/
<civodul>i guess we need tools to track CVEs
<civodul>something like