IRC channel logs


back to list of logs

<civodul>Hello Guix!
<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>hi, fps!
<civodul>derivations are the low-level format, akin to assembly, so that's not what we would transform
<civodul>but we can import the "high-level" stuff from Nixpkgs, see
<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 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>i guess the same would apply to Vim
<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
<civodul>in GuixSD this is done with the 'packages' field:
<civodul>and with Guix you can also declare the user's profile, via 'guix package --manifest':
<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>Any other key differences?
<jeaye>(other than it being less mature)
<civodul>it doesn't use systemd
<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'
<fps>i.e. you search for "nix" on and there's not a single hit ;)
<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
<civodul>heh maybe you're right!
<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
<civodul>yeah there's also no GNOME, for instance:
<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
<jeaye>I would be ok with that.
<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>note the trailing slash.
<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.
<rekado>so all is good now.
<civodul>rekado: oooh, interesting bug
<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.
<civodul>oh right, i see
***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.
<davexunit>i.e. 'guix' wouldn't be on $PATH
<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
<rekado>alezost: nice. I'll try it.
<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>ACTION tries
<civodul>alezost: oooh now i understand what you meant :-)
<civodul>ok, disable it :-)
<civodul>and yes, if you turn compilation-shell-minor-mode off, it's fast
<civodul>folding/unfolding is fast
<alezost>what about turning compilation-shell-minor-mode off by default and add "c" key binding to turn it on?
<civodul>sounds good!
<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>alezost: that's cool, we can build on that.
<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?
<alezost>yes, it can be done
<davexunit>this is very exciting to me.
<civodul>alezost: i did "ls -l /var/log/guix/drvs/*/*-gcc*"
<alezost>civodul: that's what I thought
<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
<civodul>GHC madness:
<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.
<wingo>do they have a stable abi?
<kmicu>civodul: Nix is a common tool for Haskell developers. They want to avoid building deps and using different compilers (supporting 3 recent versions of GHC is quite common practice in commercial Haskell companies). Haskell packages are big b/c they are statically linked
<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.
<davexunit>no, it's still bad.
<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
<kmicu>What complexity? :)
<kmicu>Generally users have no problems with
<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*
<civodul>kmicu: i said non-Nix
<davexunit>I would wager that most Haskell programmers do not use Nix.
<civodul>"many" is safer :-)
<Xe>i am a haskell programmer and I don't use nix
<davexunit>I'm living on the edge
<Xe>i use docker
<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..
<Xe>fps: it's not a 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 :)
<davexunit>virtualbox is nonfree software.
<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
<Xe>but for GNU/Linux no
<davexunit>instead, we suggest using QEMU.
<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?
<davexunit>fps: yes, it's a raw disk image.
<fps>let's see if i can get virtualbox to boot it
<Xe>GPL 2
<davexunit>as opposed to ISO
<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 :)
<fps>it boots
<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>yeah I was gonna say
<paroneayea>I think Haskell is pretty cool
<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
<paroneayea>but exacerbates the problem
<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: we don't have a wiki, aside from what is on
<paroneayea>here is that survey davexunit
<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? :)
<paroneayea>it's the bios thing that stops it
<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
<davexunit>speak of the devil.
<davexunit>greetings, joeyh!
<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> it's pretty bad. Also, no ABI stability
<paroneayea><joeyh> that seems too high though
<paroneayea><joeyh> Installed-Size: 388905 -- ghc.deb
<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><joeyh> yes, recently-ish
<paroneayea>sorry, shoulda pastebin'ed
<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>but they might be large anyway
<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.
<joeyh>oh so the usb installer
<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?
<fps> [if you want to boot it in VB ;) - /me runs and hides]
<joeyh>yeah, basically that
<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*
<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*
<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>joeyh: useful to know
<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
<davexunit>how about the guix 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>er, that I mean
<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
<davexunit>rekado: okay, thanks for clearing that up.
<joeyh>davexunit: sounds right.. Debian's 3 ghc packages sum to that. that includes profiling versions of all the libraries
<joeyh>and also incudes .so and .a
<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
<davexunit>which is this:
<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>to make it less beefy
<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
<davexunit>fps: 118KiB/s here, bleh.
<davexunit>joeyh: yeah, that makes sense.
<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
<civodul>davexunit: seen ?
<davexunit>civodul: oh wow!
<davexunit>no, I hadn't. thanks!
<davexunit>unfortunately, the first word is a typo.
<civodul>yeah, nor our fault ;-)
<paroneayea>oh yay
<paroneayea>n8willis is great
<davexunit>I don't know how to see such articles on lwn
<davexunit>they don't show up on the main page
<paroneayea>davexunit: subscribers see more content than non-subscribers
<paroneayea>it's in the weekly edition
<davexunit>paroneayea: I am a subscriber
<paroneayea>davexunit: oh :)
<paroneayea>at the bottom, you'll see the "Development" section
<davexunit>I guess I have to check out this section more
<davexunit>"ERROR: In procedure copy-file: Success"
<davexunit>oh dear...
<paroneayea>ERROR: Too much Success
<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>presumably, anyway.
<civodul>oh, ok
<civodul>what image is that?
<davexunit>I can upload something. trying to build an image with XFCE + GHC on it for joeyh
<civodul>i see
<fps>interesting. i have a broken install on /dev/sda1 [due to my error]. now booting the usb disk fails, too
<fps>with a kernel panic
<civodul>davexunit: 'guix size ghc' says 1209 MiB for its closure alone
<paroneayea>davexunit: I'm guessing xfce isn't needed for joeyh
<civodul>heh :-)
<davexunit>civodul: here it is
<davexunit>paroneayea: I just threw it in.
<paroneayea>davexunit: fair enuf :)
<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>joeyh: no.
<davexunit>I think you should be able to login as root without password. civodul?
<paroneayea>damn is such quality reporting
<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
<paroneayea>ok that's a bit egregious "anywhere else" ;)
<wingo>paroneayea: if only its comments section didn't exist it would be great
<civodul>don't read'em!
<paroneayea>wingo: heh
<paroneayea>wingo:'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
<davexunit>but I've also seen good discussions
<paroneayea>oh hello aeva !
<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.
<tyrion-webchat>ok, so I won't try it
<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
<davexunit>yes, it would be.
<wingo>so that the user is able to see /gnu/store by default somehow
<davexunit>that part is harder.
<davexunit>but, possible.
<tyrion-webchat>you mean replacing my current system
<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, 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: yes, it is ok, as long as guix works :D
<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>nice to know
<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>I'm interested in what they did.
<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?
<davexunit>ah, civodul left.
<davexunit>know how they**
<tyrion-webchat>davexunit: should I look on guix-devel?
<davexunit>tyrion-webchat: yes
<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
<davexunit>see if you get a login prompt
<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.
<davexunit>fps: hmmm not sure what's wrong, then.
<fps>got a message
<fps>spurious nak on isa0060/serio0
<fps>it's stilll collecting entropy it seems
<davexunit>oh weird
<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>oh well..
<fps>info has to die finaly
<davexunit>the minimal config must not include info
<davexunit>info is our preferred format
<davexunit>our manual is written in texinfo
<davexunit>much better than man pages.
<davexunit>and emacs has a really great info reader
<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>davexunit: thanks\\
<davexunit>we take pride in our emacs integration :)
<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
<fps>then i moved on ;)
<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.
<fps>davexunit: ok
<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?
<davexunit>yeah, sounds like it.
<davexunit>ACTION never used nix
<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>well, sure, there are lots of similarities.
<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)
<davexunit>but there's *so much* more code than that.
<davexunit>anyway, have to go afk.
<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 (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 ;)
<kmicu>Why so many hours?
<fps>slow downloads :)
<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> is notoriously slow, but not *that* slow
<fps>20KiB/s right now
<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 kept routing me to taiwan
<fps>kmicu: one moment..
<fps>kmicu: "The following derivations would be built:"
<fps>then a list
<fps>first entry in the list is ....-emacs-24.5.drv
<kmicu>I thought that GuixSD has keys out–of–the–box.
<davexunit>fps: what version of Guix?
<davexunit>0.8.3's binaries have been GC'd on hydra, unfortunately.
<fps>davexunit: 0.8.3
<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>so one sec and I should have a URL for you
<davexunit>odd, it claims that this file is only 800MiB...
<davexunit>joeyh: shot in the dark, but here's what was built:
<davexunit>first time doing this
<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.
<davexunit>looks like it was corrupted upon upload.
<davexunit>not sure what went wrong. :(
<civodul>davexunit: qemu-system-x86_64 -enable-kvm foo.img
<davexunit>civodul: thanks
<davexunit>if only my image didn't get corrupted...
<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
<civodul>GHC itself is 860 MiB!
<davexunit>yeah. joeyh mentioned that there's 3 debian packages that make up the full GHC, and the size is roughly the same.
<davexunit>so, we ought to create several outputs
<davexunit>to split the library from the compiler and such
<civodul>i'd guess there's a lot of HTML documentation or something no?
<civodul>how could it be this big
<civodul>oh, there's already a "doc" output
<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?
<civodul>yes exactly
<fps>ok, ty
<civodul>ghc:out refers to ghc:doc
<davexunit>civodul: /lib/ghc-7.10.2/ghc_... accounts for 406 MiB
<civodul>there are .a and _p.a files
<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
<davexunit>they might be needed?
<davexunit>oh, okay.
<davexunit>yeah, about 300MiB worth of static libs
<fps>civodul: the command started to compile something, too. that is to be expected? 28.% of 463 files
<davexunit>that's expected.
<davexunit>'guix pull' fetches the latest guix source code and compiles it.
<fps>davexunit: ok
<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>efraim: no.
<davexunit>any given version only needs to be compiled once.
<davexunit>and then it's in the store.
<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?
<davexunit>efraim: reproducibility.
<davexunit>and security.
<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
<bavier>civodul: thanks!
<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?
<davexunit>gotta keep 'em separated
<civodul>reminds me of the good ol' days
<bavier>civodul: GHC_PACKAGE_PATH
<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>i just tried it in a VM too
<civodul>i was surprised :-)
<civodul>bavier: the patch was to fix the search-path machinery right?
<davexunit>civodul: thanks! that scared me
<civodul>did you try the screen-locker thing?
<davexunit>civodul: yes, it works!
<civodul>fps: there's no reason for it to be read-only, you decide
<civodul>davexunit: cool :-)
<davexunit>wow xlockmore is straight out of the 90s
<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.
<davexunit>civodul: a-ha! xflock4
<civodul>karhunguixi: weird, works for me
<karhunguixi>(i blame xlockmore, but i guess it could be something else)
<civodul>davexunit: oh!
<civodul>we need an xfce-service maybe?
<davexunit>hmm, seems not, actually.
<davexunit>xflock4 is simply a shell script that looks for and runs, in this order:
<davexunit>- light-locker-command -l
<davexunit>- xscreensaver-command -lock
<davexunit>- gnome-screensaver-command --lock
<davexunit>- xlock -mode blank
<davexunit>- slock
<davexunit>so why doesn't it work? odd.
<civodul>is that a reliable source? ;-)
<civodul>does it have /usr/bin hardcoded or something?
<davexunit>that could be!
<davexunit>it sets PATH!
<davexunit>export PATH
<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." :)
<fps>civodul: ok :)
<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
<davexunit>and add that patch to our package recipe
<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>civodul: great
<bavier>I'll test with the latest batch of ghc-* packages, and then push
<civodul>that'll be a lot of rebuild
<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>which it saves in a dot file
<karhunguixi>i'm unaware that it can be linked to your account password
<karhunguixi>hm, i may be confused
<karhunguixi>no, i think i'm good. The password is in ~/.xlockrc
<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>oh ok
<civodul>i think it's best to have it use the account's password by default though
<karhunguixi>yeah, but it appears you need root privileges then
<civodul>yeah, which is not great either i agree
<civodul>rekado: do you think you could look at azr3 on dbus-update?
<civodul>it's a somewhat intimidating issue with libsigc++:
<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>a_e: ah, could be!
<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>is there a Guix way to achieve something similar?
<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
<civodul>and in the end it runs as root
<civodul>ACTION looks at in despair :-/
<tyrion-webchat>does it make sense to have a minimal debian (or whatever) installation and then se guix as a package manager?
<civodul>tyrion-webchat: yes, why not!
<karhunguixi>i don't see how the screen-locker-service would get root privileges though
<civodul>it makes xlockmore/slock setuid-root
<karhunguixi>ok, but you would need root for that then
<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
<tyrion-webchat>I could use ubuntu 14.04 so I don't even need to use systemd
<karhunguixi>civodul, would it be the daemon that sets setuid-root?
<karhunguixi>(just trying to work things out in my head)
<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>you can do it
<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"
<civodul>it adds tcpdump, but not emacs
<civodul>but the idea is the same
<fps>that kind of confused me a little ;)
<civodul>understood :-)
<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
<civodul>yes, exactly
<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>here you're referring to variables
<civodul>"vim" is just a variable
<civodul>you could instead look things up by name
<fps>which the gnu package vim module exposes
<civodul>but that's typically more typing
<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>to brush up my lisp
<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
<alezost>and "C-c . k" to copy that 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>it's been a while..
<bavier>that's about the gist of it :)
<fps>so the % in front of %base-packages is just part of the variable name?
<fps>or does it have special meaning?
<bavier>fps: just convention
<karhunguixi>convention for a list?
<fps>oh and car and cdr
<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.
<karhunguixi>yeah, it can take a while
<bavier>fps: hydra has been temporarily slow for a while
<fps>and it will happen on every guix system reconfigure?
<bavier>it depends
<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 ;)
<fps>we'll see
<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?
<bavier>fps: it's a poor little VM
<fps>what kind of vm?
<karhunguixi>i assume QEMU
<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"?