IRC channel logs


back to list of logs

<davexunit>yo #guix
<davexunit>so, nix-shell can now be used as an interpreter in a shebang
<davexunit>shouldn't be hard to make guix environment do the same
<davexunit>NixOS is at the tippy top of the HN front page currently:
*davexunit packages more ruby libraries
<paroneayea>davexunit: :)
*davexunit dumps 8 patches on the list
<davexunit>you're welcome and sorry.
<davexunit>I'm going to attempt to use DMD at work.
<davexunit>my boss showed me this:
<davexunit>which explains the importance of init systems, something a lot of us here already know
<davexunit>but then it prescribes a docker image that uses a crappy minimal init system
<davexunit>I'd like to replace it with dmd
<davexunit>and see if I can get that adopted.
<davexunit>sweet, technomancy is into guix!
<zacts>cool re technomancy
<zacts>do you guys usually use wicd to configure wifi on guix, or what do you use?
<bavier`>zacts: I use wicd
<zacts>oh cool
<aravind>I am unable to get X working, it launches Xorg and then the tty just freezes... the tty text scrolls past and then just locks up. I end up having to powercycle to get back into the laptop. I am launching Xorg with "Xorg -verbose 3 -modulepath ~/.guix-profile/lib/xorg/modules/ -logfile ~/xlog.txt -nolisten tcp :0 vt2" in my .xserverrc. I am logged into tty2 on my console.
<aravind>the stuff I saw online says to use a login/display manager (simple?)..
<aravind>but I'd like to launch X with startx if possible.
<aravind>the xlog file says the graphics card has been detected by the intel xorg driver just fine.
<aravind>any tips/suggestions?
<DusXMT>aravind: usually, X is on a non-managed tty (eg. vt7)
<DusXMT>I don't know if trying to run it on a one where you're logged in can work
<aravind>I recall reading that the non-managed tty thing was with suid X, these days with non-root X, it should run fine with the tty you are logged in.
<DusXMT>Ah, I didn't know that, interesting...
<aravind>I have arch linux on this same box, and that one launched X on current tty, just fine.
*DusXMT used to have a script that launched X as root and then everything else as my user when he wasn't using
<DusXMT>lightdm, or whatever GuixSD uses
<aravind>The arch linux Xorg, runs like this /usr/lib/xorg-server/Xorg -nolisten tcp :0 vt2 -auth /tmp/serverauth.dhsgfgw2
<DusXMT>Well, you probably know more than me then, back under my rock :)
<aravind>thanks for the suggestion though, I tried without specifying a tty, and that complains about not being able to open one (tty).
<aravind>so I am getting further with this path, just not all the way :(
<alezost>aravind: do you mean you start X server on GuixSD as a non-root user?
<aravind>nope, startx on arch linux with the X installed from guix.
<aravind>and as a non-root user.
<aravind>is this asking too much of guix?
<alezost>aravind: I don't really know what is needed for having a rootless X, perhaps Xorg server needs to be compiled specially. According to <> there is some dependency on logind. That might be the problem, but I actually don't know.
<alezost>I tried a "rooted" X server installed using guix on ArchLinux, and it worked for me, but I've never tried a rootless one
<aravind>oh.. how do you get a rooted version?
<aravind>alezost: I thought the default is un-rooted?
<alezost>aravind: "sudo X :0 vt7 ..."
<aravind>at that point, can you still launch your normal window manager etc, or is everything running as root ?
<alezost>everything can be run as a usual user; it's only the X server itself which is run as root
<aravind>alezost: okay, I will give that a shot, thank you.
<alezost>I actually use dmd to start X server, WM and other things on GuixSD; and I use systemd for the same purpose on Arch
<aravind>right.. I am still in my getting comfortable mode for guix, so I am trying to run a hybrid system.
<aravind>I know very little about guix(sd).. at this point.
<ewemoa>mark_weaver: here's the latest diff for stgit: -- haven't gotten through to the stgit ml yet about t/
<yang>Does Guix have a package management similar to some other distributions (apt-get, rpm) ?
<yang>or just a very unique one ?
<DusXMT>yang: It's similar to Nix (it even uses some code from Nix, namely the nix daemon), Guix build packages (or downloads them from our build farm) into a global store of packages (in /gnu/store, for example) and it then links them into the user's personal package profile (packages directly used by the user)
<yang>So Nix is neither apt-get, neither yum/rpm package management ?
<ewemoa>definitely not :)
<DusXMT>yang: Indeed.
<DusXMT>yang: Guix itself compiles instructions into a format the Guix daemon (or Nix daemon, if you please) can understand (a so-called derivation), and it then compiles the given package in an isolated chroot with only its dependencies available to it from /gnu/store. It uses the RPATH field of ELF binaries to specify exactly which versions of libraries to use from the store
<DusXMT>The daemon compiles, I meant to say
<yang>Thanks for explanation
<DusXMT>no problem :)
<DusXMT>yang: Even regular users can use Guix for personal package management without logging in as root, as it compiles their request, sends it to the daemon via a socket, and then puts links to the freshly-built packages in /gnu/store to the user's ~/.guix-profile
<mark_weaver>ewemoa: looks great! a few more comments:
<mark_weaver>iiuc, you shouldn't need to add python-2 to 'inputs' explicitly, because it is automatically added by 'python-build-system'.
<mark_weaver>you might want to use the new 'modify-phases' syntax for phases instead of 'alist-cons-after'
<mark_weaver>in the
<mark_weaver>in the license comment, s/gpl != 2/gpl2+/
<mark_weaver>otherwise looks great to me. can you make a proper git commit with changelog conforming to our conventions and post it to guix-devel ?
<mark_weaver>oh, one more thing: you should add a copyright line for yourself to the file :)
<davexunit>morning #guix
<mark_weaver>greetings, davexunit!
*davexunit is going to hack 'guix environment' to be usable as an interpreter for scripts
<davexunit>cool new feature in nix-shell
<mark_weaver>davexunit: we might need to make it a different command, since the shebang will be run as <command> <arg-in-shebang> <file>
<mark_weaver>and for guix environment that syntax would interpret <file> as a package name.
<mark_weaver>but yeah, sounds like a great feature
<davexunit>I feel like we could make it work with an additional option switch
<davexunit>#! guix environment emacs --foo
<mark_weaver>shebangs can only have one argument
<davexunit>there's an example of nix-shell in there
<mark_weaver>iiuc, "#! guix environment emacs --foo" would run: guix "environment emacs --foo"
<mark_weaver>i.e. "environment emacs --foo" as a single argument
<davexunit>so this won't be nearly as easy as I thought
<davexunit>will punt for now
<mark_weaver>it's not a big deal, it just needs another command. but that command could be extremely minimal, just tail calling into 'guix-environment' with some more arguments.
<mark_weaver>maybe 'guix shell' or something
<mark_weaver>anyway, I'm going to try to get a bit more sleep before the kids wake up :)
<mark_weaver>happy hacking!
<rekado>re ardour's "phone home feature": it can be disabled by starting ardour with "-a" or "--no-announcements"
<davexunit>I think I'm going to add a new option to 'guix environment' to allow for using the packages that are needed for a build system.
<osmano807>What file systems are supported on GuixSD?
<davexunit>osmano807: everything the kernel supports.
<davexunit>I think our biggest limitation WRT file system management right now is the lack of LVM
<davexunit>which will happen eventually, but it's not ready yet.
<fchmmr>Can someone read over this text, to make sure that all of it is accurate?
<fchmmr>(just the notes about Guix)
<osmano807>davexunit: So btrfs is supported, right?
<osmano807>In fact I will try to install on a disk with ZFS already, and I'm still a little confused where I add packages to the initrd necessary to mount.
<davexunit>osmano807: section 6.2.11 of the manual has documentation
<davexunit>there's a base-initrd procedure that you can pass an #:extra-modules keyword argument to.
<davexunit>fchmmr: I think the technical info is correct. I would just s/GSD/GuixSD/
<davexunit>since it is officially the Guix System Distribution, not the GNU System Distribution.
<fchmmr>Yes, GSD makes people think it's GNU
<fchmmr>ok, done
<davexunit>that was fast :)
<ewemoa>mark_weaver: thanks for the feedback, will investigate -- rest well :)
<fchmmr>It's funny, because I know Guix is said "geeks", but I still say "goo ix" in my head when reading it.
<ewemoa>here's an attempt at clojure:
<fchmmr>It's a bad habit.
<fchmmr>Because I already read it that way for so long, until someone corrected me.
<fchmmr><davexunit> that was fast :)
<ewemoa>i find it confusing to pronounce it "geeks" -- quite confusing
<fchmmr>Here's how I update the pages on
<fchmmr>* modify the docs in libreboot.git (my local clone)
<fchmmr>* commit
<fchmmr>* push
<DusXMT>ewemoa: It's from French
<fchmmr>* website is just a clone of the git repo: I ssh into it and run "git pull"
<fchmmr>it's super easy.
<osmano807>davexunit: The problem is that it is necessary to include some binary also in the initrd (kinda like fsck for ext*).
<fchmmr>I can very quickly update the live version of the site this way.
<fchmmr><fchmmr> * website is just a clone of the git repo: I ssh into it and run "git pull"
<fchmmr>then when you refresh the page, the change is visible
<osmano807>For now I think I'll just modify linux-initrd.scm
<ewemoa>DusXMT: ah, so may be i can disambiguate by trying to say it w/ a french accent?
<DusXMT>I myself read it "goo-ee-chs", because it just seems so much more natural... I tried to convince myself to start reading it geeks, but it didn't last long...
<davexunit>osmano807: you can write a custom initrd script
<davexunit>but you'll have to learn a bit more how to use our programming APIs
<davexunit>ewemoa: wo!
<davexunit>wow, even!
<lf94>I'm surprised Guix doesn't support i386...haha
<alezost>lf94: if you mean a 32-bit system, then it is supported
<alezost>is i386 and i686 the same thing?
<DusXMT>alezost: not technically
<mark_weaver>i686 won't work on a 386/486/586
<alezost>ok, apparently my knowledge is poor on that subject
<DusXMT>But practically, you can't run linux on an i386 (nor a 486)
<mark_weaver>DusXMT: oh, did Linux (the kernel) drop support for those?
<DusXMT>mark_weaver: [TheFlash] on #gnu mentioned that recent Linux kernels no longer work on 486 machines, since they use some instructions which I don't remember
<DusXMT>The only practical problem of compiling for i686 is then that Pentium (1) computers are not supported
<mark_weaver>well, the 586 was introduced 22 years ago, so :)
<lf94>Sorry, didn't realize Guix and GuixSD are two different things!
<lf94>GuixSD and NixOS look like serious competitors to debian if they can get the package counts up
<davexunit>lf94: yes indeed. help wanted!
<rekado>what makes it a little more difficult for us to increase the number of packages is that we want to build from source all the way down.
<rekado>it was a surprise to me to see just how many circular dependencies there are.
<davexunit>yeah, there are tons.
<davexunit>I've ranted enough about how many there are in ruby.
<lf94>Oh, there are no binary packages in GuixSD?
<davexunit>there are.
<davexunit>but those are built from source
<davexunit>by us.
<davexunit>by an automated process.
<davexunit>any user could do the same. the binaries are simply an optimization.
<lf94>Why would it be more difficult, though?
<lf94>Anyways, a more important question
<davexunit>I don't understand your question.
<lf94>Why is NixOS...seemingly...more popular than GuixSD?
<davexunit>it's been around longer
<davexunit>much longer
<lf94>Also everyone is saying guix uses nix at its core...but do they mean its algorithm, really?
<davexunit>our maintainer was a nixos hacker before starting guix
<lf94>Or are they both written in Guile?
<davexunit>nix uses no guile code.
<rekado>lf94: the daemon is written in C++
<davexunit>we use the same low-level file formats as nix
<davexunit>and we currently use their build daemon, written in c++
<lf94>Why did he abort from the nix project?
<lf94>Is there something proprietary about it?
<davexunit>there are a few reasons, but I don't know exactly why.
<lf94>If NixOS and GuixSD provide the same level of freedom...looks like duplicate work between parties to me.
<davexunit>one reason is definitely that nixos is not dedicated to including only free software in their distro
<davexunit>but there are other technical reasons
<rekado>as far as I could see Nix doesn't consistently take the "build everything from source" approach seriously.
<rekado>this can be seen in Java libs, for example, iirc.
<parolang>I thought that the point is that scheme is more expressive than the nix language.
<davexunit>rekado: they don't, unfortunately. I've found several packages that just download a prebuilt binary.
<davexunit>parolang: yes.
<lf94>Well Scheme is a whole language whereas NIH (?) is a DSL. You can't really compare them.
<rekado>as davexunit wrote "there are a few reasons".
<davexunit>our argument is that it's better to use an existing general purpose programming language that supports embedded domain specific languages.
<rekado>lf94: Guix doesn't use "just Scheme" but provides an embedded DSL.
<davexunit>Scheme and its macro system fit that.
<lf94>Yeah yeah, ok
<lf94>What's wrong with using pre-built binaries?
<davexunit>lf94: they are unreproducible.
<lf94>Can I not easily use, say, Oracle java libraries with Guix?
<rekado>and you're putting trust into whoever maintains those binaries.
<davexunit>in that particular example, they might work, but not sure.
<lf94>Well if you setup a package for it, would it?
<rekado>you can use Java libraries with icedtea6 and icedtea7 in Guix, as far as I tried.
<lf94>I don't know how any of this works really
<lf94>Ok, that's good
<rekado>(the OpenJDK is provided by icedtea6 and icedtea7)
<davexunit>lf94: well if you write a guix package it would work fine, yeah.
<davexunit>the issue is *third-party* pre-built binaries
<lf94>Well for security and non-freedom reasons, right?
<davexunit>the binaries that you may download via guix are backed by a *full* representation of precisely what was used to build it.
<lf94>I might give GuixSD a go for its money then :)
<davexunit>the full dependency tree all the way to down to glibc
<rekado>lf94: note that you can also try Guix as a package manager first.
<davexunit>no one but Nix and Guix can give you that right now.
<lf94>LISP-like languages are really popping up everywhere for me
<davexunit>Debian is making admiral efforts with the reproducible builds project.
<davexunit>but they still have many other technical problems with dpkg
<lf94>I want to use Guix for, what seems to be, easy support for multiple glibc
<lf94>Also, versions of X.
<davexunit>multiple anything, really.
<davexunit>at work, I use the guix package manager on top of an ubuntu host.
<lf94>I need X 1.12 for an ATI binary driver. On debian there is no way unless I go back to Debian squeeze.
<davexunit>so I have the latest and greatest emacs, git, guile, ruby, etc.
<lf94>But I still need packages like NodeJS...
<davexunit>we have a nodejs package
<lf94>Oh? It can work like that?!
<davexunit>and npm "just works"
<lf94>Yeah I'm going to create a list of things I use often and see if GuixSD provides them
<davexunit>ideally, of course, all the node packages would be part of the guix package repo.
<lf94>Is there an online package browser?
<davexunit>packages are being added with rather rapid pace
<lf94>Aw yea!
<lf94>Is there an API for this?
<davexunit>if something is missing for you, let us know + attempt to package it yourself :)
<davexunit>lf94: no but there should be. you can have your own API by building the guix source, though ;)
<davexunit>all of the packages are first-class Scheme objects
<lf94>Oh ok
<davexunit>it would be cool if we could host a more detailed package list online.
<davexunit>with full dependency information and such
<lf94>Well I do web development as my main source of work so this actually would be something fairly straight forward
<lf94>I'll install Guix in a VM or something and see how I can pull package information
<lf94>How is this list updated?
<davexunit>I also do web development for a living.
<davexunit>lf94: packages are bundled with the guix source
<lf94>How do I see what previous versions are available?
<davexunit>as scheme modules
<davexunit>you won't see previous versions
<lf94>But they're there?
<davexunit>they could be installed on someone's machine, but the version of guix you are using might not have a package object for it anymore.
<zacts>hm... /me checks the mailing list, but has there been any progress recently towards the goal of a Full Disk Encrypted GuixSD install?
<davexunit>I think we need a champion for it :)
<zacts>I guess I could work on this. :-)
<zacts>what where the main issues preventing this again?
<zacts>I guess I could try to solve them...
<zacts>I do have a spare computer to do this with too
<lf94>Well there's one package not in GuixSD yet - zim.
<lf94>That appears to be it though!
*davexunit struggles to get libzdb to build
<davexunit>thought I'd try to get the seafile stack packaged
<davexunit>but the configure script is telling me that it's not certain functions aren't conforming to c99
<davexunit>no idea what's going on
<civodul>Hello Guix!
<davexunit>hey civodul
<zacts>hm... I gues I'll hit the mailing lists with a few questions on issues with Full Disk Encryption
<zacts>(although, after I look into it first of course)
<osmano807>So to create a custom GuixSD install image I need qemu, for it to run qemu with KVM. Kinda annoying.
<DusXMT>osmano807: I installed GuixSD on Qemu with the installer image...
<DusXMT>Just mount it as a second harddrive
<DusXMT>eg. qemu --enable-kvm -m 1024 -hda disk.qcow2 -hdb /path/to/installer.img -boot menu=on
<civodul>zacts: could you look at ?
<civodul>and maybe email with additional "findings" :-)
<osmano807>DusXMT: I expressed myself badly. To create a custom installation image, guix system disk-image _runs_ qemu.
<DusXMT>Oh, now I see, I misread...
<DusXMT>I think I remember being able to just guix system init the appropriate file and have an installation medium like that
<DusXMT>gnu/system/install.scm should be the file if I remember correctly
<bavier`>civodul: would you like me to send the last of the hydra patches to the list?
<igor80>hi. i've tested guixsd usb install with qemu-kvm on debian 7.8. share it there
<igor80>0. new guixsd.qcow2 disk image 8G with a partition labeled "root" and swap
<igor80>1. kvm -vga std -m 512 -boot menu=on,splash-time=5000 -usb -usbdevice disk:guixsd-usb-install-0.8.2.x86_64-linux guixsd.qcow2
<igor80>2. 5 seconds to press F12 key then select boot device 2 usb
<igor80>3. wait, usb in qemu is slow. be patient
<igor80>4. for whatever reason, network is down. wake up with dhclient -6 ens3
<igor80>5. then dhclient ens3
<igor80>6. edit desktop config file with sda instead of sdX and user info
<igor80>7. following the manual without troubles
<igor80>8. wait again, it's downloading
<igor80>9. the installation is done
<igor80>10. reboot
<igor80>11. give some entropy with your keyboard till the end of the line ---
<civodul>bavier`: either that or you can push them directly, whichever seems more appropriate to you
<civodul>igor80: so you're saying the installation went rather smoothly, right? :-)
<igor80>exactly, given the network wake up thing
<civodul>yeah networking is completely manual in the installation image
<civodul>well thanks for the report
<igor80>i had to pass -6 to wake it up really
<igor80>guix is really a great work :-D
<igor80>cirrusfb was weird (linux 4 maybe) that's why i switched to -vga std
<igor80>i got a vm 644 MB i would like to share. any suggestion?
<civodul>ah yeah, we use -vga std normally
<civodul>you mean you want to share the VM image you produced?
<civodul>ok, not sure how this could be done
<civodul>but it would certainly be useful for people who want to test
<amz3>I need to rename a file (and add it to GNU_SYSTEM_MODULES) should I do two patches and two mails with [1/2] Add st. [2/2] Move dwm.scm to suckless.scm
<zacts>civodul: oh cool thanks
<zacts>re: encrypted root bug ML
<davexunit>amz3: is st already in the current module?
<davexunit>if so, just move the whole thing.
<davexunit>otherwise, what you said sounds good to me.
<amz3>ok thx
<bavier`>oh, nix released 1.9 yesterday
<bavier`>I think we could take a more recent hydra commit in that case, but I think I'll worry about that later
<mthl>I would like to know if anyone manage to update menus semi 'automatically' while editing the manual in emacs?
<civodul>bavier`: Hydra is pretty much separate from Nix, so that's fine
<civodul>which reminds me that we need to update hydra-eval-guile-jobs, in Hydra
<civodul>it must emit JSON instead of XML now
<civodul>any takers? :-)
<davexunit>,enter-store-monad is awesome
*davexunit is building ruby 2.1.6 and running a new 'gem-with-ruby' procedure to transform packages like 'package-with-python2' does
<zacts>what is enter-store-monad?
<davexunit>zacts: a meta command that guix adds to the REPL
<davexunit>so you can evaluate things in the context of the store
<zacts>oh cool
<civodul>davexunit: the only problem is that Geiser doesn't record the history for nested REPLs
<civodul>so M-p doesn't DTRT
<anthk_>can I define fstab mount options on the scm config file?
<civodul>anthk_: you can add 'file-system' objects to the 'file-systems' field
<civodul>which is similar
<civodul>so, depends on what you want exactly
<amz3>anthk_: have a look at
<amz3>there is no coloration :/
<anthk_>civodul I mean mount options
<anthk_>like noatime and such
<civodul>anthk_: you can pass them in the 'options' field of a 'file-system' object: