<fps>hi, running nixos here, watched the guix talk yesterday. interesting approach. <fps>i woder if al you lispers couldn't try to transform nix derivations to your own package format ;) <fps>"solving" the lack of packages problem.. <civodul>derivations are the low-level format, akin to assembly, so that's not what we would transform <civodul>the number of packages is getting better, too ;-) <civodul>ACTION found a bug in device-mapping handling thanks to "guix system dmd-graph" <jeaye>I've been giving nixos a run and, through my frustration, ran into guixsd. I'm wondering if it may resolve some issues that're present in nixos. <civodul>maybe, but be aware that GuixSD is much younger and not as mature as NixOS <civodul>that being said, what were your problems? :-) <jeaye>Right, consider the warning noted. <jeaye>I love the idea of a declarative approach to defining deterministic setups; I'd like to run with that. However, I spend most days compiling native software, for various projects, and I'm not interested in writing nix expressions for all of them. <jeaye>Does GuixSD provide a sane way for managing my system but also providing me a sane environment, based on what's installed, for compiling arbitrary projects? <civodul>yes, but i'm not sure i fully understand the problem <civodul>i mean, you can always install the development tools you need in your profile <civodul>and then build your projects "the normal way" <civodul>nothing really specific to GuixSD or NixOS here <civodul>then it also provides development tools like 'guix environment' that should help <jeaye>civodul: For example, I want to build https://github.com/jeaye/color_coded on NixOS so I can use it with vim. However, I can't just use NeoBundle (I know you're an Emacs guy, heh) to build it with cmake like I would on a conventional system. <jeaye>So, in this case, I setup a nix expression, went through the motions, installed, only to find that ldd doesn't find all bits for the compiled shared object unless I'm in a nix-shell for the project. But I use vim everywhere and I want that always available. <jeaye>It seems like I'm fighting the system here. <civodul>i think Guix doesn't have NeoBundle either, but there's no reasons it couldn't provide it <civodul>Emacs also has its own package/plug-in system <civodul>one can use it on GuixSD, or one can choose to use Guix instead of Emacs's own thing <civodul>as a user, i find it more convenient to handle all my packages with Guix <civodul>rather than have some handled by Guix, others by Emacs's package.el, and so on <jeaye>Right. My issue is that, while nixos/guixsd work hard to control profiles and different environment for different programs, I'd like to be able to specify a _default_ environment, perhaps. This would allow me to have access to a specific version of boost, for example, or clojure, or gcc, and have them all there so I can conventionally build software. <jeaye>I think this is what nix-shell is trying to do, but the separation of some programs (like vim) from that environment makes it tough to, in my case, compile arbitrary native plugins for vim. <civodul>you don't *have* to use nix-shell or 'guix environment' <civodul>you can always install things in your profile, with "guix package -i foo", etc. <civodul>that effectively defines your "default environment" <civodul>for instance i have 'gcc-toolchain' and a bunch of libraries in my profile <fps>civodul: oh ok, excuse my bad terminology then <jeaye>civodul: GuixSD uses scheme to define the system similar to how NixOS uses Nix, right? <fps>will play with guix in a vm then <civodul>actually GuixSD uses Scheme where NixOS uses Nix-language + Perl + Python + Bash + ... <jeaye>The "default environment" would be a subset of that which is declaratively prescribed. Having to manage it imperatively isn't ideal. <civodul>you can also declare the system's global environment, both in NixOS and GuixSD <jeaye>From what I've seen of NixOS, that isn't the case. For example, I may have Lua installed, but if I try to build a project which wants to link against it, it won't be found. <jeaye>It's there, but it's not exposed, for the sake of purity. <civodul>maybe what you observed was due to missing env vars or something? <civodul>Guix handles them mostly automatically <civodul>i guess as a first step you could try Guix on top of your current distro, to get a feel and see how well it works for you <jeaye>My current distro is NixOS, so I'd likely just jump into GuixSD. <jeaye>civodul: To be clear, GuixSD is like NixOS but 1) uses Scheme; 2) focuses more on free software <jeaye>(other than it being less mature) <fps>btw: just as a side note: i stumbled over guix in the nixos channel, where some people "complained" about the page not featuring its nixos heritage more prominently.. might be good politics to maybe do so? <civodul>many things here and there work differently, like 'guix package --search-paths' <civodul>fps: i've heard that a few times, but having been one of the main NixOS developers, i find it unfair <jeaye>civodul: Ah, the lack of systemd will be appreciated. I come from Slackware, primarily, where people feel similarly. <civodul>also note that the soon-to-be-released 0.9.0 will fix a number of shortcomings regarding how one specifies OS services <fps>civodul: yeah, it might be somewhat unfair, but would it hurt? not trying to push an agenda here, just wondering :) <fps>you know, love, peace and unity! let's solve world hunger next.. <fps>ok, back to work.. lalalaaa <wingo>if you use nixos as a desktop jeaye it's possible guixsd isn't ready for you, depending on what you want from a desktop <wingo>i have one machine that is nixos, with guix in userspace, and another that's guixsd <wingo>the guixsd one is a bit frustrating -- no gnome-shell, no networkmanager (but wicd), etc <jeaye>Yeah, I'm looking for a desktop. Minimally, I use X and i3wm. 99% of my time is working in vim with various C++ projects, so I rely on easily being able to build them. <wingo>in that case guixsd might work well for you <wingo>it's just us stick-in-the-mud gnome people that gripe a lot :) <wingo>i have had ok luck developing chrome and v8 from within my nixos+guix box <jeaye>The other 1% would be using non-free software like steam. My guess is this is where GuixSD will become a hassle. <wingo>but i realized a lot of that is because nix helpfully has a /usr/bin/env and many scripts use that shebang :) <wingo>guixsd has no /usr at all though i guess you can make your own /usr/bin/env <wingo>it's strange because i use nixos's /usr/bin/env to let things build under guix <jeaye>civodul: So, since you'd be the one to know, what I want should work, right? Allow Guix to handle my system, using Scheme, but also have libs like lua, boost, and sdl available and software like cmake, gcc5, and git available sanely such that, assuming I have everything installed, I can build arbitrary projects using those deps. <jeaye>I really didn't have good luck with that in NixOS. <fps>jeaye: "sanely" as in immediately available in your standard profile? <jeaye>Yes. For the software I'm building locally, I'd like those libs available in my standard profile. <fps>that is a question i'm interested in, too <jeaye>It's a small portion of software, compared to what will me on the system, but it's crucial to my every day development. <fps>i wouldn't mind having to do a little work to get a different profile for each project cause the isolation has distinct advantages <fps>for example for some projects i have to use boost 1.55 and for other 1.59 <fps>the real question for me would be: how hard is that? in nixos it's sometimes a little daunting... <taylan>jeaye: from what I understand, simply installing those things in your ~/.guix-profile, and sourcing ~/.guix-profile/etc/profile from your .bash_login or similar should be sufficient <jeaye>I think this is possible in NixOS, but it's so very unapproachable. <jeaye>taylan: How does that handle, as fps mentioned, different versions of libraries? <jeaye>i.e. boost 1.55 and boost 1.59 <taylan>in what way would you like that to be handled? in ~/.guix-profile, only one can be installed, but any other profiles on the system may have any other versions. <jeaye>taylan: Are they installed into ~/.guix-profile imperatively? <taylan>profiles are generated pretty much from scratch after every package transaction. e.g. when you run 'guix package --install=boost' (implicitly using the default profile, ~/.guix-profile), it creates a new "generation" of that profile and makes ~/.guix-profile point to it <civodul>jeaye: sounds like it should work, yes <rekado>re different versions of boost: you would not install those into the same profile. <rekado>I use multiple profiles for different projects with mutually exclusive dependencies. <taylan>you might have noticed that ~/.guix-profile is a symlink to /var/guix/profiles/per-user/$USER/guix-profile. that file is in turn a symlink which is made to point to /var/guix/.../$USER/guix-profile-$GENERATION after every transaction, where each such generation profile is immutable (so can be easily rolled back to etc., so long as it doesn't get deleted) <rekado>"guix package -p /desired/location/of/profile --install things" <rekado>civodul: I know what went wrong yesterday in my attempts to use the REPL. <rekado>my %load-path contained this entry: "/home/rwurmus/code/guix/". <rekado>%distro-root-directory in gnu/packages.scm results in a string without trailing slash. <rekado>as a result "(string=? directory %distro-root-directory)" in %patch-path would never be true, and so the patch path would not be appended to the root directory string. <civodul>still %distro-root-directory uses 'dirname', and i would expect it to strip extra slashes no? <rekado>right, %distro-root-directory has no trailing slash, but my %load-path does. <rekado>%patch-path does not strip off trailing slashes from %load-path entries. ***E4xoi is now known as init
<alezost>rekado: as Ludovic pointed, guix-build-log-mode is a major mode for log files. For shell-mode, there is "M-x guix-build-log-minor-mode" which also highlights build phases. I like it, so I have (add-hook 'shell-mode-hook 'guix-build-log-minor-mode) in my .emacs <sneek>Welcome back alezost, you have 1 message. <sneek>alezost, civodul says: what do you think of adding guix-build-log-mode to auto-mode-alist? <alezost>civodul: yes, I was going to add it, but then forgot :-) <alezost>civodul: btw, initially I added `compilation-shell-minor-mode' to `guix-build-log-mode-hook', as it highlights many general comilation stuff. But now I think it shouldn't be a default, because it is significantly slow on big logs, so what about removing it from that hook, and add a key binding for it instead? <efraim>if I want to build a package completely separated it would be `guix environment --pure -- guix build foo`? <alezost>efraim: I think "guix build foo" is enough <efraim>thats what I thought, but I think I'm using /usr/bin/perl as part of the autoreconf process <efraim>my conky sidebar shows 1 core pegged at `perl -w /gnu/store...` <efraim>then it says `bash ./configure...` <efraim>you're probably right, I just don't want to get it wrong :) <davexunit>efraim: guix builds happen in isolated environments already <davexunit>and 'guix environment --pure' would create an environment with *nothing* in it. <efraim>ok, so i'll assume conky's only showing a shortened version, and in top with the right settings it'll show the full path to /gnu/store/..bash <civodul>alezost: so adding guix-build-log-minor-mode to shell-mode-hook works well? <civodul>damn i should have done it from the beginning <civodul>alezost: re compilation-shell-minor-mode, it doesn't seem to be slow here <alezost>civodul: yes, but it doesn't provide keybindings - I just didn't know what keys to choose for the minor mode <alezost>civodul: you should open some big log (like gcc) <civodul>alezost: oooh now i understand what you meant :-) <civodul>and yes, if you turn compilation-shell-minor-mode off, it's fast <alezost>what about turning compilation-shell-minor-mode off by default and add "c" key binding to turn it on? <civodul>with the wealth of features in there, the difficulty now is more to "raise awareness" <civodul>or get people to use them automagically <civodul>on GuixSD all of the Emacs facilities are available by default, i think <davexunit>I still need to familiarize myself with all of these tools <davexunit>I just started using M-x guix to run importers, which I really like <alezost>civodul: how did you get gcc log so fast, did you have it locally? <alezost>ACTION is still waiting for hydra after "M-x guix b =s m<TAB> == gcc l" (which should display build log for gcc build for mips64el) <alezost>davexunit: yay, I'm not the only user of "M-x guix"! <davexunit>the thing I most want is a good way to handle 'guix environment' <davexunit>for example, for my Guile projects, I'd like to figure out how to spawn a geiser REPL that uses the desired environment <alezost>davexunit: yeah, no easy way out of the box. There is `process-environment' variable that Geiser should honor <alezost>yes, (let ((process-environment (cons "FOO=1" process-environment))) (run-guile)) works <alezost>I mean (environ) in Geiser says FOO is there <davexunit>we can re-use a lot of the 'guix environment' code to generate an sexp with those env vars <davexunit>and then run some arbitrary emacs expression? <civodul>alezost: i did "ls -l /var/log/guix/drvs/*/*-gcc*" <davexunit>alezost: I'm not familiar with the details of how guix.el bridges the scheme world and emacs world. I just know that it uses geiser to do it. <civodul>alezost: i use M-x guix occasionally, but sometimes i find that typing commands is faster <davexunit>how do you generally write scheme-side procedures for guix.el to use? do they do in guix/scripts, somewhere else? <civodul>alezost: what i do like is C-c . b and the likes, except that font-locking in *Guix REPL* is terrribly slow <alezost>civodul: it is as slow as in Geiser REPL, becaus it is the same geiser-repl-mode <alezost>davexunit: to evaluate scheme code synchronously, 'guix-geiser-eval' is used: (guix-geiser-eval "(+ 1 2)") <alezost>to evaluate in Geiser REPL: guix-geiser-eval-in-repl <alezost>civodul: I agree, typing is usually faster; mostly I use "M-x guix" for looking at graphs <alezost>civodul: btw, I usually disable font-locking in any comint-mode (shell, geiser, etc.) when something is running <alezost>davexunit: To evaluate in *Guix REPL*, `guix-eval' and `guix-eval-in-repl' are used: they can use any procedure from "emacs/guix-main.scm" file and the modules it uses <kmicu>It’s about providing binary substitutes for majority of possible compiler and system combinations. That is quite nice actually as a stress test for Nix/Guix ecosystem and as a service for haskell developers. <wingo>why are those packages so large? <wingo>i don't see why an opengl package would be 250MB <efraim>c-ares is at version 1.10.0, and the download includes the string 1_10_0. can I call it from (version-major) "_" (version-minor) "_" (version-micro) or something like that? <taylan>efraim: or (string-map (lambda (c) (if (char=? c #\\.) #\\_ c)) version) <civodul>kmicu: it's a nice stress test, but it's also scary when you think about GHC: NixOS is the only distro that provides this level of flexibility, what do other GHC users do? <civodul>and incidentally, what should Guix do with GHC? <efraim>taylan: I'll try that, didn't want to hardcode the version <davexunit>this sort of thing is what turns me off from using Haskell at all <davexunit>everything I read about building Haskell programs seems like a nightmare. <davexunit>ah yes, static linking. another reason to cross off Haskell as a sane environment. <taylan>IIRC Go also does static linking, but I've heard good things about that. maybe they do it in a more sanitized way. <kmicu>civodul: Guix does not give any advantage over Nix for Haskell development so it does not need to support it at all besides user tools like XMonad/pandoc/hakyll etc. <davexunit>Guix has advantages over Nix for all developers. <civodul>kmicu: i know many Haskellers use Nix, but surely not all of them <civodul>what i mean is that the Haskell packaging situation looks pretty bad <kmicu>davexunit: It would be a good idea then to list them on Guix home page to clearly show them. <civodul>not very far from the npm quagmire that paroneayea describes, it seems <davexunit>kmicu: we aren't in a competition for Nix's user base. we list our general reasons why Guix is good on the web page prominently. <kmicu>civodul: how so? It’s very good. That entry on ML list about supporting more combinations. Current haskellPackages set works very well. <civodul>kmicu: i wasn't clear; what peti does in Nixpkgs for Haskell is awesome, no problem here <civodul>but how do non-Nix people deal with this complexity, is what i wonder <davexunit>I read an article that took a large poll and determined that packaging is the #1 complaint amongst haskell users <davexunit>kmicu: yes, but civodul is asking about people who *don't use Nix* <davexunit>I would wager that most Haskell programmers do not use Nix. <Xe>i am a haskell programmer and I don't use nix <kmicu>Ahh non-Nix users have Stack/Stackage now for that. Haskell infrastructure in Nixpkgs supports Stack now also hence additional power required for build farm. <civodul>kmicu: i know, but non-Nix users cannot approach the flexibility of what peti does, not even remotely <civodul>IOW, they must be screwed quite often <Xe>civodul: i just rebuild a container if I get stuck <fps>um, how can i get this image mounted in virtualbox? i un-xz -d'ed it <davexunit>it seems pretty clear that building software written in Haskell by people who aren't intimately familiar with all of Haskell's quirks are screwed, more or less. <kmicu>civodul: With LTSs provided by Stackage situation is much better now. <Xe>fps: it didn't work for me in virtualbox, but basically you have to convert it to a VMDK <fps>Xe: ugh.. i ust wanted to mount it as virtual cd.. <civodul>Xe: yes, sure, but that sounds like a non-solution: once you manage to get a working environment, you freeze it and don't look back, no? :-) <fps>now the virtualbox gui crashed :) <Xe>davexunit: it's GPL 2 <davexunit>it does not work without a proprietary component. <fps>oh, xmonad just failed to show the dialog correctly <Xe>davexunit: the virtualbox drivers are all open source <Xe>the fact that they are signed is a different issue <Xe>and is only there to make insecure boot happy <civodul>Xe: yes but a proprietary compiler is needed for some part of VB nowadays, AIUI <Xe>civodul: for the windows components sure <davexunit>"The virtualbox-* packages were moved to contrib at VirtualBox 4.2, as a non-free compiler (Open Watcom) is required to build the BIOS." <fps>so, what exactly does hide in that image? it's just a bitwise image of a usb stick? <fps>let's see if i can get virtualbox to boot it <fps>something like this, ok: VBoxManage convertfromraw /path_to_image/copy_of_disk.img /path_to_virtualbox_images/virtual_disk.vdi --format vdi <Xe>vmdk might be preferable <fps>VBoxManage convertfromraw guixsd-usb-install-0.8.3.x86_64-linux guix.vdi --format vdi <fps>this seeems to work though :) <paroneayea>you'd think haskell people would be more concerned about clean design <davexunit>paroneayea: the code is pretty, but good luck compiling it! <davexunit>for some definition of "pretty" that is not mine. <paroneayea>but I think it's obvious to me that the packaging world has gotten so fractured and so out of control <paroneayea>that everyone is inventing crazy, impossible to control in different ways reinventions to try to keep up <paroneayea>not to mention the weird idea the world has gotten that in order to be a cool language, you need your own packaging scheme and repository <paroneayea>which does grow out of some "current state of the world" reasons <fps>so, where's the wiki where i can add that info, such that other people don't have to search for it? ;) <davexunit>fps: truly useful information should get into our manual <rekado>I am/was a Haskeller, and what turned me off most was cabal hell. <fps>davexunit: is getting it up to run in a virtualbox deemed useful info? <fps>if so i'll log my steps <davexunit>fps: as mentioned before, Virtualbox is no longer free software, so we wouldn't want to promote its use. <kmicu>fps: you could add that info on Nix Wiki “Migration to Guix(SD)”; that would be handy. <rekado>GHC is great, but as soon as you have to use external libs (and you don't get far without) you're in trouble. <davexunit>now, instructions for bootstrapping a QEMU VM without having Guix already would be useful. <fps>kmicu: kek ;) i'll log it and will consider a suitable place <paroneayea>davexunit: virtualbox is "free but shackled", right? :) <davexunit>paroneayea: yes, the code itself is free, but it depends upon a proprietary component in order to function. <davexunit>until that issue is resolved (which it won't be), virtualbox cannot be included in fully free distros. <davexunit>unsurprisingly, Oracle denies that "Open Watcom" is proprietary <paroneayea>btw this came up in another channel with Joey Hess <paroneayea><joeyh> please make guix as good as nix on packaging every haskell thing. kthxbye <paroneayea><paroneayea> I guess those package sizes are so large because of static compiling <paroneayea><joeyh> yeah, by default haskell libraries statically link other libraries <paroneayea><joeyh> I'd think guix could build haskell libraries as shared libraries and do much better, since it solves missing ABI versioning (maybe?) <paroneayea><paroneayea> joeyh:does Haskell provide the mechanism to do shared libraries? <paroneayea>anyway joeyh gave me permission to copy that conversation bit over <joeyh>yeah, the numbers I see for guix seem rather big, even if you have profiling builds along with the regular builds <davexunit>if there's anyone that can help us sort out our Haskell problems, it's joeyh, I would think. <paroneayea>joeyh: I don't know what the numbers are for #guix, though the numbers I linked in the other channel were not for Guix's packages fwiw :) <paroneayea>I'm sure #guix people would like to keep things well under control though, and make as much use of dynamic linking as we can <joeyh>oh, so that was nix numbers. <joeyh>btw, where is the pre-installed guix image for a vm? <davexunit>joeyh: we distribute raw disk images for installation purposes. <davexunit>though, you can build Guix from source and generate QEMU VM images. <davexunit>joeyh: what kind of an image would you like to see? a qcow2 with a basic desktop environment and stuff? <joeyh>so, fwiw, here's a fairly standard haskell library. Source code is 300 lines and it depends on a typical chunk of the haskell library ecosystem: <joeyh>-rwxr-xr-x 1 joey joey 143K Oct 29 12:03 libHSconcurrent-output-1.0.1-ghc7.8.4.so* <joeyh>-rw-r--r-- 1 joey joey 137K Oct 29 00:47 libHSconcurrent-output-1.0.1.a <joeyh>and then after --strip-unneeded: <joeyh>-rwxr-xr-x 1 joey joey 95K Oct 29 12:03 libHSconcurrent-output-1.0.1-ghc7.8.4.so* <joeyh>so shared is a win, but not a panacea. Most of the remaining size is taken up by tons and tons of symbols <joeyh>that links against 30 other shared libraries <paroneayea>I wonder what the rate of growth of binaries becomes the larger the dependencies become <davexunit>joeyh: if I made a vm image for you, would you like haskell already installed? <joeyh>wouldn't mind learning the nix command line <rekado>davexunit: "people who aren't intimately familiar with all of Haskell's quirks" ---> this is nothing to do with Haskell but with cabal. You don't need to know about Haskell's quirks (which?) to build software. <joeyh>I know the nix one, except the switches are impossible to remember <davexunit>joeyh: poking at a vm config based on my laptop's config + ghc. juggling a few different tasks at once but I'll let you know if I get something built and uploaded. <joeyh>paroneayea: it basically comes down to the number of symbols the library exports, and imports from other libraries. The mangled symbols are pretty big, and I've often seen up to 50% of the stripped .so are just the symbols <davexunit>guix is reporting that the installed size of our ghc package is 860.5MiB <joeyh>especially since haskell tends towards lots of small functions <joeyh>davexunit: sounds right.. Debian's 3 ghc packages sum to that. that includes profiling versions of all the libraries <davexunit>btw, I don't see a mention of --strip-unneeded in our haskell build system. <joeyh>if you went with shared libraries for haskell executables, split library (and ghc) would make sense <joeyh>well, it's useful if you don't care about gdb ;) <joeyh>which is nearly useless on haskell libraries anyway <davexunit>yeah, we could split the package into many outputs <davexunit>hydra is transferring files reaaaaally slowly. going to be awhile before I have GHC. <fps>i get like 300k/s which isn't too bad:) <joeyh>otherwise, some tiny haskell program would need to pull in all of ghc for libHSbase.so <fps>we chatted about using a distributed data store for nixos once or twice :) <davexunit>I hope some of our resident haskellites have registered that note as well. :) <davexunit>we want to encourage more peer-to-peer stuff in guix. <fps>where you lookup files by their hash, which would also make checking their correctness really easy and decentralize the delivery <joeyh>ipfs seems like it could be very useful for this kind of thing <davexunit>we have 'guix publish', which allows anyone to run a server that exposes a Hydra-compatible interface <davexunit>and a GSoC student has done work on gnunet integration <fps>i worked a little bit on morphis <fps>which sadly has stalled so ipfs is probably the better choice <davexunit>I don't know how to see such articles on lwn <paroneayea>davexunit: subscribers see more content than non-subscribers <paroneayea>at the bottom, you'll see the "Development" section <davexunit>I guess I have to check out this section more <civodul>davexunit: nice, how did you get that? <davexunit>civodul: ran out of VM image space when using 'guix system vm-image --image-size=2048MiB' <davexunit>I can upload something. trying to build an image with XFCE + GHC on it for joeyh <fps>interesting. i have a broken install on /dev/sda1 [due to my error]. now booting the usb disk fails, too <civodul>davexunit: 'guix size ghc' says 1209 MiB for its closure alone <paroneayea>davexunit: I'm guessing xfce isn't needed for joeyh <davexunit>to save time, I took my laptop's config, removed my user account, added ghc, and called it a day <paroneayea>it's fun to see guix boot up an xfce instance, I do think <paroneayea>ACTION has been itching to switch to StumpWM again lately <davexunit>civodul: that config was made hastily from another config of mine, so there's a bunch of unnecessary imports. don't mind the mess. :) <joeyh>does that set a root password? <fps>ok, i'll delete sda again and recreate it <davexunit>I think you should be able to login as root without password. civodul? <davexunit>maybe I should remake the image but with a joeyh user with no password <paroneayea>why can't anywhere else get good reporting like this <civodul>davexunit: yes the password is initially empty <wingo>paroneayea: if only its comments section didn't exist it would be great <paroneayea>wingo: lwn.net's comments section is pretty bad, but reddit and hacker news are even worse <paroneayea>lwn often has some informed discussions, probably a higher proportion than reddit / HN, but definitely can be really intolerable :) <davexunit>there's a couple annoying users that I have noticed <tyrion-webchat>Hello, is it possible to install guix on a system where I am not root? <davexunit>tyrion-webchat: in theory yes, in practice no. <davexunit>running as an unprivileged user introduces many severe limitations. <davexunit>which is a bummer, but the current state of affairs. <tyrion-webchat>second and harder question: my laptop with debian almost died. How difficult it is to install guix on my root partition, given that the whole system is encrypted (also /boot) <wingo>i wonder if it would be possible with user namespaces <wingo>so that the user is able to see /gnu/store by default somehow <davexunit>if unprivileged users can create user namespaces, then they can create any other namespace. <davexunit>and that opens the door to making unprivileged guix installs, complete with build isolation and substitutes from hydra.gnu.org, possible. <wingo>tyrion-webchat: so the thing is that you'd be nuking your debian installation, to start out with <wingo>because debian and guix want to do different things with /etc, /var, and so on <joeyh>huh, doesn't nix have a way to use ~/.nix for the user store? <wingo>some people do have encrypted partitions working, and though installation isn't straightforward it's possible to get working <davexunit>you can do that with guix, but that eliminates the possibility of using substitutes. <tyrion-webchat>wingo: so, I could boot with a live distro, and then mount my root partition and install guix there <davexunit>joeyh: users using unprivileged guix currently get no build containers or chroots because they cannot create those, and if they can't write to /gnu/store, then the new store directory changes all of the build hashes <davexunit>thus they must bootstrap the entire system from source. <davexunit>and inevitably there are problems in the process due to the lack of isolation. <wingo>tyrion-webchat: yes and guix's install image is live so that should work in theory. i don't know anything more about encrypted partitions though. reading the manual is essential and ask here if you have questions :) <davexunit>some people recently got encrypted stuff working. <davexunit>*but* you need to use guix master, not our 0.8.3 release. <joeyh>hmm, didn't nix use a layer of indirection to avoid the hashes changing? Ie, everything uses ~/.nix and it symlinks off to /nix <tyrion-webchat>davexunit: so I guess there is no documentation on how to do it? <davexunit>joeyh: but wouldn't the root user need to setup the /nix stuff? <a_e>Interesting discussion on ghc; I noticed its bigness when looking at raincat, and now I am getting an explanation. <davexunit>tyrion-webchat: just what is on the mailing list, I think. <joeyh>indeed, but in user-mode install, it doesn't symlink to there <a_e>Reading the channel log is more interesting than reading the newspaper! <davexunit>joeyh: I don't know they handle substitutes then. civodul? <joeyh>hm, seems I may be wrong about nix, at least, the regular install instructions mention /nix <fps>hmm, the system booted. now it hangs after "setting up setuid programs in..." <fps>and random: nonblocking pool is initialized <davexunit>fps: are you sure it's really hanging? try pressing enter <fps>davexunit: tried that a few times <davexunit>oftentimes, the log output in tty1 will write over the login prompt <fps>i'll leave it sitting <fps>maybe something needs to timeout <fps>note: i used the barebones config changing only the boot device <tyrion-webchat>davexunit: thank you for the hint, I found something, but since I would need to use the guix master, I am a little bit scared <tyrion-webchat>so unless I can talk to someone else that succeeded I think I will just wait for things to get more mature <davexunit>tyrion-webchat: okay. 0.9.0 is coming soon enough. <fps>spurious nak on isa0060/serio0 <fps>it's stilll collecting entropy it seems <fps>now it's continuing to boot <fps>and i got a lgin prompt <fps>i had to provide entropy by simulating myself coding on drugs <fps>ugh, an guix tells me to run "info guix" and info's not found :) <fps>info has to die finaly <fps>emacs? what is that? never heard of it.. <fps>ACTION runs away dodging flame bombs <davexunit>but we do generate basic man pages for the various guix subcommands. <fps>davexunit: cool. fiddling a bit while reading the manual a bit more then <davexunit>'guix package -i info man-db' to get info and man <fps>btw: i watched the guix talk on the website and thought to myself: this looks cool enough to use emacs a little more <fps>i used to like emacs quite a lot a decade ago or so. until i found out how hard it is to make it not destroy our custom indentation without giving up syntax highlighting <fps>then i wrote a c major mode that was basically a noop and lived with that for a while <davexunit>ah, yeah, you have to teach emacs what your indentation rules are. <fps>our indentation rules were super simple in an editor that left tabs and spaces alone and never tried to indent itself ;) <davexunit>I like to focus on problem solving instead of indenting by hand. <fps>so if i use guix package -i ... as root packages get installed system wide? <fps>oh, it even runs vim's test suite. nice <davexunit>fps: no, it installs to the root user's profile. <davexunit>system-wide packages are found in /run/current-system/profile <davexunit>and that is changed via updating your OS config and running 'guix system reconfigure' <fps>like nixos-rebuild switch and editing the config.scm before that? <fps>ok, time to dust up my lithp <kmicu>fps: internals including libstore are the same. <davexunit>libstore is the only part that is the same, really. <kmicu>Unfortunately that *part* is so important that you cannot just remove it *yet*. <kmicu>Personally I would like to see full rewrite in lisp. <davexunit>I mean, we'd prefer a daemon written in Scheme to one written in C++, but it's very fortunate that we have the Nix daemon to use. <davexunit>eventually we'll have to have our own daemon written in Guile. <davexunit>not sure when that time will come, but it will. <kmicu>I’m aware of that, but for now, today, semantics are the same as with Nix (with libstore, libutil, nix-daemon and .drv files.) <davexunit>yes, but that doesn't extend to say, system configuration. <davexunit>sure, nix and guix do similar things, but we don't share code for this. <kmicu>I’m *using* both systems and I don’t see much difference ¯\\_(ツ)_/¯ <davexunit>but the implementation is almost entirely separate code. <kmicu>libstore, libutil, nix-daemon, the core of Nix/Guix is more than similar — it’s the same code for both systems. You can diff it. <kmicu>(User facing stuff is different though) <fps>ok installing emacs in the root profile to make hacking the config.scm more pwetteeh <fps>btw: when i installed vim, it rebuilt it from source. in the bare bones config it doesn't pull binary packages? or was i just unlucky? <joeyh>davexunit: hey, so heading home soon, how is that image coming? <kmicu>fps: just remember to use paredit, or smartparens’ strict mode, or at least electric-pair-mode ( ͡~ ͜ʖ ͡°). You could also request a ‘guix layer’ for https://github.com/syl20bnr/spacemacs (if you still would like to use vi’s modal editing style) <fps>kmicu: i'm somewhat fin with macs :) <aeva>there is always evil-mode <fps>it'll probably take a few hours to get emacs anyways ;) <fps>and my bayesian prior is centere at infinity <fps>so before it finishes i cannot tell <kmicu>I thought it was b/c of disabled substitutes ‘EricJMRitz: Took about 8.5 hours but guile-emacs finally finished installing.’ ;) <aeva>emacs was the first thing I installed with guix on fedora, and I didn't think it took terribly long to pull down the entire dependency tree etc <fps>hmm, so should i stop the installation and research the substitutions thing? <fps>or maybe i'll make some roibos tea in the meantime and see where that takes me <kmicu>Maybe someone here with fast connection could share an Emacs closure with you. <civodul>fps: are you building everything locally? <fps>civodul: i don't know :) i ust installed the bare bones system and did guix packages -i emacs <fps>my keyboard is having a stroke <civodul>in that case it's downloading pre-compiled binaries <civodul>i guess you could tell the difference no? :-) <civodul>hydra.gnu.org is notoriously slow, but not *that* slow <fps>it varies by quite a lot though <fps>also i wasn't sure if it was pulling all kinds of sources before building them. vim got rebuilt from source for example <efraim>i'm never sure if hydra is slow or far away or if it is our internet cable through cyprus. <kmicu>fps: what’s in the first line of ‘guix build emacs --dry-run’ output? <efraim>although hydra is blazing fast compared to that month http.debian.net kept routing me to taiwan <fps>kmicu: "The following derivations would be built:" <fps>first entry in the list is ....-emacs-24.5.drv <kmicu>I thought that GuixSD has hydra.gnu.org keys out–of–the–box. <davexunit>0.8.3's binaries have been GC'd on hydra, unfortunately. <davexunit>joeyh: it just finished uploading to my server... it's a 4GiB disk image. <davexunit>probaby larger than it needs to be, but 2GiB wasn't enough for the system + GHC <davexunit>odd, it claims that this file is only 800MiB... <davexunit>civodul: what qemu command would one use to boot a vm image made via 'guix system vm-image' <davexunit>joeyh: sorry, forget about that image. it's bad. <civodul>davexunit: qemu-system-x86_64 -enable-kvm foo.img <civodul>fps: re GC'd things, yes, you should run 'guix pull' <civodul>we should profile the size of GHC and do something about it <davexunit>yeah. joeyh mentioned that there's 3 debian packages that make up the full GHC, and the size is roughly the same. <davexunit>to split the library from the compiler and such <civodul>i'd guess there's a lot of HTML documentation or something no? <fps>civodul: in the middle of getting emacs? <civodul>well if you're almost done, you might as well wait <fps>civodul: it's building mesa ;) <fps>so ctrl-c it, guix pull and retry? <davexunit>civodul: /lib/ghc-7.10.2/ghc_... accounts for 406 MiB <civodul>joeyh mentioned it earlier i think no? <civodul>at any rate i'd be in favor of removing all the static libs <civodul>we don't keep them in other packages <fps>civodul: the command started to compile something, too. that is to be expected? 28.% of 463 files <davexunit>'guix pull' fetches the latest guix source code and compiles it. <efraim>oh, that reminds me, I had a question and an idea <efraim>if I have 2 users and the first does guix pull and finishes and the second does guix pull and nothing has changed, does everything get compiled the second time? <davexunit>any given version only needs to be compiled once. <efraim>ok, so that takes away most of the reason for my idea, but it may still be useful <efraim>right now it downloads as guix-master-$(random-string) <efraim>if it were something else, like unixtime, then it would be easier to see what the most recent tarball is <efraim>and it might be possible to figure out which files have been modified and need to be recompiled <davexunit>efraim: the problem there, unfortunately, is that it's not enough to just know which files have changed. <davexunit>those changed files may have introduced ABI breakage, meaning that other files need to be recompiled, too. <davexunit>thus, the only safe approach is to rebuild fully. <efraim>so in the interest of throwing out ideas and seeing what sticks, is there a reason we don't just distribute the built files? <bavier>civodul: should gnu-build-system be passing "--disable-static" to configure then? <efraim>davexunit: i figured on the security at least <civodul>bavier: i checked and it doesn't have that flag (which is from Libtool, usually) <civodul>bavier: i just emailed a summary of these issues on guix-devel <civodul>a way to tweak you and others into fixing it ;-) <bavier>speaking of ghc, I'd like to push the native-search-path patches to core-updates later today <efraim>what do we do about the xz tarball? <efraim>it looks like hydra still has the xz tarball, so as long as we trust hydra we can still download xz-5.0.4 <joeyh>civodul: the static libs are useful for haskell developers who want to produce a program binary that is self-contained and so easy to deploy to other systems. Seems somewhat common in the haskell comminity <civodul>joeyh: yeah maybe we should just keep'em separated <civodul>bavier: which native-search-path was it? <wingo>does guix facilitate static linking for any other platform? <wingo>if not and there are significant savings to be had by not supporting it for haskell then punting might be a good option <wingo>platform == language runtime etc <davexunit>I guess it depends on haskell user expectations? <bavier>we might be able to sort the static libs into a separate output, but I'd expect they'd still be included in the package closure due to the package.conf file <bavier>probably easier to just remove them completely <fps>hmm, config.scm is read only? <efraim>it looks like it's also a result of running ./configure <alezost>fps: I don't know what config.scm you mean, but you can pass any file to "guix system" command <davexunit>how does one unlock the screen after running 'slock'? <civodul>davexunit: ah that's fun! you have to type the password directly <civodul>bavier: the patch was to fix the search-path machinery right? <civodul>did you try the screen-locker thing? <civodul>fps: there's no reason for it to be read-only, you decide <davexunit>civodul: what I would like is to figure out how to make XFCE's "lock screen" menu entry work <karhunguixi>by the way, xlockmore has been working ok for me for some days but today at work i had to alt+prtscr[REISUB] to get my desktop back. Screens were just black. <karhunguixi>(i blame xlockmore, but i guess it could be something else) <davexunit>xflock4 is simply a shell script that looks for and runs, in this order: <civodul>does it have /usr/bin hardcoded or something? <fps>alezost: oh ok, i was just following the installation instructions.. <davexunit>seems like upstream should just remove that entirely <fps>alezost: but you're right, there was an "e.g." :) <civodul>davexunit: some people like to hardcode file names :-) <davexunit>if I get a chance, I'll send a patch to the xfce folks and see what they think <bavier>civodul: yes, first patch was for directory patterns in search-path-as-list and the second fixes search path stuff for our ghc package <civodul>bavier: oh right, these are fine of course <bavier>I'll test with the latest batch of ghc-* packages, and then push <karhunguixi>civodul, regarding screen locker permissions i think root is required only when the locker program checks your unlock attempts against your account password, /etc/shadow. <bavier>ah yes, I forgot about rebootstrapping. <karhunguixi>like slock does. Whereas xlockmore let's you specify the password to unlock, and doesn't require root <civodul>karhunguixi: you mean xlockmore can use a password that is not your password account? <karhunguixi>yes, you specify your desired password when you start it the first time <karhunguixi>i'm unaware that it can be linked to your account password <karhunguixi>deleting this and running xlock prompts you to set a password before it locks the screen <karhunguixi>(i've mostly been playing with this on another computer) <civodul>i think it's best to have it use the account's password by default though <civodul>yeah, which is not great either i agree <civodul>rekado: do you think you could look at azr3 on dbus-update? <a_e>Might it not just be an issue of adding -std=c++11 or something like this, as yzsong added to a few other programs? <civodul>C++ compilers spit so many lines that it's hard to tell <karhunguixi>with a traditional distro you could have added to /etc/sudoers something like: "%users ALL=(ALL) NOPASSWD: /usr/bin/slock" <karhunguixi>i.e. giving users explicit permission to run slock with root privileges <civodul>yes, but one doesn't necessarily run the screensaver via 'sudo' <civodul>so the screen-locker-service thing sounds preferable over that <tyrion-webchat>does it make sense to have a minimal debian (or whatever) installation and then se guix as a package manager? <karhunguixi>i don't see how the screen-locker-service would get root privileges though <civodul>it makes xlockmore/slock setuid-root <a_e>tyrion-webchat: That is what I am doing on two machines. <a_e>For some notion of "minimal"... <a_e>For instance, mysql-common and mysql-server-core-5.5 are installed by default. <alezost>karhunguixi: to make /etc/sudoers you can specify 'sudoers-file' field in 'operating-system' declaration <karhunguixi>civodul, would it be the daemon that sets setuid-root? <civodul>karhunguixi: no, you add (screen-locker-service slock) to your config, run 'guix system reconfigure', and bam! 'slock' is setuid-root <civodul>it's done by the "activation script" <fps>h ok, there's a difference between system packages and other packages? <fps>since i couldn't add vim to base-packages <civodul>make sure to use the (gnu packages vim) module in your config <fps>that's what i'm looking at :) <fps>and is it expected that a guix system reconfigure /etc/config.scm takes quite a long time just to update the list of substitutes? <fps>the text below the first example in that section mentions adding emacs. but emacs is not mentioned in the config at all. does it come from the (use-modules (gnu)) ? <fps>" The example above adds Emacs to those, taken from the (gnu packages emacs) module" <fps>that kind of confused me a little ;) <fps>so to get vim i'd use (use-modules (gnu packages vim))? <fps>and then add it to the packages list <fps>i'll read up on the modules docs <fps>i suppose i could also somehow inspect all (gnu packages ...) modules so i don't have to hunt them down and add them manually evertime? <fps>it irks me as kind of redundant <bavier>fps: you can use 'guix package --show=<foo>' to find out which modules you need to load <civodul>you could instead look things up by name <fps>which the gnu package vim module exposes <fps>i suppose i could try writing a function that takes a name and both (use (gnu package name)) and (cons* name %base-packages) <fps>oops, cons, not cons* if i inferred it right that one takes more than one value and the other only one <civodul>the (gnu packages) module provides find-best-packages-by-name, for instance <alezost>ACTION uses "M-x guix-edit <package>" to find a package module <civodul>alezost: i had forgotten that one, nice! <fps>is there a way to set the console fonts and width/height? for the time without x? <karhunguixi>alezost, aha, i didn't get your point initially, but i see now you can specify the _contents_ with sudoers-file :) <fps>i think i remember it being some nasty kernel parameter back in the days <fps>80x24 feels arcane :) <fps>ok, i need to first redo a quick tutorial on scheme and particularly guile <fps>i basically only remember (f arg1 arg2 arg3) ;) <fps>oh and something about lambda ;) <fps>so the % in front of %base-packages is just part of the variable name? <fps>or does it have special meaning? <alezost>karhunguixi: yes, the contents, or a file that will be used as sudoers <alezost>karhunguixi: I think it's a convention for global variable <fps>btw: can i expect the updating of the list of substitutes to take quite a long time? <fps>on the order of minutes? <fps>or is that just a temporary slowness of hydra? <karhunguixi>ok, i've only seen them in plural form so i assumed list <a_e>It is a slowness of hydra. <a_e>Not that temporary, unfortunately. <bavier>fps: hydra has been temporarily slow for a while <fps>and it will happen on every guix system reconfigure? <bavier>if the store items needed are still around, it shouldn't take as long <fps>ok, so if i'll do anything in guix i guess i might try my hands on ipfs integration ;) <bavier>because hydra is only queried for missing items <fps>do you have a load-balancing/automatic mirror selection in place? <fps>so if i have a root server with some disk capacity and some bandwidth, might that help? <fps>how much traffic do you get? <fps>per month, for example? <bavier>fps: civodul recently polished up support for multiple substitution servers <karhunguixi>it's my impression that it's not "a lot" of traffic per se, but that hydra is running in a quite limited environment <fps>karhunguixi: care to elaborate? <a_e>rekado: I tried to compile azr3 with -std=c++11; this does not help. <a_e>It still fails with: <fps>oh, i tried cons*'ing %desktop-services to %base-services and i get a nice fat stack trace ;) <civodul>karhunguixi: it's a Xen host with abysmal i/o performance and little RAM and disk <bavier>fps: they're both lists, so you should 'append' instead <fps>bavier: hah, thanks :) <alezost>fps: btw you shouldn't join them, because %desktop-services already has %base-services <fps>alezost: ok, got ya, i guess that explains the error i got about multiple ncsd's <fps>hmm, now networking is provided more than once.. <fps>how to go about finding out more about this? <karhunguixi>civodul, is beefing up hydra the first priority when more fiat money becomes available? <fps>civodul: how much is "little RAM and disk"?