<mange>The phases are quoted, and are evaluated elsewhere. You need to unquote references that don't exist in the build environment. You can use , to do so (so ,elogind-hook-script in the format call). You can see the same thing has been done with phases as the first argument to modify-phases.
<Dedalo>Hi guys, I'm new to Guix and GuixSD in particular. I didn't install it, but I'm trying to understand the difference with NixOS (and Nix). I have a lot of question but I would start three in particular: 1) I'm switching from macOS and I will need some proprietary software like Skype, Spotify, etc. Can I install this software on GuixSD. If yes, how? 2) I will need (since I'm a dev) to install stuff from source, using make &&
<Dedalo> make install. Is that something that I can do, out of the box? 3) I will install the distro on a Lenovo X1 Carbon, and I'm worried about the kernel drivers. What do you suggest?
<mange>I think the main differences between Guix and Nix are that Guix is fundamentally a free software distribution, and that it uses Guile Scheme to define packages instead of the Nix language. There are other differences, but I think they're the big ones.
<mange>That means for your first question: you can run proprietary software like Skype/Spotify/etc., but it's not necessarily straightforward, and there is no official support for doing so, and support should not be sought through official channels.
<mange>For your second question, the preferred way to install things in Guix is from source! The distribution is made up of packages which specify how to build packages from source. You may find that you would rather write a package definition (which will call make && make install) to have Guix manage your installation (allowing for easy rollbacks, dependency isolation, etc.).
<mange>For the third question: Guix doesn't officially support running a non-free Linux with binary drivers. It is possible to run a non-free kernel, but it is not documented or encouraged. I don't know whether that computer would work with the Linux-libre kernel that is the default in GuixSD.
<Dedalo>In relation to your second answer, I think is cool that I can create a package. The main drive to use one of these distros is that they support rollback and many version of the same packages. But what about the fact that both GuixSD and NixOS don't use FHS but they have their own hierarchy? Is this going to be a problem? I'm thinking especially to the packages that are using hard paths, which is not a good practise but
<Dedalo>In relation to your third answer (and the first one as well) my question is: ok, it's not officially supported and I shouldn't ask on the official channels, but is that something easy or not? I have seen a screenshot of a guy running GuixSD on a Mac, so I'm sure is possible. :-)
<mange>It does pose some problems for some things. Usually if you're compiling from source things are okay, and you can patch the source to fix assumptions about paths. For pre-compiled binaries it's much more of a problem.
<mange>GuixSD makes writing a new kernel definition quite easy.
<Dedalo>Thank you, one last question for tonight, then I will leave you alone. :-) Which is, in your opinion the advantage of GuixSD over NixOS?
<mange>GuixSD's service composition model for assembling a system makes more sense to me than the NixOS mechanism of changing settings in one big system settings object. I remember being really confused about NixOS and how I would add my own settings, whereas in GuixSD it was quite easy for me to work out.
<mange>I also think Guix just feels more approachable, and flexible. All the power of Guix is available to me as a Guile Scheme library, so I can do a lot of things with that.
<mange>For example, I used to generate my Emacs configuration by getting Guix to query elpa/melpa to pull down recipes for my Emacs packages, then it would assemble a Guix profile containing all of the packages that I wanted, at their most recent version. I could only do that because all the pieces were exposed in Guile.
<jackhill>+1 for the whole OS being embedded in Guile. That's pretty big for me.
<Dedalo>So you can basically write a bunch of scheme files and have a system that can be completely initialised from that file, more or less like you do with a Dockerfile to create a container?
<Digit>i wish guix documentation came in pill form... so i could just swallow a pill, and know all of guix. #lazylearner
<mange>Dedalo: Similar, but different. You can write arbitrary code, but the end result is a declarative configuration. Dockerfiles are a series of instructions to get the machine into the right state, but with Guix/Nix you're creating a specification, and then the Guix/Nix internals put the system into that state.
<mange>My Emacs configuration thing would check elpa/melpa, but then what it actually put together was a list of Emacs packages and versions which Guix would then instantiate in my ~/.guix-profile/ directory to create an Emacs with all the packages that I use. It was pretty cool being able to do that.
<iqubic>How hard is it to switch from NixOS to GuixOS?
<brendyn>not very i guess. you could install guix ontop of nixos, and then reconfigure to make it in to a guixsd system
<iqubic>But would that remove all the nix depedencies?
<iqubic>Oh, wait, the distro is called GuixSD, and not GuixOS?
<mange>I'd say about as difficult as switching from Mint to Debian.
<brendyn>firefox is difficult because of the inclusion of Rust. we have to find a solution for packaging rust programs. I don't know much about it, but I think the sources contain hashes which we have to recompute because we also need to modify hashbangs
<iqubic>If I switch I'd be spending a few months learning a new syntax just to be able to do everything I can already do with Nix.
<iqubic>It would be a step backwards for me, not a step forward as I initially thought.
<mange>I think the main distinguishing things are: the implementation language, using the full power of Guile Scheme instead of the Nix language; and the system configuration style, using service composition rather than Nix's system object approach.
<brendyn>I just started with guix and never really touched nix so I don't know too much about the differences
<mange>The reason I suggested using a VM would be to see whether you liked the feel of Guix more than Nix. I found that Guix made a bit more sense to me than Nix, so I decided to use it instead of Nix.
<iqubic>What do you mean when you say Nix has an object approach?
<mange>In Nix you have one big "system" object, which you set values and flags on. So to enable awesome as your window manager you set a particular value in a sub-object, and that might result in some other values getting modified elsewhere (and so on until it reaches a fixpoint). At least, that's it from memory.
<iqubic>Those three options you just specified are available on Nix too.
<mange>When you run "guix system init" or "guix system reconfigure" you provide a file that Guix evaluates. That file should return an operating-system object which specifies the desired operating system.
<mange>Yep, in two different ways. You can write a package definition for the project that tells Guix how to build it, then run "guix environment -f my-package.scm" to get into a shell, ready to build it.
<iqubic>brendyn: What do you want to do with inherit?
<mange>Or you can write a manifest, and create a local profile for it using "guix package --profile=my-profile --manifest=project-dependencies.scm", then source it into your shell with ". my-profile/etc/profile".
<iqubic>brendyn: What do you think inherit would do in Nix?
<iqubic>let's make sure we are talking about the same thing here.
<mange>Anyway, I need to go AFK for a bit, so I'm going to stop responding now. I think Guix is really worthwhile, but it is differnet to Nix. I would advise you to try it out in a VM to see whether you like it or not.
<brendyn>like if you want to package two versions of linux, you can just inherit the main one, change the version number and hash
<brendyn>there are many packages defined that way in guix
<mange>You won't necessarily be able to do much "new" stuff with Guix, but you might enjoy the way you can do it in Guix. Exposing the full power of Guix as a Guile library is something we haven't even touched on, but that is really useful, too.
<iqubic>Oh, I'm not sure if you can do that in Nix. I was thinking about the keyword nix has called "inherit"
<iqubic>Which is something else entirely different.
<brendyn>i think i saw something like overwridederivation
<g_bor[m]>snape: Did you follow the discussion regarding creating a stable branch?
<snape>hi g_bor[m]! Yes I've seen that it involved ad-hoc Cuirass support
<g_bor[m]>snape: yes, i've also seen that. Do you think we can make this more generic? Does it worth?
<vagrantc>i'm struggling to create a new arm-trusted-firmware- variant, but it builds and installs a 4GB file, mostly padded with zeros that isn't actually needed ... i'm trying to figure out where to insert a (delete-file "...")
<vagrantc>if you use (modify-phases %standard-phases) with something which has inherrited from another definition... will %standard-phases include the inherited phases, or will it reset it to the default %standard-phases and then modify that
<g_bor>I mean to have a local copy of the repository on the machine running cuirass, and write to that. Then we can allow cuirass to write there, and an external service could watch this for writes, adn push to savannah when a change occurs?
<snape>yes, but calling a script is easier than pushing a branch
<g_bor>sneek: later tell vagrantc: It seems that you are missing a closing parenthesis after ((#:phases phases , but it was balanced at the end, causing no immediate syntax error, but leaving the syntax form open. I've sent you a mail with the correct patch. (Please notice that I did not build it, did not check the copyright lines, and did not made the modification to the ovmf package).
<g_bor>yes, I do. Actually two errors. Will have a look in a minute.
<g_bor>rekado: I get: panic cannot find importVocab file 'ANTRLTokeTypes.txt'. Then a backtrace telling that antlr exited with exit code 1. Arguments were: "-o org/antlr/tool" "org/antlr/tool/serialize.g".
<g_bor>This is email@example.com. It builds fine on master, and also on staging where we already use icedtea-8 as icedtea.
<rekado>does the file exist (use “guix build -K”)? Can you reproduce this outside of the build container?
<rekado>snape: the Cuirass web interface is now available on berlin.guixsd.org (I removed the index.html for now)
<Hydro>Hello ! New to GuixSD... just did a "guix system reconfigure..." but it failed near the end, trying to [re]install Grub, cause had I forgoten to mount /boot/efi. Now, i could try to re-install Grub manually, but it is unclear to me, yet, how this could affect "generations" and this kind of "guixy" things ?!
<brendyn>cant you just run reconfigure again after mounting it?
<Hydro>sure... it's just... it takes time and appears to download lots of things i allready have... but i could of course
<Hydro>k, ill try to do that and do some reading after that, to get a better understanding of guix. Thanks Brendyn
<cryptocat1094>In GuixSD, how do service updates work? Are the programs running as services considered to be running from root's profile?
<brendyn>cryptocat1094: try setting up guix, and then finding a program you want but isnt already in and then package it. ask for help in this channel when you are stuck, then email the patch to firstname.lastname@example.org
<kballou>rekado: correct, I'm using `guix build -f gnu/packages/admin.scm anisble`. I'm trying to update ansible to 2.5.7... I may be doing something incorrectly. I'm drafting an email with the patch details.
<rekado>kballou: that’s not how “guix build -f” should be used.
<rekado>kballou: the file that you pass to “guix build -f” must end with a package value.
<rekado>if you are working on a git checkout simply run “guix build ansible”
<kballou>rekado: that seems to be it, it looks like it's building correctly in the `./pre-inst-env`. ~However, I still don't understand why what I was doing was wrong?~ Oh, I see. `--file` doesn't mean what I thought. Thank you for the clarification.
<kballou>snape: I've killed my system with `-j`... compiling the Linux kernel with `make -j` brought a 2 core machine to a load average of about 90 before I killed it.
<snape>it shouldn't. '-j' takes the number of cores
<kballou>I know, that's why I was so confused... Out of habit, I usually always specify a number now :|