<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>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 <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>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>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) <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>File "/tmp/nix-build-python2-rdflib-4.1.2.drv-0/rdflib-4.1.2/rdflib/plugins/parsers/notation3.py", 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 <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. <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 ;-) <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! ***Digit_ is now known as Digit
<mark_weaver>rumors of the loss of this video turned out to be incorrect! <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_>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. <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. <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 <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>we should run it with GUILE_INSTALL_LOCALE=1 i guess <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. <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>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 have a package variant python2-scikit-learn. <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) <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_>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 <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_>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 <mark_weaver>Sleep_Walker: you could probably avoid one of those patches by setting LDCONFIG=true <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: 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. <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>LOCPATH must be in #:env-vars as well <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. <civodul>we could have gexp->derivation and build-expression->derivation do it systematically <civodul>and perhaps add a #:locales parameter <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 :) <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>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>civodul: do lookups of *.local work for you with that system? <mark_weaver>that you can reproduce my system so easily showcases Guix's strengths nicely :) <civodul>you have a very elaborate config, BTW! <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>when I see civodul do everything from the REPL, it encourages me to improve my setup *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.... <mark_weaver>good sound quality though. it should amplify nicely. <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? <jxself>Given that it's 720p, 480k seems a little small? <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. <jxself>Didn't mean to step on anyone's toes. Sorry. <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. <Digit>yeah, not just positive in the freeom dimension, but positive in the practical dimension too, which combined, real world emancipation. i love it. :) <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>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. <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. <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>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 <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>I wonder if that's because they are generated on demand. <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 :) <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 <civodul>if they are unrelated, one commit per package, yes <rekado>created an issue on gitorious; hope they can at least make the tarball-generation for tagged refs deterministic.