IRC channel logs


back to list of 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>(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 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>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>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> 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
<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>but I could just use the git-fetch download method on a file:/// URI
<davexunit>which will DTRT
<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>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.
<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>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
<davexunit>it has inspired me to try to write a useful hack!
<davexunit>paroneayea: heh, that's pretty neat
*paroneayea now reading on the gnu distribution system configuration stuff to try to get a sense of how guixops will work
<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
<cehteh>mhmpf .. i am giving up on GSD ... no matter what i try it always fails somehow
<davexunit>useful little slideshow
<davexunit>invokes my desire to write a replacement for systemd-nspawn
<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
<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>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>i have no spare computer and dont want to trash my productive systems
<davexunit>kvm, something else?
<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>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>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