<scrubmin>I was wondering how I would go about getting the ati driver working instead of the vesa one. <scrubmin>In Xorg.0.log I get "18.876] (EE) Failed to load module "ati" (module does not exist, 0)" <mark_weaver>scrubmin: looks like a line for xf86-video-ati needs to be added to the others in 'xorg-configuration-file' in gnu/services/xorg.scm <mark_weaver>the best thing to do is to build guix from a git checkout, make that change, and then run "./pre-inst-env guix system reconfigure <os-config>" from that built git checkout. <mark_weaver>scrubmin: make sure to pass --localstatedir=/var to configure <Steap>ACTION is about to drop a nice hack on guix-devel <codemac>Does guix have copyright assignment papers I should submit for my patch? I just realized I forgot. <davexunit>I think the container code will have to wait another release. <davexunit>too many issues cropping up and I'm going to be afk for a week. :( <paron_remote>davexunit: ah well, sometimes this happens. don't despair! It's still awesome stuff :) <davexunit>mark_weaver: surprisingly, tests/containers.scm passes inside the guixsd container I'm currently running <davexunit>and all but one test in tests/syscalls.scm passes <davexunit>but that test isn't related to the new syscall wrappers I've added <davexunit>so I imagine that it's a test that is skipped during our builds <davexunit>"set-network-interface-address" is the test in question. <davexunit>now why does 'make' segfault in the container <scrubmin>Im trying to build guix and autoconf spits out a bunch of undefined macros <davexunit>scrubmin: the guile m4 macros need to be on our ACLOCAL_PATH <davexunit>what distro are you using? you probably need to install the "guile-dev" package or whatever. <davexunit>scrubmin: oh, well 'guix environment guix' will a spawn a shell with everything you need to build guix <scrubmin>davexunit: I'm still getting undefined macros I typed "guix environment guix --exec=autoconf" is that the correct way to use it? <scrubmin>I get "/gnu/store/cjr6hq2habc11g1g1yq8i2l2ca3x2dp4-automake-1.15/share/aclocal:/gnu/store/d7dzj3xrp93xwc2pm1mspaw7x9byc6mh-gettext-0.19.4/share/aclocal:/gnu/store/hjwxp8szsf8zhbpf32k5xld69q2fizsc-pkg-config-0.28/share/aclocal:/gnu/store/r16v30hlw2d6n232rm37p53qy8rpr7f2-libgcrypt-1.6.3/share/aclocal:/gnu/store/63lp72xz64axrbrlvpyln449v42h0zbh-libgpg-error-1.18/share/aclocal:/gnu/store/5cqm1pk28agrc5yys99c6ng8i9ki5chg-guile-2.0.11/shar <scrubmin>nevermind I think autoreconf --install did the trick <paron_remote>I discovered that I'm not hitting the (guix build syscalls) issue if I go back a number of commits <paron_remote>60a56db0074259355a590851131aa23e1549fd8c specifically works for me, but master does not work <paron_remote>guess maybe it's related to the other issues discussed above though. oh well <chipb>huh. has sourceforge started mangling source tarballs too? I'm getting repeated hash mismatch downloads of sqlite. <chipb>guix download it from the sqlite.org site itself, and I get the expected hash. go figure... ***tschwing_ is now known as tschwinge
<phant0mas>Guix on Hurd 23 tests pass, 14 left to go :-) <tyrion-webchat>is anyone of you connecting with tor to freenode? because I am failing to do so <Steap>chipb: sourceforge has been known for doing "weird" things with the tarballs <tyrion-webchat>anyway, yesterday I fell asleep and could not install guix, is it possible to do it using the wifi to connect to the internet? <phant0mas>hey mark_weaver, I am getting 'guix build: error: build failed: a `i686-hurd' is required to build `/gnu/store/8q3m8f7yjwfishvb0bi0pn4hqgdy5bw2-guile-bootstrap-2.0.drv', but I am a `i686-gnu'' <phant0mas>is it because the tarballs were built with target i586-pc-gnu, but in hurd I am using configure --with-system=i686-hurd? <breton>Jookia: I guess he is, it's just night where he lives :) <Steap>14:29 < breton> davexunit is not here <Steap>14:29 < Jookia> breton: is he ok <davexunit>paron_remote: reading the issues you had with master, I think I need to include an additional module in the virtual machine derivations. <breton>davexunit: I asked folks from Murano how their thing works <davexunit>breton: oh cool. did you learn anything interesting? <breton>they have a daemon running on a target machine, which listens to rabbitmq <breton>(I am not sure what it is yet, I'm in process of finding out) <davexunit>I probably won't use any of those things, unless I *have* to use heat. <davexunit>I didn't realize YAML was so widespread. it's such a bad markup language. <breton>it's human-readable, widely spread <Steap>ACTION works on OpenStack and does not know Murano :D <davexunit>breton: HOT may be useful, but guix would hide all of that nastiness. :) <paron_remote>davexunit: I also had those same problems with the container launch thing after I rebased it <paron_remote>davexunit: however! I did switch to the wip-deploy branch and ran the example from your email <davexunit>paron_remote: I got it fixed for vms, but I'm concerned that I broke something else. <davexunit>paron_remote: system booted without issues. going to patch master now. <phant0mas>guix daemon chroot support on hurd not working thanks to the non existent mount.h <scrubmin>I just ran "./pre-inst-env guix system reconfigure <my-config>" on a git checkout of guix, do I need to do "make install" or was that it? <mark_weaver>phant0mas: it sounds like you need to pass --with-system=i686-gnu to configure when building guix on hurd, and we should eventually fix it so that it auto-detects that properly. <phant0mas>I already did pass it :-) I am working on the chroot issue now <mark_weaver>inexplicably, applying a security update to openssl seems to broken the python2-urwid build, which wicd depends on :-( <davexunit>I was very excited when I first saw both qemu VMs boot. <davexunit>scrubmin: that's it. just use guix via './pre-inst-env guix' now <davexunit>wgreenhouse: on of our "work in progress" branches <zacts>my only personal critique of guix as a package manager on debian <zacts>is that I don't like setting up tons of PATH variables in my bashrc or whatever <zacts>I guess you can do 'source guix.bash' <zacts>but it still seems kind of messy to me <davexunit>'guix package --search-paths' outputs it all, though. <zacts>maybe something like what rbenv does? dont' know... <zacts>where guix handles all the paths for you, so you don't have to manually set paths and other env variables <zacts>davexunit: perhaps not a good comparison <zacts>was guix package --search-paths a reply to my statement, or to paron_remote? <zacts>the other thing is the other env variables <davexunit>it prints out all of the environment variables you needed <zacts>davexunit: are those even non-path env variables? <davexunit>there's some amount of environment variables you just have to deal with because things aren't installed to /usr <zacts>but yes, the main issue was the PATH variables for me <zacts>so that solves it I think, so thanks <zacts>davexunit saves the day, yet again <davexunit>I just dump them in my .bash_profile and forget about them <paron_remote>davexunit: pushed a conflicts-resolved, rebased patch to the list <paron_remote>davexunit: trying to see what I should do next to help things; maybe I should try to get dustycloud.org and mediagoblin.org reproduced with this <davexunit>zacts: for LIBRARY_PATH and CPATH, you can add gcc to your profile. <davexunit>the search path specs are defined in the gcc package <davexunit>paron_remote: depends on how in-depth you want to go. we need an nginx-service :) <davexunit>I would like to see a trivial web application that uses a database <davexunit>something that we have all or most of the packages for already. <davexunit>I was planning on just writing a simple guile web server <paron_remote>davexunit: I've got a little poll application I need to run that I wrote in guile <davexunit>but if trac has minimal setup, that would be great. what's it written in? <paron_remote>davexunit: trac is python, but Debian actually got that one packaged ;) <paron_remote>I could get mediagoblin.org and dustycloud.org to both hook into this <zacts>oh I'm switching my blog from jekyll to pelican too <zacts>jekyll didn't have enough already made themes <davexunit>I'm going to switch from pelican to haunt eventually. <davexunit>but for now, I want to get pelican working again on guixsd <zacts>there is also chicken scheme's hyde egg <zacts>and I know of one person who uses it <zacts>but I think you would have to design your own themes in S-XML and SASS <zacts>and I'm currently too busy to do this <davexunit>I wanted something that was more extensible and functional <davexunit>there's a posts database, and they are all passed to the specified #:builders, who return one or more <page> objects <zacts>a guile equivalent to hyde, haunt, sounds like it would really be great <davexunit>and by "database", I just mean a directory with files. not SQL or anything. <davexunit>and the posts can be any format that there is a reader for. <zacts>oh someone was asking on a scheme channel about functional databases <zacts>(we did end up discovering that the haskell guys were making progress in purely functional database designs) <phant0mas>yaaay part of the daemon works for builds :-D <zacts>and there was a paper on the subject <davexunit>paron_remote: we have pygments, jinja2, six, and maybe a couple more. <paron_remote>as motivation to port mediagoblin.org and dustycloud.org's static rendering over to guixops <davexunit>paron_remote: that sounds like a realistic goal. <paron_remote>okay, I'm on it! That's how I'm spending my afternoon :) <scrubmin>I got guix rebuilt with the ati driver but it still uses vesa :(, how can I fix that? <davexunit>paron_remote: python.scm or web.scm seems fine to me. <davexunit>as long as the web module isn't included in the python module <davexunit>or anything else that would cause a circular dependency <davexunit>I don't think python.scm need only have libraries, there are already full applications in there like pygments <paron_remote>davexunit: okay! will add it in python.scm, less importing foo <mark_weaver>scrubmin: pastebin.com blocks tor users such as myself. please use a different paste service. <scrubmin>mark_weaver: what alternative should I use(I dont know which ones block tor). <paron_remote>feedgenerator (which we have all the dependencies for) and blinker, which I'm looking into <sneek>Welcome back civodul, you have 1 message. <phant0mas>civodul: it's working!! we are building on the hurd vm <phant0mas>had a problem with the daemon, solved/worked around it and now it's building!! <paron_remote>I'm assuming 'License :: OSI Approved :: BSD License', in the metadata is not efficient for us in meeting "it's under this license" requirements <paron_remote>bug filed, but annoying for now. I'll proceed with working on the packaging in a branch but hopefully we can get this fixed. <mark_weaver>the source code definitely needs to specify its own license <mark_weaver>scrubmin: I'm sorry, it's not clear to me what's going on there. <mark_weaver>this line looks worth investigating though: (EE) open /dev/dri/card0: No such file or directory <mark_weaver>I don't know much about what's needed for Radeon support. do you need a non-free driver or blob? <mark_weaver>paron_remote: really, the source files should each contain a copyright notice. <mark_weaver>at the very least, there should be something that makes it clear what license the code is covered by. I don't think the mere presence of a license somewhere in the tarball is sufficient by itself. <paron_remote>mark_weaver: sadly very little in the python world conforms to that <paron_remote>I'm sure that's true in pretty much all popular language communities, sadly. <paron_remote>not like I should judge, mediagoblin has outdated copyright years, but at least we have the headers :) <davexunit>it's no surprise why so many programmers don't like copyleft and stuff. <davexunit>they don't care about licensing much in the first place <davexunit>paron_remote: "ops guys at 2 in the morning" <mark_weaver>the problem is, if the license of the code is not clearly stated, then the author could decide that he didn't really intend to make it free software. <mark_weaver>and it's not clear to me that a court would be persuaded by the argument "well, I found a copy of a free software license in the tarball, so I assumed that everything else in the tarball was covered by that license" <mark_weaver>after all, there are plenty of examples of tarballs that contain a COPYING file but the code is under a variety of different licenses. the COPYING file is just there to satisfy the requirement for the GPL code that the license be included. <mark_weaver>we need to educate the people who don't care about licensing. <davexunit>civodul: there were some mishaps with some of my patches. the clone/setns/pivot-root tests are failing on several build slaves because they run older kernels without user namespace support. :( <davexunit>I've stopped applying patches since. I have no more time to make commits before I go disconnect for a week. <mark_weaver>software is not free software if we must take it on faith that the author won't challenge our rights. <mark_weaver>davexunit: at least one of those tests fails even on a machine with user namespace support. <mark_weaver>(namely jxself's hydra build slave, which is running 3.13 and /proc/self/ns/user exists) <davexunit>mark_weaver: yeah, I need more insight into that. <davexunit>I ran the syscall tests in a guixsd container and 1 network related test failed. <civodul>davexunit: we need to see how it fails, and just tolerate failures that are due to a too old kernel <civodul>like if it's EINVAL, fine, we just mark the test as passed <davexunit>civodul: I had a little snippet that tested that the kernel version was >= 3.8 and that /proc/self/ns/user existed, maybe that could be a condition for running the tests or not. <civodul>maybe checking for /proc/self/ns/user is enough? <davexunit>I'd like to know which test is failing on jxself's machine. I find it hard to debug test suite issues because the backtraces are eaten. <mark_weaver>maybe we should modify the 'check' phase of our guix package to dump the test logs to stdout in case of a failure. <mark_weaver>(it might also be helpful to modify the default 'configure' phase in gnu-build-system to dump the contents of config.log in case of an error) <davexunit>logs are our only means of introspection into build failures <davexunit>paron_remote: do you use markdown for your pelican sites? if so, you'll also need to package the python library it uses for that. <davexunit>civodul: I've noticed a couple of additional container issues. 'make' segfaults inside of 'guix environment --container', and bash tab completion throws errors about 'setpgid'. <davexunit>I don't know exactly what's going on with the first one, but I think the container will need /bin/sh for starters. <davexunit>I'm guessing the second issue comes from the fact that the process group is probably only accessible outside of the container or something. <davexunit>I was hoping to avoid the setsid and psuedo-terminal stuff for now because I don't fully understand it, but it looks like it needs fixing. <davexunit>paron_remote: oh don't worry about it if you don't need it <davexunit>because it's an optional dependency for pelican <paron_remote>but I think we have one mediagoblin post that's in markdown <paron_remote>I kind of like rst, it's pretty okay as far as markup things go <paron_remote>if I'm gonna do loose markup things though, orgmode is da best <amz3>rst blocks are not very friendly <davexunit>just wish it was easier to implement org-mode parsers. <amz3>I only know the basics of org-mode <paron_remote>davexunit: not to mention that it's soooo easy to change the orgmode defaults so your orgmode works nothing like anyone else :) <paron_remote>davexunit: sorrrta, there are some "kinda discouraged" variables you can set <paron_remote>but that got more discouraged in the ~standardizing the format in the switch to org-node export format <davexunit>there very well could be, I just can't find it. :) <davexunit>paron_remote: btw, use 'guix import pypi' to make your life easier <paron_remote> raise ValueError('ZIP does not support timestamps before 1980') <paron_remote>I had it install from git, because that has the proper license stuff <paron_remote>I guess I could rename the whole directory to be in the 1980s ;p <rekado>paron_remote: take a look at python2-elib.intl <rekado>you may have to pass a configure flag to fix this. <civodul>davexunit: does 'guix environment something --container -E "setsid /bin/sh"' work better? <civodul>bavier1: hadn't you started looking at improving 'guix refresh -l' wrt. to implicit inputs? <civodul>maybe we're missing something in /dev <paron_remote>I figured it suffered the same anti-copyleft stance as similar tools in its space :) <paron_remote>civodul: pretty nice static site publishing software written in python <paron_remote>so does mediagoblin.org (the homepage, not mediagoblin itself) <paron_remote>civodul: I'm going to try to do a real usecase of guix ops <paron_remote>since both mediagoblin.org and dustycloud.org use pelican <paron_remote>it gives me something to actually test getting up and running with as a baseline <civodul>paron_remote: you actually run pelican on the servers themselves? <civodul>if it's for static sites, i imagine you could simply run it on your laptop and then upload the HTML, no? <paron_remote>civodul: I set up a build process that builds on the server mainly because I kept accidentally building my dev environment and pushing that ;) <paron_remote>civodul: I'm excited to get the website itself to be a package and build a derivation of that :) <civodul>you could even transfer it using 'guix archive' <codemac>In the guix docs I didn't see this - when declaring a system you want to set up with `guix system vm-image` I was curious what options (like bootloader, root disk, etc) are necessary? <civodul>codemac: you have to specify the same options are usual, but some are ignored or overridden <codemac>ok - is there any way I can help document it? guix is certainly a very convenient way to create vm images. <civodul>codemac: sure; it would be ideal to add a link in guix.texi, under the 'vm-image' description <wgreenhouse>looks like a very convenient way to make custom liveusb systems, too <civodul>yes, that's quite convenient for that