<Apteryx>Is building documentation locally useful or should I use pre-built man pages?
<Apteryx>sneek: later tell alezost: I'm getting often the error "Wrong type argument: arrayp, nil" when issuing M-x guix in a fresh Emacs. The workaround is to cd into ~/src/guix, ./pre-inst-env guix environment guix && make (compile the files). Any idea what's going on? Maybe the load-compiled-path should be adjusted as well as the load-path?
<sneek>alezost, Apteryx says: I got my emacs-guix flow working much better now, thanks! Is there a way to keep a failed build artifact after running 'C-c . b'?
<sneek>alezost, Apteryx says: seems one way is to recall the last call at the REPL and add the argument needed, like so: (guix-command "build" "-K" "eudev").
<sneek>alezost, Apteryx says: I'm getting often the error "Wrong type argument: arrayp, nil" when issuing M-x guix in a fresh Emacs. The workaround is to cd into ~/src/guix, ./pre-inst-env guix environment guix && make (compile the files). Any idea what's going on? Maybe the load-compiled-path should be adjusted as well as the load-path?
<mray[m]>so what about guix installing packages that only work with non-proprietary graphic drivers? Is there a main setting i need to adjust to make them work?
<Apteryx>mray[m]: Could you please rephrase your question? It's not clear to me what you are asking.
<mray[m]>Apteryx: sure. i'm very new to guix and not thattechnically skilled in particular. So i tried installing different packages that require 3D acceleration. Upon installing "teeworlds" i noticed that it does not run and filed a bug. The answer was that it probably is due to guix expecting the free nouveau driver (but i use nvidias driver)
<mray[m]>now I also could not get minecraft to run.
<mray[m]>I'm trying to find out if this is due to a guix setting of some way - or if both cases depend on developers assuming more devoted GNU lovers.
<Apteryx>OK, I understand better now. This is an interesting problem; I'm not sure why the guix binaries wouldn't work with the proprietary OpenGL implementations; my intuition would have been that the given OpenGL implementation is an abstracted detail, and that as long as it provides the required features it should work.
<Apteryx>But I'm no expert on the matter. Hopefully someone else around here can answer your question.
<Apteryx>mray[m]: Does teewords work if you install it on the host system (the foreign distro, since obviously you are not on GuixSD)?
<mray[m]>Apteryx: i *strongly* think so but can check.
<Apteryx>(i.e. through the native package manager of that foreign distro?)
<adfeno>mray[m]: I don't know the issue in detail, because I didn't investigate...
<adfeno>I *guess* this is a bug because: I base my guess in the similar issues in kernls that passed through the GNU Linux-libre scripts (which unfortunatelly, due to a known and hard/diffcult-to-fix bug, denies loading non-free firmware even if the user hmself asks to --- after the kernel was successfully installed).
<ng0>what does the firmware have to do with guix on Ubuntu?
<adfeno>ng0: Nothing? I just tried to make an analogy. Although I do recognize that making such things always fails, so this is why I said it's a *guess*. ;)
<ng0>sorry, read it again, you are right. I'm not really present (sick)
<adfeno>I wonder if forcing the computer on building the OpenGL parts works...
<adfeno>... probably not, because the build is in a chroot, so it doesn't know about the user's real environment and capabilities.
<adfeno>mray[m]: I wonder if switching to nouveau helps...
<adfeno>I'm a nouveau user... Got a GPU specially selected for using it. :)
<elc79>i tried to install without desktop option... and the installation failed again...
<cbaines>elc79, oh dear, is it clear what failed in particular?
<elc79>at least i tried 11 times to install this, and always fails
***Acou_Bass is now known as eddie
<cbaines>assuming it failed the same way each time, it sounds like the issue is reproducible anyway
***eddie is now known as Guest61586
<mray[m]>Just got a response to my bug report. The way I understand it guix does not link to proprietary libraries because they are not in the repo. Not sure I understand why it can't still link to them anyway.
<mray[m]>janneke: i don't *want* to use those drivers in the first place. it's just without them soem stuff is unusable.
<mray[m]>cbaines: i guess I'm asking for the impossible, but the idea is that guix provides "everything" - then it should work no matter what - and not miss anything. yet I'm missing a thing that prevents me from running a package.
<cbaines>mray[m], the "everything in the store" is ideal in some ways, but it's always possible to reach outside it. For linked libraries, you might be able to use the LD_LIBRARY_PATH to reach outside the store for example.
<mray[m]>i guess any os can only run one driver at a time, so that's not going to work because of that.
<ng0>I'd like to test that claim with more than one system to consider if those packages are really unusable
<atw>how have people's interactions with "guix gc" been? I should mention that I don't use guix full-time yet. Anyway, I think that I might do a lot of "guix environment [--ad-hoc] ..." to temporarily use packages without installing them into any system profile. IIUC, this would mean that my store could get pretty big. Once it does, I would just invoke gc. But, this could mean re-downloading stuff the next time I do "guix
<atw>environment". Right? So, here's the crazy idea (that might be based in poor assumptions): have gc be invoked automatically, deleting the least recently used stuff, only when space in the store runs low. Does this already happen? Has this been proposed before?
<dustyweb>atw: the manual shows an example of running guix gc at night on a cronjob
<atw>--root is what I was looking for, but I'm still thinking that having to run gc yourself/via cron could be better. My thinking is that we only need to run gc when we're too low on space in the store to add the next thing. So would it be possible/desirable to have the build daemon (if that's the right part) detect when there is too little free space in the store to add the new store item, and then initiate a gc?
<atw>Ideally, this would free the user from having to automatically or manually run gc
<elc79>cbaines, i'm deleting also the other packages showed in that error, i tried to install after deleting im-modules but after this the installation ended with the same error
<adfeno>mray[m]: That thing about LD_LIBRARY_PATH, but I think you'll have to base your own packages on the current ones, thus building stuff again.
<cbaines>elc79, so, did the builder for the gtk-im-modules derivation fail again?
<adfeno>... besides, I'm not a developer, so I don't know how to do so. Neither I want to, because: I'm in favor of free/libre software, so I suggest you to use nouveau with your GPU, or look for (or hire?) a computer technician to replace the unfriendly GPU with a better one, like *some* from Intel (not every one of these are good).
<elc79>gbaines, yes, it failed again, i'm removing the other packages showed in the error, profile.drv and system.drv
<elc79>gbaines, i can't remove one of the profile.drv packages.... guix gc says it is still alive
<elc79>cbaines, what happens if i remove manually this files?
<cbaines>elc79, could you check if this is the problem I think it is. The details are in the bug report I posted, but what you need to do is check if the -L option is passed to guile in the derivation.
<cbaines>also, if you try running a guix command in a shell, you should see the files that are causing the slow start
<Apteryx>cbaines: yes, nothing is shown in strace. I only change a single file, so that's what I would see anyway. If I use guix in my dirty tree using ./pre-inst-env guix edit python-pip it flies. But if I open Emacs, then try M-x guix RET e it stops there and times out. I see guile is using 100% of a CPU in top.
<civodul>Apteryx: if you run M-x guix off a checkout, you'd better run "make" before
<Apteryx>yes, if I run make it solves the issue. But why?
<civodul>if you don't run "make", Guile auto-compiles things in the background, which takes a while
<Apteryx>I can understand the M-x guix underlying guile process taking as long as when I do "./pre-inst-env guix edit ..." in my checkout when I have dirty files, but I don't understand why it takes much much longer.
<civodul>the end result should be the same, but it's annoying
<Apteryx>I feel it's recompiling the complete tree.
<civodul>it should be recompiling just that single file, then
<cbaines>Note that I think it uses timestamps, rather than contents, so if you checkout a different branch with changes to several files, then go back to the previous branch, all those files will need recompiling.
<Apteryx>cbaines: right. I'm testing on the same branch, with a trivial change (changed 1 digit of a hash in python.scm). I'll try to measure the time difference between terminal vs emacs-guix but it appears to be massive.