IRC channel logs


back to list of logs

<davexunit>jxself: it seems to be sort of hard to manage per-user configs with guix right now, so maybe stow is good to have around ;)
<a_e>A have a similar python problem.
<a_e>The python file contains
<a_e> import html5lib
<a_e> assert html5lib
<a_e> html5lib = True
<a_e>except ImportError:
<a_e>Which raises an error. However, my PYTHONPATH contains
<a_e>And this contains an html5lib directory with python files.
<a_e>And this seems to make the tests fail.
<a_e>Oh, doing it by hand, "import html5lib" complains about a missing module "six".
<a_e>Should then python2-six be a propagated input of python2-html5lib?
<a_e>Actually, python2-six does not even exist yet. Time to add it first!
<bavier`>html5lib might only be importing it for python2
<a_e>bavier`: It looks so.
<a_e>Is there a way of determining which (propagated) inputs are needed?
<a_e>Using the egg file or PKG-INFO or something?
<a_e>bavier`: six is needed for any version of html5lib, under python 2 or 3.
<bavier`>a_e: interesting that it didn't make it into the input sooner
<a_e>That is the annoying thing with python modules, they lack the configure phase!
<a_e>bavier`: Well, so far, nothing has actually used html5lib as input!
<Steap>a_e: yeah, six is a compatibilit layer between Python 2 and 3
<a_e>Steap: Interesting!
<Steap>rather than writing "if python2: ... else: ..." you have a single piece of code, much more readable
<Steap>so I guess it's needed for any version of Python :)
<Steap>a_e: there might be a requirements.txt file
<Steap>in which all requirements are listed
<bavier`>a_e: yeah, doesn't help of the package is never used :P
<a_e>Steap: Indeed, in the source. It says "six".
<a_e>So these requirements always need to be propagated?
<Steap>a_e: yeah, six is "2*3" :p
<Steap>not sure whether they have to be propagated, but that tells you what you must package first
<Steap>I was willing to add the parsing of requirements.txt to the pypi importer
<Steap>not sure how to do this though
<Steap>would saying "well, we need this library and it does not seem to be packaged" on the standard output be enough ?
<a_e>Or add it to the inputs?
<a_e>Then compilation fails if they are not there.
<bavier`>Steap: the cpan importer just puts the required package references into the output package
<Steap>yeah, I tried that and it was kind of weird to do
<Steap>let me look at how it is done
<Steap>guix/import/cpan.scm, ok
<Steap>well, I got something that parses the content of requirements.txt
<Steap>I'll try to see if I can add the code that generates the list of pairs
<a_e>The tests of my python package still fail after correcting html5lib. What a pity!
<Steap>because of a missing library ?
<a_e>No, with a message like this under python 2:
<a_e>ValueError: unichr() arg not in range(0x10000) (narrow Python build)
<Steap>oh that's gonna be fun.
<a_e>FAIL: test.test_issue375.test_rdfpipe_bytes_vs_str
<a_e>Issue 375: rdfpipe command generates bytes vs. str TypeError
<a_e>Steap: I think '#:tests? #f' might be a simple solution...
<Steap>yeah but that defeats the purpose of tests...
<a_e>How about this:
<a_e>File "/tmp/nix-build-python2-rdflib-4.1.2.drv-0/rdflib-4.1.2/rdflib/plugins/parsers/", line 1594, in _unicodeEscape
<a_e> "bad string literal hex escape: "+argstr[i:i+n])
<a_e>BadSyntax: at line 14 of <>:
<a_e>Bad syntax (bad string literal hex escape: 00012451) at ^ in:
<a_e>"...0012451 in Cuneiform numeric ban 3
<a_e>:a :b """\\nthis \\ris a \\U^00012451long\\t
<a_e>""" .
<Steap>these issues are awful
<Steap>can you run the tests successfully outside of Guix ?
<civodul>bavier`: this one is for mark_weaver i guess :-)
<civodul>we'll deprecate 2.0.5 support in the next release
<a_e>Steap: I was just going to try this.
<civodul>good night/day!
<a_e>Good night!
<Steap>a_e: yeah, maybe the package does weird stuff
<a_e>Okay, the tests fail also outsided of guix.
<a_e>Not our fault then ;-)
<Steap>does Debian patch it ?
<a_e>Yes, they drop lots of lines from rdflib-2.4.2.orig/rdflib.egg-info/SOURCES.txt
<a_e>All of the form 'test/*'.
<a_e>In fact, they drop exactly test/*.pyc, while keeping test/*.py.
<Steap>pyc are compiled Python files
<Steap>are they shipped with the tarball ?
<a_e>No. In Debian, I have been looking at version 2.4.2, and I packaged 4.1.2.
<a_e>In the newer one, there is this:
<a_e>+# Disabling doctest as some require network access, which isn't available during Debian package build
<a_e>And I actually disabled an input, since there would be a circular dependency otherwise.
<a_e>Maybe these tests would need it.
<a_e>Enough for tonight. Talk to you later!
<mark_weaver>bavier`: I just pushed a fix to the (guix build download) compilation failure on guile 2.0.5. if you could try it, I would be grateful.
<bavier>mark_weaver: your fix seemed to do the trick, thanks!
<mark_weaver>bavier: that's good!
***Digit_ is now known as Digit
<mark_weaver>rumors of the loss of this video turned out to be incorrect!
<civodul>Hello Guix!
<grantix>mark_weaver: !!!
<grantix>Very neat, :^)
<grantix>civodul: Howdy.
<grantix>I'm about to build a development VM on my main box, do I need to do anything special -- or should my VM have read/write access to the host-system's store?
<grantix>Letting it build and going from there.
<rekado_>once more about stow: I packaged it to see if this approach to managing dotfiles would work for me:
<rekado_>getting something packaged for Guix is clearer and safer than just building it in a polluted environment.
<rekado_>about solfege and its dependency on pygtk: should I proceed with providing wrappers for all Python executables so that the PYTHONPATH is set to include the pygtk directory or is there a better way to do this?
<rekado_>without doing anything I get an import error when running "solfege".
<rekado_>as pygtk is just a regular input it does not appear in ~/.guix-profile/lib and I don't want to have to tell users to manually add the long pygtk store directory to their PYTHONPATH.
<civodul>rekado_: i think you'll indeed have to wrap all the executables to they get the right PYTHONPATH
<civodul>assuming Solfege is only meant to be used as a standalone program
<rekado_>AFAICS it's only used as a standalone programme.
<rekado_>do we have procedures to simplify the wrapping?
<rekado_>Emacs, for example, also has wrapped executables.
<rekado_>I suppose that's handled by the build system.
<grantix>Yeah, "/gnu/store is a read-only file-system" in my VM.
<grantix>Brb, logging into my Stumpwm session.
<rekado_>Ah, we have "wrap-program", which should be sufficient.
<civodul>yeah wrap-program should work well
<civodul>oh oh!
<jxself>If only I had looked in this channel earlier and had time to wget that talk to watch on the way to work before I had to leave for work. Oh well.
<davexunit>bummer :(
<davexunit>you'll enjoy it when you see it.
<davexunit>it's good.
<Sleep_Walker>I'm about to resend luajit fix, which is almost the same as it was already reviewed
<Sleep_Walker>I tried to reach Luajit upstream but they are not responding to this issue at all and patches were on mailing list unnoticed
<Sleep_Walker>but the patches are needed and obvious and I don't mind keeping them up-to-date so lets just use them
<civodul>Sleep_Walker: sounds good!
<mark_weaver>civodul: you wrote before your vacation that builds were done with a UTF-8 localed before the locales were removed from glibc, but when I looked, I didn't see anything that would have set LANG or LC_ALL or would have called 'set-locale' in the guile builders. was I missing something?
<mark_weaver>would you like to arrange for a UTF-8 locale to be set by default for non-bootstrap builds?
<civodul>mark_weaver: i think they were always done in a C locale actually
<civodul>yes, i was planning to add glibc-utf8-locales to the implicit inputs in core-updates
<mark_weaver>okay, that matches what I saw. well, my main concern is with Guile being able to handle non-A
<mark_weaver>non-ASCII POSIX byte strings, e.g. for filenames or command-line arguments.
<civodul>yes, right
<civodul>we should run it with GUILE_INSTALL_LOCALE=1 i guess
<mark_weaver>and also LANG ?
<mark_weaver>this was actually the last thing I was waiting for before asking hydra to build all of core-updates, but I wasn't sure how best to accomplish it or what you'd think, so I waited.
<civodul>oh ok
<civodul>LC_ALL rather?
<civodul>do you want to give it a try?
<civodul>that may be faster ;-)
<mark_weaver>should we use LC_ALL? I confess I don't know the difference, but I seem to be of the impression that LANG is what people usually have set.
<mark_weaver>I would think we would want to emulate what most developers are building things under.
<mark_weaver>(well, I don't agree with that as a general rule, but in this case it seems reasonable :)
*mark_weaver looks up the difference
<mark_weaver>according to the glibc manual, LANG and LC_ALL are effectively equivalent as long as no other LC_* variables are set. if they are, then they take precedence over LANG but LC_ALL takes precedence over all.
<civodul>ah ok, i wasn't sure about the difference either
<civodul>just a vague feeling that LC_ALL was "stronger" ;-)
<mark_weaver>civodul: well, that's was true!
<mark_weaver>anyway, I guess these environment variables need to be set in the derivations themselves, rather than in a phase, so that the guile build process will pick them up, but I'm not sure how best to deal with the bootstrapping issues.
<civodul>exactly, using the #:environment-variables or #:env-vars (?) parameter
<rekado_>I'm confused.
<rekado_>I have a package variant python2-scikit-learn.
<rekado_>this depends on python2-numpy.
<rekado_>numpy needs matplotlib and that needs pycairo.
<rekado_>I understand that package-with-python2 renames all "python-X" inputs to "python2-X".
<civodul>be aware than python2-numpy is different from (package-with-python2 python-numpy)
<civodul>which is kinda unfortunate
<rekado_>in order to make this work my python2-scikit-learn package inherits from (package-with-python2 python-scikit-learn)
<rekado_>and then throws out python2-numpy from the input and adds it manually.
<rekado_>I do the same for python2-matplotlib.
<rekado_>but still when I build it python2-pycairo (which does not exist) is being built.
<rekado_>and that fails, because it's really just python-pycairo which fails for python 2.7
<rekado_>so ... how can I build python2-scikit-learn with only the real python2 inputs?
<rekado_>it's actual inputs are really just python-numpy, python-scipy, python-nose, and atlas.
<rekado_>maybe I just fixed it by not inheriting inputs at all.
<rekado_>(still waiting for the build to complete but this looks promising. At this point I'm very confused, but also relieved.)
<rekado_>it worked!
<rekado_>oh, I think I know why it didn't work before: I tried to remove inputs from (package-inputs (package-with-python2 scikit-learn)), but (package-inputs ...) does not return the inputs of the inputs.
<rekado_>so what I did had no effect whatsoever.
<rekado_>I was erroneously thinking that I was dealing with a bag of inputs.
<rekado_>while I'm making noise: should python-setuptools be a native input? What about inputs used for testing? Are these also native inputs?
<davexunit>rekado_: sounds like they should be native inputs
<davexunit>but I'm not totally sure. this has come up before...
<rekado_>I remember that python-setuptools should be native, but I'm not sure about testing stuff like nose and mock.
<rekado_>I don't know which python will be used to test --- the target python or the source, and if this all matters at all.
<civodul>rekado_: inputs used only during the build process should be native inputs
<civodul>(think cross-compilation)
<rekado_>I'm trying to think "cross-compilation", but I don't know what it means for running Python tests.
<rekado_>because during tests the built stuff is run.
<rekado_>that stuff is built for the target.
<rekado_>so, should the test modules (say python-nose, or python-mock) be built for the target as well?
<civodul>tests are typically not run when cross-compiling
<civodul>so yes, test modules should probably be native-inputs
<civodul>that said, while it's a good thing to do, we're probably far from supporting cross-compilation of Python modules
<civodul>and it's not a primary goal either
<Sleep_Walker>please, ignore that mail :E
<mark_weaver>Sleep_Walker: you could probably avoid one of those patches by setting LDCONFIG=true
<mark_weaver>maybe adding that to #:make-flags
<mark_weaver>civodul: regarding setting LANG and GUILE_INSTALL_LOCALE variables in most derivations, two questions: (1) where should this be done (e.g. how generally), and (2) how should we deal with the bootstrapping issues? if you'd prefer to just make the changes yourself rather than talk me through it, that's fine too :)
<Sleep_Walker>mark_weaver: I'm aware of that
<Sleep_Walker>mark_weaver: that was my first approach
<Sleep_Walker>mark_weaver: but when I sent patches to upstream, I made it into patch
<Sleep_Walker>because the code is wrong and passing LDCONFIG is just workaround
<mark_weaver>civodul: we'll want to make sure that graft derivations are run with either a UTF-8 or ISO-8859-1 locale.
<mark_weaver>Sleep_Walker: okay
<civodul>mark_weaver: simply change the 'graft-derivation' procedure to pass #:env-vars '(("GUILE_INSTALL_LOCALE" . "1")("LC_ALL" . "en_US.UTF-8"))
<civodul>and also add a (setenv "LOCPATH" glibc-utf8-locale)
<civodul>arf, no
<civodul>LOCPATH must be in #:env-vars as well
<mark_weaver>and we need to add an input
<civodul>so it needs to lazy-refer to glibc-utf8-locales
<mark_weaver>well, I could make the change specifically to graft derivation. my real question is about how to do this more generally, and how to deal with the bootstrap.
<mark_weaver>and how generally do we want to do it.
<civodul>we could have gexp->derivation and build-expression->derivation do it systematically
<civodul>and perhaps add a #:locales parameter
<civodul>which could be #f during bootstrap
<mark_weaver>sounds good to me. if you'd be willing to do this, I would be grateful. it's a bit beyond what I'm comfortable doing at this point, although I would certainly study what you did :)
<Sleep_Walker>and now it is correct
<civodul>mark_weaver: ok, i'll try :-)
<civodul>i admit it's trickier than i initially thought
<civodul>BTW, i just booted into "your" system, the operating-system config that you posted
<mark_weaver>ah, neat!
<mark_weaver>I've also added some commits, e.g. to clear out /tmp and /var/run at the beginning of the boot script (before running activations)
<mark_weaver>and to populate /etc/ssl, etc.
<mark_weaver>civodul: do lookups of *.local work for you with that system?
<civodul>not in the vm
<civodul>i'm investigating
<civodul>but it does work for me
<mark_weaver>thanks :)
<civodul>on my laptop i mean
<mark_weaver>that you can reproduce my system so easily showcases Guix's strengths nicely :)
<civodul>yeah that's fun
<civodul>you have a very elaborate config, BTW!
<civodul>it's nice
<mark_weaver>heh :)
<civodul>there are probably ideas that we should integrate
<davexunit>it's really cool when you can reproduce this stuff easily.
<mark_weaver>yeah, getting some of these services ready to upstream is on my TODO, but if someone else were to beat me to it, I wouldn't mind :)
<davexunit>I have that feeling with 'guix environment' a lot.
<mark_weaver>davexunit: yeah, 'guix environment' is really great. I need to get in the habit of using it more.
*mark_weaver still uses stone tools for a lot of things
<davexunit>I feel that way about how I build packages
<davexunit>when I see civodul do everything from the REPL, it encourages me to improve my setup
<davexunit>I also don't use the emacs mode enough.
*mark_weaver works on converting the video of civodul's FOSDEM 2015 talk to .webm
<mark_weaver>oh, hmm, I could maybe amplify it at the same time....
<davexunit>mark_weaver: that would be great!
<mark_weaver>the maximum volume in that file is -20.3 dB. yikes!
<mark_weaver>good sound quality though. it should amplify nicely.
<davexunit>good to have a sound engineer around
<mark_weaver>ffmpeg -i the_emacs_of_distros.mp4 -c:v libvpx -b:v 480K -c:a libvorbis -af volume=20dB the_emacs_of_distros.webm
*mark_weaver lets it work while I watch it :)
<davexunit>mark_weaver: is that a guix built version of ffmpeg?
<davexunit>nice :)
<mark_weaver>I believe in eating our dog food :)
<jxself>Given that it's 720p, 480k seems a little small?
<jxself>How's it look at that rate?
<mark_weaver>well, the MP4 was at 489kbps
<mark_weaver>it looks pretty reasonable to me.
<mark_weaver>btw, for the sake of completeness, here's the command I used to determine the maximum volume in the file: ffmpeg -i the_emacs_of_distros.mp4 -af volumedetect -f null /dev/null
<mark_weaver>jxself: the thing is, most of the image area is taken up by slides, so there's very little movement.
<jxself>OK. I always use -crf for constant quality mode.
<mark_weaver>jxself: ah yes, that's probably a good idea. my knowledge of audio is stronger than my knowledge of video.
<mark_weaver>jxself: maybe I should get rid of the -b:v option entirely, what do you think?
<mark_weaver>though I'll have to play with the crf value to achieve a good file system.
<jxself>You can do both, like -crf 10 -b:v 480K
<jxself>In that case the 480K acts as an upper limit.
<mark_weaver>jxself: right, and maybe I don't want any upper limit.
<jxself>And if you can get by with less, less wil be used.
<mark_weaver>jxself: would you like to handle converting the video? you could take the -af volume=20dB and then do what you think is best for the rest.
<jxself>Nah. I was just bored and talking.
<mark_weaver>jxself: okay, well, I appreciate your input!
<jxself>Didn't mean to step on anyone's toes. Sorry.
<mark_weaver>no, not at all!
<mark_weaver>your suggestion to use -crf was a good one
<Digit>watching the fosdem guix talk. starting to see (esp with emacs integration) how much better it is than nix(os). :) ~have yet to get back to installing it. busy times.
<mark_weaver>Digit: glad to hear it! :)
<Digit>yeah, not just positive in the freeom dimension, but positive in the practical dimension too, which combined, real world emancipation. i love it. :)
<civodul>heh, power to the people! :-)
<davexunit>Digit: that's why our official slogan is "Have it your way"
<davexunit>I don't think a large fast food burger chain has used that...
<Digit>sounds very pro-choice. snapping at gentoo's useflag heels yet? or is that further down the road still?
<davexunit>Digit: there was a conversation about useflags on the mailing list. We don't think it's particulary useful for us.
<davexunit>since packages are first-class Scheme objects
<Digit>yeah, i've yet to get into that way of thinking about it. ... started watching the mit computer science lectures on lisp, inspired in no small part by guix (and it being overdue, having been an emacs user for at least a couple years now).
<mark_weaver>on the one hand, using a private git branch, it's easy to keep arbitrary local patches to any part of guix, and to easily merge upstream into your branch or rebase your branch on top of upstream master.
<mark_weaver>and this is strictly more flexible and powerful than use flags.
<mark_weaver>on the other hand, it would be possible to facilitate global changes by making our package descriptions honor those global flags.
<mark_weaver>but there are a few problems at this point
<davexunit>Digit: the thread I was thinking of is this:
<mark_weaver>well, I can't really continue this now, but the main thing is that it would multiply the number of combinations to test by a rather large factor, and our community is as yet too small to effectively test so many combinations.
<mark_weaver>and our build farm is not nearly large enough to build pre-compiled binaries for all of those possible combinations.
<mark_weaver>maybe some day...
<bavier`>I want to start committing some of the perl modules I have packaged. Two questions: 1) can I alphabetize the perl packages like nix does, and 2) should I try to upgrade our perl first?
<bavier`>Upgrading our perl would prevent me from needing to package newer versions of a few core modules to satisfy version dependencies.
<davexunit>bavier`: trying to upgrade our perl sounds reasonable, if it doesn't break anything.
<mark_weaver>it might have to be done on core-updates. I suspect that a lot of things end up depending on perl indirectly.
<mark_weaver>but yeah, upgrading perl sounds good to me
<bavier`>sounds good. I'll work on that before pushing any other perl packages.
<civodul>bavier`: should go to core-updates, indeed
<bavier`>Also, should I commit each package individually?
<civodul>the deps for Hydra?
<bavier`>civodul: yes
<civodul>it's fine to make 1 commit per package if that's what you have
<civodul>just don't send them to the list :-)
<bavier`>civodul: no, I won't send them to the list. And I don't have them all packaged yet, but I wanted to start getting some pushed, after rekado_ redundantly packaged a few I had.
<civodul>yes, it's a good idea to not wait for too long
<bavier`>our perl-5.16.2 is marked "end of life" on
<jxself>It's time for Perl 5.20.2.
<mark_weaver>civodul: okay, I'll take a look, thanks!
<mark_weaver>civodul: btw, any idea why bug-guile is no longer on gmane?
<mark_weaver>recently I've started mostly reading the development lists on gmane.
<Digit>thnx for the mailing list link, davexunit. (been lured into too many conversations elsewhere, n now it's sleepytime. will check it out in the morning)
<rekado>For the second time the hash for a tarball downloaded from gitorious has changed.
<rekado>this bothers me a bit.
<rekado>same project.
<rekado>I wonder if that's because they are generated on demand.
<civodul>could be the case
<rekado>good thing it's my own project, so I can move the tarballs.
<rekado>but it's a bit disappointing anyway.
<civodul>perhaps they provide other URLs for something more stable?
<Sleep_Walker>Feature rich, fast, resource friendly but good looking, massively themeble terminal emulator running in X or framebuffer
<Sleep_Walker>I hope it is not much obvious I like terminology terminal much :)
<civodul>heh :-)
<Sleep_Walker>ok, I have it ready for review - 5 packages in separate file (I plan to add more there)
<civodul>i would avoid superlatives and such in the description, tho
<Sleep_Walker>do you prefer one package - one commit
<civodul>if they are unrelated, one commit per package, yes
<Sleep_Walker>or I can pass whole file as one commit?
<Sleep_Walker>ACK :)
<rekado>created an issue on gitorious; hope they can at least make the tarball-generation for tagged refs deterministic.