IRC channel logs


back to list of 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:
<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 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
<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 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
<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>davexunit: can we only get that by running as root ?
<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 for downloading pre-built binaries
<Steap>The main issue is when 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: 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>i'll poke around for examples. thanks davexunit
<davexunit>jmd: the point is that people don't build stuff and upload the results.
<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>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.
<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
<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.
<davexunit>or <insert-paradigm-here>
<Jookia1>i haven't learned a scheme before, is guile a good one for beginniners?
<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:
<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?
<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>it's called UK in this directory
<mark_weaver>KonaHumper: "loadkeys uk" is probably what you want.
<KonaHumper>yeah perfect
<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.
<mark_weaver>the folks on #libreboot can help you with that
<KonaHumper>gonna go afk for a sec
<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.
<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
<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!
<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
<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
<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 ( You upload an image (raw, qcow2) to glance and tell nova to spin up a vm with the image.
<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:
<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, 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.
<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 ( 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.
<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?
<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>looking at this it seems it might be ok:
<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"
<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>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>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.
<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>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
<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.
<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>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>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>doesn't fix it ;p
<mark_weaver>Steap: hmm, (gnu packages ld-wrapper) doesn't exist. I guess maybe it did in the past.
<mark_weaver>Steap: you might try deleting ~/.cache/guile/ccache
<mark_weaver>or maybe there are problems from old stale files in your installation directory
<Steap>mark_weaver: oh indeed, some old files were still there
<Steap>rm -rf helped me