IRC channel logs


back to list of logs

<davexunit>orbea: guix comes with guix.el
<orbea>is that guixsd, guix or both?
<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, 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)
<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.
<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...
<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>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 <>
<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
<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
<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
<fps>civodul: i want to pass "--cache-failures" as argument. but it looks like i can do that similarly
<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>damn, forgot an appointment. bbiab. eta 1h
<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>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
<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?
<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 next time they update their repo :)
<taylan>orbea: s/acheived/achieved/
<rekado>orbea: yay!
<taylan>what I should really be saying: neat! :)
<efraim>civodul: I couldn't remember how to get a nice graph, so I dumped the output in pastee
<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
<Steap_>civodul: you do not use unified diffs? :p
<civodul>i do
<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
<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
<orbea>i like the idea behind librejs, but hte implementation is horrible
<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>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:
<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>4.9.3 to be more precise
<fps>like i said. i'm rebuilding the world..
<fps>from a to z
<fps>i'm at g, obciously ;)
<effa>rekado: you can overwrite any matplotlib parameter in your personal matplotlibrc file. Check the doc.
<rekado>effa: ah, good to know.
<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 :)
<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:
<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>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?
<civodul>ACTION hacked up a CVE database parser
<davexunit>I'm having a strange issue on a computer I'm trying to convert to GuixSD
<civodul>together with a 'guix lint' checker
<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>I don't have this issue with my other computer that uses the nouveau driver