<amz3>I have the following error: <sneek>amz3, davexunit says: pushed 2 commits to fix the null texture issue. <amz3>$ ./pre-inst-env guix package -i st <amz3>guix package: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory <amz3>ok I get it I need to fix the socket filepath <amz3>I forgot to set the correct state directory <mark_weaver>"Package management with cabal is the single worst aspect of using Haskell. [...] Comments connected cabal with words like hell, pain, awful, sucks, frustrating, and hideous." <mark_weaver>'Asked if improvements to package management would make a difference to their future choice of Haskell for a project, 38% said it would be "crucial" and a further 29% said it would be "important".' <ewemoa>is there some guix-related wiki where one can record tips and notes? <mark_weaver>ewemoa: there's a mostly empty section of the manual reserved for that kind of thing. <mark_weaver>or at least I have a recollection of such a thing. trying to find it now. ***nukke is now known as nukke_
***nukke_ is now known as nukke
<Lorenz>I have some inspiration I would like to share. do you want to listen? <Lorenz>I have stumbeled upon a book by ted nelson of xanadu and i have some ides that may be usfull <Lorenz>sorry for such english, it is not my naitive toung <Lorenz>hello? Would anybody care for my attention, yes i am little bit pushy. (mumble, muble) large body text ... <Lorenz>so here i am alone in this chat room all by my (aperently) alone, what shocker .. <Lorenz>i am in no way influenced by red wine and consquently typing, just tierd and have lousy grammer. <Lorenz>so maybe someone her could pick these ideas, I doubt it. <Lorenz>first, remove cut and paste by palo alto researtch <Lorenz>use: move text, insert text, hide text, unhide text, duplicate text <Lorenz>and also the fake keyboard dos clones of douglas englbart suck horse shit <Lorenz>at least whomever came up with spacecadet keybaord gave some clear use and honesty over where there influence came from. <Lorenz>it is still a clone over palo alto research <Lorenz>we need a large body operating system that handel fucking large body of text by the end-user. algabraic databases will not cut it! <mark_weaver>Lorenz: this channel is for discussing the Guix package manager and GuixSD distribution. it is not the right forum for those ideas. <Lorenz>thank you, for arresting me. i'll leave <mark_weaver>ewemoa: nicely done, and it's great that you made it into a tutorial <mark_weaver>if you copy .dir-locals.el from the git checkout to your ~/.guix-packages/ directory, then emacs will do a better job auto-indenting the code. <mark_weaver>when developing a package, it's good to use "guix build -K <package-name>". the -K asks the daemon to leave the build directory in /tmp in case of failure. <mark_weaver>without -K, the build directory is automatically removed <mark_weaver>in your install phase, you should be #t after the (for-each ...), to signal success. phase procedures are expected to return a boolean indicating success or failure. <ewemoa>mark_weaver: thanks for the comments -- i will try the .dir-locals.el idea and thanks for spotting the duplicated git clone -- have been using -K fruitfully when testing, will add it to the write-up <mark_weaver>also, it's good that you added a 'file-name' field for the git checkout. we should probably add something like that to all of our 'git-fetch' origins. <mark_weaver>it's good to see that kind of attention to detail :) <ewemoa>mark_weaver: ah, good to have confirmation of that -- wasn't sure :) <mark_weaver>ewemoa: I would also recommend you consider building guix from the git checkout and getting in the habit of making changes directly to the git checkout. this takes a modest initial investment in time but is well worth it, IMO, for several reaasons. <mark_weaver>it means you can contribute your packages to us properly <mark_weaver>it means you can modify your local copy of guix in arbitrary ways, not just by adding packages, and git helps make it easy to merge our continued upstream work into your local branch. <mark_weaver>or alternatively, periodically rebasing your local commits on top of our upstream. that's what I do, but it's a matter of preference. <ewemoa>mark_weaver: yes, it sounds like a good idea to work off of a checkout -- i used to do that but when i tried before, i ran into difficulties which i didn't resolve -- perhaps it's worth trying again <mark_weaver>I'd be glad to help you work through any problems you might have. <ewemoa>thanks -- then i may move in that direction :) <mark_weaver>after you already have guix it's easy because you can use 'guix environment guix' to launch a subshell with everything you need to build guix. <mark_weaver>just make sure to pass --localstatedir=/var --with-libgcrypt-prefix=$HOME/.guix-profile <ewemoa>mark_weaver: thanks for the tips -- hope to transition soon -- but it looks like i might want to package stgit first :) <amz3>I have added two packages (st and dwm-azerty ie. dwm with a patch for azerty kbd), I should send two patches? <amz3>both are in the same file dwm.scm (which should be renamed to suckless.scm IMO) *amz3 will restart his IRC client <ewemoa>mark_weaver: i am using an installation of guixsd 0.8.2 and have cloned the git repos for guix -- is the HACKING file a good place to start reading? <ngz>Hello. When using guix on top of a host distribution, how do you get "guix.el"? <alezost>ngz: it is described in the manual: (require 'guix-init) should be enough if you installed guix in your distro <ngz>The library cannot be found. <alezost>ngz: what distro is it and how did you install guix? <ngz>Archlinux. I downloaded Guix tarball and installed it manually, following instructions on the manual. <alezost>or do you mean "binary installation"? <ngz>There is no make install there. <alezost>ngz: so guix is somewhere in the store I suppose. What "which guix" tells you? <alezost>ngz: is it a link? (sorry for all these questions, I didn't try binary installation, but I know how to configure "guix.el") <ngz>Yes, it is. It points to /root/.guix-profile/bin/guix <mark_weaver>ngz: our binary tarballs don't put anything into /usr/* <mark_weaver>so I'm not sure how you ended up with /usr/local/bin/guix <mark_weaver>oh, sorry, the manual recommends putting a link there. never mind me :) <mark_weaver>ngz: I think the thing to do is to run 'guix pull' and 'guix package -i guix' from your normal user account, and then guix.el will be in ~/.guix-profile/share/emacs/site-lisp/ <alezost>ngz: the point is you need to find where ".../usr/share/emacs/site-lisp/guix.el" is placed and (add-to-list 'load-path "<that-dir>") before (require 'guix-init) <ngz>mark_weaver: OK. Trying. <mark_weaver>ngz, alezost: the binary tarball includes /gnu/store/sfw64fin80dhmn160cq71f46v7hfgbfm-guix-0.8.2/share/emacs/site-lisp/guix.el but I don't recommending adding that store directory to your emacs load-path directly. <ngz>alezost: the problem is that a "locate" on "guix.el" only returns something in the store, <alezost>ngz: yes, then what mark_weaver says is the way <crtsyal>I ran dhclient enp* like it says for installation but I don't think it is working <alezost>crtsyal: did you ran "enp*" or the real thing (like enp0s7)? <alezost>crtsyal: hm, perhaps your network interface is down; could you look at "ifconfig" output <mark_weaver>crtsyal: you could try adding the -v option to dhclient, with enables verbosity. <ngz>mark_weaver: still no luck. <ngz>mark_weaver: I used guix package -i guix. guix is installed. But a new Emacs still cannot find guix.el (when using (require 'guix-init)) <alezost>ngz: did you add the dir to load-path? <crtsyal>it is sending dhcpdiscover to 255.255.255.255 <mark_weaver>ngz: did you add ~/.guix-profile/share/emacs/site-lisp to your load-path? <mark_weaver>apparently that is sometimes needed before running dhclient, although not for me. <ngz>alezost: Oups no I didn't. I was lured by find ~/ -name "guix.el" not returning anything. <ngz>alezost, mark_weaver: I see the library there, so it should be fine now. Thank you. <ngz>May I suggest to add this to the manual? <alezost>ngz: thank you for reporting, yes we should make the manual more clear <alezost>mark_weaver: I'll make a patch for that later today <ngz>On another topic, while I'm at it, I have a PATH problem. I have modified .bashrc to export various guix related environment variables. However, gnome (from Archlinux) apparently cannot find executables (e.g., Emacs) installed with guix. <crtsyal>mark_weaver yeah that fixed it. I feel a bit foolish now. <alezost>ngz: I think that's because gnome is running by a systemd service which knows nothing about your .bashrc environment <ngz>I think so. But I don't know what files it knows about. <ngz>So if I create a shortcut (e.g. Super+E) for Emacs, it launches host distrib Emacs, not the one from guix. <alezost>ngz: I know that "systemctl set-environment" may be used to change the systemd env on the fly (also you may use "systemctl show-environment" to find your current env), but I don't know how to make systemd to set environment before it starts services. I think there should be some config file for that. <alezost>ngz: or maybe there is some "Gnome-special" way to change the env <ngz>OK. I'll look into that direction. Thanks. <alezost>mark_weaver: do you know the answer? <mark_weaver>we should remind people not to set their environment variables in .bashrc, because that makes 'guix environment' not work properly. <mark_weaver>environment variables should be set in .bash_profile <ngz>alezost: For the record, putting everything in ~/.profile did the trick. <mark_weaver>alezost: I guess it is because gnome-session is launched from their display manager in such a way that .bashrc is not loaded in a parent process of gnome-session. <alezost>mark_weaver: yeah, apparently ~/.profile is loaded <ngz>.bash_profile and .bashrc were not. <mark_weaver>ngz: you should avoid setting environment variables in .bashrc for other reasons. it causes them to be reset in *every* interactive shell, which prevents you from having shells where the environment variables are set in a different way. <mark_weaver>in particular, the 'guix environment' command spawns a subshell with different environment variable settings. that command won't work properly if you reset your environment variables in .bashrc <ngz>mark_weaver: I know. But it's the Archlinux way to proceed. .bash_profile consists of a single line: [[ -f ~/.bashrc ]] && . ~/.bashrc <mark_weaver>ngz: well, that way is incompatible with the 'guix environment' command. <ngz>So they just blur the differences between the two commands. <mark_weaver>oh sorry, there's nothing wrong with loading .bashrc from .bash_profile. that's good. <mark_weaver>but the environment variables should be set in .bash_profile, before loading .bashrc <ngz>You mean GUIX_PROFILE, GUIX_PACKAGE_PATH and LOCPATH? Or every other environment variable (e.g. EDITOR, PATH...)? <mark_weaver>ngz: ideally, all environment variables should be set in .bash_profile, not .bashrc <mark_weaver>you should be able to spawn an interactive subshell with different environment variable settings. <ngz>OK. I can try it. And where do I source "$HOME/.guix_profile/etc/profile"? <ngz>I assume in .bash_profile since it modifies PATH. <iyzsong>ngz: Yes, I think both ~/.bash_profile or ~/.profile should work <ngz>OK. Let's see what horrible things are going to happen. <ngz>Apparently I'm still alive... So it looks fine. <civodul>could it be a problem on the build machine or a network issue? <mark_weaver>civodul: looks complete to me. ends with "guix build: error: build failed: build of `/gnu/store/xj90h00rq5d25rvqgz9x0x300n0mc1kp-glibc-intermediate-2.21.drv' failed" <mark_weaver>checking for suffix of object files... configure: error: in `/tmp/nix-build-glibc-intermediate-2.21.drv-0/build': <mark_weaver>configure: error: cannot compute suffix of object files: cannot compile <civodul>mark_weaver: w3m had somehow stopped before the end, i can see it now <civodul>if you can get that config.log, i'd be interested in seeing it :-) <mark_weaver>civodul: unfortunately, I have to build some other things first. it's not clear to me how to get the substitutes from hydra to this build-slave. <mark_weaver>looks like I'm going to have to build gcc-4.9 first, which will take a long while. <mark_weaver>I guess it was the other mips slave that tried to build this, and I just ran 'guix gc' on it. <mark_weaver>hmm, I suppose the hack would be to rebuild it from hydra, and then use whichever build slave tried to build it. <mark_weaver>but then it takes a long while to compile 'guix' from the git checkout, which I already did on librenote. <mark_weaver>civodul: what's the easiest way for me to get the build prerequisites for glibc-intermediate from hydra to librenote? <davexunit>I'd like to setup a single computer on my network to act as a proxy store for all of my other machines. <davexunit>is this possible with some combination of build offloading and 'guix publish'? <civodul>mark_weaver: with substitutes enabled, try: guix build -e '(@@ (gnu packages commencement) glibc-final)' <civodul>but they should already be on librenote no? <civodul>or maybe they're on the other mips machine? <mark_weaver>civodul: as I recall, you once specifically told me that substitutes must be disabled on hydra build slaves. <davexunit>ah, 'guix environment' is lovely. I was in my guix dev environment, but I wanted to experiment with libnl bindings for containers, so I just ran 'guix environment --ad-hoc libnl' to add it to the environment. <mark_weaver>I guess they _were_ on the other mips build slave, but I just ran "guix gc" without arguments on it. <civodul>mark_weaver: that's correct, they must be disabled, but you can "cheat" just while you get things into place <civodul>comment out librenote from machines.scm before you do <civodul>davexunit: thinking about the GHC issue that bavier reported, i wonder if 'guix environment' should build a profile instead of doing things "manually" <civodul>all the hooks would be run, so there would be that package.cache thing for GHC <davexunit>civodul: the problem with profiles is that they must be GC'd <davexunit>I should mention that Haskell folks use nix-shell just fine <civodul>by profile, i mean the thing built by profile-derivation, not an actual GC root in /var/guix/profiles/ <civodul>so it's just as ephemeral as any other derivation <davexunit>and nix-shell is implemented as a hack in nix-build (or whatever the name is) <civodul>if nix-shell manages, we must do it as well ;-) <davexunit>though it becomes distinctly different from how the daemon builds its environment. <civodul>so back to the GHC issue, how does that work in the build environment, then? <davexunit>anyway, I dunno what's going on with Haskell, as I am not a Haskell programmer, but I know the Nix folks have it working. <davexunit>so I guess my recommendation is that those interested in Haskell on Guix should do some research into how it is working on Nix <davexunit>and then discuss changing the behavior of 'guix environment'. <davexunit>civodul: looking forward a bit, I'm attempting to use libnl for the networking component of the Guix container implementation. I know that adding more dependencies isn't the best thing, so should we make it optional somehow? <mark_weaver>davexunit: if you use the dynamic FFI to get to it, then it can be optional in the same way that gnutls is optional now. <civodul>but maybe there'd be modules that must not be built/installed when libnl is not available <davexunit>not sure how to effectively turn off the container features <davexunit>civodul: more immediately important: I'm trying to decide if I should not use 'operating-system-derivation' for containers. <davexunit>on one hand, a container doesn't need a kernel or initrd <mark_weaver>civodul: the error from config.log is this: /tmp/nix-build-glibc-intermediate-2.21.drv-0/cca0suib.s:4: Error: unknown pseudo-op: `.nan' <mark_weaver>this must have to do with the new support for another representation of NaNs in gcc-4.9 <davexunit>on the other hand, if a user ran 'guix system build', the derivation they'd get is not the one that would be used when the container was launched. <mark_weaver>MIPS traditionally interprets the signaling-NaN-bit in the opposite way that it is interpreted on other platforms. <mark_weaver>there is now support for making it use the same representation as on other platforms. <mark_weaver>I guess that maybe the bootstrap binutils can't cope. <davexunit>the boot script for a container is also different than a full system, so I guess 'guix system build' as-is cannot build the right derivation without more context. *mark_weaver wonders if anyone is actually using our MIPS port anymore. <civodul>no idea, but we definitely don't get lots of feedback on that... <civodul>well, should we update the bootstrap binutils? <mark_weaver>civodul: dunno, updating the bootstrap tarballs makes me nervous, from a security perspective. <mark_weaver>we have greater exposure now than we did then, more likely that newly built ones might get compromised. <civodul>mark_weaver: well, if they are compromised, it means that our recipes are already compromised <civodul>because they're built using recipes we already have <mark_weaver>civodul: I'm not worried about compromised recipes, but rather that the new bootstrap binaries won't correspond to the source code. <mark_weaver>right now, using substitutes means trusting hydra and all the build slaves. <mark_weaver>but if you build everything locally, then only the bootstrap tarballs need to be trusted. <mark_weaver>well, at least those are the only _binaries_ that need to be trusted. <civodul>i think the likelihood of a targeted Hydra compromise is still low, because it wouldn't really pay off <mark_weaver>if I update the mips bootstrap tarballs, it will be with my Yeeloong that I've been carrying around everywhere, and which has not ever used any substitutes. <mark_weaver>(the same machine that built the current mips bootstrap tarballs) <mark_weaver>but I wonder if there's a not-too-gross workaround available for this problem. <civodul>this reminds me of Debian's "dirty secret" as Nussbaum called it in his FOSDEM talk <civodul>even for bootstrap binaries the situation is better <mark_weaver>reproducible builds is the only truly satisfactory solution to this problem, but that assumes that the bootstrap tarballs are uncompromised. <mark_weaver>I derive some comfort from the fact that we were quite an obscure project when our bootstrap tarballs were generated. <mark_weaver>and although we have few users, the fact that we are well positioned to resist compromise in the long term might make us more of a target. <civodul>i would like to be able to say that, but i don't think this is the case <civodul>what about building those on librenote or the other one? <civodul>presumably it's already built there, even <civodul>such as adding another binutils layer in commencement.scm <civodul>hmm actually glibc-final is already built using binutils-boot0, which is "ours" <civodul>so maybe we misunderstood the problem? <mark_weaver>maybe there's a reasonable way to get the intermediate gcc to stop generating those .nan directives. <civodul>because it's definitely built using the latest Binutils <civodul>so the problem might be either that GCC 4.9 expects an unreleased Binutils <civodul>or that we need to pass an option somewhere to tell GCC to DTRT *davexunit 'guix system container' successfully launches dmd ;) <davexunit>now to work out issues with some base services <davexunit>hmm, why are there 6 dmd processes in the container... ***fchmmr is now known as randomperson
***randomperson is now known as randombeing
<mark_weaver>davexunit: if you have services that call primitive-fork and don't immediately exec in the child, that would explain it. ***randombeing is now known as fchmmr
<davexunit>mark_weaver: okay, I think the failing console-font-ttyN services are the culprit <davexunit>to probe further I need to write a quick tool to spawn a process inside the container from the outside.