<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.
<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?
<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'
<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?
<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>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.
<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".
<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>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.
<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>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
<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.
<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.
<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
<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"
<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: 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 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.