IRC channel logs
2015-02-14.log
back to list of logs
<Digit>having that along with is better than nothing. thanks. :) but yeah, i did mean a version with it embedded, oh~ nm, the view just changed to what's on screen now. i thought it was going to be just a shot of the fella without seeing what was being pointed at. nm. <ewemoa>Digit: seems like it worked out afterall :) <iyzsong>mark_weaver: hi, is it ok for now to push libxml2 and gnutls change to master? <mark_weaver>oh, I see now. the gnutls change should be pushed to core-updates. there's no rush on that one. <mark_weaver>the libxml2 change should also be pushed to core-updates, I think, but not master. <mark_weaver>iyzsong: how about adding zlib as an input to libxklavier for 'master', and doing the proper fix on core-updates. would that be okay? <mark_weaver>the problem with doing this directly on master is that it will require about 1500 rebuilds. <mark_weaver>in a few days, I'd like to ask hydra to do a full build of 'core-updates' and then merge it into master after it's finished building on intel. <mark_weaver>but before doing that, I'd like to see what other updates/fixes we can get into core-updates. <iyzsong>but .. how to do that? merge master to core-updates and cherry-pick the changes? <mark_weaver>iyzsong: after you do the temporary fix to 'master' and add libxklavier, let me know and then I'll merge 'master' into 'core-updates'. then you can fix things up properly on core-updates. okay? <iyzsong>um, what's the temporary fix to 'master', doesn't just pick the libxml2 and gnutls PATCH from ML to 'core-updates' enough? <iyzsong>I think we can leave libxklavier later <mark_weaver>oh, okay. if libxklavier can wait until core-updates is built (in about a week, hopefully), then no need for a temporary fix. <mark_weaver>(the temporary fix would be to add 'zlib' as an input to libxklavier) <iyzsong>by the way, it's Chinese new year now, I'm on holiday :) <mark_weaver>iyzsong: oh, I wanted to ask you before: would it make sense to add an 'xfce-session' for slim? <mark_weaver>I was trying to help someone new to set up xfce on GuixSD. I told him to create an ~/.xsession script, but wondered if there was a better way. <iyzsong>mark_weaver: yes, but I think you have to add xfce to 'packages' manually, See also: bug #18698 <mark_weaver>hmm. ideally, the packages and services would be able to find what they need from the store, without requiring them to be in the profiles. however, maybe that's too difficult in some cases, dunno. *iyzsong just rebase and add 'libxml2, gnutls, libxklavier' to 'core-updates' <iyzsong>mark_weaver: thanks for the helping! *mark_weaver reopens bug #18698 <mark_weaver>linux-libre 3.19 doesn't boot properly on my Libreboot X60. the system seems to hang while trying to do something related to intel graphics, maybe while trying to start X. has anyone else had a problem with this? <fchmmr>You'll need to stay on <3.19 for the time being. <fchmmr>I would appreciate any help at all. <mark_weaver>unfortunately, I won't be able to help much with this anytime soon. there was a second baby born into my household a few days ago, and we are all overwhelmed and with very little sleep :-/ <mark_weaver>but I can take care of reverting us to 3.18.7 for now <fchmmr>I expect that this will be fixed before long. <fchmmr>Either in coreboot, or linux. That's more or less how it goes. <fchmmr>(this actually looks like a regression in linux, rather than a bug in coreboot, but I could be wrong) <fchmmr>3.19 (kernel parameters in GRUB): <fchmmr>No options: system won't boot. ACPI PCC probe fail. <fchmmr>acpi=ht -> system won't boot. same error. <mark_weaver>I personally consider support for Libreboot machines out of the box to be a requirement for GuixSD. <fchmmr>acpi=noirq -> system won't boot. same error. <fchmmr>pnpacpi=off -> system won't boot. same error. <fchmmr>noapic -> system won't boot. same error, plus "ACPI: SCI (ACPI GSI 9) not registered <fchmmr>nolapic -> won't boot. same errors as with noapic, plus "e1000e 0000:01:00.0 0000:01:00.0 (uninitialized): Failed to initialize MSI interrupts. Falling back to legacy interrupts." <fchmmr>I tried all of those kernel options, on the "linux" line in GRUB. <fchmmr>mark_weaver, try those on your 3.19 to see if you get the same results. <mark_weaver>fchmmr: sorry, I don't have the spare time to try it. <fchmmr>something to do with pci devices, apparently. <fchmmr>that could be anything, but there are few pci devices that would cause issues. <fchmmr>It might be video related. That "ACPI PCC probe failed" error is shown on other systems, but I get the impression that it doesn't cause a failed boot .I've even been told that by a kernel developer. <fchmmr>So it looks like the problem lies elsewhere. <fchmmr>I'm actually juggling several bugs simultaneously. <fchmmr>The other one is a GRUB bug that's existed for some time. Someone is working on a fix, and I'm helping test it. <fchmmr>The bug is in the SYSLINUX parser when GRUB sees a vesamenu.c32 file. Currently it will just fail. <fchmmr>And there are huge amounts of work in lots of areas in libreboot that I still need to do. <mark_weaver>I wish I could help more. Libreboot is a very important project. <fchmmr>I'm working with others (mtjm, mainly) on making libreboot more contributor-friendly. <fchmmr>This includes things like documenting how libreboot is developed (work flow, maintenance guides, how everything is set up in git, etc), what areas are high priority, and so on. <fchmmr>mtjm is also interested in converting the documentation to sphinx/rest (similar to markdown), where currently I just edit directly in html. <fchmmr>I'm making some edits to improve the usability of the installation instructions. <mark_weaver>fchmmr: ah, I'm glad to see instructions for the R400. I might use one of those for a small server. <fchmmr>That's git. It's not in the stable release yet. Works, though. *mark_weaver likes the levitating GNU image better, but it's not important. anyway, I must sleep now. happy hacking! <rekado>I get an error using "guix pull" on an installation of the system distribution. <rekado>after downloading guix-master.tar.gz it says: "errer parsing derivation `/gnu/store/zjbsx...-tar-1.28.drv': expecting string `Derive(['" <mark_weaver>rekado: can you paste the contents of that .drv file somewhere? <mark_weaver>make a copy of it please for investigation, and then use 'guix gc -d' to delete it and try again. <taylanub>is it too minor of an improvement to make it worth? I'm thinking it might be more friendly to non-lispers who want to write package recipes. <mark_weaver>I would prefer to wait until civodul returns before discussing something like this, so that he can participate in the discussion from the start. what do you think? <mark_weaver>I don't want to have a week long discussion before he can even comment on it. <mark_weaver>jxself: I reverted our linux-libre to 3.18.7 for now, since 3.19 doesn't work on Libreboot X60 machines. <taylanub>oh right, he's away. sure, let's wait; I'll note it down so I don't forget. <phant0mas>mark_weaver: rebased wip-hurd on master, made sure everything works as before and sent the patches to the list for review. <phant0mas>now it will be easier for me and Marek to work on it <taylanub>is it normal that these SBCL tests would fail in our build environment? http://sprunge.us/HhOS it seems to 1. get an unexpected errno (instead of the designated exception) when requesting an unexistent protocol (TCP and UDP work fine), 2. gets nil from all of GETPWUID, GETPWNAM, GETGRID, GETGRNAM <mark_weaver>phant0mas: so these are the same patches that you had before, just rebased? if so, and there's nothing new, then please update the 'wip-hurd' branch on savannah by running "git push origin :wip-hurd" (note the ':') and then "git push origin wip-hurd". <jxself>mark_weaver: It doesn't? Why not? <mark_weaver>I noticed it on my own machine, and then fchmmr confirmed it (I guess on a different distro), and that he's working on it. <jxself>Okay. This might be a good reason for having that updated kernel package thing with various versions? :) <mark_weaver>jxself: yes, of course. It's just that I'm overloaded right now, partly because of a second child just being born into my household a few days ago. <jxself>Oh, kids? Eeek. Good luck with that. :) <mark_weaver>I'm not a parent myself, but I live with my best friends who are parents, and I help with that in exchange for room and board. <mark_weaver>taylanub: oooh, are those the only test failures with an sbcl bootstrapped from source code in guix? if so, that's great! out of curiosity, which CL implementation did you use for the bootstrap? <jxself>Ah ha. I imagine that this will be fixed in 3.19.1. <taylanub>mark_weaver: I used CLISP for bootstrapping, and it goes much smoother than I'd have expected :) <mark_weaver>taylanub: the PWENT and GRENT errors are expected. our build environment doesn't contain entries for those users. <jxself>mark_weaver: The kernel configuration also needs to be reverted back to the 3.18 one. <mark_weaver>jxself: I just reverted your 3.19 update commit and then updated to 3.18.7 in another commit. so I guess that's taken care of. <jxself>Ah yes, I see I missed that. So nevermind. <mark_weaver>taylanub: and I guess the "GET-PROTOCOL-BY-NAME" is because the build environment lacks /etc/protocols <mark_weaver>taylanub: so yeah, all of those errors are expected and probably don't indicate any actual problems. <rekado>mark_weaver: the drv file is empty. *shrugs* <mark_weaver>rekado: as I recall, there is (or was) a common problem where crashes on ext3/4 filesystems would result in some files being empty, maybe because the file creation would get committed to disk before the contents were written, or something to that effect. I don't remember the details though, or the current status. <mark_weaver>it may be that there's something we could do in guix-daemon to prevent that, dunno. <mark_weaver>rekado: for now, I suggest "guix gc -d /gnu/store/xxx.drv" and try again. <mark_weaver>rekado: what kind of filesystem is running on your /gnu/store partition? <mark_weaver>I guess mounting with "-o data=ordered" should avoid the problem, at some cost to performance. <mark_weaver>but the problem may have been fixed at some point. what version of linux (the kernel) are you using on the machine that has write access to /gnu/store ? <mark_weaver>looks like the situation was improved in 2.6.30, but maybe you're running an older kernel than that. <taylanub>to what extent should one patch occurrences of /bin/sh in a package? SBCL has some modules, not needed at build-time, that refer to /bin/sh <a_e>They should be patched, as there is no guarantee that /bin/sh will exist at runtime. <a_e>(Do we have it in gsd currently?) <taylanub>hm, it's not just /bin/sh either. and I bet a lot of packages have such references to standard Unix tools. do we really intend to patch them all? <a_e>Normally I do. Without guarantee that all of the occurrences are found, of course. <a_e>It makes sense: Otherwise, the outcome is not functional. <a_e>It depends on the runtime environment and not only on the inputs. <taylanub>then there's a module which creates executables, and it puts #!/bin/sh at their top. these might be intended to be cross-system executables, so I suppose in that case the #!/bin/sh should remain so? <a_e>Again, I do not think so. We would like an outcome that depends only on the bash used as input. <a_e>There was discussion to add /bin/sh as a symlink to gsd. If this has not been done yet, then all such scripts do not work. <taylanub>that means executables created with Guix's SBCL will only run on Guix systems that have the same SBCL package from Guix installed (or concidentally the same Bash package, for some other reason) <a_e>In any case, I think it is a clutch. <a_e>Oh, I see; so the executable scripts are not created during the build process, but there is some kind of compiler that a user who has installed sbcl can execute? <a_e>And that creates the scripts at runtime, not build time? <taylanub>right, it's a module contrib/sb-executable. then again I just noticed it uses 'exec sbcl ...' in these executables, and if the target system are expected to have SBCL then the question is whether it'd be an onerous expectation of them to have Guix's SBCL and not just any SBCL... <taylanub>I guess it would be though. if SBCL users exchange such executables, we can't limit them like that... <a_e>It depends on how portable these scripts are. <a_e>Python scripts tend to start by something like "/usr/bin/python", and then it is anybody's guess whether this will work with python 2 or 3. <mark_weaver>taylanub: for starters, /bin/sh doesn't exist in our build environment <mark_weaver>GuixSD does include /bin/sh for user convenience, but none of our packages should depend on it. <a_e>Has anybody already seen the following: <a_e>Gen6+ requires Kernel 3.6 or later. -- Segmentation fault. <a_e>It happens with calibre that I just packaged (minus some dependencies that are needed according to its web page, but that are not needed at least for compiling and installing it). <taylanub>mark_weaver: these modules aren't used at build-time though <a_e>No idea. Part of a cryptic error message. <mark_weaver>taylanub: well, that package is used as an input to some other package, then it won't work <a_e>Searching the web returns something related to mesa. <mark_weaver>taylanub: executables created by Guix would normally only work on Guix anyway, because they will have embedded rpaths to find their libraries, dynamic linker, etc, in /gnu/store <mark_weaver>forget about trying to compile stuff that works on both Guix and traditional GNU/Linux distros. <mark_weaver>even our autotools packages create a ./configure script et al that look for things in the standard (FHS) places. <taylanub>#lisp is also telling me that the module is probably not meant for making portable executables. I'll patch it then. <mark_weaver>the whole point of autotools is to create portable bootstrap scripts. <mark_weaver>so then those have to be fixed up in the early phases of gnu-build-system, as usual. <mark_weaver>another example: our linker (ld) doesn't add rpaths automatically, but we have an 'ld-wrapper' package that takes care of that. <a_e>I am trying to build a vm image with my calibre, that uses the guix kernel. <mark_weaver>anyway, I'd like to hear what civodul thinks, but for now I wouldn't worry about trying to allow sbcl's compiler to produce portable executables. that's a can of worms. <a_e>What are "module-import-compiled"? I am having about a dozen of them. Are they all different kernel modules? <mark_weaver>a_e: not kernel modules, they are compiled guile modules (.go files) <a_e>Okay. Their names are not very telling ;-) <a_e>How again do I open an xterm in ratpoison? *paroneayea updating mediagoblin so that we don't do the insane thing of committing javascript libraries into our repo anymore <paroneayea>an insane thing which almost all libre webapps do, but soon we won't anymore <paroneayea>I'm having to use bower, but I think it would be nice if there's a future where there's a guix environment option that handled things <paroneayea>and guix was broadly available enough where I could recommend it for a development environment solution <a_e>You mean, you copy external js libraries into your source tree? <a_e>Well, there is worse. I am trying to package handbrake (a dvd ripper), and they _download_ external libraries, even if they are available on the system. <paroneayea>I know it's insane, most libre web applications have done it, but that doesn't mean it's good :) <paroneayea>a_e: so actually, how to do "linking" with javascript and css libraries installed on the system <a_e>Nix works around it by replacing "wget" with a more or less empty script. <a_e>It should be easy to package js libraries and reference them in your web app, no? <paroneayea>a_e: I'd probably need to symlink them into the package <paroneayea>a_e: it isn't easy because the web server needs to serve them <a_e>Yes, in a functional environment, a package should be built from its inputs, not some random tarball downloaded from outside. <paroneayea>and you need to make it easy so that the paths to serve those libraries are "mounted" in the apache/nginx/whatever in a predictable way <a_e>Symlink or rewrite the path, no? <paroneayea>especially in thinking how to reduce steps for users <a_e>I see, there is a sandbox around apache? <paroneayea>a_e: symlinking is probably the answer, rewriting in the config isn't, because you need users to find a way to dump all those config steps into their webserver config manually <paroneayea>so if you can have an "extlib" directory full of all the symlinked paths <paroneayea>than telling users to constantly update their apache/nginx configs as you change up your javascript dependencies <a_e>How about using a "www" user that installs all the guix packages? And then have apache serve its home directory? <paroneayea>a_e: that's something to think about when I think about how to guix environment it up ;) <paroneayea>in the meanwhile I also need to support debian and fedora things that don't have an easy way to install guix yet <a_e>These web things are too complicated! ;-) <paroneayea>a_e: but if you're interested in me scheming with you in the future about this when I think about guix-alternative routes, I might ping you :) <a_e>You may, but indeed I know nothing about web apps... <a_e>I just have a running apache (and configuring it on debian was already more complex than what I expected). And I must have used jquery once in the past... <a_e>mark_weaver: It seems to me that hydra has become quite a bit faster with nginx installation and tweaking the caching. <taylanub>mark_weaver: hm, what about "portability" across different versions of SBCL on the same Guix system? ex.: user uses the sb-executable module to create an executable to be used on the same system, later updates the Guix SBCL package, garbage-collects the old one, and now those executables don't work anymore until they're regenerated with the SBCL from the updated package. <a_e>Almost there with my vm! <a_e>So again if someone can quickly help: I included an xterm into my image. What is the key combination to open it in ratpoison? <mark_weaver>everything compiled in guix is linked to a particular dynamic linker, precise sets of shared libraries, etc. requiring a particular sbcl executable is analogous. <mark_weaver>the model in guix is that everything on top has to be either recompiled or grafted. <mark_weaver>and that's needed to support the unusual features we provide <mark_weaver>if you compile a C program on Guix, but outside of a guix package recipe, then the shared libraries it is linked to could get garbage collected if you don't take measures to prevent it. that happens to be periodically. <a_e>Thanks, I found it in the meantime! <a_e>Now when I run calibre, nothing seems to happen. <grantix>a_e: Sorry, was running errands. :^P <mark_weaver>a_e: yes, civodul implemented much more aggressive caching, and it really helps. <a_e>It should open another window. Would this be tiled and my xterm halved in size? <a_e>Oh, something does happen. It is just slow in qemu. The configurator opens in front! <grantix>a_e: No, in Ratpoision you have to manually split. <mark_weaver>and there are commands to resize tiles. see Ctrl-t ? (iirc?) <grantix>Ctrl-t s is horizontal, Ctrl-t S is vertical. <grantix>But yes, Ctrl-t ? does open up all set commands, or at least all default commands. *grantix is going do dedicate next weekend to see how far he can get at packaging Stumpwm. <mark_weaver>grantix: did you notice that we have clisp now? (as well as ecl and soon sbcl) <a_e>Thanks for the crash course! <grantix>Ratpoison is workable, but it's a major downgrade now that GSD is now on my major box again compared to Stumpwm. <a_e>Actually, calibre also crashes, since it is looking for one of its documented inputs that I did not add yet. <a_e>Ah, the pleasures of python! <grantix>mark_weaver: Yeah, that's a bit big boost to my motivation. :^) <taylanub>mark_weaver: this SBCL module can create executables for the user. e.g. I could put the generated file in my ~/bin to use it as a stand-alone tool. but it will actually be a shell script with a shebang and doing "exec sbcl [...flags...]" <paroneayea>is there a nice way to connect the scheme file I'm at to the geiser repl? <grantix>I would do it this weekend, but I have a test Tuesday that I haven't really studied much for yet and some homework I need to catch on before said test ... one day I will learn not to procrastinate, maybe. <taylanub>paroneayea: if it defines a module, you can switch to that module via ",module (foo bar)" <taylanub>paroneayea: e.g. while editing $guix_src/gnu/packages/lisp.scm, I can do ",module (gnu packages lisp)" in the REPL to get the same environment <paroneayea>taylanub: thanks... what I mean is, I'd like C-x C-e to start stuff in the geiser repl started by M-x guix-all-available-packages and etc <paroneayea>taylanub: but if I do C-x C-e it doesn't run things in the *Guix REPL* <paroneayea>just seems to be a geiser buffer started by M-x guix-all-available-packages <paroneayea>and I figure, hey, if I'm hacking guix, that probably already has the environment set up right :) <grantix>taylanub: Part of Emacs shipped package now, via guix.el I think? <grantix>taylanub: If you have Emacs installed via Guix, you should have it in your site-lisp iirc. <mark_weaver>paroneayea: someone on #guile might be able to help. I confess that I've never gotten in the habit of using geiser much, because of various problems I've had when I've tried. I should really rectify that though. by all accounts it makes guile hacking much nicer. <paroneayea>"how to associate a scheme buffer with a particular geiser repl" <paroneayea>seeing civodul hack around in his emacs made me feel like I really want an interactive guix hacking experience :) <grantix>Yeah, I want to jump into Geiser a bit more than I have thusfar. Seems very nice, but never have dedicated the time to really do anything non-trivial in it. <mark_weaver>civodul and alezost are the most likely to know both geiser and guix well enough, but I guess neither are around right now. <paroneayea>grantix: mark_weaver: I got into it because davexunit's sly project makes great use of it *grantix hopes that talk got recorded, but it sounds like it may of not been. *grantix is trying to think the best way to set a background service of/for seeding those Gabou torrents. <grantix>Maybe make a service that starts rtorrent in a specific session dedicated to such things, and connect from that session if/when need be. <grantix>mark_weaver: I know you mean transmission-daemon proper, but it would be cool to have a dedicated daemon to seed GSD. :^) <Gabou>grantix: I'll have to do it again, someone proposed to include sig files in it! :P <mark_weaver>grantix: I don't understand what you mean. it sounds like saying "I know you mean httpd, but it would be cool to have a dedicated daemon to serve guix's web pages" <jxself>Means we should make our own torrenting daemon from scratch because.... well.... because.... :) <mark_weaver>or "I know we have gcc, but it would be cool to have a dedicated compiler to build guix-daemon" <grantix>mark_weaver: I know you mean to it'd be a good idea to have a service for Transmissioin-daemon, but it'd be cool if we had a service or generally some easy to run file that plays off said service for transmission -- that makes it very trivial to seed to said torrents. <mark_weaver>Gabou: the sig files can be downloaded separately and are very small. <grantix>mark_weaver: The argument was that they are so small, and it's more convient for people to verify from there and not have to go to the the ftp server or whever it may be hosted, iirc. <Gabou>mark_weaver: okay then, I thought that was good too since you can check directly on the website *grantix was just casually browising the mailing list, but it was something along those lines. <a_e>They can be downloaded separately, but will people do? I think it is good to include them so that people become aware of the signatures. <a_e>So there is also a pedagogical impetus :-) <Gabou>btw, I have a question... I'm a parabola user and I was wondering how do you handle udev? Right now udev in Parabola is provided by systemd, do you have your own with dmd? <grantix>mark_weaver: Oh sorry, I just read over my first comment. Yeah, I didn't mean deamon on the secod bit, but a service for said daemon if I wasn't clear with the restatement above. <mark_weaver>a_e: well, I guess. it would be kind of unusual though. <mark_weaver>especially when a torrent is just one file, there's no need to make a directory. <a_e>Maybe. In the wild, it is rather unusual to sign things also... Most of the software I am packaging is unsigned. Gnu gives the good example. <Gabou>mark_weaver: thanks, that was my solution too <a_e>Yes, but there is no drawback to making a directory. Just mkdir... <grantix>I guess one could always offer a GuixSD-usb-install_all that ships both archs, and sigs neately in a dir structure. GuixSD is real small, in a *.xz. :^P <a_e>Actually I also made a torrent with the mktorrent script from debian, but apparently my tracker was not working. <a_e>Shipping both archs, however, is expensive for those who wish to install only one. I would rather separate them into two torrents. <mark_weaver>grantix: still, I don't think it's worth making a special service just to seed some particular set of torrents. <mark_weaver>a_e: oh, definitely! they should be separate torrents. <mark_weaver>I thought they already were. I vaguely remember seeing two torrent files posted. <a_e>They were, but grantix suggested to merge. <grantix>450mb isn't that costly, for both archs and the sig files for them -- really, when compared to other "distros". <mark_weaver>grantix: what would be the advantage to putting all arches into one torrent? <mark_weaver>for a lot of people, half a gig is costly to download. <grantix>mark_weaver: I mean, I'm going to be biased because they way I organize files and dirs ... probably tangiably to most nothing, but if shipping one arch and one dir is not jusifiable as I think you eluded to -- at leas this seems more significant in that such a thing I would think one would expect (as in shipping sigs). :^P <grantix>I mean, can't we just ship the sigs in a *.xz with the usb-install-image? <grantix>mark_weaver: Are the sigs tied to *.xz? <a_e>You can create a new tarball containing the image and its signature. A bit overkill, I would say, for just two files. <a_e>Much easier: Create a directory with the two files and turn it into a torrent. <a_e>A signature is always tied to a single file. Usually with the same name, but the ".sig" or ".asc" extension stripped. <a_e>Does this answer the question? <mark_weaver>yeah, the two reasonable options I see here are (1) each torrent contains only one compressed image, and (2) each torrent contains a directory with one compressed image and its sig. <a_e>mark_weaver: Agreed. <grantix>I just find it odd that the distro is shipping seperate from the config to start. Is there a cost not having the *.sig shipping in the *.xz? That's a way to ensure that everyone downloading GuixSD gets the signature and that signature really is low-cost. <grantix>Sorry, did not get a lot of sleep last night. <mark_weaver>based on the filenames, it looks like the .xz files are what has been signed, not the uncompressed images. <mark_weaver>grantix: an .xz contains only one file, unless it is .tar.xz, which this isn't. <mark_weaver>having separate .sig or .asc files is the standard method. it is what people are used to. <grantix>Oh, so it's just compression; Doesn't at like a dir? <jxself>Although a .tar.xz might only have one file too ;) <a_e>And then you can sign it. <a_e>And make a new tar with the file and the signature, <a_e>And then you can sign it. <a_e>And make a new tar with the file and the signature. <a_e>An original way of filling your disk! <taylanub>SBCL build is done but having LANG=POSIX LC_CTYPE=en_US.UTF-8 in my environment (which I normally do) causes SBCL to say "WARNING: Setting locale failed." at startup. <taylanub>ah, it looks in /run/current-system for locales. that means it'll work on GSD, just not with Guix on other distros, correct? <mark_weaver>or install the new 'glibc-locales' package and set LOCPATH as it suggests to use locales from guix <zacts>I just got a used calculus II book, and it had an old Univac Fortran punch card in it <zacts>it's probably been in there for years man <zacts>I got the calculus books to go along with the MIT OCW <jxself>Now you just need a UNIVAC to go with it. :) <ijp>calculus books make great tools for clubbing people to death <ijp>perfect examples of feature-creep <davexunit>taylanub: re: your sbcl patch: those inputs shouldn't be GC'd, because sbcl containers references to the relevant store items <taylanub>davexunit: I meant after the SBCL package itself has been GC'd <paroneayea>hey davexunit, btw do you know a way to associate the current scheme buffer with the geiser buffer that M-x guix-all-available-packages sets up? 
