IRC channel 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.

<scrubmin>thanks

<mark_weaver>scrubmin: make sure to pass --localstatedir=/var to configure

<paron_remote>hm

<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.

<paron_remote>o/

<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

<davexunit>hmm

<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>ok

<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>e/aclocal

<scrubmin>"

<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 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>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>folks

<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>hahah

<Steap>"is he ok"

<Steap>davexunit: are you ok ?

<davexunit>hmm?

<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 -- http://docs.openstack.org/developer/heat/template_guide/

<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>er

<paron_remote>wait

<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>:)

<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 :-(

<mark_weaver>bizarre

<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

<davexunit>one*

<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

<davexunit>need*

<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>yeah

<zacts>or the GIT_LIBRARY_PATH

<davexunit>no, just set it to your profile

<zacts>ok

<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

<davexunit>cool

<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.

<zacts>ok

<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>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

<davexunit>yeah

<paron_remote>davexunit: if pelican could get packaged

<davexunit>I want that one, personally. :)

<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>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>hehe

<davexunit> https://git.dthompson.us/haunt.git

<zacts>there is also chicken scheme's hyde egg

<zacts>and I know of one person who uses it

<davexunit>example config: https://git.dthompson.us/haunt.git/blob/HEAD:/example/haunt.scm

<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

<zacts>cool

<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

<zacts>analogous

<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

<zacts>sorry

<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: https://github.com/getpelican/pelican/blob/master/setup.py#L4 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 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 :)

<davexunit>woo!

<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 http://pastebin.com/ugjemY9n

<scrubmin>And my xorg log file http://pastebin.com/FiCDXbkv

<paron_remote>where should pelican go?

<paron_remote>it's not really a library so python.scm seems wrong

<paron_remote>web.scm?

<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>ok sorry

<scrubmin>mark_weaver: what alternative should I use(I dont know which ones block tor).

<paron_remote>scrubmin: paste.lisp.org or pamrel.lu are both good

<scrubmin>alright

<mark_weaver>paste.lisp.org/new

<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: http://pamrel.lu/c7be7/ | xorg.scm: http://pamrel.lu/74e39/

<paron_remote>wowww okay, even though feedgenerator is free software

<paron_remote>there's no license included

<paron_remote>welllll

<paron_remote>it's not necessarily

<paron_remote>but it's based on django code

<paron_remote>argh

<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 http://lists.nongnu.org/archive/html/g-wrap-dev/2015-07/msg00001.html

<paron_remote>ACTION files a bug https://github.com/dmdm/feedgenerator-py3k/issues/7

<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~

<scrubmin>*!

<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

<scrubmin>hmm

<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>er

<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: http://cube-drone.com/comics/c/alien-geometries

<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>yeah

<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 :)

<paron_remote>else's

<davexunit>haha

<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

<paron_remote>hm

<davexunit>there very well could be, I just can't find it. :)

<paron_remote>davexunit: maybe the new parser is the standard ;)

<davexunit>hehe

<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>np

<davexunit>paron_remote: http://orgmode.org/worg/dev/org-syntax.html

<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

<paron_remote>:)

<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>OHHHH

<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>heh

<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 mediagoblin.org (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 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 ;)

<davexunit>ACTION goes AFK for a week

<davexunit>happy hacking!

<paron_remote>have a good vacation davexunit !

<davexunit>thanks!

<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

<civodul>s/link/explanation/

<wgreenhouse>looks like a very convenient way to make custom liveusb systems, too

<civodul>yes, that's quite convenient for that

IRC channel logs

2015-07-10.log