IRC channel logs

<cehteh>while ! guix system init ...; do sleep 5; done ... grr

<taylanub>Hydra cannot exactly be mirrored AFAIK (since it's constantly building new stuff) but someone was working on P2P binary substitutes over GNUnet

<cehteh>would be cool in the long run

<davexunit>how do we deal with packages that try to install stuff into the dbus store directory?

<davexunit>I'm pretty sure this has come up before

<davexunit>trying to package bluez, for bluetooth stuff

<iyzsong>davexunit: I think we have no choice, but patch it into $out/share/dbus-1/services, etc.

<davexunit>iyzsong: okay

<davexunit>in which module would you folks put a package for 'libical'?

<davexunit>it's a library for dealing with the iCal calendar format

<rekado->I'm very happy with my GuixSD audio workstation running on a Thinkpad T60. It all just works.

<rekado->I have a lot of collisions relating to "share/icons/hicolor/icon-theme.cache" -- is this something we can delete from package outputs?

<rekado->packages installing this file are calf, ibus, emacs, inkscape, exo, libxfce4ui, thunar, ... and a couple more.

<taylanub>hmm, I copy mesa's $mesa/include/GL directory to /tmp/xyz/GL and add /tmp/xyz to the front of CPATH, but e.g. "#include <GL/glext.h>" still uses $mesa/include/GL/glext.h and not /tmp/xyz/GL/glext.h

<taylanub>am I missing something? otherwise I guess Qt's build system must be doing something undesirable.

<joolean>Having some trouble doing a pre-inst-env guix build. coreutils bails out of configure if guix-daemon runs the build as root, and if I add --build-users-group, weird stuff happens - I get logged out of my current GNOME desktop session, e.g.

<joolean>Any ideas?

<taylanub>joolean: I think one should always use --build-users-group with a dedicated 'guix-builder' group and a number of 'guix-builder-x' users in that group

<joolean>Okay.

<joolean>(How many?)

<taylanub>the manual tells to just create 10 of them. in practice, it depends on how many builds you will possibly want to run in parallel AFAIK.

<taylanub>one 'guix build' call will use up one user, AFAIUI

<paroneayea>oh! davexunit

<paroneayea>did you see:

<paroneayea> https://twitter.com/sirgazil/status/592072138061979649

*paroneayea is excited

<davexunit>paroneayea: awesome!

<davexunit>he showed us a mockup a few months back that looked something like this

<davexunit>but this is much improved

<davexunit>grr, having locale issues.

<davexunit>no idea how to fix this one.

<davexunit>I got a package to build, but then it complains that it can't set the locale to en_US

<davexunit>and then crashes later :)

<paroneayea>uhoh!

<paroneayea>davexunit: using the gnu-build-system I assume?

<paroneayea>it does have a setup locale thing

<paroneayea>though I don't know how it works :)

<cehteh>can guix use a http proxy for downloading?

<davexunit>paroneayea: it's some runtime issue thing... I haven't traced it enough to know why it happens, though

<rekado->davexunit: is it a python application?

<rekado->(I have seen something like this in both solfege and ibus-pinyin, both Python applications.)

<davexunit>rekado-: no, c++

<davexunit>ohhh I see

<davexunit>it's trying to open stuff like /run/current-system/locale/en_GB.UTF-8/LC_IDENTIFICATION

<davexunit>but I'm not using guixsd

<davexunit>is there an environment variable I can tweak to get around this, maybe?

<davexunit>YES. got it to work

<davexunit>set $LOCPATH to point at the glibc locales in /gnu/store

<davexunit>and now the dolphin emulator works! :)

<rekado->I installed some glibc locales package and pointed LOCPATH at ~/.guix-profile/lib/locale

<rekado->iiuc this is something the user should be doing, not the application.

<davexunit>yeah

<davexunit>that's what I did

<rekado->ah, ok.

<paroneayea>woo re: dolphin emulator!

<davexunit>it's still a long way from being acceptable to include in guix, but hell I got it to build.

<paroneayea>davexunit: two off topic things btw on my mind!

<paroneayea>davexunit: 1) do you think there ever might be a way that "guix environment" and building a package for the targeted project in guix might have more symmetry?

<paroneayea>eg if I have a package.scm in mediagoblin

<paroneayea>could some of that info actually be used to make the guix package

<paroneayea>davexunit: 2) I wonder if you might be interested in writing up a blogpost on GuixOps, or give me resources you think I should read up on

<paroneayea>I think I'd like to help on it.

<paroneayea> http://nixos.org/nixops/ I guess I should print out the paper.

<davexunit>paroneayea: answer to question 1: I'd like to have the package.scm files used for guix environment to be real, buildable packages

<paroneayea>davexunit: awesome.

<davexunit>the current issue there is how to tell guix to use the root of the source tree as the 'source' field and don't do checksums

<paroneayea>why not do checksums?

<davexunit>it's impossible

<paroneayea>oh wait

<paroneayea>I see.

<paroneayea>you're kind of recursing on the package building operation?

<paroneayea>maybe I see ;)

<davexunit>well, no.

<davexunit>the issue is that your git checkout of a project will never have a reliable hash

<davexunit>well, maybe you mean this sort of recursion:

<davexunit>it's impossible to take the hash of the source tree, including the package defintion that needs that hash

<davexunit>it's why the guix-devel package in (gnu packages package-management) always points to an earlier commit

<davexunit>furthermore, the contents of .git or whatever will be constantly changing

<paroneayea>I s33

<paroneayea>see

<paroneayea>damnit

<davexunit>so, I dunno how to actually make a buildable package to keep in my project repos that doesn't have to do the same sort of thing

<davexunit>well... I think I might know a way that would work

<davexunit>write a procedure that does the hashing when the package expression is evaluated

<davexunit>I should try that right now...

<paroneayea>can the hashing procedure potentially ignore .git?

<davexunit>no

<davexunit>but I could just use the git-fetch download method on a file:/// URI

<davexunit>which will DTRT

<paroneayea>hm

<paroneayea>so basically, duplicate the checkout

<davexunit>yeah, the source has to end up in the store somehow

<davexunit>otherwise it can't be built

<paroneayea>that could be time consuming on very large repositories for just doing something like "guix environment"

<paroneayea>eg if you're hacking kernel source

<davexunit>the alternative is to duplicate everything and include the .git directory in the store

<davexunit>using url-fetch

<davexunit>the source *must* go in the store

<paroneayea>yeah I guess if you're going to go the symmetry route

<paroneayea>there's no way around it

<davexunit>what do you mean by symmetry?

<paroneayea>davexunit: well, you have sly/package.scm right

<paroneayea>why not just have the build-system actually be a bit recursive: check out sly, then actually use the definition in sly/package.scm as the basis for building it

<paroneayea>then the sly package definition could be very minimal

<paroneayea>or:

<paroneayea>maybe the sly package definition used in "guix environment" could export something to dump into guix/gnu/packages/

<paroneayea>anyway that's what I meant by symmetry, avoiding defining twice

<davexunit>I plan on doing the former.

<davexunit>well, if the package were upstreamed, you'd have to define it twice.

<davexunit>no way around that. the guix upstream version would use a release tarball.

<paroneayea>yeah

<davexunit>and the package in the repo would use your own checkout and would have other dev related tweaks

<davexunit>since it would need to do the autotools bootstrapping

<paroneayea>yeah

<paroneayea>makes sense

<paroneayea>davexunit: I hope I'm not being annoying with these questions btw

<davexunit>not at all

<paroneayea>davexunit: also, for your amusement http://anderspapitto.com/posts/2015-02-28-deb-installation-nixos.html

<davexunit>it has inspired me to try to write a useful hack!

<davexunit>paroneayea: heh, that's pretty neat

<paroneayea>:)

*paroneayea now reading on the gnu distribution system configuration stuff to try to get a sense of how guixops will work

<paroneayea>uhoh

<paroneayea>looks like the side of my Reasoned Schemer book is now reserved for tea stains.

<ijp>they've grown up slightly, it used to be jelly stains

<davexunit>haha

<cehteh>mhmpf .. i am giving up on GSD ... no matter what i try it always fails somehow

<davexunit>paroneayea: https://chimeracoder.github.io/docker-without-docker

<davexunit>useful little slideshow

<davexunit>invokes my desire to write a replacement for systemd-nspawn

<paroneayea>yeah

<davexunit>cehteh: from what I saw before, it sounds like you may have a somewhat complicated setup that we don't handle gracefully yet.

<cehteh>davexunit: eh?

<davexunit>cehteh: have you written about the issues you were having to the mailing list?

<cehteh>i just started with an empty VM

<davexunit>oh, okay.

<cehteh>one time grub barfed out, antother the tar testsuite failed, etc

<davexunit>the tar test suite? umm...

<cehteh>when building it, its running make check

<davexunit>have you been building the entire distro from source?

<cehteh>that time hydra failed to send the package and it --fallback to building

<cehteh>well hydra fails a lot

<davexunit>yes, known issue.

<davexunit>it's an overloaded VM that we are replacing

<cehteh>i am wondering if one could create a bunch of proxy servers to lessen the burden on hydra

<davexunit>we have new dedicated server being built that will improve things for the short-term

<cehteh>like say 4-8 first tier caches, and then anyone else can donate some proxy which connects to these

<paroneayea>does Hydra run GuixSD? :)

<davexunit>paroneayea: not yet

<cehteh>an just dns roundrobin iver that pool

<davexunit>because Hydra isn't packaged

<cehteh>is that the nix project hydra?

<cehteh>or a fork thereof?

<davexunit>yes, it's their CI platform

<davexunit>and we run our own instance of it

<cehteh>btw heretic question: was it ever discussed to have some kind of non-free repo?

<paroneayea>guix-heresy should probably exist, but hosted outside of gnu ;)

<cehteh>yes of course

<davexunit>cehteh: we will not include one.

<davexunit>nor will we promote one.

<paroneayea>I think if someone starts guix-heresy, it'll be easy enough to find

<davexunit>yeah.

<paroneayea>and it should be hosted on github, for extra heresy ;)

<davexunit>use/abuse GUIX_PACKAGE_PATH as you wish

<cehteh>well, its a bit of a double edged sword .. of course its not the point to host one, but letting the FSF decide which software i can run would take away some freedom of me as well, so some 'mention' .. not as stong as promotion would be okish imo

<paroneayea>cehteh: but the fsf isn't deciding what software you can run

<paroneayea><davexunit> use/abuse GUIX_PACKAGE_PATH as you wish

<cehteh>yeah i am just overstating :)

<paroneayea>nor is gnu

<cehteh>but you get what i mean i hope

<paroneayea>I certainly get what you mean, though I think it's good to be clear :)

<davexunit>we do not tell you what software you are allowed to run, but we certainly will not be leading users toward proprietary software.

<cehteh>i for myself strongly prefer free software and using gnu/linux since a long time exclusively ..

<cehteh>but there are a few cases where non-free software is necessary

<davexunit>the guixstapo won't track you down if you run skype on your guixsd system.

<cehteh>anyway first i have to get this running

<cehteh>haha .. i hate skype :D .. mor thinking about non-free firmwares for better hardware support etc ..

<davexunit>cehteh: have you tried just using guix on top of another host distro, for starters?

<cehteh>nah

<cehteh>i want to try the whole thing :)

<cehteh>i could try that as last resort :)

<cehteh>but a pure gsd for playing around sounds nice

<davexunit>so you're doing this all from a VM somehow?

<cehteh>yes

<cehteh>i have no spare computer and dont want to trash my productive systems

<davexunit>kvm, something else?

<cehteh>kvm

<davexunit>platform?

<davexunit>x86_64?

<cehteh>x86_64

<cehteh>hey i have an rpi (old one, first series 256mb ram :D) leftver

<davexunit>you won't be able to run guixsd on that.

<cehteh>would be a perfect build plattform right? .. noooo :)

<davexunit>we have an armhf port, but it requires using guix on top of another host system

<cehteh>yes .. first get the basic thing working

<cehteh>(for me)

<cehteh>so http proxy siupport isnt there yet as far i see

<davexunit>I don't use proxies so I don't know the state of that

<davexunit>what are you trying to do with a proxy?

<cehteh>i have a polipo running here locally on a server

<cehteh>could use that to cache http requests .. when tryin installing again :)

<cehteh>as i saied before, would be also nice to have some public proxies in front of hydra to lessen the load there

<cehteh>but thats another thing

<davexunit>I don't know how'd you use such a proxy

<davexunit>because hydra is a dynamic web application

<cehteh>when guix downloads packages from there, these are not statically served?

<cehteh>(or at least have headers indicating their lifetime)

<davexunit>I don't know exactly, but hydra exports binaries in nix archive format

<davexunit>which is then compressed with bz2

<davexunit>we have an nginx frontend that does caching

<davexunit>so repeated downloads of the same binaries is quicker

<cehteh>ah

<cehteh>thats what i was thinking you can chain such caches together

<davexunit>this is really a job for 'guix publish', but it's not very fancy yet.

<cehteh>maybe some people could donate caches

<davexunit>well, the thing is that guix is decentralized in theory

<cehteh>wow .. computer which running the kvm crashed

<davexunit>so rather than a 'cache', people would just run their own 'guix publish' servers

<cehteh>as long its only theory one could build some redneck decentraliization

<cehteh>and i have to get a guix system working here at first

<davexunit>it wouldn't work the way you are expecting it to

<davexunit>you could run guix on one machine, build your OS config with 'guix system build config.scm', which would download *everything* needed for that system. then, from the installation image, you could authorize that guix machine as the one to server binaries.

<davexunit>and bam, local binaries.

<cehteh>yeah

<cehteh>i am strill struggeling at the very first part :)

<davexunit>I wrote 'guix publish' for this purpose.

<davexunit>it does the basics, but it doesn't compress archives or anything yet.

<cehteh>server completely locked up .. fscking now

<davexunit>Tsyesika: bummer about the keybaord thing :(

<davexunit>I'm not sure what steps we should take to troubleshoot

IRC channel logs

2015-04-26.log