IRC channel logs

<orbea>interesting https://github.com/alezost/guix.el

<davexunit>orbea: guix comes with guix.el

<orbea>cool

<orbea>is that guixsd, guix or both?

<davexunit>both

<orbea>:)

<davexunit>the guix git repo has guix.el

<davexunit>it's maintained alongside the CLI

<davexunit>and the rest of guix

<xd1le>davexunit: so has development of it moved to the guix repo instead?

<xd1le>because i would prefer it in a separate repo of it's own like in https://github.com/alezost/guix.el, and maybe just have a submodule reference of it in the main guix repo

<xd1le>(this is because i manage my emacs packages using submodules, and I wouldn't want to update the guix.el package everytime there's a commit to the guix repo which is unrelated to guix.el)

<orbea>heh.... "guix package: error: search=guix.el: extraneous argument"

<davexunit>xd1le: it's development is done in the main guix git repo, yes.

<davexunit>and it makes very much sense to do so

<davexunit>keeping a separate guix.el repo in sync with the developments of the main guix git repo would be very difficult

<davexunit>this is the same reason why we maintain all of the packages together

<davexunit>just like Linux maintains all of the drivers in the same source tree

<xd1le>davexunit: makes sense, although i still think it's possible to use submodules to do it

<xd1le>but i guess this is more a fault of me using submodules to manage emacs packages

<davexunit>submodules are ugly

<xd1le>(git submodules are not a very well featured part of git unfortunately)

<xd1le>yeah

<davexunit>there are really no significant advantages to maintaining the code separately

<xd1le>yeah, true

<davexunit>it would only lead to confusion when people use the wrong guix.el with the wrong guix

<xd1le>i wouldn't want to change the project's development method just for the way i do things, it should probably be the other way around

<xd1le>(unless there's like some clear advantage to the project itself)

<xd1le>davexunit: also orbea had a question i think btw.

<davexunit>oh?

<xd1le>davexunit: orbea said: 'heh.... "guix package: error: search=guix.el: extraneous argument"' above

<davexunit>sounds like a cli syntax error

<xd1le>anyway, i guess git subtrees are the solution for me here, but I hate that they check in the subprojects files into the main repository. ugh :/

<xd1le>one day i'll probably just switch to using guix to manage emacs packages...

<orbea>xd1le: no question, just amused my search query didn't work

<orbea>oh i see, I missed typed search instead of --search, derp

<orbea>sed 's/missed//g'

<xd1le>orbea: no worries

<davexunit>sweet. made a VM that boots into Kodi

<fps>ok, my vm doing the build of everything just froze at some point ;)

<fps>seems to be mostly an X/vnc/qemu problem though

<taylan>sneek: later tell civodul I certainly wouldn't mind it. It might take a little longer until I'm back to productivity...

<sneek>Okay.

<fps>oh nice.. qt fails to build

<fps>now everytime a package has qt5 as dependency it tries to build qt5 again

<fps>oops, coffee. brb

<fps>ok, that's an immense waste of electricity and entropy in general

<fps>time to rethink this whole thing in scheme :)

<fps>basically: start with the complete list of packages. start to build each one. if anyone _or_ one of its dependencies fails to build, remember that

<fps>and don't even try to build another package that has one of the failed ones as deps

<fps>how would yo go about that in guile?

<fps>oh, there would be a way that would result in me having to do no work at all :)

<fps>but it would mean rethinking how a derivation result is represented

<fps>right now, if a package fails to build, that information is lost. it's available only implicitly by the user remembering that he tried to bbuild it, but there's no result in the store

<fps>there needs to be a way to represent failure to build in the store. guix build -K is part of the solution

<fps>let's see

<fps>if guix build had a --consider-kept-failed-result-as-failure option

<fps>hmm

<fps>then i could just use these two

<fps>i'll send a poposal to the ML

<fps>ok, sent a mail to the ML explaining the issue a little more..

<taylan>fps: build failures are cached so it probably tries to rebuild qt when a dependency of qt changes, not when something depending on qt changes

<alezost>orbea: "guix package --search=guix.el" gives you no result because it is literally a part of Guix; see <https://www.gnu.org/software/guix/manual/guix.html#Emacs-Interface>

<alezost>xd1le: I agree with you that it's better to develop "guix.el" outside of Guix. It would be much more convenient for me both as a user and as a maintainer :-) But I think the others don't agree with this :-(

<fps>taylan: how can a Qt dependency change?

<fps>taylan: or rather: care to elaborate?

<fps>anotehr package i see repeatedly fail to build is qemu

<xd1le>alezost: oh well. :(

<taylan>fps: a package which Qt depends on

<taylan>fps: or more precisely, in Guix terms, an input to Qt

<taylan>fps: as an input changes, the Qt package that it tries to build also changes, i.e. theoretically it could succeed this time

<taylan>fps: oh I just saw your mail on guix-devel. for some reason I thought you were referring to hydra.

<civodul>Hello Guix!

<sneek>civodul, you have 1 message.

<sneek>civodul, taylan says: I certainly wouldn't mind it. It might take a little longer until I'm back to productivity...

<civodul>taylan: ok, will do

<fps>taylan: allright. thanks for clearing that up. in my case no package definition changes though..

<fps>is it correct that different build failures are handled differently though? i.e. failure due to exeeding max silent time for example?

<fps>maybe i completely misinterpreted the output i saw flying by

<fps>:)

<taylan>fps: I responded to your mail

<fps>taylan: oh, awesome :)

<fps>so, what's the canonical way to restart the daemon with different options? is it a service?

<taylan>ACTION does it manuall

<taylan>ly*

<fps>ah, the guix-configuration service has an extra-options argument

<fps>guix-service, not guix-configuration service.. hm hmm

<fps>i wonder what's the simplest way to change that one part of the configuration for the guix-service in the %base-services..

<fps>hmm, does the faiure caching of the build daemon treat different failures differently?

<fps>i.e. if a build failed due to a transitive error like a 404 might get treated differently than a build failure where the source fetch succeeded

<fps>one is *it might

<fps>one depends on state, the other doesn't

<civodul>fps: if you want to disable substitutes, see the 'modify-services' snippet at https://www.gnu.org/software/guix/manual/html_node/Using-the-Configuration-System.html

<fps>civodul: i want to pass "--cache-failures" as argument. but it looks like i can do that similarly

<civodul>exactly

<fps>civodul: btw: if you have a second or two, maybe you can shed some more light on how that failure caching works precisely?

<fps>especially wrt to the mail i sent this morning and my remark above about treating different failures differently?

<fps>making coffee. brb

<fps>hmm

<fps>damn, forgot an appointment. bbiab. eta 1h

<fps>re

<efraim>Wading through python builds I'm thinking of some improvements for the pypi importer

<efraim>setuptools: If it wants it, it goes in native inputs

<efraim>parse test-requirements (if it exists) and add to native-inputs

<efraim>tests? #f: change to "tests? #f ;; pypi importer did not find the tests"

<efraim>guix build python2-cryptography works, guix build python2-oauthlib fails when building python2-cryptography :(

<civodul>efraim: could you run "guix build -d python2-cryptography python2-oauthlib" and check the python2-cryptography .drv file names?

<rekado>the broken gtk backend for matplotlib bites me too often.

<rekado>I have a package written in python and it depends on a subset of pylab.

<rekado>pylab depends on matplotlib.

<rekado>ah, forgot to set GI_TYPELIB_PATH=~/.guix-profile/lib/girepository-1.0

<rekado>again.

<rekado>it's a pity that this needs to be done and there's no search path informing the user about this.

<efraim>civodul: The following derivations will be built: /gnu/store/35yjbi1djvnz6b5idxq61hgf4zj1jb1n-python2-oauthlib-1.0.3.drv /gnu/store/8mykjynbcly3w60r5f3mgq3pfh3qz25y-python2-cryptography-1.0.2.drv

<efraim>/gnu/store/35yjbi1djvnz6b5idxq61hgf4zj1jb1n-python2-oauthlib-1.0.3.drv

<efraim>/gnu/store/vicw1l0399c9lksg6s501y0bflgk0k9m-python2-cryptography-1.0.2.drv

<rekado>a matplotlib dependency forces me to run "ssh -X"; a Python programme with matplotlib as an input will fail on a remote session where X forwarding is not enabled.

<rekado>that's because of the GTK backend.

<rekado>can this be avoided?

<rekado>many of those applications that use matplotlib indirectly don't really need to plot anything at all.

<rekado>this particular application has pylab as an input and doesn't do any plotting at all.

<rekado>I'm also unhappy about matplotlib propagating gtk+. This just seems like a really bad thing to do.

<civodul>rekado: i have a local patch to use the Tkinter backend for matplotlib, but i was waiting for tk-update

<civodul>efraim: so indeed, the two python2-cryptography differ; can you "guix graph python2-cryptography python2-oauthlib" to view that?

<efraim>sure

<lfam>civodul: Do you have a tool to diff the output of guix graph?

<civodul>lfam: apart from 'diff' ;-), no

<rekado>civodul: using the Tkinter backend is certainly an improvement, but I'm not sure if it would fix the issue of forcing X forwarding.

<rekado>with the Tkinter backend we would no longer have to propagate GTK+?

<civodul>probably, i guess

<orbea>Guix will be available on slackbuilds.org next time they update their repo :) http://slackbuilds.org/cgit/slackbuilds/commit/?id=6fea2e2e8

<taylan>orbea: s/acheived/achieved/

<taylan>:P

<rekado>orbea: yay!

<taylan>what I should really be saying: neat! :)

<orbea>heh

<efraim>civodul: I couldn't remember how to get a nice graph, so I dumped the output in pastee pastee.org/24gep

<rekado>efraim: you can pipe the output to graphviz's "dot"

<efraim>also python2-unittest2 should rely on python2-setuptools, not python-setuptools

<rekado>efraim: you're right! This should be fixed.

<civodul>efraim: the thing is, package-with-python2 does automatic rewriting of the dependency graph

<civodul>so, if there happens to be something "special" to be done for the python2 variant of one package, it won't know

<civodul>it's probably what's happening here

<civodul>that's why i suggested visualizing the graph

<civodul>mark_weaver: i think now is a good time to merge tk-update; thoughts?

<efraim>only the directly built python2-cryptography is pointing to python2-ipaddress

<civodul>mark_weaver: OTOH there are fishy things like http://hydra.gnu.org/build/831334/nixlog/1/tail-reload

<Steap_>civodul: you do not use unified diffs? :p

<civodul>i do

<Steap_>hum

<fps>oh nice. qt5 finished building. i wonder if building all packages will be done by tomorrow then ;)

<fps>i doubt it though

<orbea>qt5 didn't blow your comp up compiiling? ;p

<Steap_>civodul: how did you get the two different Python builds ?

<orbea>I tried compiling it on my openrc eudev arch laptop a few times since it had too many stupid dependencies, overheated my laptop every time

<fps>orbea: this is a 19" server in a data center.. itshould handle it allright i hope

<orbea>ah, yea

<rekado>hah, buildr even depends on Python through the pygmentize gem.

<davexunit>rekado: software development is fucking terrible

<rekado>so, to replace Java's Maven we need not only hundreds of Ruby thingies but also countless Python thingies.

<davexunit>right now people in my office are talking about using nvm, the node version manager, and installing a C++ application through npm

<rekado>I don't want to see the dependency graph. It's making me sick.

<orbea>sounds fun,,,,

<rekado>davexunit: ugh!

<davexunit>and there's *nothing* I can do to fix it

<rekado>at what point did things go so terribly wrong?

<rekado>was it always so bad?

<davexunit>the explosion language-specific package managers

<wingo>does anyone have a firefox package?

<davexunit>no, just icecat.

<wingo>we should probably package it

<wingo>given that icecat is really old and unusable for some purposes

<wingo>like webdev, anything security-sensitive, etc

<davexunit>firefox on its own cannot be included in guix

<davexunit>unfortunately

<wingo>that does not make sense to me fwiw

<davexunit>iceweasel might be a good target

<wingo>ah, the trademark thing. humm.

<davexunit>there's more than that

<wingo>firefox built from source is free afaiu

<davexunit>it recommends the use and installation of proprietary software, and with the inclusion of EME will download proprietary blobs without your consent.

<wingo>i think you can turn off eme and recommending proprietary software is a silly reason not to include it imo

<davexunit>I'd like a minimally patched firefox that was easy to keep up-to-date

<davexunit>this would be a discussion to bring to the FSF about their requirements for being an endorsed distro.

<wingo>given that most js is non-free, seems an inconsistent way to draw the line

<davexunit>that's why icecat comes with librejs

<wingo>which no one uses :P

<davexunit>yeah

<orbea>i like the idea behind librejs, but hte implementation is horrible

<davexunit>agreed

<orbea>er, interface more like it

<wingo>i just tried to do a video chat with talky and it was impossible because icecat is too old and buggy

<davexunit>anyway, I do web development full-time, I want an up-to-date firefox as well, but Mozilla just doesn't make that easy.

<wingo>and i would have been able to do it with free software if guix had firefox

<wingo>*shrug*

<wingo>now it's impeding my ability to make free software :P

<davexunit>Mozilla won't even agree to display licensing information prominently for add-ons

<davexunit>it's way too hard to determine if an add-on is free or not

<davexunit>it's an unfortunate situation.

<rekado>hmm, seems like we cannot use snippets with ruby gems.

<rekado>it will unpack the gem as a tarball and then assume that the first of the three produced tarballs is a directory containing the sources.

<wingo>ACTION will package firefox and put it somewhere

<civodul>Steap_: following item #6 in the fine manual: https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html

<Steap_>the abs_srcdir/abs_builddir is quite funny

<Steap_>no idea why this would happen

<civodul>somehow the real name of TMPDIR leaks into the build env

<Steap_>civodul: so probably a Guix issue rather than a Python one ?

<civodul>a Python issue revealed by Guix, i'd say :-)

<civodul>though the TMPDIR leak is an issue on our side, indeed

<davexunit>ACTION has a guixsd config that boots right into Kodi

<davexunit>GuixSD for home theather PCs!

<Steap_>civodul: yes, Guix should make this impossible

<wingo>davexunit: right on!

<efraim>not suprisingly, adding python2-ipaddress as an input for python-cryptography didn't cause python-oauthlib to fail and caused python2-oauthlib to build successfully

<davexunit>wingo: :)

<davexunit>not all hope is lost!

<davexunit>now I can replace my ever-broken fragile Debian Sid HTPC

<fps>hmmm, wouldn't it be nice if one could disable the check phase globally? ;)

<davexunit>that would require rebuilding the world ;)

<davexunit>test suites are good.

<rekado>In a weak moment I have also wished for a way to cheat by disabling all tests...

<fps>davexunit: i'm rebuilding the world anyways :)

<fps>that's all i'm doing since two days ago or so

<fps>some python just spent an hour on tests

<rekado>one hour is not the worst

<rekado>many of the science python modules have very big test suites.

<fps>oh, gcc is getting built. how long will that take compared to qt?

<rekado>it will be built three times.

<fps>the more the merrier

<rekado>is it really gcc or a custom gcc?

<rekado>like gcj, gfortran, ...?

<fps>gcc-4.9

<rekado>oh

<fps>4.9.3 to be more precise

<fps>like i said. i'm rebuilding the world..

<fps>:)

<fps>from a to z

<fps>i'm at g, obciously ;)

<fps>*obviously

<effa>rekado: you can overwrite any matplotlib parameter in your personal matplotlibrc file. Check the doc.

<rekado>effa: ah, good to know.

<rekado>thanks!

<effa>yw

<rekado>davexunit: re Kodi's icedtea input: have you tried using gcj as a JDK?

<rekado>sometimes it actually works.

<davexunit>rekado: will that have a big difference?

<davexunit>I was just about to push the patches

<rekado>don't let this keep you from pushing the patches.

<rekado>just a thought.

<rekado>I always try building with gcj first, because it's smaller than the full JDK as per icedtea.

<rekado>ACTION has to go

<davexunit>rekado: oh I see, thanks!

<davexunit>see ya

<davexunit>if it works I can make another patch

<davexunit>there's plenty of stuff to improve in the kodi package, but this is a good start.

<davexunit>rekado: I'd like to review your ruby patches but I just haven't had time outside of hacking on Kodi and real life stuff.

<efraim>hmm, then I tried to build python2-keystoneclient, and it failed because it didn't find python2-unittest2 with python2-oauthlib

<civodul>"sometimes it actually works" :-)

<davexunit>I love that I can test GuixSD configs easily in VMs before moving them to the metal.

<civodul>you should post your config for Kodi

<civodul>it's likely going to be useful for others

<davexunit>civodul: yes

<civodul>cool stuff

<davexunit>I just need to get one more patch into guix ;)

<civodul>sure :-)

<davexunit>civodul: is it cool if I commit a patch that exports 'slim-configuration' and 'slim-service-type' from (gnu services xorg) ?

<davexunit>I used the 'modify-services' syntax to replace the slim-service in %desktop-services with a new one that boots directly to kodi

<civodul>davexunit: sure, go ahead!

<civodul>we should probably export all these

<civodul>i wasn't sure at the time

<davexunit>civodul: awesome, thanks.

<davexunit>that's all I need for my config to work :)

<civodul>neat

<davexunit>now to wait for some rebuilds to make sure everything still works ;)

<davexunit>and then I'll share

<davexunit>here's a very simple GuixSD + Kodi setup: http://pamrel.lu/ba1e3/

<davexunit>gexps ftw

<civodul>davexunit: concise & efficient!

<davexunit>civodul: yup! :)

<davexunit>very pleased by this

<davexunit>next steps are to write services for the Transmission daemon and web interface

<davexunit>then I can safely replace Debian on my HTPC

<effa>rekado: regarding GI_TYPELIB_PATH, the package 'gobject-introspection' declares a search-path-specification and 'matplotlib' uses and propagates the former.

<effa>despite of this "guix package --search-paths" doesn't show anything about GI_TYPELIB_PATH. Is this intentional or an oversight?

<effa>(I have it in my profile)

<fps>hmm, in the package chicken there's a file called a.c

<fps>it compiles for over an hour now ;)

<rekado>the chicken packages seem to be broken on all platforms, timing out.

<fps>ok, i'll blacklist it then.. or maybe it's a test..

<fps> https://pastee.org/7gpt6

<fps>last lines of output

<rekado>compare this to the output of the chicken build on hydra.

<fps>rekado: where could i find the hydra oututs?

<fps>got it

<fps>yeah, it's the same

<fps>it would be interesting to see some statistics about the max silence times per job

<fps>a histogram

<civodul>mark_weaver, wingo: thoughts about concurrent access to modules? https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00385.html

<civodul>ACTION hacked up a CVE database parser

<davexunit>cool!

<davexunit>I'm having a strange issue on a computer I'm trying to convert to GuixSD

<civodul>together with a 'guix lint' checker

<civodul>oh?

<davexunit>sometime after booting and dmd is doing its thing, the screen goes black and never resolves

<davexunit>seems to be due to nouveau

<davexunit>leaves me unable to do anything

<civodul>not even ctrl-alt-f1 and such?

<davexunit>nope

<davexunit>I don't have this issue with my other computer that uses the nouveau driver

IRC channel logs

2015-11-25.log