IRC channel logs
2015-04-29.log
back to list of 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. <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_>you can boot right into the GNU system this way. <rekado_>even with vmware you should be able to just load the image and boot from 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 <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 <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 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 <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 :) <davexunit>Tsyesika: anyway, you won't find those log files because failed builds are deleted <Tsyesika>davexunit: okay running the build command you suggested, will paste the log file once it's done <cehteh>configure: error: C++ preprocessor "/lib/cpp" fails sanity check <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>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 <cehteh>i am installing guix from source/git now <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 <cehteh>guix is quite new with a small userbase, i wont wonder when there are some cornercases people are not aware yet <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>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 <Tsyesika>cehteh: i don't wanna just download something though <cehteh>would be an request for improvement, wget, curl, fetch .. anything should be on the image <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 <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>the HACKING file documents what's needed to build from a git checkout <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. <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 <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? <paroneayea>ph4nt0mas: I'm excited to play with guix + hurd more <paroneayea>davexunit: I didn't expect that NixOps was python based. <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. <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>eh when doing a system init, i give no user password for the initial user(s) <cehteh>root w/o password .. seriously :D <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>but i never used windowmaker, have to figure things out <davexunit>I'm assuming you created a VM with the demo-os config <davexunit>and go to applications -> terminals (i think) -> xterm <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>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>'guix system reconfigure' does system updating <bavier>cehteh: you can put any user in the wheel group <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 <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. <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>but I don't think that's what he's thinking of <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>vmlinuz88: what error exactly, and what hardware? <bavier>cehteh: I see, you're bringing it up yourself <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? <vmlinuz88>cehteh it's a build error after running guix system init ... fails to build /gnu/store/*-system.drv <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>it *sounds* like nix people have an answer to this <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? <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>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. <bavier>vmlinuz88: it sounds like guix if trying to build a package and failing <bavier>vmlinuz88: have you enabled substitutes? <vmlinuz88>bavier Right. I'm not sure if substitutes are enabled. Is it a specific option to pass to guix system? <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>vmlinuz88: welcome to the struggles i had a few days ago :) <cehteh>btw: my nick highlight only works when you type the correct nick :) <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>strangely i think thats even default, if your setup doesnt use them something may already be wonky ... BUT: hydra is wonkey tooo <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>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>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 <paroneayea>davexunit: what I don't understand is how guix system knows to remove a config file it set up <davexunit>and instantiates that as /run/current-system <davexunit>the root file system is setup with the minimum directories needed <davexunit>ludo might have more details on what *needs* to be in / <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 <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 <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 <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. <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>but not unsolvable, and certainly a much better place to be in than "everything's stateful" <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 <davexunit>I started writing httpd-service, but I didn't get far. <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>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. <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 <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 <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 <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>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>I think joeyh is more likely to be sympathetic given how git-annex works ;) <paroneayea>guinix is my new lazy term for when I don't feel like saying (gu|n)ix ;) *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>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>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>phant0mas: probably because of a chicken-and-egg problem: patching requires Patch, which requires Tar, which requires Patch <civodul>paroneayea: sure, i'll look into it, but i seem to have a big backlog ;-) <taylanub>civodul: yup, I didn't consider it might be a Geiser bug <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 :/ <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 <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 <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>davexunit: oh by the way, it does compile a lot of things during the installation <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