<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? <Apteryx>Is it safe to assume that after a (substitute* call, the file will have been updated on disk? I'm executing a (system* call on the script on the next line. <Apteryx>(and it doesn't seem to have been updated) <Apteryx>moved it to a subsequent phase and it now works <bavier1>weird, I just did a 'guix gc' followed by 'guix package --delete-generations=...' and that last command prompted a download of a bunch of bootstrap packages and building of binutils <cehteh>i seen sometihng similar some time ago <mekeor>sometimes `guix package -r` builds some packages, too, i think <Apteryx>bavier1: maybe grafts on guix dependencies? <Apteryx>arg. Now "M-x guix build eudev" doesn't do the same thing as "C-c . b". Both REPLs have "~/src/guix" in their load-path. <sadiq[m]>Hi. I always get "ERROR: In procedure symlink: No space left on device" when trying to install any package <sadiq[m]>is there some configuration I should be looking for (I have around 7GiB free space in /) <mekeor>sadiq[m]: although i don't know why guix thinks 7GB is not enough space: maybe you could just work-around by deleting unused system generations and garbage collect? <sadiq[m]>how can I make guix gc not delete the bootstrap binaries? <bavier1>sadiq[m]: have you sent email to the list before? <bavier1>first-time emails go through a filter that might delay their arrival <elc79>the installation failed... again <elc79>failed at some point during this night with the package network-manager-1.8.2.drv <elc79>and that's it, a waste of time for nothing <elc79>the installation failed many times after i tried with the package, then i did guix pull to have the latest packages, this failed many times and when worked it toke one whole day... <elc79>and now after i had my computer doing this during this night... the installation failed <elc79>i0ll wait for an answer, but i don't know if GuixSD can work, for me GuixSD is a hell <janneke>elc79: can you share the exact command that failed, and error message? <elc79>janneke: do you have some idea? <janneke>elc79: possibly...i found that substitutes are available for modem-manager and network-manager <janneke>let's make sure that you are using substitutes <elc79>guix system init /mnt/etc/config.scm /mnt <elc79>janneke: during the installation i saw a lot of times updating substitutes <elc79>i don't know if there's an installation log <janneke>elc79: hmm, what if you try that with --no-grafts <janneke>do you get substitutes for network-modem/network-manager then? <elc79>janneke: how can i know this? <janneke> /gnu/store/ybgshikwfxrgamf54ag9nibx6bsyqn91-network-manager-1.8.2 <janneke> /gnu/store/y42y48namfh04m6szchrgbm8chpd49nx-modem-manager-1.4.14 <janneke>ACTION thinks that initial installation should always be possible with all binary substitutes, ie without building packages <elc79>there is 3 files in that folder named modem-manager, "guile-builder" "drv" and "lock" <elc79>and two more network-manager, "drv" and "guile-builder" <elc79>the version is the same than yours 1.4.14 for modem-manager 1.8.2 for network-manager <janneke>elc79: i don't know what this means, are you running: guix system init /mnt/etc/config.scm /mnt --no-grafts? <mray[m]>so guix updates itself, right? - what if there was a debian package of it - would that only have to be installed once? <mray[m]>for people like me "dipping in a toe" is tempting but hard - a debian package could possibly make sense in that case I guess. <janneke>mray[m]: guix can install newer versions of itself (like any package) alongside eachother <mray[m]>:D so why isn't there a debian package for it? <mray[m]>I mean it would have a certain in-your-face-factor without doubt. :D <mray[m]>oh! Why isn' t that linked on the homepage? <janneke>i stopped maintaining that because 1) I switched everything except for my phone to GuixSD <janneke>and 2) the binary installation is only 8 steps and give quite some insight <mray[m]>That is a pitty. I had real trouble and had a very good personal assistant with happy_gnu . <janneke>mray[m]: probably because it would need some love... <mray[m]>just leftclicking on a *.deb would have been awesome :) <mray[m]>i see. Thanks for ahving done it at all! <janneke>mray[m]: it was Diane Trout's effort, i only added some minor patches <mray[m]>Don't you think the main download page featuring a .deb file to jsut download would increase people getting familiar with guix instantly? Maybe I'm not that representative :P <mray[m]>Well thanks then to everybody who deserves it! <mray[m]>Why is this only a "recipe" for a deb, not a binary? You guix people seem to like recipes! <janneke>mray[m]: we like recipes without binaries *much* better than the other way around <janneke>we do like binary substitutes, though ;-) <mray[m]>janneke: substitutes are prebuilt sourcecode but checked if it matches the source really? <janneke>mray[m]: something like that, see node `Substitutes' in the Guix manual <elc79>the vm become frozen, stop working, and now i have do this again... <elc79>this is worst experience installing Linux ever <elc79>with less resources i was able to install every distro, including Gentoo, but GuixSD it's a nightmare <elc79>trouble after trouble and i'm losing the hope of seeing GuixSD working <elc79>i don't know is because my lock of patience, this is frutration after frustration, i don't see any light at the end. <sadiq[m]>elc79: some 4 days back, I had the same feeling. Once I got this up, I find this pretty good, and solid (except for the network usage) <elc79>if the installation can be resumed... but when fails you have to do all the work again <sadiq[m]>elc79: are you trying to install with gnome/xfce desktop? <sadiq[m]>elc79: hm.. I tried with gnome, and failed every time. Then i was told to install the bare-minimal version. And after the system is boot, add xfce/gnome, which worked <elc79>maybe i will do that when this shit fails again <sneek>Welcome back alezost, you have 3 messages. <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? <alezost>Apteryx: "C-c . b" and "M-x guix b" are not the same thing, so they may build different packages (and in a different manner) <Apteryx>alezost: I could reproduce the issue; I'll report it in the next minutes. <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>... but I would assume this to be a bug. <mray[m]>well seems like i can only start the guix one now... <mray[m]>removing the guix one. works fine now. <mray[m]>installing from ubuntu repos worked, installing through guix fails. Same with minecraft. <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. <civodul>mray[m]: Guix is a distribution of free software, so there are no proprietary libs <mray[m]>guix isn't a distribution - i'm running ubuntu ;) <mray[m]>civodul: i see - but i don't understand the problem on a technical level when it seems to be on a ideological. <elc79>this is the first error i got, and after doing "guix pull", a lot of attempts to install after this. ***Guest61586 is now known as Acou_Bass
<elc79>cbaines: this error was 4 days ago, but it's the same now <civodul>mray[m]: i'm don't know what problem you're referring to actually :-), but all i can say is that Guix as a project is committed to providing only software that respects the user's freedom <cbaines>elc79, so it looks like a bug in guix, and I think I've encountered this one as well <janneke>mray[m]: every guix package needs a full description of all its inputs, which means that no guix package will reference anything outside of /gnu/store <janneke>mray[m]: in that sense, guix is a standalone software distribution even when run on a foreign distro <mray[m]>janneke: so you are saying it is *impossible* to reach out to antyhing outside - independent of its free software status? <mray[m]>oh I see. so I would have to find a nvidia guix repo. <mray[m]>does anybody have knowledge of such unholy undertakings? <cbaines>elc79, one thing you could try would be to delete the derivation, and then try again. You can do this with guix gc, e.g. guix gc -d /gnu/store/kmw8w...-gtk-im-modules.drv <janneke>mray[m]: for reproducibility reasons you do not want to reference anything that's not a dependency <mray[m]>ACTION is wondering why guix can't then just link to other drivers and also provide them instead... <cbaines>mray[m], do you mean "link" in the linked library sense, or something else? <elc79>now it's compiling ghostcript <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 <dustyweb>what do people use for scanning stuff in Guix? <ng0>actually it's very easy to make use of non-free firmware, but it's just an annoyance to use <mray[m]>ng0: on a system that is currently running nvidia drivers it very much loooks like it (for a "good" reason) <dustyweb>though it doesn't look like the scanner shows up in the GIMP <dustyweb>does it need to be in my system profile? <ng0>even the linux project is moving the blobs out of the kernel for good in 4.4 <janneke>haven't used anything but my phone's camera for "scanning" since years... <ng0>that is still "a" system and not multiple. You can report a bug, but before it can be considered unusable there's more to test. Might be that it's just your unique combination. <ng0>dustyweb: simple-scan <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 <ng0>mray[m]: oh, you reported a bug. nvm then. <atw>Let's say I use a big package every day via an environment. If I invoke gc every night, then won't starting the environment every morning mean re-downloading the big package? <dustyweb>atw: you may want to use the --root flag to keep the environment around <dustyweb>there's been discussion also on the list about allowing environments to have generations etc like normal profiles <atw>oh, ok. --root would be nice as long as I left the profile running. That'd probably work for me ☺ <dustyweb>by doing source /path/to/your/root/etc/profile <atw>dustyweb: oh thanks, misread the manual. <atw>maybe your command should be in the manual? <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 <cbaines>elc79, did gtk-im build successfully? <elc79>i have two folders with this package, i think one is the original from the 0.13 tarball and the other from guix pull <cbaines>if it's the same problem I was having, it is the derivation (.drv) files that are broken <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 <cbaines>Not all things in the store are packages <cbaines>If the ...-gtk-im-modules.drv file is indeed a problem in the way I'm guessing, the same thing won't apply to the profile.drv and system.drv files <cbaines>elc79, I think you mentioned you ran guix pull? If so, when did you do this? <elc79>cbaines, i have three gtk-im-modules.drv files, five profile.drv, and three system.drv <elc79>cbaines, one user said to me to do this, and i succesfully did it ... after many attempts <elc79>but nothing has changed after this <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. <ng0>unpredictable impending doom and world collapse. you should use guix gc to delete files from the store. <elc79>cbaines, i did guix gc -d to the folder, but now i do guix gc -d to the drv <elc79>and here we go again, "guix system init /mnt/etc/config.scm /mnt --no-grafts" <elc79>i removed desktop services from config.scm <elc79>and again the same damn error... <elc79>i did guix gc -d to the gtk-im-modules.drv file and this file still there <elc79>believe or not but i have 20 years using Linux, and never faced something like this. <cbaines>elc79, have you checked if the .drv file contains the -L argument when in calls guile? <elc79>cbaines, i don't know, how can i check this? <cbaines>* cat /gnu/store/...gtk-im-modules.drv <cbaines>then take a look at the end where it calls guile (which will be /gnu/store/.../bin/guile ) <elc79>cbaines, at the begin or at the end? <cbaines>It should say something about --no-auto-compile <cbaines>but the important thing here is if there is a -L option by that <cbaines>you could also probably grep the whole file for -L if that is easier <elc79>cbaines, there's no -L option but --no-auto-compile is there <cbaines>Unfortunately, I think its something unreproducible to do with the way the guix package is built <cbaines>I've encountered this when using guix environment --ad-hoc guix, but not in the installation image <elc79>cbaines, so... it can't be solved? <cbaines>I would normally work around it by rebuilding guix, but I'm not sure how to do that in the installation image <elc79>cbaines, everyone here installed GuixSD trough 0.13 tarball? <cbaines>elc79, I don't know, I'm guessing you are using the USB installer image, is that right? <cbaines>Hmm, ok, that is possibly less popular than the x86_64 image, but I can't imagine it being broken <elc79>"/run/current-system/profile/bin/guix" <cbaines>Ok, actually, if my currenly unproven hypothesis is correct, then something may have gone wrong when guix pull was building guix, which means that it doesn't work <cbaines>One thing you could try to salvage this situation is run guix pull again, and hope that you don't run in to the same problem <elc79>no, i needed one whole day after many failed attempts to do this operation <cbaines>what failed about running guix pull? <elc79>it failed during guix-latest compilation <cbaines>can you remember anything about the compilation failure? <cbaines>Ah, currently there is an issue with Guile that means that compiling guix needs ~2G of memory <elc79>i run many distros with the half of this and always works, and some swap of course <cbaines>in the short term, could you create a swapfile? <Apteryx>Is there a way to cause guile to emit logs about what it's compiling/doing? <Apteryx>Everytime I start Emacs and do M-x guix RET e using a dirty source file in my ~/src/guix, it runs for ages. <Apteryx>oh, look likes I should attach strace with the -p PID option. <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. <Apteryx>When all I changed is a single file. <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. <elc79>well, i will try with x86_64 image <janneke>cbaines: is there anything that elc79 could salvage from their broken install to get a finger behind this mess? <cbaines>Maybe, I don't know what would be useful, or an easy way to get at the data <cbaines>When I've encountered this, I've deleted the relevant guix package from the store, and rebuilt it, and that has worked around the issue <cbaines>If I encounter it again, I'm hoping to take a copy of the package before deleting it, so that it's possible to compare the two <elc79>janneke cbaines, i want GuixSD with xfce, i can remove gnome line in config.scm? <cbaines>I'd also recommend trying to install a very minimal system first of all, and then working up from there <janneke>elc79: i would suggest to not use any desktop at all in the initial install <janneke>elc79: esp. with what you've been through <elc79>ok, i put ;; in these lines? <janneke>yes, make sure to keep parentheses () balanced <elc79>i modified my settings, hostname, timezone, locale, grub, user, and then i set desktop services not be used <elc79>gnome, xfce and desktop-services these three lines i put ;; at the begin of the line <elc79>and then can i run guix system init? <elc79>wow, now it's going to compile ghostscript, it could be better if i have binaries <Apteryx>Interesting. Evaluating modified Guile modules inside Emacs when used with M-x guix is an order slower than when using guix from the terminal. Is strace the best tool to help me profile why? <elc79>the installation is completed! <cbaines>I'd recommend thinking a bit about how you want to manage the configuration, e.g. if you have a config.scm for the system, where to keep it ***Acou_Bass is now known as eddie
<cbaines>also, I'd recommend trying reconfiguring, especially as I think you installed a more minimal system than you wanted ***eddie is now known as Guest7781
<elc79>yes, i have a very basic system <elc79>if i want to install xfce, what i have to do? <dustyweb>elc79: if you want to use xfce, the easiest way for that one is to put it in your system profile, because then you can select it from the login manager <elc79>ok, and then i have to do guix system reconfigure? <dustyweb>elc79: you can then switch between desktop choices with f1 <elc79>i think a guix pull is required before reconfigure <cbaines>elc79, well, definately not required by guix <elc79>my fault, i had to get up the network ***Guest7781 is now known as Acou_Bass
<dustyweb>I did a reconfigure today and xorg doesn't come up <dustyweb>I'm guessing my x200 isn't cool enough for gdm ;) <civodul>dustyweb: gdm isn't used yet, but kms is <civodul>i've had random crashes while my laptop was idle today, with Xorg restarting <dustyweb>civodul: regardless, my old generation booted fine! <dustyweb>commit c68c201fdd429140da1c606861c9296b9cb01265 was also a graphics-affecting commit <dustyweb>well, gotta get stuff done, but I guess I can rebase and test later <dustyweb>thank goodness I can always select old guix generations! :) <jonsger>dustyweb: I had this week also issues with gdm and xorg who doesn't came up. It was on a opensuse tumbleweed system not guixsd... <civodul>see? other distros have bugs too! :-) <dustyweb>oh yeah, I mean, I've been in the same situation I am now before: about to go on a two week trip and you upgrade and everything breaks <dustyweb>I couldn't just select the previous revision on boot and carry on :) 
