IRC channel logs
2015-06-13.log
back to list of logs
<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 packages more ruby libraries *davexunit dumps 8 patches on the list <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 <zacts>do you guys usually use wicd to configure wifi on guix, or what do you use? <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. <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. <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? <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. <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 ? <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 <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>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>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 is going to hack 'guix environment' to be usable as an interpreter for scripts <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. <davexunit>I feel like we could make it work with an additional option switch <mark_weaver>iiuc, "#! guix environment emacs --foo" would run: guix "environment emacs --foo" <davexunit>so this won't be nearly as easy as I thought <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>anyway, I'm going to try to get a bit more sleep before the kids wake up :) <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. <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? <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 <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. <fchmmr>Because I already read it that way for so long, until someone corrected me. <ewemoa>i find it confusing to pronounce it "geeks" -- quite confusing <fchmmr>Here's how I update the pages on libreboot.org: <fchmmr>* modify the docs in libreboot.git (my local clone) <fchmmr>* website is just a clone of the git repo: I ssh into it and run "git pull" <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 <lf94>I'm surprised Guix doesn't support i386...haha <alezost>lf94: if you mean a 32-bit system, then it is supported <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 <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 <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>I've ranted enough about how many there are in ruby. <lf94>Oh, there are no binary packages in GuixSD? <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 <lf94>Why is NixOS...seemingly...more popular than GuixSD? <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? <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 <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. <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. <lf94>What's wrong with using pre-built binaries? <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 <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 <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... <lf94>Oh? It can work like that?! <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>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 <davexunit>it would be cool if we could host a more detailed package list online. <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>lf94: packages are bundled with the guix source <lf94>How do I see what previous versions are available? <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? <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 <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>and maybe email 19190@debbugs.gnu.org with additional "findings" :-) <osmano807>DusXMT: I expressed myself badly. To create a custom installation image, guix system disk-image _runs_ qemu. <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>6. edit desktop config file with sda instead of sdX and user info <igor80>7. following the manual without troubles <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 <igor80>i had to pass -6 to wake it up really <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>you mean you want to share the VM image you produced? <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 <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 *davexunit is building ruby 2.1.6 and running a new 'gem-with-ruby' procedure to transform packages like 'package-with-python2' does <davexunit>zacts: a meta command that guix adds to the REPL <davexunit>so you can evaluate things in the context of the store <civodul>davexunit: the only problem is that Geiser doesn't record the history for nested REPLs <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>so, depends on what you want exactly <amz3>there is no coloration :/