IRC channel logs

<davexunit>another regular core developer also seems to be afk for several days

<jessica_lily>hey, when i tried installing guix using the: guix system init command i get an two unttest failures in the "guix" package (in nar.scm and store.scm). It says there should be a test-suite.log file but I can't find it

<jessica_lily>I presume it was cleaned up by guix itself when it failed

<jessica_lily>I'm not sure if these failures would actually stop me using the system too so it might be nicer to just bypass them for now?

<rekado_>would it be a good idea to change numpy(-bootstrap) to build against openblas rather than atlas? This would make it (and the many packages that depend on it) substitutable.

<rekado_>(it also would remove the need to fetch texlive each time numpy/matplotlib have to be built)

<dca>does anybody have guixsd demo as vmware image?

<iyzsong>dca: I never used vmare and don't know about it. we have usb image for qemu, and some mentioned using VirtualBox on the mailling list.

<rekado_>dca: there's a qcow2 disk image: http://alpha.gnu.org/gnu/guix/

<dca>ok, qcow should work, but i only see gnu-system-demo-0.6.qcow2.xz

<rekado_>oh, right, these are probably a little too old.

<rekado_>try the usb image instead.

<rekado_>you can boot right into the GNU system this way.

<dca>ok, thx

<rekado_>even with vmware you should be able to just load the image and boot from it.

<rekado_>(though I haven't tested it)

<rekado_>I only tried the USB image on an actual USB drive.

<rekado_>dca: feel free to ask for help here.

<jessica_lily>does anyone know how to get the info on why the tests are failing so i can report the bugs

<rekado_>jessica_lily: sorry, no idea. Are you getting these failures also when running "make check" in your guix directory?

<rekado_>or have you booted from the USB image?

<jessica_lily>I'm getting them when guix tries to install itself, i'm running the "guix system init" command from the guixSD image

<rekado_>I see.

<jessica_lily>on the "guix" package two unit tests are failing one in nar.scm and one in store.scm

<rekado_>I'm sorry, I'm not familiar with this. I only did this once and everything worked fine there, so I would not know where to look for the log file :-/

<jessica_lily>it does say a test-suite.log file has been produced but using the locate command i can't find it so i am guessing i was cleaned up by guix

<rekado_>have you also tried "find . -name test-suite.log"?

<rekado_>locate operates on a file database which may be out of date

<jessica_lily>i know but i did an updatedb

<rekado_>ok

<Tsyesika>hey davexunit

<davexunit>hey Tsyesika

<Tsyesika>so I tried installing it this morning but when i do guix system init and it gets to installing the "guix" package it fails on two unit tests

<Tsyesika>one being in "store.scm" and the other being in "nar.scm"

<Tsyesika>it does mention a test-suite.log" file but that doesn't seem to exist, i suspect guix cleaned it up when it failed.

<davexunit>I don't see why 'guix system init' would be running unit tests

<davexunit>is it trying to build guix from source for some reason?

<Tsyesika>i believe it was yes

<cehteh>ho

<Tsyesika>i don't know why

<Tsyesika>i think it built a lot from source actually (not only guix)

<cehteh>Tsyesika: i had that fails too on one of my various tries

<cehteh>doing a guix pull before the system init updates the installer, and fixed some problems

<davexunit>Tsyesika: are you using substitutes from hydra?

<Tsyesika>davexunit: i have no idea, i'm still getting to grips with guix, thus far i just followed the docs, the only modifiecations i made to the sample config file were file system and user account

<cehteh>hydra sometime (often) fails :/ .. then guix will build locally, same here

<cehteh>trying another time of day works

<Tsyesika>well i'm running it now to check and it's definitely building it locally

<davexunit>does it build *everything* locally

<davexunit>?

<davexunit>that will surely take forever

<Tsyesika>i don't know i started it last night and just left it while i slept, when i re-run it, it only tries to build guix now

<cehteh>yes you dont see the downloads because they are much faster than the builds :)

<Tsyesika>cehteh: does it download in parallel?

<Tsyesika>like, whilst it builds something else

<davexunit>Tsyesika: anyway, you won't find those log files because failed builds are deleted

<cehteh>no

<Tsyesika>davexunit: i suspected so

<davexunit>you can run 'guix build -K guix'

<davexunit>and the failed build will remain in /tmp

<davexunit>I'm not sure why the tests fail, though

<Tsyesika>well i can provide the log file

<Tsyesika>davexunit: okay running the build command you suggested, will paste the log file once it's done

<davexunit>send it to the list

<cehteh>configure: error: C++ preprocessor "/lib/cpp" fails sanity check

<cehteh> .. meeh :D

<Tsyesika>hm i need to install a mail client on this machine to do that >.<

*cehteh just installed a very small debian 8 and bootstrapping guix

<Tsyesika>cehteh: i was considering installing as minimal centos as i could and just using guix ontop

<Tsyesika>so i didn't have to care about the OS

<Tsyesika>but i decided i'd go the guixSD route instead

<cehteh>Tsyesika: i failed on that, now i try to get it running on top of debian in a vm just to get used to it and bootstrapping a guixsd from that

<davexunit>I don't know wth is going on with your installations

<davexunit>all of mine work with minimal fuss...

<Tsyesika>mine or cehteh's?

<cehteh>i am installing guix from source/git now

<davexunit>both

<cehteh>well fighting debian8

<cehteh>anyway .. i can manage that :) no i have something where i have some grips instead a failed install and i will report bugs/send patches as far as possible

<davexunit>you can also build your own installation images

<davexunit>with the latest guix

<davexunit>and try that

<cehteh>guix is quite new with a small userbase, i wont wonder when there are some cornercases people are not aware yet

<cehteh>yes thats my plan

<davexunit>since there have been a lot of improvements and fixes since 0.8.1

<davexunit>I would just build and upload one but I'm short on time

<cehteh>lemme check why the cpp test fails, that sounds unusual

<Tsyesika>davexunit: well i'm happy to submit these bugs and collect the info, if i don't do it someone will just run into these bugs later

<cehteh>no worries, if i am in urge to use guixsd as new distribution then i think i would be very wrong already :)

<davexunit>Tsyesika: thanks :)

<davexunit>every new user runs into something we haven't seen before

<cehteh>ah .. no c++ installed at all, no wonder it barfs :D

<Tsyesika>awh come on! curl isn't installed on this image

<davexunit>Tsyesika: wget?

<Tsyesika>i don't know how to use it >.<

<davexunit>wget > curl

<davexunit>I don't know it's on the image, though

<cehteh>in the simplest case

<cehteh>ah no, no downloader is there

<cehteh>i found that too

<cehteh>guix package -i wget

<davexunit>yeah

<davexunit>might be worth adding wget to the image.

<Tsyesika>cehteh: i don't wanna just download something though

<Tsyesika>i vote adding curl :P

<cehteh>would be an request for improvement, wget, curl, fetch .. anything should be on the image

<cehteh>yes

<davexunit>Tsyesika: what are you trying to do?

<cehteh>or lynx

<Tsyesika>paste the log file

<davexunit>wget can do what curl can do

<davexunit>guix package -i curl

<Tsyesika>yep i got it

<cehteh>i would vote for lynx or w3m .. some basic browser would solve a lot issues, watching local html docs, browsing/searching the web for fixes, downloading stuff

<davexunit>we don't want to add too much to the installer.

<cehteh>building guix wants dot .. thats a missing dependency on configure.ac

<Tsyesika> http://pamrel.lu/d0933/raw

<davexunit>no, it isn't.

<davexunit>it's only needed for building from git.

<davexunit>it's not needed for building from release tarballs.

<cehteh>yes but some small tools for debugging/rescueing the installation are really a big help

<davexunit>personally, I have no clue how to use lynx or w3m, so it would be of no use to me.

<cehteh>ah ok, well i am only reporting here, maybe that should be detected

<davexunit>it shouldn't.

<davexunit>because it's not needed to build a release.

<cehteh>mhm ok

<davexunit>the HACKING file documents what's needed to build from a git checkout

<cehteh>anyway .. i just install it :)

<cehteh>hah nice .. ok i should read that

<Tsyesika>cehteh: i'm trying to do a guix pull and see if i can run the installation stuff again and have it work

<davexunit>we should probably build more bleeding edge installation images in the future

<cehteh>bah .. debian .. graphviz-dev doesnt depend on graphviz :)

<davexunit>since we're in alpha, it's really a good idea to use the latest master commit most of the time.

<Tsyesika>yeah

<davexunit>thanks for sticking it out through all these difficulties, Tsyesika and cehteh

<davexunit>ludo will surely be more helpful, when he makes his triumphant return.

<Tsyesika>no problem :)

<davexunit>I have to head to work now. ttyl

<cehteh>guix up and kicking :)

<Tsyesika>cehteh: congrats :)

<rekado_>does Guix already run as a package manager on top of the Hurd or are more changes required? (Is this what the wip-hurd branch is there for?)

<ph4nt0mas>rekado_: currently wip-hurd can build most of the binaries needed to bootstarp itself on a hurd system

<davexunit>ph4nt0mas is doing good work :)

<ph4nt0mas>davexunit: :-)

<ph4nt0mas>davexunit: any idea where mark_weaver is?

<rekado_>ph4nt0mas: woo, that's great! Are you working on vanilla hurd or debian hurd?

<rekado_>ph4nt0mas: I'd really like to help you. Is there anything ... simple but tedious you would be willing to outsource to me?

<rekado_>I'm going to package zeromq; may I place it in a new module "networking.scm"? Or is there something better suited?

<rekado_>(we could move the contents of socat.scm to networking.scm then)

<rekado_>or would it better fit to messaging.scm (even though it means a different kind of "messaging")?

<iyzsong>maybe message-queue.scm? and will have rabbitmq etc.

<rekado_>I see in socat.scm a note: ";; XXX: Group with other networking tools like tcpdump in a module?"

<rekado_>isn't this all networking in some general sense?

<rekado_>zeromq also does TCP and sockets.

<iyzsong>ah, ok, that make sence

<paroneayea>ph4nt0mas: I'm excited to play with guix + hurd more

<paroneayea>thanks for working on it!

<paroneayea>huh

<paroneayea>davexunit: I didn't expect that NixOps was python based.

<davexunit>paroneayea: hehe

<davexunit>remember when I said that a good portion of nixops was code to parse nix expressions and operate on them with xml xpath?

<davexunit>;)

<taylanub>when a package has input /gnu/store/foo, then /gnu/store/foo/lib is added to LIBRARY_PATH automatically, right?

<davexunit>should be, yeah. try dumping the env vars in your builder to verify.

<iyzsong>taylanub: yes, if you have gcc (has a search-path-specification for it) too.

<iyzsong>and use gnu-build-system..

<taylanub>libatomic-ops wants to be compiled with -latomic_ops as per its pkg-config file, but it only provides libatomic_ops.la and libatomic_ops.a in its $prefix/lib directory. does that even work?

<cehteh>tada .. guixsd installed from a debian *works* :)

<cehteh>(in a kvm)

<davexunit>yay!

<cehteh>eh when doing a system init, i give no user password for the initial user(s)

<cehteh>how do i log in?

<cehteh>root w/o password .. seriously :D

<davexunit>yeah nothing is set on the demo OS

<davexunit>you can run passwd yourself or specify the password hash in your OS config

<cehteh>whats the terminal in windowmanager, no xtern, no wmterm (guessing)

<cehteh>will do

<cehteh>but i never used windowmaker, have to figure things out

<davexunit>I'm assuming you created a VM with the demo-os config

<davexunit>so you'll have xterm

<cehteh>nop

<cehteh>no such file

<davexunit>right click on the desktop

<davexunit>and go to applications -> terminals (i think) -> xterm

<davexunit>something like that

<cehteh>btw is it possible to install files globally (for all users), is there some staging in the profiles (i'd like site, host, user )

<davexunit>yes, the 'packages' field of your operating-system expression

<cehteh>ok

<davexunit>of course, the users must add the appropriate directories to their $PATH and such

<cehteh>i am somewhat new to this, but i am wondering why there is no "system" user with guid 0, home=/ .. which runs on behalf of global task

<cehteh>anyway .. now i am as far as i can get started, just ignore my noobish questions :)

<davexunit>that's root, no?

<davexunit>the users on the machine are completely up to you

<cehteh>root privs .. but managing the system (users themself, software installed for anyone, kernel, ...)

<davexunit>I don't see the need for that

<cehteh>ok

<davexunit>'guix system reconfigure' does system updating

<cehteh>mhm .. no network :/

<bavier>cehteh: you can put any user in the wheel group

<cehteh>thats not what i meant

<cehteh>or is there a guix package --global -i foobar ?

<davexunit>no

<bavier>the os-config, like davexunit said, is where stuff like that goes

<davexunit>the "global" stuff is in /run/current-system

<davexunit>and /run/booted-system

<cehteh>i like some orthogonality, os-config currently sounds like some special case

<davexunit>it's the primary means of representing your system.

<cehteh>i'd rather have my own archive server which hosts a 'site-config' maybe some dervitations (server, desktop, laptop) .. then each machine has its own local config for the system .. and finally every user has its own

<davexunit>if you could imperatively modify the global system, we'd lose the technical advantages that guix offers.

<cehteh>i dont want that of course

<davexunit>then I am confused

<cehteh>well .. i am on the run ,. bbl

<davexunit>I don't know what you mean by "os-config current sounds like some special case"

<davexunit>okay

<iyzsong>yes, that will be cool. (operating-system (inhert (@ (my-site) os) ...)

<davexunit>that's easy to do

<davexunit>but I don't think that's what he's thinking of

<davexunit>there's some bigger misunderstanding

<iyzsong>ah, time to sleep, bye!

<davexunit>bye

<davexunit>I get real discouraged when people's idea of fixing package management is to

<davexunit>bleh

<davexunit>I get real discouraged when people's idea of fixing package management is to write some tool that "unifies" multiple distinct package managers

<davexunit>a package manager that manages package manager, surely that's what we need!

<davexunit>oh, and guix is just yet another package manager so it's not worth using.

<paroneayea>cehteh: I need to do that soon (re: testing guixsd on my debian machine)

<vmlinuz88>when I ran guix system init it failed to build *-system.drv

<phant0mas>rekado_: I am working with the vanilla sources but I have a debian hurd vm running in qemu

<phant0mas>rekado_ paroneayea thanks for your support :-)

<paroneayea>:)

<cehteh>re

<cehteh>... grr .. networking doesnt come up

<vmlinuz88>has anyone encountered the build error I mentioned above?

<bavier>cehteh: do you have dhcp-client-service configure for your system?

<cehteh>configured in what way?

<cehteh>dhclient ens3 ... times out

<cehteh>vmlinuz88: what error exactly, and what hardware?

<bavier>cehteh: I see, you're bringing it up yourself

<bavier>I was wondering if you were using http://www.gnu.org/software/guix/manual/guix.html#Networking-Services

<cehteh>prolly a kvm problem again

<cehteh>first i want to have it manually working, just for debugging

<paroneayea>so, in theory can you describe your whole system including files like /etc/apache/sites-available/foo.conf in the system configuration of guixsd?

<paroneayea>or is that a guixops type next-level of things

<paroneayea>maybe a question for davexunit

<bavier>paroneayea: that's the goal

<paroneayea>bavier: for guix system, or for guixops?

<vmlinuz88>cehteh it's a build error after running guix system init ... fails to build /gnu/store/*-system.drv

<vmlinuz88>one moment and ill give you hardware specs

<cehteh>with what error?

<bavier>paroneayea: in guixsd if it pertains to the local system

<paroneayea>bavier: aha, but it doesn't support configuring all those files and etc at this point?

<paroneayea>I also wonder how you could handle doing a "rollback" of a configuration setup... eg, if you add an apache config file, but later it gets removed

<bavier>paroneayea: there's still work to do in various areas

<paroneayea>does that file ever get collected?

<paroneayea>is there a plan for that?

<paroneayea>and by collected I mean removed :)

<paroneayea>it *sounds* like nix people have an answer to this

<paroneayea>but I don't know enough to really say.

<bavier>'guix system reconfigure' handles generating system configuration files, so they can be rolled back with the rest of the system.

<vmlinuz88>ceteh there are several instances of "error" in the output. one is make Error 1 for test-suite.log, Error 2 for check-TESTS, Error 2 for check-am, Error 2 for check-recursive, and Error 2 for check. Is there anything specific you need to know about hardware?

<vmlinuz88>cpu is intel Xeon E3-1200

*paroneayea stumbles into this post http://sandervanderburg.blogspot.com/2015/03/on-nixops-disnix-service-deployment-and.html

<cehteh>vmlinuz88: you have to look closer on these errrors to find out about whats actually failing

<vmlinuz88>ceteh those are what it says are failing, check-am, check-TESTS, etc.

<vmlinuz88>it also says "cannot build derivation /gnu/store/*-profile.drv" and same for *-system.drv. it also says dependencies couldn't be built

<cehteh>so thats is where you have to look and start debugging

<cehteh>just vague "something cant be built" wont neccessary help fixing it

<cehteh>while .. i fixed something with just 'guix pull' to update to a recent version

<vmlinuz88>well, I mentioned those things above, but nobody responded

<cehteh>but note: i am new here too

<cehteh>btw .. why arent there any snapshots/tags for guix pull, would be nice to have something like 'last known good', 'nightly', 'release 0.x' or whatever

<vmlinuz88>ceteh, I mentioned a lot more than "something couldn't be built". I've never debugged C code before, so I'm not quite sure what these errors mean or where they originate.

<Sleep_Walker>last known good = nightly = HEAD :b

<bavier>vmlinuz88: it sounds like guix if trying to build a package and failing

<bavier>vmlinuz88: have you enabled substitutes?

<paroneayea>bavier: oh interesting

<vmlinuz88>bavier Right. I'm not sure if substitutes are enabled. Is it a specific option to pass to guix system?

<bavier>vmlinuz88: http://www.gnu.org/software/guix/manual/guix.html#Substitutes

<vmlinuz88>bavier thank you

<vmlinuz88>bavier Ah! That would probably be the better option, to enable substitutes.

<bavier>vmlinuz88: try that and see how things go

<cehteh>bavier: the strange thing would be why is it failing for him, but hydra built it (if so)

<bavier>cehteh: correct, that would also be useful to know

<cehteh>meh ... the linux libre kernel seems to support virtio block devices .. but not so ethernet devices, wont that be the better choice, if running in a vm you want both anyway and virtio is guranteed to be a pure libre driver

<cehteh>still no way to get the network up

<vmlinuz88>bavier that page you linked to says to use the hydra.gnu.org repo I need to archive its public key. Do you know where I can find this public key?

<cehteh>its in the guix toplevel directory

<cehteh>cd /gnu/store/*-guix*

<cehteh>vmlinuz88: welcome to the struggles i had a few days ago :)

<vmlinuz88>ceteh Thanks!

<cehteh>btw: my nick highlight only works when you type the correct nick :)

<vmlinuz88>oops! lol

<vmlinuz88>sorry

<vmlinuz88>cehteh so once i archive the public key for hydra.gnu.org, how do I tell guix to use substitutes? Does it use them by default now?

<cehteh>it just does

<vmlinuz88>okay, thank you

<vmlinuz88>:)

<cehteh>strangely i think thats even default, if your setup doesnt use them something may already be wonky ... BUT: hydra is wonkey tooo

<bavier>our build farm is underpowered

<bavier>but... hydra is getting an upgrade soon ;)

<cehteh>would be nice when it has some frontend caches for load distribution

<cehteh>i saied that already a few days ago

<paroneayea>I think I need to get something working via guix vm so I can grok how things work

<paroneayea>for the guix system stuff

<paroneayea>its' probably not hard, but I'm being nervous anyway, which is probably silly.

<cehteh>well .. i am struggleing here ever second step, its still really a bit bumpy

<bavier>cehteh: patches and bug reports welcome! :)

<cehteh>earlier today i finally managed to setup a system image in a kvm .. now the network is broken

<cehteh>bavier: will do as soon i have a system useable to debug the stuff and i can track the bugs down

<cehteh>so far i dont even know why network isnt working, prolly i restart the whole kvm stuff and try again, windows alike :D

<cehteh>that didnt fix it

<cehteh>e1000 module is loaded .. but dhclient dont get any response

<davexunit>paroneayea: re: your system configuration questions: all of that stuff is defined in the OS config

<davexunit>and for your example about apache httpd, you would just include the (not yet available) 'http-service' in your services list

<davexunit>with the appropriate virtual host configs

<paroneayea>davexunit: what I don't understand is how guix system knows to remove a config file it set up

<paroneayea>when you upgrade to a new config

<davexunit>it doesn't remove anything

<paroneayea>oh

<paroneayea>it just leaves old stuff in place

<paroneayea>?

<davexunit>it builds a new tree

<davexunit>and instantiates that as /run/current-system

<paroneayea>okay, but how does that appear in /etc/?

<paroneayea>does it ever? :)

<davexunit>it would be in /run/current-system/etc

<paroneayea>oh I see..

<davexunit>or something to that affect

<davexunit>effect*

<paroneayea>and that's symlinked to /etc/?

<davexunit>no

<paroneayea>:O

<davexunit>we don't follow the FHS :)

<paroneayea>oh :(

<davexunit>guix wouldn't work without it

<davexunit>or rather, with it.

<davexunit>there's no /usr

<davexunit>the root file system is setup with the minimum directories needed

<davexunit>there is a /etc that has passwd and stuff

<davexunit>ludo might have more details on what *needs* to be in /

<davexunit>since he wrote it all

<davexunit>I'm just observing

<paroneayea>I see that nixos does the same thing

<paroneayea>not following the FHS is... well, "bold", heh

<paroneayea>I guess I see structurally why true.

*paroneayea reads http://sandervanderburg.blogspot.com/2011/11/on-nix-nixos-and-filesystem-hierarchy.html

<davexunit>oh cool someone wrote about it

*davexunit reads

<paroneayea>the debian-devel criticism posted is interesting, though I think wrong in many places https://lists.debian.org/debian-devel/2008/12/msg01027.html

<paroneayea>one thing that I think is true is that debian does a lot of things as in terms of upgrading database formats and etc on updates

<paroneayea>and so rolling back isn't as easy as --roll-back in many types of setups

<paroneayea>but

<paroneayea>I think it's also underestimating just how much of the upgrade fear is reduced

<davexunit>I think I've read this criticism before

<paroneayea>it does seem true that it puts the responsibility of doing those updates in the hand of the user, there's no real way to do that automatically *for* the user in (gu|n)ix

<davexunit>and disagree with pretty much all of it

<paroneayea>I disagree with most of it, though the difficulty of migrations is probably one true thing.

<davexunit>nix got laughed at during joeyh's debconf talk

<davexunit>that's stateful stuff, though.

<paroneayea>yeah too bad, I think joeyh actually likes nix a lot

<paroneayea>davexunit: right, stateful stuff, which is "out of guix's concerns", but still within the concerns of users doing an upgrade

<paroneayea>not that debian always succesfully upgrades my stuff :)

<davexunit>guix/nix does a great job at distinguishing stateless and stateful things.

<paroneayea>davexunit: I agree

<davexunit>but yeah, what's the best way to migrate a db? not sure.

<paroneayea>davexunit: it's still true that guix/nix throws up its hands in a "not my problem" way when it comes to state upgrades of "user data"

<paroneayea>how to make clear to users that they need to take steps sometimes, I'm not sure.

<davexunit>yeah, that requires some though.

<davexunit>thought*

<davexunit>but not unsolvable, and certainly a much better place to be in than "everything's stateful"

<paroneayea>thanks for clarifying things for me, davexunit

<paroneayea>davexunit: I assume that guix packages for apache, etc make a policy of trying to *not* make assumptions about where /etc/ type config files and etc are, and hope that you can somehow specify that yourself

<davexunit>debian isn't just going to back up your precious databases to another server before doing an upgrade either.

<paroneayea>that way /run/ and etc could work, but maybe if you're running an existing debian system, /etc/ could still work?

<davexunit>paroneayea: http has flags for specifying which config file to use

*paroneayea nods

<paroneayea>okay, I figured it was something like this

<davexunit>I started writing httpd-service, but I didn't get far.

<paroneayea>davexunit: thanks for clarifying things

<davexunit>np

<davexunit>when you throw away the FHS, things can be harder to conceptualize.

<davexunit>but ultimately it's for the best. the FHS to me is equivalent to global state.

<paroneayea>makes sense

<paroneayea>davexunit: one thing I do think is true: trying to prepare a package so that it can work with *both* debian and guix

<paroneayea>I think makes you think about a lot of design stuff to keep things clean.

<davexunit>a lot of software that uses a proper build system "just works" on guix.

<davexunit>pkg-config, autotools, etc.

<paroneayea>yeah

<davexunit>those typically work like a charm.

<paroneayea>I don't really like the autotools system as a whole from a design perspective, but I do admire at how much it "just works" once it's set up

<davexunit>yeah, the autotools are a total mess.

<paroneayea>but the APIs of ./configure && make are nice :)

<davexunit>but they work well.

<paroneayea>I do like that the GNU coding standards leave open the possibility of replacing ./configure

<paroneayea>it just says it needs to support ./configure standard flags, but you can use non-autoconf/automake if you like

<paroneayea>nobody has done this afaik

<davexunit>people that hand roll their configure and Makefile typically make unportable assumptions

<paroneayea>but some day, maybe ./configure will be a declarative scheme file :)

<davexunit>autotools is great at eliminating those assumptions

<davexunit>would be cool to try

<paroneayea>sounds boring though ;)

<paroneayea>to me at least :)

<davexunit>yeah

<davexunit>and hairy

<paroneayea>would be exciting to use, if someone else did it!

<davexunit>I am not capable of learning all the lessons learned from the autoconf people and then writing a replacement

<paroneayea>davexunit: one funny thought I've had, make compiled with guile support

<paroneayea>you could just have the ./configure replacement write out scheme

<paroneayea>that the makefile just imports

<paroneayea>to build up the rules

<paroneayea>that would be fun.

<paroneayea>and yes I agree, I'm not probably capable (almost certainly not patient enough) to do it myself.

<davexunit>I could probably hack up a toy implementation that did nothing useful :)

<paroneayea>davexunit: I think the biggest thing that people laughed at in joeyh's talk btw

<paroneayea>was about the symlinks

<davexunit>yes

<paroneayea>I think joeyh is more likely to be sympathetic given how git-annex works ;)

<paroneayea>which looks a lot like guinix ;)

<paroneayea>guinix is my new lazy term for when I don't feel like saying (gu|n)ix ;)

<paroneayea>also heyyyyy civodul !

<paroneayea>welcome back

<davexunit>he's back!

<bavier>woohoo!

<civodul>hi there! :-)

*davexunit drops stack of paperwork on civodul's desk

<paroneayea>davexunit: thanks for explaining so much to me lately btw

<paroneayea>I really do want to help out with guixops, but I need to get a better sense of how these things work.

<paroneayea>I need to figure out some sort of VM hoster that allows for guixsd hosting

<paroneayea>I'd like to do guixsd for dustycloud.org as a first testcase.

<paroneayea> https://nixos.org/wiki/Install_NixOS_on_Rackspace_Cloud_Servers maybe I should see if I can do this for guixsd.

<paroneayea>oh, linode! :D

<paroneayea> https://nixos.org/wiki/Install_NixOS_on_Linode

<paroneayea>I wonder if linode requires a blobby kernel, I don't remember.

<ph4n70m4s>damn, trying to patch the tar package gets me a (vm-run "VM: Stack overflow" ())

<Tsyesika>davexunit: seems my macbook doesn't boot after i successfully run the guix system init command, i don't think it installed grub but it didn't report errors either

<Tsyesika>sigh >.< i shall try again in a bit i guess

<taylanub>does anyone know why sometimes when working with a store connection (I think it's from using `with-store'), you get some output like ((result "huge sexpr in this string") (output . "stdout"))?

<alezost>taylanub: I also notice such things, but I think it's some output from geiser and it's not related to a store connection.

<taylanub>aha

<_`_>paroneayea: if they are just xen pvs, it shouldn't

<davexunit>paroneayea: I need to get a better sense of how these things work, too. :P

<davexunit>those blog posts you posted are real useful

<davexunit>I should experiment with installing guixsd to a digitalocean droplet or something

<_`_>I don't think do lets you use your own kernel sadly.

<davexunit>ah

<davexunit>bummer

<civodul>taylanub: you mean in Geiser?

<civodul>phant0mas: probably because of a chicken-and-egg problem: patching requires Patch, which requires Tar, which requires Patch

<paroneayea>civodul: btw, when you're more settled in

<paroneayea>would love your feedback on http://lists.gnu.org/archive/html/guix-devel/2015-04/msg00500.html

<civodul>phant0mas: see commencement.scm

<civodul>paroneayea: sure, i'll look into it, but i seem to have a big backlog ;-)

<phant0mas>ok

<paroneayea>civodul: I figured :)

<civodul>:-)

<taylanub>civodul: yup, I didn't consider it might be a Geiser bug

<taylanub>civodul: welcome back BTW :)

<taylanub>I just happened to be done with the Qt 5.4 / i686 patch today; it's quite dirty but if you think it's fine then we won't miss out on Qt 5.4 on i686 on the 0.8.2 release.

<cehteh>mhm still no luck getting the network running

<cehteh>same vm, booting debian works :/

<civodul>taylanub: excellent!

<rekado->phant0mas: re vanilla hurd: I see. (The differences between the running system in the VM (= Debian GNU/Hurd) and the vanilla sources made it very hard for me to keep up with development, personally.)

*davexunit is having a lot of fun with linux namespaces

<davexunit>guile as PID 1 inside a PID namespace :)

<civodul>davexunit: :-)

<civodul>that's also what happens with build envs in guix-daemon

<vmlinuz88>cehteh bavier: I'm now trying it out on a virtual machine.

<cehteh>tell me when you have success getting the networking up .. i am checking that later, having not the slightest idea whats going wrong there

<Tsyesika>I'm getting a "guix system: symlink: File Exists" for glibc

<Tsyesika>this is whilst running guix system init

<davexunit>Tsyesika: eek. any more info?

<davexunit>like the source and target for the symlink?

<Tsyesika>it doesn't say as far as i can tell

<bavier>Tsyesika: I encountered that while installing guixsd once

<bavier>it was because I had had a previous unsuccessful installation

<bavier>and some of the files and symlinks were still lying around

<Tsyesika>humph

<Tsyesika>i've tried installing this four times already xD

<bavier>I think I just deleted everything in /gnu/store and tried installing again, but my memory might be a bit fuzzy; this was a month or two ago

<Tsyesika>bavier: thanks for letting me know

<Tsyesika>davexunit: oh by the way, it does compile a lot of things during the installation

<Tsyesika>takes quite some time

<Tsyesika>but hydra is being quite flakey giving 504s and saying it's "somewhat slow"

<vmlinuz88>I still get guix system: error: build failed: build of '/gnu/store/<a-long-string-of-alphanumerics>-system.drv' failed

IRC channel logs

2015-04-29.log