IRC channel logs

<codemac>is there a way to get dmd to log to stdout only?

<codemac>would like to run it as a daemon underneath `systemd --user`, and have it's logs just go to the journal.

<davexunit>yesss I found the race condition

<davexunit>now, to deal with it...

<davexunit>finally. container-excursion test is fixed!

<davexunit>container patches are almost done. need to add a test and tweak (gnu system linux-container) and I'm done.

***tschwing_ is now known as tschwinge

<phant0mas>mark_weaver: I on the other hand got a crashed vm last night and had to rebuild guix inside the hurd vm

<phant0mas>did a cleanup

<phant0mas>I will reply to the mail

<mistnim>there is this link on the contribute page that leads to a 404: http://schemers.org/Documents/#intro-texts

<rekado_>sneek: later tell davexunit I'm now using "guix environment --ad-hoc" rather than loading it from the env.scm file.

<sneek>Got it.

<rekado_>sneek: later tell davexunit Yay for finding the the race condition!

<sneek>Got it.

<jmd>From www.gnu.org today: "For Guix to work, the Novena board needs a kernel option that is disabled by default. So before installing Guix, one needs to rebuild a kernel, which is amazing."

<jmd>Why is it so amazing? Isn't that normal?

<rekado_>jmd: "one needs to rebuild a kernel, which is amazingly easy using a check-out of the official Novena Linux kernel sources and a script also provided by the project."

***francis7 is now known as botbottle

***botbottle is now known as francis7

***francis7 is now known as fchmmr

***fchmmr is now known as francis7

***schjetne` is now known as schjetne

<davexunit>morning guix

<sneek>Welcome back davexunit, you have 2 messages.

<sneek>davexunit, rekado_ says: I'm now using "guix environment --ad-hoc" rather than loading it from the env.scm file.

<sneek>davexunit, rekado_ says: Yay for finding the the race condition!

<Jookia1>davexunit: morning! the gnu planet talked about the novena kernel needing patching - does this mean there's someone out there running a novena port of guix? ;)

<davexunit>Jookia1: you can run guix (the package manager, not the distro) on ARMv7 machines, yeah.

<davexunit>I need to recompile the kernel for myself and play with my Novena more.

<Jookia1>davexunit: what's blocking guixsd on arm?

<davexunit>not sure exactly, but the bootloader is definitely one thing.

<Jookia1>i'm planning to do some work on the novena bootloader

<Jookia1>u-boot is getting syslinux support which would save a LOT of effort

<mistnim>I have a problem, I can't change my wireless card mac address with "ifconfig device hw ether", it says the card can only have on address

<mistnim>but this same command works on every other distro

<toothbrush0>hey! I seem to be running into weirdness with the Guile `mkstemp!` procedure...

<mthl>mistnim: Thanks for reporting the URL problem.

<davexunit>mistnim: I don't know much about this stuff, but I do know that we are using roughly the same ifconfig that you'd be running anywhere else.

<toothbrush0>A package wants to use (substitute* "dir/file" ..) but i get a backtrace complaining of an error in `mkstemp!`, saying "Not a directory"...

<davexunit>toothbrush0: sounds like the file name is wrong?

<toothbrush0>davexunit: when i do ./pre-.. guix build -K signing-party, all looks well in /tmp/nix-...

<toothbrush0>i'm trying to investigate what changed upstream since it used to work with an older version

<mistnim>I god disconnected, sorry if somebody answered please send again

<mthl>mistnim: https://gnunet.org/bot/log/guix

<davexunit>mistnim: no new messages

<mistnim>ok thanks

<mistnim>so you have no idea what might be the problem? I can't connect at all, since my wifi connection allows me only one mac

<toothbrush0>davexunit: found something: looks like the directory structure changed between the two versions. as in, it used to be tar:/signing-party-v../stuff, whereas now it seems to be tar:/stuff

<haypo>hi. i would like to try the guix program, but i fail to install it

<mistnim>can you test on your machines if "ifconfig devince hw ether newmac" works for you?

<haypo>i downloaded the binary tarball, but it looks to require a chroot to run. guile ELF doesn't work, and guix fails at start (after installing guile on my fedora)

<haypo>i'm now trying to compile guix, but it requires a lot of dependencies. i would help to have a single command to install all dependencies on fedora

<haypo>or better... have a fedore package for the guix program!

<Steap>Did you follow http://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html when you tried the binary install ?

<haypo>it's something like: sudo dnf install guileguile-devel bzip2-devel sqlite-devel gcc-c++

<haypo>Steap: ah? i missed the link to the doc

<Steap>maybe try this

<Steap>I've never tried the binary install, to be honest

<haypo>Steap: hum, i don't want to untar from /

<haypo>as root

<davexunit>inspect the tarball

<davexunit>you'll see that it's safe.

<davexunit>not going to destroy /usr or something

<haypo>davexunit: i trust guix. but i want to be able to uninstall it easily. not have to dig the tarball to see which directories were created

<Steap>well, at least it should not.

<davexunit>haypo: sure. would you like to build an rpm package?

<Steap>you'll end up with /gnu anyway

<haypo>davexunit: nope, sorry

<Steap>haha

<davexunit>okay. I would recommend that you try out the binary installer, then. uninstallation is quite easy, as almost all data is kept in /gnu

<davexunit>you can nuke that directory and /var/guix (I think) and be done with it.

<haypo>i compiled guix from sources. i had to create the /gnu directory

<haypo>haypo@smithers$ /opt/guix/bin/guix package -i python

<haypo>guix package: error: build failed: unable to fork: Operation not permitted

<Steap>haypo: are you running the daemon as root ?

<Steap>It's one of the limitations.

<davexunit>yeah, sounds like the daemon isn't running as root.

<haypo>Steap: the daemon is not running as root

<Steap>The daemon must run as root, but guix can be run as a normal user

<haypo>"The daemon must run as root" the daemon should at least emit a warning at startup

<davexunit>the daemon needs to be root in order to create containers.

<haypo>or exit with an error

<Steap>That seems like a valid point.

<davexunit>haypo: patches welcome.

<haypo>haypo@smithers$ sudo /opt/guix/bin/guix-daemon

<haypo>warning: daemon is running as root, so using `--build-users-group' is highly recommended

<davexunit>to be precise, the daemon doesn't *have* to be run as root, but you really want to run it as root.

<haypo>davexunit: no, i don't want to run it as root :)

<davexunit>if you don't run it as root, you get no isolation.

<Steap>davexunit: yeah, it's unclear to me why we couldn't have everything running as a single user

<davexunit>Steap: we need isolation to prevent build processes from escaping their jails.

<Steap>haypo: http://www.gnu.org/software/guix/manual/html_node/Build-Environment-Setup.html#Build-Environment-Setup

<Steap>davexunit: can we only get that by running as root ?

<davexunit>yes.

<davexunit>currently.

<Steap>oh ok

<Steap>"currently" is the key :)

<davexunit>that's the state of Linux.

<haypo>"/opt/guix/bin/guix package -i python" looks to download the world (well, bootstrap its world)

<Steap>do we have doc on this ?

<Steap>haypo: yep

<davexunit>yeah it's in the manual somewhere.

<Steap>I must say it is quite a pain to download the world, but you do not do that every day

<davexunit>haypo: yes, guix contains a full depdency tree.

<davexunit>haypo: make sure you've authorized hydra.gnu.org for downloading pre-built binaries

<Steap>The main issue is when hydra.gnu.org is down and you end up compiling all that on your laptop

<haypo>ok, i give up today for guix. it looks much more complex to install from what i expected :-p

<davexunit>well, it seems you haven't actually read our installation instructions...

<haypo>sorry i don't want to spend my afternoon on it. it was just to give a short try. i don't know guix at all :)

<haypo>i'm not going to install this stuff on my fedora

<haypo>it looks more like a complete OS

<Steap>haypo: it is meant to be a complete OS :D

<toothbrush0>haypo: I hope nobody will shoot me for the comparison, but from a very far distance, it's perhaps comparable to Homebrew on OS X, but much nicer... (when installed on top of another running distro, that is)

<bavier>GuixSD ;)

<Steap>haypo: some people use it on top of an existing distro

<haypo>toothbrush0: homebrew is required on OS X because it's hard to install common Linux software (ex: python) on OS X. but i already have dnf on my fedora

<Steap>what is dnf btw ?

<toothbrush0>the comparison is flawed. all i was getting at was that it can function as a "parallel" package manager :)

<haypo>Steap: https://fedoraproject.org/wiki/Features/DNF the new yum

<haypo>"a new package management library built on top of libsolv"

<haypo>FYI yum became an alias to dnf in fedora 22

<Jookia1>will guix have binary ARM packages?

<davexunit>Jookia1: no, we need donations of ARM machines for our build farm.

<Jookia1>davexunit: hmm, what if ARM users just build packages and send them off? i imagine that could help for giant packages

<davexunit>Jookia1: that wouldn't work.

<davexunit>we need packages to be built constantly for continuous integration purposes

<toothbrush0>Hm, okay. I've come to the conclusion that the `unpack` phase is breaking: in gnu-build-system.scm line 144 after doing "tar xvf" it tries to do a `(chdir (first-subdirectory "."))`, but that doesn't work for a particular package. How can i prevent that?

<Jookia1>davexunit: aww, i see.

<davexunit>we don't do "maintainer uploads" like debian and others

<jmd>davexunit: That's because we don't have "maintainers"

<davexunit>toothbrush0: you can replace that phase

<toothbrush0>right.

<toothbrush0>i'll poke around for examples. thanks davexunit

<davexunit>jmd: the point is that people don't build stuff and upload the results.

<jmd>no.

<davexunit>because that leads to unreproducibility.

<davexunit>toothbrush0: look for 'modify-phases' in the package recipes

<davexunit>(modify-phases %standard-phases (replace 'unpack (lambda ...)))

<jmd>It would also be asking for security issues.

<davexunit>yes

<davexunit>tainted binaries

<jmd>But do other distros work like that? Surely not.

<davexunit>I imagine they are moving away from it

<davexunit>but debian has maintainer uploads

<davexunit>and I know for sure that people that run their own package repos build the packages on some machine of theirs and upload them to the repo.

<Jookia1>yikes

<davexunit>a CI system might build them, but there's still similar issues

<davexunit>different results depending on which machine builds it

<Jookia1>with guix you'd get the same package derivation hopefully

<davexunit>often you do.

<davexunit>still work to be done to approach 100%

<Jookia1>is this a guix-specific problem

<davexunit>reproducibility? no.

<davexunit>guix is a solution for the problem.

<Jookia1>i mean, compared to nixos

<davexunit>I'm not sure what the question is.

<davexunit>what do you mean by "problem"?

<Jookia1>oh soryr

<Jookia1>sorry*

<davexunit>it's okay. just trying to understand.

<Jookia1>i'm a bit half-asleep :P with guix you don't get the same package derivation 100%, to my understanding it's based on nix - is this a problem specific to guix or do they share it?

<davexunit>it's the same for nix.

<davexunit>we can't guarantee bit-for-bit reproducibility right now.

<Jookia1>ah. oh! i don't mean binary reproducitbility, i mean the derivation

<Jookia1>unless guix uses different terminology, the derivation is the sum of the dependencies's packages and its package

<davexunit>I don't follow.

<davexunit>that's not an issue.

<davexunit>it's the build processes.

<Jookia1>ah, i thought so

<Jookia1>i have a kind of newbie question with that actually, to my knowledge guix uses lisp. how is purity enforced?

<davexunit>well now you need to be more specific: "purely functional package management" is different than "purely functional programming".

<davexunit>are you talking about purity in the build environments or in the code?

<Jookia1>the code. is there anything stopping me from writing in the guix package that a random numeral or IO be used?

<Jookia1>be used to build the package and affect the results, that is

<davexunit>you could do that.

<davexunit>just like some build script could do the same

<davexunit>in a makefile

<Jookia1>ah, i see

<Jookia1>i apologize for the oblivious questions

<davexunit>no problem

<davexunit>guile is multi-paradigm. you can write imperative code with it just as well as functional code.

<Jookia1>exciting!

<Jookia1>i haven't learned a scheme before, is guile a good one for beginniners?

<davexunit>yes

<alezost>mistnim`: I know nothing about ifconfig, but I heard it hasn't been actively maintained for many years, so just a wild guess: perhaps other distros have some patch for this problem that we don't have.

<alezost>Perhaps "ip link set <device> address <address>" will work ("ip" is from "iproute2" package)

<davexunit>mark_weaver, everyone: https://www.openssl.org/news/secadv_20150709.txt

<Jookia1>davexunit: that looks like a variant of the old chain of trust attack

<davexunit>our openssl version is affected.

<rekado_>haypo: reading the installation instructions does not take a whole afternoon. I know because I did read them. If you want to try guix I recommend you read the instructions. (You don't have to read the whole manual.)

<rekado_>considering that ngs-sdk explicitly checks for i?86 or x86_64, should I add a supported systems field to avoid building it on other systems?

<KonaHumper>hello

<mark_weaver>davexunit: the container tests fail on my Libreboot X200 running GuixSD

<mark_weaver>tests/containers.scm:71: FAIL call-with-container, all namespaces

<mark_weaver>any idea?

<mark_weaver>hi KonaHumper!

<mark_weaver>davexunit: bah, thanks for letting me know about the openssl thing.

<KonaHumper>mark_weaver: you installing on an x200 as well? I'm just about to switch from slackware

<mark_weaver>KonaHumper: I'm a core Guix developer, and have been running GuixSD on the Libreboot X200 (and X60 before that) for a long time.

<mark_weaver>I wonder if we should just switch to libressl while we're at it.

<KonaHumper>Oh sweet

<mark_weaver>well, maybe better to wait on that in case there are problems. I want to roll out this fix asap.

<toothbrush0>mark_weaver: i'm sorry, i managed to fat-finger and as a result pushed the libgpg-error update anyway :(

<toothbrush0>i meant to push N-1 patches, but i sent all N

<toothbrush0>i hope i didn't seriously screw anything up?

<toothbrush0>bottom line: i must be more careful with magit. I did P (pushing) then -d (for dry run) then P again to push, but i didn't press the '-' properly and therefore the d wasn't recognised, and the subsequent P pushed everything in the queue :( *facepalm*

<mark_weaver>toothbrush0: I reverted it, no worries.

<mark_weaver>thanks for letting me know.

<toothbrush0>thank you very much mark_weaver

<toothbrush0>how does that work, and how much leeway (in terms of time) is there?

<mark_weaver>well, there's always a chance that hydra will create a new evaluation in between the unwanted change and the revert, in which case it will trigger a lot of builds.

<mark_weaver>but in this case I happen to know that hydra is now working on evaluating the new openssl-update branch.

<mark_weaver>there's also a chance that someone out there does a "guix pull" between the two, in which case they will end up having to rebuild a lot of stuff.

<mark_weaver>anyway, although of course you should try to be careful, don't worry about it so much. we all make mistakes.

<mark_weaver>thanks for the updates

<toothbrush0>ok, i see.

<toothbrush0>sorry about the hassle, and i'll treat magit with kid gloves from now on :/

<mark_weaver>heh :)

<KonaHumper>what's the procedure for choosing a different keyboard layout? I'm using a GB keyboard

<alezost>KonaHumper: if you mean for the X server, you can use setxkbmap for that

<alezost>KonaHumper: for the VT, there is 'loadkeys'; also we have "console-keymap" service

<mark_weaver>KonaHumper: if you use XFCE, then it looks like you can configure the keyboard layout by navigating from the applications menu -> settings -> keyboard

<mark_weaver>probably this could be made nicer somehow...

<KonaHumper>trying to use loadkeys, I can't seem to find the right one

<paron_remote>hello #guix!

<mark_weaver>loadkeys will only change it in the text consoles. you'll need to do something different in X anyway.

<KonaHumper>well I've not got xwindows up yet

<alezost>KonaHumper: what do you usually use on other distros

<KonaHumper>only just booted off usb

<KonaHumper>usually en_GB

<KonaHumper>OH

<KonaHumper>it's called UK in this directory

<mark_weaver>KonaHumper: "loadkeys uk" is probably what you want.

<KonaHumper>yeah perfect

<KonaHumper>thanks!

<paron_remote>okay so

<paron_remote>davexunit: turning on my guix setup

<paron_remote>today is guixops helping day

<paron_remote>davexunit: should I look at the container stuff or wip-deploy?

<alezost>KonaHumper: Alternatively, instead of using "loadkeys uk" after every boot, you may put (console-keymap-service "uk") into your system declaration

<mark_weaver>KonaHumper: right, in the 'services' field.

<KonaHumper>alright I'll have to note that down

<KonaHumper>also, I've tried using wpa_supplicant to connect to the wireless but i'm getting "nl80211: driver does not support authentication/association or connect commands"

<KonaHumper>I'm guessing this is needing specific drivers for this card?

<mark_weaver>hmm, dunno

<mark_weaver>I normally use 'wicd' to manage the wireless network after installation, and that papers over a lot of issues like this.

<mark_weaver>during installation, would ethernet be an option?

<davexunit>mark_weaver: I would expect all of the tests to fail, not just that one.

<KonaHumper>not up here, I could run downstairs and plug her in though

<KonaHumper>will have to run back up to chat though

<mark_weaver>does your wireless card require uploading a non-free blob?

<davexunit>mark_weaver: there's likely a syscall that returns non-zero. mount, clone, pivot_root, something.

<KonaHumper>I don't recall having to download one for slack

<mark_weaver>well, slack probably just comes with all of them already

<KonaHumper>likely yeah

<mark_weaver>what kind of wireless device is it?

<mark_weaver>GuixSD is a 100% free distro, so to blobs included.

<mark_weaver>*no blobs included

<KonaHumper>It's an x200 so I suspect it's an intel one

<mark_weaver>ah yes

<KonaHumper>arch wiki says Intel PRO/Wireless 5100/5300 AGN

<mark_weaver>KonaHumper: I recommend installing Libreboot and then installing an Atheros card.

<KonaHumper>alright

<mark_weaver>the folks on #libreboot can help you with that

<KonaHumper>gonna go afk for a sec

<paron_remote>okay

<paron_remote>davexunit: just read through the code in the wip-deploy branch

<paron_remote>it's less code than I expected, which isn't bad! :)

<paron_remote>davexunit: I think you said it needs to be rebased on top of master. Should I try to produce a patch for that?

<paron_remote>it looks like that'll be easy.

<davexunit>paron_remote: hopefully won't need any patching, but maybe.

<davexunit>go for it.

<davexunit>:)

<paron_remote>davexunit: how can I be most helpful right now?

<paron_remote>davexunit: I'm asking a friend who works on openstack for their dayjob how to best build an adapter for it

<paron_remote>davexunit: they expressed interest in guixops btw

<paron_remote>they're "breton" on irc

<paron_remote>a mediagoblin hacker

<davexunit>ooh cool

<davexunit>paron_remote: I don't have a concrete "most helpful thing" right now. have you been able to successfully spawn local VMs with it?

<paron_remote>davexunit: about to do that :)

<paron_remote>I'm merging it with master first so I can use latest substitutes

<davexunit>please rebase instead of merging

<davexunit>to keep linear history.

<paron_remote>davexunit: okay :) there's a small merge that was necessary, but pretty easty

<paron_remote>davexunit: so I guess if I merged correctly I'll submit the updated patch to the list?

<davexunit>as long as there's no merge commit.

<paron_remote>davexunit: yeah there isn't one

<davexunit>okay cool

<davexunit>you were using 'merge' in another sense. got it.

<paron_remote>ACTION runs make :)

<paron_remote>davexunit: yes there were conflicts

<davexunit>okay

<paron_remote>I mean in the way that while rebase says "unmerged", but that's well established now :)

<paron_remote>or maybe just magit says that ;)

<paron_remote>ACTION compiles!

<davexunit>woo

<paron_remote> http://www.openstack.org/software/openstack-compute/ https://nixos.org/wiki/NixOS_and_OpenStack_Compute

<paron_remote>davexunit: my guess is this is what we want to integrate with

<davexunit>something like that

<davexunit>nova sounds right

<paron_remote>maybe time to steal ideas from https://github.com/openstack/python-novaclient

<paron_remote>probably this should become its own library for guile?

<davexunit>meh, don't worry about that part for awhile. :)

<davexunit>for simplicity, I'd like to focus on getting the basic adapter interface right by testing with local VMs and (soon) containers.

<paron_remote>davexunit: sounds good.

<davexunit>but yeah, we'll have to be thinking about openstack or other remote deployments.

<paron_remote>davexunit: oh, I'm getting a helpful intro from my friend

<paron_remote>I'm going to post it to the list

<paron_remote>on steps for doing openstack stuff with guix

<paron_remote>whoo done compiling guix with the rebased branch

<paron_remote>sent those notes to the list.

<paron_remote>hey breton :D

<paron_remote>breton: I just sent that email referencing our conversation to the list

<paron_remote>btw, introductions:

<paron_remote>breton, meet davexunit, the main hacker pushing guixops and guix deployment'y stuff right now

<paron_remote>davexunit, meet breton, mediagoblin hacker and current openstack hacker too

<paron_remote>breton: and welcome to #guix :)

<breton>hi :)

<breton>I don't think I can help too much now, because the component I work on (keystone) is very far from what you do. But I would love to hear questions so that I could find out something too.

<davexunit>breton: hello!

<amz3>hi :)

<amz3>ACTION random guix user

<davexunit>breton: I'm interested in learning the requirements for creating automated openstack deployment scripts.

<davexunit>to deploy GuixSD systems.

<breton>you want to deploy openstack automatically or deploy vms in openstack?

<amz3>breton: Does openstack support containers (like docker) ? and how? :)

<davexunit>breton: deploy vms on openstack.

<davexunit>amz3: it's for vms

<amz3>I heard about a container backend

<amz3>aws has support for docker

<davexunit>breton: deploying openstack would also be sweet, but that's a whole different topic. :)

<breton>amz3: I have not heard about something like that

<breton>davexunit: cool. Maybe you should have a look at Murano. Murano is an app catalog that installs, say, apache, to a vm.

<davexunit>breton: guix has an API for declaratively describing operating system configs. I want to "realize" those configs on an openstack vm.

<davexunit>we can already do this with local qemu

<amz3> https://wiki.openstack.org/wiki/Docker

<breton>I can ask folks how murano works

<davexunit>breton: are you saying that Murano can be inspiration? I wouldn't want to actually use that.

<breton>well, for inspiration and for example how it interacts with other openstack components. I'd say that guix will be a direct competitor for murano ;)

<davexunit>the stuff I gotta figure out: how to create the storage and VM, copy a GuixSD system closure to it, handle networking, etc.

<davexunit>breton: okay, I will take a look at it.

<davexunit>thank you.

<breton>a VM needs to run GuixSD so that something could be installed into it, right?

<davexunit>breton: that would be what was installed.

<davexunit>some guixsd image.

<davexunit>we have tools now that build raw disk images and qcow2 images suitable for use with kvm.

<breton>ok, I don't understand how guix works, but in openstack a vm is usually spinned up from an image (http://docs.openstack.org/image-guide/content/ch_introduction.html). You upload an image (raw, qcow2) to glance and tell nova to spin up a vm with the image.

<davexunit>okay

<davexunit>sounds like I want to upload qcow2 images, which we can already build.

<rekado>I have a luks device that I map in my system config with (mapped-devices ...), however, the system no longer boots as it's waiting for the decrypted device to appear.

<rekado>there should be a prompt for the passphrase on booting up.

<rekado>Is anyone here familiar with how to get this to work?

<mark_weaver>davexunit: I need to update the guix snapshot, but I'm having trouble finding a recent one that passes tests. I went back to 9f04196, which passes on my GuixSD laptop but its syscalls tests fail consistently on hydra: http://hydra.gnu.org/build/570166

<davexunit>damn it.

<mark_weaver>davexunit: might this have to do with syscalls you recently added? maybe they don't pass on older kernels?

<davexunit>mark_weaver: what kernel is hydra running?

<davexunit>if it can build guix packages it should be fine

<mark_weaver>davexunit: well, hydra.gnu.org is running 2.6.32, but the relevant thing here is the kernel running on the build slaves.

<davexunit>oh okay

<davexunit>2.6 is definitely too old, but yeah that's irrelevant if it's not building guix

<mark_weaver>but anyway, guix is supposed to support kernels down to 2.6.32

<davexunit>containers require 3.8 or newer. shall we detect kernel version and disable tests accordingly?

<davexunit>I didn't realize we were concerned with kernels that were so old.

<davexunit>I guess we never ran into such problems because the guix daemon doesn't create user namespaces.

<mark_weaver>davexunit: so, one of our build slaves is running 3.13, another is running 3.2

<davexunit>I wish this build log said which tests in tests/syscalls.scm failed.

<mark_weaver>somehow, we need to make it so that guix can build and pass tests with older kernels.

<davexunit>yes

<tyrion-mx>Hello, I am doing "guix system vm demo.os" (from ubuntu 14.04) but it says "failed to initialize KVM: No such file or directory". Do you have any idea?

<tyrion-mx>I also tried installing qemu-kvm

<davexunit>mark_weaver: can we programmatically determine the kernel version and skip the container tests if necessary?

<mark_weaver>tyrion-mx: the build users have to be able to access /dev/kvm. I would "sudo chmod 666 /dev/kvm"

<tyrion-mx>ok, thanks :)

<davexunit>mark_weaver: I'm sorry about the headache.

<mark_weaver>davexunit: no worries, I appreciate the work you've been doing

<mark_weaver>the problem I'm facing now is that I can't re-enable one of our build slaves (hydra.gnunet.org) until I update guix on hydra, and I can't update guix on hydra until I have a version that builds.

<tyrion-mx>mark_weaver, I have no /dev/kvm :O

<mark_weaver>and meanwhile we have this openssl update to rebuild, and it's going a lot slower than it could be.

<davexunit>mark_weaver: could you perhaps make a commit that disables the tests so you can update the snapshot

<davexunit>and then we'll revert it later?

<davexunit>and I or someone else will replace it with a test for the kernel version

<mark_weaver>tyrion-mx: "sudo mknod -m 666 /dev/kvm c 10 232"

<mark_weaver>tyrion-mx: hmm, although maybe you need to modprobe something...

<mark_weaver>tyrion-mx: what is the output of "lsmod | grep kvm" ?

<davexunit>tyrion-mx: your machine needs to support hardware virtualization

<mark_weaver>bah, this is a pain :-(

<davexunit>tyrion-mx: if you're running an intel machine, try: cat /proc/cpuinfo | grep vmx

<davexunit>to see if you have necessary requirements for kvm

<tyrion-mx>cat /proc/cpuinfo | grep vmx <- this produces nothing. I guess I don't have hardware virtualization

<tyrion-mx>my laptop really sucks

<tyrion-mx>I can still try using virtualbox, right?

<davexunit>tyrion-mx: virtualbox uses nonfree software these days so I don't recommend that one.

<tyrion-mx>:O

<amz3>tyrion-mx: try without vm

<tyrion-mx>I didn't know that

<amz3>guix not guixsd

<amz3>install it on top of ubuntu

<tyrion-mx>amz3, I already have guix installed, but I wanted to try a full graphic environment, to see if it could effectively replace my ubuntu

<tyrion-mx>davexunit, anyway the homepage of virtualbox says it is GPL ...

<mark_weaver>tyrion-mx: the BIOS used in virtualbox can only be built with a non-free compiler.

<amz3>tyrion-mx: try an usb disk

<mark_weaver>that's why it's not in debian's main repository

<amz3>never tried myself, but it's harmless

<tyrion-mx>and so, if parts of it are non-free how could it be released as GPL ?

<mark_weaver>it's not that parts of it are non-free, it's that it can't be *built* without non-free software.

<tyrion-mx>umh, ok

<tyrion-mx>that's a strange thing indeed, a free software that cannot be compiled :D

<mark_weaver>if you have build guix from source code, e.g. from the git repo, then you might be able to remove the kvm requirement by removing "-enable-kvm" from 'common-qemu-options' in gnu/system/vm.scm

<mark_weaver>but without kvm, the performance may not be good.

<tyrion-mx>nope, I did not :/

<mark_weaver>do you have a spare partition that you could install Guix

<mark_weaver>GuixSD on?

<tyrion-mx>no, but I could make one I guess

<mark_weaver>that's probably your best bet

<tyrion-mx>the problem is that I don't have an other pc, to browse the internet for the manual or troubleshooting :P

<tyrion-mx>can I install all the needed stuff from ubuntu into the partition and then try to boot ?

<mark_weaver>I would boot from the USB installer. the installation manual is automatically brought up in one of the virtual consoles in there.

<tyrion-mx>I dind't know about the USB installer, sweet

<mark_weaver>to prevent overwriting your main 'grub', put /dev/sdaN instead of just /dev/sda in the 'device' section of the 'grub-configuration'.

<tyrion-mx>thanks, for the advice, where N is the guixsd partition, correct?

<mark_weaver>right

<tyrion-mx>is the grub-configuration a step of the USB installer, or do I have to edit a config file?

<mark_weaver>you have to edit a config file. you need to do that anyway.

<tyrion-mx>ok, heading for the docs :)

<mark_weaver>tyrion-mx: does your wireless device need a blob?

<tyrion-mx>umh, how do I check that?

<mistnim>what chipset is it?

<mark_weaver>you can probably find it with either lspci or lsusb

<tyrion-mx>Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter

<mark_weaver>sounds hopeful!

<tyrion-mx>yay!

<tyrion-mx>looking at this it seems it might be ok: https://wiki.debian.org/ath9k

<mark_weaver>tyrion-mx: excellent :)

<mark_weaver>yes, you're all set

<mark_weaver>it should work "out of the box"

<mark_weaver>in the installed system we have "wicd" for configuring the wireless network easily. from the install system you need to create a wpa_supplicant.conf file manually. it might be easier to plug into ethernet during the install, if that's okay.

<tyrion-mx>an other question, the other time I downloaded guix, the first thing you told me to do, was to update it (running guix pull if I remember correctly). Now, can I download an "already updated" version of the USB installer, so I don't have to do the update later?

<mark_weaver>the ethernet device will have a different name than you're used to. "ifconfig -a" to find out what it is, and "ifconfig <device> up" before "dhclient <dvice>"

<tyrion-mx>or I don't have to worry about it?

<mark_weaver>tyrion-mx: no, you should run "guix pull"

<tyrion-mx>ok

<mark_weaver>davexunit: what commits do you think I need to revert to avoid the tests that may fail on older kernels or kernels that don't have all the needed support (e.g. user namespaces) ?

<mark_weaver>or maybe it's better to just move forward and skip those tests on kernels without the needed support.

<mark_weaver>we can assume the kernel has what's needed to run 'guix-daemon'

<mark_weaver>I guess 43ace6ea76b0cb4e2ba3f6486acba7dc66e2f19d and 8950ed11c6a0d51be056b3509f3ab269787696e9

<mark_weaver>hmm, maybe the CLONE_NEWUSER flags

<mark_weaver>oh, maybe the 'pivot-root' test too, since it also uses CLONE_NEWUSER

<davexunit>mark_weaver: all the new tests use user namespaces, otherwise only root could run the tests.

<mistnim>anybody looked into my bug? Maybe the version of ifconfig you provide in the image doesn't support mac change?

<davexunit>ugh.

<davexunit>I really don't want these commits reverted.

<mark_weaver>davexunit: okay, we need a way to skip those tests if either (1) the kernel is too old, or (2) user namespaces are not configured into the kernel

<davexunit>(utsname:release (uname)) will get us the kernel version

<mark_weaver>davexunit: well, that still won't help with (2)

<davexunit>yes

<davexunit>I know

<davexunit>I don't know how to tell that user namespaces are available

<davexunit>well, (file-exists? "/proc/self/ns/user") should be sufficient

<mark_weaver>ah, could be

<mark_weaver>better only check on linux though, so we don't gratuitously break the hurd.

<davexunit>sure

<mark_weaver>it looks like jxself's build slave might have everything we need. if I could just force this build to happen on that machine for now, that might work.

<mark_weaver>but I don't know how to do that :-(

<mark_weaver>jxself's build slave has kernel 3.13 and /proc/self/ns/user exists, anyway.

<mark_weaver>the other slaves are older

<mark_weaver>heh, well, I guess the file won't exist on the hurd anyway.

<mark_weaver>hmm, I guess I could just disable the other build slaves temporarily

<mark_weaver>ACTION tries

<davexunit>mark_weaver: fingers crossed

<davexunit>mark_weaver: this is ugly but: (and (version>=? (car (string-split (utsname:release (uname)) #\\-)) "3.8") (file-exists? "/proc/self/ns/user"))

<davexunit>I'm sorry that I'm not in a position to make any commits right now

<mark_weaver>davexunit: that's fine

<mark_weaver>thanks

<mark_weaver>jxself's slave is now building guix from commit 9f04196. hopefully it will pass tests there.

<davexunit>I hope so.

<mark_weaver>bah, no. it still failed syscalls.

<davexunit>damn it.

<Steap>Hum, ./pre-inst-env guix package -A works, but if I install guix and run guix package -A, I get http://paste.debian.net/280807/

<mark_weaver>and it's running kernel 3.13 and /proc/self/ns/user exists on that machine.

<Steap>maybe something is wrong with my GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH environment variables

<Steap>does that ring a bell to anyone ?

<davexunit>mark_weaver: could you just disable them in the build container

<davexunit>now that I'm thinking about it, they don't have a hope of passing in there.

<mark_weaver>disable what?

<davexunit>they're already in a container.

<mark_weaver>ah

<davexunit>mark_weaver: setns and clone tests

<davexunit>I wasn't thinking clearly before.

<davexunit>and pivot-root

<davexunit>since that relies on containers.

<davexunit>and tests/containers.scm needs to be skipped entirely.

<davexunit>I completely overlooked what these tests would do when inside the build container.

<davexunit>perhaps they can work, but they'll need more setup than we have time for right now.

<paron_remote>hm

<paron_remote>ice-9/boot-9.scm:106:20: no code for module (guix build syscalls)

<paron_remote>did that move at all since the wip-deploy branch was updated?

<davexunit>no

<davexunit>I have to go now. apologies to everyone.

<mark_weaver>it seems like bad design to me for things to work so differently inside containers. I'd think that you should be able to create a container within a container.

<mark_weaver>but that's a criticism of Linux, not anything else.

<mark_weaver>davexunit: okay, thanks for the insights.

<davexunit>namespaces can be nested.

<davexunit>but our build container may not be prepared for that

<davexunit>it will take more investigating.

<paron_remote>oh I see what I did wrong

<paron_remote>I'm dumb.

<paron_remote>forgot the ./pre-inst-env

<paron_remote>oh or maybe that doesn't cis it

<paron_remote>arg

<paron_remote>fix

<paron_remote>doesn't fix it ;p