IRC channel logs


back to list of logs

<davexunit>another regular core developer also seems to be afk for several days
<davexunit>gotta run
<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:
<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
<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
<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>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
<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
<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
<cehteh>just wget <url>
<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>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
<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
<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.
<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>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?
<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 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)
<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>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
<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
<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 ?
<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"
<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>I get real discouraged when people's idea of fixing package management is to
<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 :-)
<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
<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
<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?
<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 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>cehteh so once i archive the public key for, how do I tell guix to use substitutes? Does it use them by default now?
<cehteh>it just does
<vmlinuz88>okay, thank you
<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>it just leaves old stuff in place
<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
<paroneayea>and that's symlinked to /etc/?
<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
<davexunit>oh cool someone wrote about it
*davexunit reads
<paroneayea>the debian-devel criticism posted is interesting, though I think wrong in many places
<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>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>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>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.
<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>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
<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!
<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 as a first testcase.
<paroneayea> maybe I should see if I can do this for guixsd.
<paroneayea>oh, linode! :D
<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.
<_`_>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.
<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
<civodul>phant0mas: see commencement.scm
<civodul>paroneayea: sure, i'll look into it, but i seem to have a big backlog ;-)
<paroneayea>civodul: I figured :)
<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>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