***Server sets mode: +nt
<damo22>janneke: it sounds like youre running hurd in a virtual machine, is there any difference from running the stock qemu image in qemu? <janneke>damo22: no; it's just that: qemu in qemu; seems to work now though <janneke>i cannot get "into" the second vm, something qemu-network'y so it seems <damo22>oh so you can run guix in qemu and then launch hurd in a qemu in there? <damo22>if youre already in hurd, you can launch a sub-hurd i believe without qemu <janneke>we're adding a "service" that starts a hurd using QEMU, so usually there would be just one QEMU <janneke>for testing purposes, we usually create a fresh Guix system in a VM <janneke>so it's not a blocking requirement, but nice to have <damo22>janneke: does guix have a way to integrate with gratis providers of CI? <damo22>for example, a dockerhub base image could be one way to do that <damo22>so in any CI that supports docker you could docker pull the base image and somehow call into it to do CI testing <damo22>or just point to it as the base image and youd have it already there <janneke>damo22: i have no idea, i'm not using either docker nor gratis CIs <janneke>"guix" is planning/dreaming to add this hurd-vm service to some of our own CI machines, creating a herd of hurd-vm's <damo22>but it would be really nice to also have an official base docker image for guix or no? <damo22>its basically a tarball as far as i know <janneke>to run a docker container, you need to run a docker service <janneke>which is a great way to run arbitrary binaries <janneke>i would not oppose someone creaeting docker image, just color me unimpressed <damo22>yes, but a lot of gratis CI providers do that for you and all you need to use their free as in beer compute is a tarball with your base image <janneke>thanks for thinking along, i don't want to sound grumpy/non-appreciative! <damo22>i like the idea of spending microsoft's money on electricity to run unit tests <janneke>damo22: i'm really green to this, be sure you know about "guix pack --format=docker" though! <janneke>i'm not at all clear as to what you're building -- just hate to see you do work that could be avoided by having more information <damo22>well im not sure either i need to research it <damo22>but for example, fedora has one, its a minimal system base tarball <damo22>so you can do eg, "docker pull fedora:30" and it logs into dockerhub and pulls the version 30 of the base image <damo22>but that same image can be specified in a yaml file in .travis.yml on a github repo and it auto pulls that one and uses it as the "OS" <damo22>its not secure at all, but if youre just running unit tests, who cares <bk1603>I am trying to build mig from the docs, but the compiler fails to find `<mach/message.h>`. I did install the headers to `~/Mach/gnu`, and that's what the variable `$GNU` is set to. But it still errors out. I checked for the headers and they are available in `~/Mach/gnu/usr/local/include`. <damo22>bk1603: its probably easiest to have a working hurd vm to develop hurd, at least that is what I experienced <damo22>you can get an image for the vm from the topic of this chat <damo22>i suggest the "disk image" and boot it with qemu <bk1603>damo22: Thank you, I have downloaded the image. (Network has been very slow.) I will boot it up and see how that goes :) <damo22>bk1603: dont forget to use kvm accelleration, check qemu --help <bk1603>damo22: Thanks a lot. I finally have it up and running, and was able to compile mach without any problems. Now I can start working on things :) ***janneke_ is now known as janneke`
***roptat_ is now known as roptat
***janneke` is now known as janneke
<Pellescours>bk1603: to build mig on my linux computer I had to set the path where are mach headers in TARGET_CFLAGS variable <Pellescours>TARGET_CFLAGS="-I~/hurd/headers/include/usr/local/include" ../configure --datadir=~/hurd/headers/include/usr/local/include <janneke>also youpi, thanks for your support; it looks like there will be xattr gnu.translator support in future linux kernels <janneke>i have no idea what the timeframe will be though <jrtc27>in fact I have no idea how that -I~/... is even working, it shouldn't <jrtc27>~ only expands in a shell when unquoted and unprefixed <jrtc27>(try `echo ~/foo -I~/foo "~/foo"` and note the output) <Pellescours>jrtc27: I replace my real path by ~ for the sample, in real I used absolute path