IRC channel logs


back to list of logs

<scrubmin>Hello fella's, im gnu here
<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
<scrubmin>Ok I will try to do that.
<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>codemac: nope.
<davexunit>we don't do copyright assignment.
<codemac>thanks - just checking :)
<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>paron_remote: :)
<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
<scrubmin>How do I fix that?
<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.
<scrubmin>using guixsd
<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?
<davexunit>better to just spawn a new shell
<davexunit>so leave off the exec
<davexunit>just 'guix environment guix'
<davexunit>and then 'echo $ACLOCAL_PATH'
<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>which I was also hitting for "guix system vm" commands
<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 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>ok, it seems tor is disabled
<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?
<tyrion-webchat>instead of the ethernet cable, as you reccommended yesterday
<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?
<phant0mas>yes that was the problem
<breton>davexunit is not here
<Jookia>breton: is he ok
<breton>ok, I'll tell later then
<breton>Jookia: I guess he is, it's just night where he lives :)
<davexunit>morning guix
<Steap>"is he ok"
<Steap>davexunit: are you ok ?
<davexunit>yes, of course.
<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.
<davexunit>I'll try to replicate and fix right now.
<breton>ok, he is here
<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>and they somehow use heat templates --
<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>why? I like yaml :)
<breton>it's human-readable, widely spread
<davexunit>s-expressions far better.
<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: cool
<paron_remote>davexunit: I also had those same problems with the container launch thing after I rebased it
<paron_remote>davexunit: also!
<paron_remote>I'm being dumb
<paron_remote>that wasn't container related at all.
<paron_remote>sorry it's early
<paron_remote>yes you're right just VMs
<paron_remote>davexunit: however! I did switch to the wip-deploy branch and ran the example from your email
<paron_remote>and *that* ran great
<davexunit>paron_remote: nice! :)
<davexunit>paron_remote: I got it fixed for vms, but I'm concerned that I broke something else.
<davexunit>reconfiguring my laptop to see
<davexunit>not so scary thanks to rollbacks
<davexunit>paron_remote: system booted without issues. going to patch master now.
<davexunit>thanks for finding the bug!
<davexunit>paron_remote: fixed pushed to master.
<paron_remote>davexunit: great!
<paron_remote>davexunit: I'll rebase my rebased branch :)
<phant0mas>guix daemon chroot support on hurd not working thanks to the non existent mount.h
<paron_remote>*compile compile compile*
<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
<paron_remote>davexunit: awwwww yisss
<paron_remote>wip-deploy rebased and now working on master
<mark_weaver>inexplicably, applying a security update to openssl seems to broken the python2-urwid build, which wicd depends on :-(
<davexunit>mark_weaver: oh no :(
<davexunit>paron_remote: oh yeah! :)
<paron_remote>*kool-aid man busts through the wall*
<davexunit>paron_remote: exactly :)
<davexunit>I'm glad wip-deploy works for you
<davexunit>along with the example deployment file
<davexunit>I was very excited when I first saw both qemu VMs boot.
<paron_remote>davexunit: me too :)
<wgreenhouse>davexunit: wip-deploy?
<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>it can end up being a mess
<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...
<davexunit>rbenv sucks, I use it daily.
<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
<davexunit>eval $(guix package --search-paths)
<zacts>was guix package --search-paths a reply to my statement, or to paron_remote?
<davexunit>to you
<zacts>oh cool, ok
<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?
<zacts>like which openssl to use?
<zacts>and ca_certs?
<davexunit>which openssl to use? like LIBRARY_PATH?
<zacts>or the GIT_LIBRARY_PATH
<davexunit>no, just set it to your profile
<davexunit>there's some amount of environment variables you just have to deal with because things aren't installed to /usr
<zacts>I see
<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
<davexunit>occasionally I have to add another one.
<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 and 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>and have it all "just work"
<paron_remote>davexunit: maybe Trac would be a good candidate
<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>which is a good sign
<paron_remote>davexunit: if pelican could get packaged
<davexunit>I want that one, personally. :)
<paron_remote>I could get and 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>ACTION looks up haunt
<davexunit>zacts: you won't find much, I wrote it.
<paron_remote>davexunit: the knights who say NIH? :)
<zacts>oh I see!
<zacts>there is also chicken scheme's hyde egg
<zacts>and I know of one person who uses it
<davexunit>example config:
<davexunit>paron_remote: hehe yes
<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
<zacts>well not equivalent
<davexunit>the site is a union of all <page> objects
<zacts>oh cool
<davexunit>and by "database", I just mean a directory with files. not SQL or anything.
<davexunit>like jekyll, pelican, etc.
<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
<davexunit>anyway, enough spamming guix with this.
<zacts>oh indeed
<davexunit>I was reprimanding myself :)
<davexunit>not you
<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
<paron_remote>davexunit: this looks pretty feasible
<zacts>and there was a paper on the subject
<phant0mas>on hurd
<davexunit>paron_remote: !
<davexunit>we have most of these, I think.
<zacts>phant0mas: oh wow, coolio!
<davexunit>paron_remote: we have pygments, jinja2, six, and maybe a couple more.
<paron_remote>davexunit: I'll try to package pelican then
<paron_remote>as motivation to port and'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?
<scrubmin>Here is my xorg.scm
<scrubmin>And my xorg log file
<paron_remote>where should pelican go?
<paron_remote>it's not really a library so python.scm seems wrong
<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: blocks tor users such as myself. please use a different paste service.
<scrubmin>ok sorry
<scrubmin>mark_weaver: what alternative should I use(I dont know which ones block tor).
<paron_remote>scrubmin: or are both good
<paron_remote>okay nice, so
<paron_remote>only two dependencies to add for pelican
<paron_remote>feedgenerator (which we have all the dependencies for) and blinker, which I'm looking into
<scrubmin>mark_weaver: xorg log: | xorg.scm:
<paron_remote>wowww okay, even though feedgenerator is free software
<paron_remote>there's no license included
<paron_remote>it's not necessarily
<paron_remote>but it's based on django code
<paron_remote>the metadata says BSD
<paron_remote>but there is no COPYING
<paron_remote>and no headers
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, daviid says: did you see this
<paron_remote>ACTION files a bug
<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!!
<civodul>yay, congrats phant0mas!
<civodul>ACTION needs to catch up
<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>it needs the COPYING/LICENSE file in the source, yeah?
<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.
<scrubmin>ok :(
<scrubmin>I will eventually solve it~
<mark_weaver>this line looks worth investigating though: (EE) open /dev/dri/card0: No such file or directory
<mark_weaver>maybe you are lacking a kernel module or something
<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>I don't know the answer
<mark_weaver>paron_remote: really, the source files should each contain a copyright notice.
<davexunit>paron_remote: there is a LICENSE file
<paron_remote>davexunit: he just added it now
<davexunit>oh lol
<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.
<davexunit>paron_remote: that was quick
<paron_remote>mark_weaver: sadly very little in the python world conforms to that
<paron_remote>even little things like django
<paron_remote>even big things :)
<paron_remote>most of django's source files lack a copyright notice.
<paron_remote>and that's true for most python libs I see :|
<paron_remote>I'm sure that's true in pretty much all popular language communities, sadly.
<davexunit>people are sloppy about it
<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
<paron_remote>davexunit: breton: unrelated to the above:
<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>honestly, I think I'd get laughed out of court.
<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)
<mark_weaver>*linux-libre 3.13
<davexunit>mark_weaver: yeah, I need more insight into that.
<mark_weaver>ACTION goes afk for a while
<davexunit>I ran the syscall tests in a guixsd container and 1 network related test failed.
<davexunit>all the syscall tests I added passed.
<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
<civodul>but we can look into it
<civodul>(while you're away)
<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>oh sure
<civodul>maybe checking for /proc/self/ns/user is enough?
<davexunit>should be, but I can't say for certain.
<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>I think that would be good.
<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.
<paron_remote>davexunit: hm not normally
<paron_remote>davexunit: but I'll package it anyway!
<davexunit>paron_remote: oh don't worry about it if you don't need it
<davexunit>I was just curious
<davexunit>because it's an optional dependency for pelican
<paron_remote>davexunit: I usually use rst or html
<paron_remote>but I think we have one mediagoblin post that's in markdown
<paron_remote>so might as well.
<davexunit>oh okay
<paron_remote>I kind of like rst, it's pretty okay as far as markup things go
<paron_remote>it's a lot less bad than markdown
<paron_remote>if I'm gonna do loose markup things though, orgmode is da best
<davexunit>I used rst, but I think I prefer markdown.
<amz3>rst blocks are not very friendly
<davexunit>org-mode is best by far, of course.
<davexunit>just wish it was easier to implement org-mode parsers.
<amz3>I only know the basics of org-mode
<paron_remote>davexunit: there's a standard for it now, but yeah
<paron_remote>it's not easy
<paron_remote>davexunit: not to mention that it's soooo easy to change the orgmode defaults so your orgmode works nothing like anyone else :)
<davexunit>but the file format stays the same right?
<paron_remote>davexunit: sorrrta, there are some "kinda discouraged" variables you can set
<paron_remote>so that pretty strong fundamentals change
<davexunit>ah I see
<paron_remote>but that got more discouraged in the ~standardizing the format in the switch to org-node export format
<davexunit>I can't find the standard
<paron_remote>I though ttheree was such a thing
<davexunit>there very well could be, I just can't find it. :)
<paron_remote>davexunit: maybe the new parser is the standard ;)
<paron_remote>oh hey btw
<paron_remote>I'm packaging things now for pelican
<paron_remote>should this be one patch or many for the dependencies?
<davexunit>one patch for each new package
<paron_remote>got it, can do
<paron_remote>thx davexunit
<davexunit>maybe this?
<paron_remote>davexunit: there it is :)
<davexunit>moved conversation to #guile. :)
<davexunit>paron_remote: btw, use 'guix import pypi' to make your life easier
<paron_remote>davexunit: already using it
<davexunit>paron_remote: good!
<paron_remote> raise ValueError('ZIP does not support timestamps before 1980')
<paron_remote>ValueError: ZIP does not support timestamps before 1980
<paron_remote>lol what
<paron_remote>that's while it was trying to install the feedgenerator
<paron_remote>I bet I know!
<davexunit>guix sets all timestamps to 0
<paron_remote>I had it install from git, because that has the proper license stuff
<paron_remote>but yeah, then it's trying to zip it up in the sdist
<paron_remote>and it breaks
<paron_remote>hm, I wonder how to fix this
<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>ISTR discussing it long ago
<paron_remote>rekado: aha thanks!
<paron_remote>that worked, thanks rekado
<davexunit>civodul: inappropriate ioctl for device
<civodul>interesting :-)
<civodul>well, we'd need to strace it
<civodul>maybe we're missing something in /dev
<paron_remote>wow, I had no idea pelican was AGPLv3
<paron_remote>the things you learn while packaging!
<paron_remote>I figured it suffered the same anti-copyleft stance as similar tools in its space :)
<paron_remote>however no visible "or later"
<civodul>what's pelican?
<paron_remote>civodul: pretty nice static site publishing software written in python
<paron_remote>davexunit and I both use it
<paron_remote>so does (the homepage, not mediagoblin itself)
<civodul>oh, ok
<paron_remote>civodul: I'm going to try to do a real usecase of guix ops
<paron_remote>by using pelican publishing
<paron_remote>since both and 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 ;)
<davexunit>ACTION goes AFK for a week
<davexunit>happy hacking!
<paron_remote>have a good vacation davexunit !
<civodul>paron_remote: i see :-)
<paron_remote>civodul: but yes that's what I used to do ;)
<paron_remote>civodul: I'm excited to get the website itself to be a package and build a derivation of that :)
<civodul>yes, that's pretty cool :-)
<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?
<paron_remote>civodul: yeah :)
<civodul>codemac: you have to specify the same options are usual, but some are ignored or overridden
<civodul>like the bootloader and root disk
<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