IRC channel logs


back to list of logs

<angelic_sedition>I'm having trouble getting guixsd installed in virtualbox. "guix system init..." says that it completes successfully, but when I reboot I get a kernel panic and just before it 'ERROR: In procedure state: No such file or directory: "/etc/static/localtime"'. Any ideas?
<angelic_sedition>Also, after "guix system init /mnt/etc/config.scm /mnt", config.scm is still the only file in /mnt/etc. Should there be others?
<angelic_sedition>procedure stat*
<mark_weaver>angelic_sedition: can you paste your config.scm somewhere?
<mark_weaver>a bad configuration can lead to the init process dying, which causes a kernel panic.
<angelic_sedition>mark_weaver: Okay, this is the config.scm:
<mark_weaver>looks okay to me.
<mark_weaver>angelic_sedition: when you boot in virtualbox, does it start by running our grub menu?
<mark_weaver>are you are loading our kernel and initrd directly in some other way?
<mark_weaver> /mnt/etc is not populated until the first boot
<angelic_sedition>It starts with grub, yes
<mark_weaver>can you send email to about it?
<angelic_sedition>Yes. Is there any other information I should give?
<mark_weaver>include the config.scm, the exact command you used, and the version of 'guix
<mark_weaver>btw, we provide a 'guix system vm' command to build VM images for qemu.
<angelic_sedition>Okay thanks
<angelic_sedition>Does that work outside of the gsd?
<angelic_sedition>okay, thanks for the help
<angelic_sedition>Where would be a good place to give feedback on the gsd?
<mark_weaver>we call it GuixSD now, btw.
<mark_weaver> or
<angelic_sedition>okay, ty
<angelic_sedition>Does "guix system vm" ignore the partition scheme?
<paroneayea>interesting... can you only have python2 or python3 in a single guix profile?
<paroneayea>no 2 and 3 both?
<mark_weaver>iyzsong: I see you pushed those commits to 'wip-glib'. is there anything else you'd like to push before I start hydra building it?
<iyzsong>mark_weaver: Yes, I'd like to remove all the 'CC=gcc' setenv calls
<mark_weaver>iyzsong: are those no longer needed?
<iyzsong>mark_weaver: Yes, with the new gobject-introspection-cc.patch.
<mark_weaver>ah, okay, I'll wait then...
<paroneayea>very close to havinga guile-minikanren package...
<paroneayea>I got it to pull it down, but not sure where to have it copy the stuff after it does so
<paroneayea>I know I want it to end up on the guile load path
<mark_weaver>paroneayea: did you use ijp's port of minikanren to guile?
<paroneayea>mark_weaver: yes that's what I'm attempting to package
<paroneayea>however I don't know where the scripts would get copied in the #:builder build expression
<mark_weaver>a module named (foo bar) should be put in <out>/share/guile/site/2.0/foo/bar.scm
<paroneayea>mark_weaver: gotcha
<mark_weaver>it'll be great to have that package, thanks! :)
<paroneayea>mark_weaver: and is there a way to copy a directory? I see ways to copy individual files
<mark_weaver>paroneayea: see 'copy-recursively' in (guix build utils)
<paroneayea>mark_weaver: got it, thanks
<paroneayea>mark_weaver: also do you think guile-minikanren is a good name for the package?
<paroneayea>there is a mainline "minikanren" which is why I am hesitant to use that
<paroneayea>but it does not work for guile right now.
<paroneayea>it does work for some other schemes
<paroneayea>or r6rs-minikanren, I dunno
<paroneayea>oh, it should be guile-
<paroneayea>because that's where I'm copying it to
<iyzsong>mark_weaver: done. please start build it on hydra ;-)
<mark_weaver>iyzsong: okay, thanks!
<mark_weaver>paroneayea: good question, maybe ask on the list?
*paroneayea nods
<paroneayea>btw, I have it so that it installs to the right place
<paroneayea>but I can't get it to work in guile still it seems
<paroneayea>cwebber@earlgrey:~/devel/guix$ ls ~/.guix-profile/share/guile/site/2.0/
<paroneayea>json json.go json.scm minikanren minikanren.scm
<paroneayea>scheme@(guile-user)> (use-modules (minikanren))
<paroneayea>While compiling expression:
<paroneayea>ERROR: no code for module (minikanren)
<paroneayea>I guess there is no guile-style module definition
<paroneayea>btw, I got it :)
<paroneayea>it works.
<mark_weaver>paroneayea: hmm, we probably shouldn't be putting things into the top-level namespace like that.
<mark_weaver>is that there ijp put it?
<mark_weaver>and is that where guile-json installs by default also?
<paroneayea>mark_weaver: I'm not sure what top-level namespace means
<paroneayea>mark_weaver: however I was wrong anyway
<paroneayea>the way to import is
<paroneayea>(import (minikanren mk)
<paroneayea> (minikanren mkextraforms)
<paroneayea> (minikanren mkprelude))
<paroneayea>since it is R6RS packaging
<mark_weaver>I mean that modules should generally have at least two components
<mark_weaver>module names, I mean.
<paroneayea>mark_weaver: I think both guile-json and minikanren do as above, just that minikanren uses (import)
<mark_weaver>so, in the upstream guile-json, the module name is just (json) ?
<paroneayea>mark_weaver: there is (json builder) and (json parser) and (json syntax)
<paroneayea>though there is a json.scm
<paroneayea>the json.scm does nothing other than export modules tho
<paroneayea>so I think it's fine?
<mark_weaver>blah, I'm going to have to talk to the upstream guile-json author about it.
<paroneayea>heh ok
<paroneayea>anyway, the good news, the thing works :)
<mark_weaver>that's good!
<paroneayea>I'll submit a patch to the guix list
<mark_weaver>thanks :)
<mark_weaver>iyzsong: there seem to be problems with the CC=gcc removals. for example:
<mark_weaver>error: Failed to execute child process "cc" (No such file or directory)
<mark_weaver>iyzsong: there are some other failures that lead to hundreds of new dependency failures, see
<iyzsong>mark_weaver: oops, thanks for notice. let me try to fix it.
<iyzsong>while I'm at it, I'll bump gtk+, gtkmm to latest version.
<rekado_>new feature in R 3.2.0: "R CMD INSTALL gains an option --built-timestamp=STAMP allowing 100% reproducible package building, thanks to Dirk Eddelbuettel."
<paroneayea>o/ guix
<paroneayea>and o/ davexunit
<paroneayea>hey davexunit, maybe interesting to you (I still have to post it to guile-devel, will do after I finish getting ready for the day) but:
<paroneayea>ijp: ^^
<davexunit>paroneayea: awesome!~
<jrandall>I'm struggling to get guix working from behind a firewall that requires outbound http/https traffic to go via an http proxy. I've spent the past few days developing fixes that make the core of guix work with a proxy (see patches at, but now I'm stuck because the bootstrap guile is only version 2.0.9, and 2.0.10 or greater is required for proxy support.
<jrandall>Can anyone advise me on how I can move to a newer version of the bootstrap guile?
<bavier>jrandall: have a look in gnu/packages/bootstrap.scm
<jrandall>I was just poking around in there - I see that for armhf it is already using 2.0.11
<bavier>you may be able to make 2.0.11 the universal version
<bavier>and use 'guix build bootstrap-tarballs'
<jrandall>so far I haven't been able to get `guix build bootstrap-tarballs` working because it seems to use the existing bootstrap guile, but I guess I can try to create the binary tarball manually?
<bavier>jrandall: you may need to wait until civodul gets on here...
<jrandall>Thanks, I'll keep an eye out... in the meantime I'll keep poking around at trying to create an x86 binary tarball for guile 2.0.11
<jrandall>It looks like guile-bootstrap-tarball defined in gnu/packages/make-bootstrap.scm is relevant, but I'm not sure how to call it
<paroneayea>davexunit: others: how do you generally send patches to the list?
<paroneayea>I'd love it if it opened up a buffer in mu4e
<davexunit>paroneayea: that or just attach the patch in an email yourself
<paroneayea>ok :)
<davexunit>I haven't configured git-send-email to work correctly, yet.
<paroneayea>haha, mu4e-action-git-apply-mbox
<paroneayea><3 emacs programs
<mark_weaver>jrandall: if you replace the bootstrap guile, then you'll need to build *every* package from source code, starting with a bootstrap process not unlike that described in Cross [GNU/]Linux From Scratch.
<mark_weaver>jrandall: do you want to be building everything yourself, or do you want to use binaries built by our build farm?
<paroneayea>submitted guile-minikanren to the list
<paroneayea>I didn't even call it minikranen this time!
<jrandall>mark_weaver: unfortunately, I can't access anything without a guile that supports http proxies so I guess I have no choice but to build them myself?
<paroneayea>which I seem to accidentally do all the time
<davexunit>paroneayea: hehe
<davexunit>thanks for packaging it! I will enjoy it. :)
<mark_weaver>jrandall: there are other options. but first, can you answer my question?
<jrandall>mark_weaver: I'd ideally like to be use binaries built by your build farm as well as develop new packages that I build myself
<mark_weaver>jrandall: okay, so you shouldn't replace the bootstrap guile. let's find another option :)
<jrandall>mark_weaver: ok - I assume eventually guix is supposed to start using the non-bootstrap guile package... is there a way I can get to that point by getting binaries built elsewhere?
<mark_weaver>jrandall: this will require some study, and quite possibly civodul knows the answer from memory.
<jrandall>ok, i'm happy to wait, thanks!
<mark_weaver>I'm afraid I don't have a ready answer for you right now.
<mark_weaver>jrandall: thanks for your patience, and for working on improving it!
<jrandall>mark_weaver: no problem - I suspect not too many people these days are still stuck behind corporate proxy servers (some of our machines are now freed from it, but this particular set is still firmly trapped)
<jrandall>In order to use the pre-built binaries from hydra, do we need to keep the default store path as /gnu/store ?
<jrandall>mark_weaver: ah, then that explains why I am not getting the substitutes - in that case I will want to be building everything from source
<mark_weaver>I should also warn you that the absolute path of the store needs to be kept quite short.
<mark_weaver>because absolute pathnames of programs in the store need to be put into shebangs at the top of scripts, and the kernel imposes a severe limitation on the length of those.
<mark_weaver>I forget the exact length, but it's quite constraining in practice.
<mark_weaver>jrandall: out of curiosity, why can't you put it in /gnu/store ?
<jrandall>mark_weaver: Oh, I see - that makes sense. /gnu/store is 10 characters, and I was intending to use one with 20 - is that likely to be too long?
<mark_weaver>quite possibly
<jrandall>I can put it at /gnu/store on some machines on which we have full access, but I was hoping to also use guix on other machines where we only control a mountpoint under /software
<mark_weaver>are you able to run guix-daemon as root?
<mark_weaver>can you use a bind mount to map /gnu to something within /software ?
<mark_weaver>e.g. mount --bind /software/gnu /gnu
<jrandall>mark_weaver: only on some of the machines - I was hoping we could run it as a non-root daemon user who owns the store on those machines
<jrandall>we wouldn't be able to do that on some of the machines, at least not without going through a heavy change request process
<mark_weaver>I believe there may be issues with running guix-daemon as a non-root user. in that case it is unable to create a chroot or isolated build environment, and so the builds may pick up things from the host environment and many things may break.
<jrandall>an alternative might be for us to provide our users with the guix environment inside containers
<jrandall>(inside of which we can operate as root)
<jrandall>I see there is a potential GSoC project having something to do with guix targeting containers
<mark_weaver>yes, see "Linux container support" in
<mark_weaver>guix-daemon essentially creates containers for doing builds, where only the declared inputs are available to the build process.
<mark_weaver>package build systems tend to be resourceful in finding things from the host system though, and if they do, the builds will break.
<jrandall>Is there any documentation on how to setup a hydra-like build server to serve substitutes (in case we do want to change the store path and build our own environment)?
<mark_weaver>hydra is not yet nicely packaged, but we are working on that. in the meantime, take a look at section 2.3.2 of the manual "Using the Offload facility"
<jrandall>Oh, I've just noticed the time - I need to head out but I'll try to come back later this evening
<mark_weaver>okay, ttyl!
<Sleep_Walker>gnunet_bot: seen civodul
<mark_weaver>sneek: seen civodul
<sneek>civodul was here May 07 at 12:12 pm UTC, saying: that's still a good idea anyway ;-).
<mark_weaver>Sleep_Walker: gnunet_bot only logs. sneek is the one who will deliver messages and some other things.
<mark_weaver>but I see that its clock is set wrong
<mark_weaver>sneek: seen mark_weaver
<sneek>I last saw mark_weaver on May 08 at 08:09 am UTC, saying: sneek: seen mark_weaver.
<mark_weaver>scan last:40
<mark_weaver>oops :)
<Sleep_Walker>mark_weaver: thanks
<Sleep_Walker>it seems that bug#20081 is not fixed :(
<mark_weaver>Sleep_Walker: can you send mail to about it?
<davexunit>paroneayea: one thing I noticed about your minikanren patch is that you don't compile the scheme files. I think adding that step would be good. 'guild compile' does the job.
<mark_weaver>I never studied that bug, and it's probably more efficient for civodul to look at it.
<davexunit>paroneayea: I'll make a reply on list later when I'm at home with a better email setup.
<mark_weaver>davexunit +1
<davexunit>I'm very excited to have this packaged, since I just bought "The Reasoned Schemer" this weekend.
<mark_weaver>that's a great little book
<paroneayea>davexunit: cool, that makes sense... I should do that.
<davexunit>I'll try out the package myself later when I'm on a guix machine.
<davexunit>paroneayea: you picked a tricky first package!
<mark_weaver>yes, indeed.
<mark_weaver>a package without a build system included, it seems.
<davexunit>it makes sense because they are just R6RS modules with no ties to any implementation
<mark_weaver>ah, that's true
<mark_weaver>maybe we should have a better way of dealing with pure R6RS scheme code.
<mark_weaver>maybe an r6rs-build-system or something
<davexunit>perhaps we could come up with the start of a guile-r6rs-build-system if we wrote a package for industria
<davexunit>and see the common code between it and this minikanren package
<paroneayea>davexunit: mark_weaver: yeah civodul suggested maybe we could eventually have a r6rs-build-system thing
<davexunit>that would be very helpful for libraries like these
<davexunit>industria is my next most wanted r6rs package
<paroneayea>I didn't realize this was a harder than normal first package :)
<paroneayea>anyway I had fun doing it!
<davexunit>that's what matters! :)
<paroneayea>okay, so if I was going to compile that though, I'd need the guild command right?
<paroneayea>how do I access that?
<davexunit>paroneayea: guile comes with 'guile'
<davexunit>so it should be in your build environment already
<paroneayea>okay, so I can just call a system*?
<davexunit>(system* "guild" "compile" source-file)
<paroneayea>also, I assume need to copy down the license file, since it's modfied BSD
<paroneayea>I was following grue-hunter, but I think that might do the wrong thing
<paroneayea>ah, I see
<paroneayea>if the copyright headers are in the COPYING
<paroneayea>does it need the file copied over?
<paroneayea>yes it does.
<paroneayea>I should throw an error if the "guild compile" fails
<paroneayea>I could use "assert" but that requires including (rnrs base (6))
<paroneayea>though I could also just use (if (not (zero? (system* "blah"))) (error "uhoh"))
<paroneayea>for whatever reason, guild is not on the path
<mark_weaver>paroneayea: it might be simpler to use the 'gnu-build-system' and remove the phases you don't want
<mark_weaver>gnu-build-system includes some useful phases, notably one that sets environment variables and paths.
<paroneayea>mark_weaver: I could probably do that I guess? I'm also just confused as to why guild isn't there
<paroneayea>is it because maybe it isn't on the $PATH?
<paroneayea>mark_weaver: also, it's not clear in the docs, do you know what the difference between "inputs" and "native-inputs" is?
<paroneayea>in a package definition
<paroneayea>gotta stop being distracted by this
<mark_weaver>paroneayea: right, it's not on the path. setting path is one of the things done by an early phase of gnu-build-system
<mark_weaver>paroneayea: when cross-compiling, e.g. building for ARM on an intel box, native-inputs are built to run on intel, and inputs are built to run on ARM.
<davexunit>you get a reference to guild like so: (string-append (assoc-ref %build-inputs "guile") "/bin/guild")
<davexunit>can get*
<davexunit>paroneayea: ^
<paroneayea>davexunit: yeah I just figured that out, but now I'm getting other weird errors
<paroneayea>I thought I had a good recipe
<paroneayea>but seems like no.
<mark_weaver>right, but there may be other needed variables as well
<paroneayea> gives me this weiiiird output
<mark_weaver>I'm one-handed right now. it's hard to do much. one arm holding a baby
<paroneayea>no worries :)
<civodul>Hello Guix!
<paroneayea>hi civodul
<mark_weaver>hi civodul!
<mark_weaver>I'm currently trying to get the 'guix' package to build successfully on MIPS and ARM, so that I can make self-contained tarballs for them.
<mark_weaver>I'm currently stuck on the fact that 'guix package -A' never prints anything on armhf, because it's not in %supported-systems, which causes one of the tests to fail.
<jrandall>hi civodul
<mark_weaver>maybe hydra should have its own variable for %hydra-supported-systems or something?
<civodul>mark_weaver: could you add that to %supported-systems?
<civodul>ahh i see
<civodul>yes, you're right
<civodul>we probably need a separate variable for Hydra
<civodul>we just need it in build-aux/hydra/gnu-system.scm in fact
<mark_weaver>civodul: also, 5763ad9266 does not seem to affect guix package -s at all
<mark_weaver>(although its commit message says that it does)
<civodul>it adds a "systems:" line normally
<mark_weaver>oh, I see..
<civodul>yeah, initially i made the same for -s and -A
<civodul>but then thought that this was not ideal for -s
<mark_weaver>I do think that we should have a way to find packages even if they aren't supported on %current-system
<mark_weaver>I'd been using guix package -A for that, but I can switch to using -s instead.
<mark_weaver>sounds good, thanks!
<civodul>i'm looking at the libstdc++ RUNPATH issue, it's terribly annoying
<civodul>or boring
<civodul>or both
<mark_weaver>thanks for working on it!
<civodul>GCC 5.1 is out! \\o/
<mark_weaver>civodul: another problem I ran into on armhf is that there's a call to (search-bootstrap-binary "guile-2.0.9.tar.xz" ...) in tests/packages.scm, but on armhf it's guile-2.0.11.tar.xz
<mark_weaver>I was thinking of just putting a redundant 'match' in there, but it's not so nice.
<mark_weaver>well, I'll just do the redundant match for now...
<paroneayea>I kind of wish I could run `guix package --search-paths` in guile
<paroneayea>in bash
<paroneayea>and have that just set up whatever's needed
<paroneayea>it doesn't actually work though due to the quoting I guess.
<mark_weaver>paroneayea: the early phases of gnu-build-system do exactly what you need
<mark_weaver>I would recommend just using that build system and remove/replace the phases that don't do the right hting.
<paroneayea>mark_weaver: great! (btw the --search-path was about my .bashrc :))
<mark_weaver>oh, I see.
<mark_weaver>well, for one thing it's not a particularly fast operation.
<paroneayea>hm I suppose
<mark_weaver>and it only takes into account things in your user profile, not things in the system-wide profile.
<mark_weaver>although really that other problem should be fixed somehow anyway.
<paroneayea>maybe guix should write out a standard_env_things thing that should be sourced ;)
<mark_weaver>I think there might be a bug ticket discussing this issue.
<mark_weaver>paroneayea: it's not a bad idea!
<civodul>mark_weaver: regarding the test, ok for the redundant match (i don't have a better idea right now)
<civodul>paroneayea: one can run "eval `guix package --search-paths`" and that kinda works
<paroneayea>civodul: maybe it would be nice to have a post-hook for guix package install/remove things that writes source'able files out
<paroneayea>both for the system profile stuff
<paroneayea>and then a per-user one
<paroneayea>I guess that would be upon changing generations and etc too
<paroneayea>so it would have to run on a lot of operations
<paroneayea>but still, such a thing would be nice
<paroneayea>and could maybe simplify some usage...
<davexunit>what are we talking about?
<davexunit>to me, 'guix package --search-paths' is something you run rarely and stuff into your bashrc
<davexunit>it's a helper
<paroneayea>davexunit: let me put it another way
<paroneayea>what if we end up targeting users who don't ever run the guix cli stuff directly
<paroneayea>which we want to do eventually right?
<paroneayea>have a graphical package manager and etc
<paroneayea>we'd want a way to have this environment stuff mostly set up for them right?
<davexunit>I'm not sure what the right thing is there
<civodul>paroneayea: i sympathize with the idea that it should just DTRT to make it work out of the box
<civodul>however, i can't think of anything "acceptable" that can be done automatically
<paroneayea>civodul: not even providing on-profile-change hooks?
<civodul>opam (OCaml's package manager) offers to write env var settings in ~/.bashrc, and asks interactively whether the user is ok
<civodul>that's fine, but not quitte elegant IMO
<davexunit>the problem I see with such a hook is that the process becomes imperative
<paroneayea>I don't think writing stuff to ~/.bashrc is good
<paroneayea>but ~/.guix_bashenv or etc
<paroneayea>or maybe each profile
<civodul>paroneayea: what would this hooks be used for?
<paroneayea>could have such a thing
<paroneayea>civodul: so that users can add to their own .bashrc
<paroneayea>source path/to/my-profile/env-stuff
<civodul>and there would be a convention that "env-stuff" files are always created, etc.?
<paroneayea>what if you made it more functional in that it happens as part of each generation of profile being built?
<paroneayea>and actually is put into that generation
<paroneayea>civodul: yeah
<paroneayea>at that point it needn't be a hook
<paroneayea>well you could have a hook
<civodul>like there could be ~/.guix-profile/the-env ?
<paroneayea>civodul: right
<davexunit>to complicate matters: what about when you want to also use the current system's paths?
<civodul>it is so much better than "eval `...`"? :-)
<paroneayea>davexunit: what if you source both, in order?
<davexunit>then one would clobber the other
<paroneayea>civodul: <mark_weaver> well, for one thing it's not a particularly fast operation.
<paroneayea><mark_weaver> and it only takes into account things in your user profile, not things in the system-wide profile.
<paroneayea><mark_weaver> although really that other problem should be fixed somehow anyway.
<paroneayea>the top one at least, is one reason why better than eval
<paroneayea>though maybe there could be something that does profile merging, I don't know.
<civodul>yes there's an open bug for profile merging
<civodul>on guixsd, that is
<paroneayea>at any rate, I wonder if it's hooked into each generation and just always written out
<paroneayea>if that makes it a bit less imperative
<paroneayea>I guess the issue though
<paroneayea>is it's not just bash that needs this
<paroneayea>I have no idea how to handle, say, the gnome shell overview.
<davexunit>the login shell needs the correct env
<davexunit>I don't know how to change it without reloggin
<paroneayea>I'm not sure either.
<paroneayea>I do think this is a critical issue to have a solution to in the long term. I have no idea what such a solution could be though.
<paroneayea>in the meanwhile, I mean, I'm okay with doing --search-paths and adding it manually
<civodul>paroneayea: but it *has* to be manual, no?
<davexunit>in practice, the search paths rarely change
<civodul>i guess i don't fully grasp what the problem is
<paroneayea>civodul: the problem is that I'd love GuixSD to become a solution to even the non-technically-inclined in the future
<civodul>yes, me too!
<paroneayea>and that can't happen if it involves "well, just open your .bashrc ..."
<paroneayea>there has to be some automatic way to propagate the current profile's environment requirements to the user's environment
<paroneayea>there's one "cheater route" :)
<civodul>but the thing is, except on GNU/Hurd (!), we can't change the environment variables of running processes
<paroneayea>which is to ship with default environment paths that have all the most commonly changed environment variables in the guixsd already set up
<civodul>so it's a tricky thing anyway
<civodul>but on GuixSD, i agree we can (and will) do better
<paroneayea>civodul: do you think the "by default you already have all these paths set up to these places" is the best route?
<paroneayea>for guixsd
<paroneayea>obviously, doesn't work for guix on debian :)
<civodul>yes, definitely
<paroneayea>that seems fine to me.
<civodul>actually on guixsd /etc/profile already has a bunch of libraries initialized for convenience
<civodul>the next step is to auto-generate it
<paroneayea>also, I'm not surprised that Hurd has a solution that monolithic kernel systems don't :)
<paroneayea>pretty neat to hear though
<paroneayea>maybe guixsd will be the route to which I actually play with Hurd again.
<paroneayea>I've gotten really distracted via Guix today!
<paroneayea>I feel kind of bad about it. I need to focus on mediagoblin tomorrow
<paroneayea>but I feel much better about knowing how guix's packaging works now
<paroneayea>plus now I can play with minikranen :)
<civodul>oh, minikanren, yay! :-)
<paroneayea>yeah I submitted a patch!
<civodul>i haven't completely caught up with today's emails
<civodul>paroneayea: very nice!
<paroneayea>which actually I did most of last night
<paroneayea>but then davexunit and mark_weaver convinced me to try to get it to compile the .scm files and I went down a deep rathole :)
<civodul>good to see you on board :-)
<paroneayea>it's good to be on board! :)
<civodul>i think libstdc++ killed my emacs
<civodul>i had done too many gcc recompiles in my shell buffer i guess
<civodul>and emacs spent more and more time in gc
<civodul>and eventually spent all its time in gc
<paroneayea>the gnu garbage compiler