IRC channel logs

2014-03-31.log

back to list of logs

<civodul>yeah me too!
<civodul>i just sent an email to summarize
<civodul>i made my first GPG-signed commit with Git
<civodul>(i remember doing that with tla back in the day)
<mark_weaver>oh, interesting. I knew that tags could be signed, but I didn't know commits could be.
<civodul> http://mikegerwitz.com/papers/git-horror-story seems to have useful practical info
<civodul>anyway, good night/day!
<phant0mas>good morning guix
<civodul>Hello Guix! :-)
<dfgd3>civodul: ping
<dfgd3>guix package -i tor --no-substitutes fails for me on 6ef91c
<dfgd3>The relevant thread on the gnutls list suggest that the problem is server-specific. Is there a workaround?
<civodul>dfgd3: pong
<civodul>lemme check
<civodul>dfgd3: are you using the current master, or pre-merge?
<civodul>that seems to relate to one of the bugs i closed this week-end
<civodul>this one: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14884
<civodul>(i'm trying locally but i need to rebuild some stuff)
<dfgd3>civodul: I specified the commit above.
<civodul>ah this is pre-merge
<civodul>too late...
<sriharsha>should version numbers of packages follow xx.xx.xx convention?
<sriharsha>I am not able to install gnunet-svn-32804 version package, but it is listed as available.. http://pastebin.com/CEJ6PcJi
*mark_weaver has transitioned his YeeLoong to /gnu/store, close to what core-updates was just before the merge.
<mark_weaver>sriharsha: I think the problem there is that the logic that separates the string you typed into package-name and version number doesn't handle that kind of version number.
<sriharsha>oh
<mark_weaver>sriharsha: the relevant logic is in 'package-name->name+version' in guix/utils.scm. the split happens where there's a '-' followed by a digit.
<civodul>sriharsha: yes, version numbers must be comparable with version>? (aka. strverscmp)
<mark_weaver>so the version number has to start with a digit.
<civodul>pastebin.com isn't available over tor
<civodul>ah and yes, like mark_weaver said
<sriharsha>ok.
<civodul>this restriction is due to the way the version number is inferred from strings like "foo-1.0"
<civodul>on the command line
<mark_weaver>and as civodul hinted at, the version should also be properly ordered with respect to numbered releases, which I think means that you need to include the most recent release version number in the version string, and maybe add the SVN revision as some kind of suffix.
<civodul>but otherwise you can always use guix package -e '(@ ...)'
<mark_weaver>we should probably come up with a convention for these kinds of version numbers. I'll need it for bitlbee also.
<sriharsha>hmm. I guess for the package, I shall change the package name as gnunet-svn and then use the revision numbers as the sole version number
<sriharsha>*for the gnunet SVN package
<civodul>mark_weaver: maybe "32804svn"?
<sriharsha>oh, can we put string after the first number then?
<civodul>yes, that would work, i think
<sriharsha>ok, that would be nice.
<sriharsha>civodul, I am running hydra on my machine
<civodul>see "guix package -A|cut -f2|grep '[a-z]$'"
<civodul>sriharsha: excellent!
<sriharsha>so, I have got a path in the store: /gnu/store/zwa0w65r825xl2xffn2blyc61fl9pgxq-alsa-lib-1.0.27.1
<civodul>congratulations, because it's definitely not easy...
<sriharsha>but, when I go to the url http://localhost:3000/nar/zwa0w65r825xl2xffn2blyc61fl9pgxq-alsa-lib-1.0.27.1
<sriharsha>it says "Path /gnu/store/zwa0w65r825xl2xffn2blyc61fl9pgxq-alsa-lib-1.0.27.1 is no longer available."
<mark_weaver>civodul: so for bitlbee, for example, the most recent release is 3.2.1, and suppose I want SVN revision 1007, which is more recent than that. what should the version string be?
<civodul>sriharsha: right, you need to set NIX_STORE_DIR=/gnu/store
<civodul>that is, in the environment of the hydra-* processes
<sriharsha>yes, I did set NIX_STORE_DIR before starting hydra-server. Hydra recognized /gnu/store but it says that path is not available. Co-incidentally, I found that path is also listed in 'nix-store --gc --list-dead'
<civodul>mark_weaver: i'd say "1007svn", WDYT?
<mark_weaver>debian has a well-crafted set of version string conventions and comparison rules. I wonder if we should borrow from them here.
<sriharsha>does this mean that Hydra does not serve dead paths?
<civodul>mark_weaver: yes, probably a good idea to get inspiration from that
<mark_weaver>civodul: but we want something that 'version<?' considers newer than 3.2.1 but older than 3.2.1.1 or 3.2.2, right?
<civodul>sriharsha: no, it's possible that a directory exists, but is not "valid" per Nix/Guix
<sriharsha>oh, I am rebuilding some stuff, will test it again and ask
<sriharsha>mark_weaver, perhaps 3.2.1+1007svn
<sriharsha>?
<mark_weaver>right, I was thinking something along those lines would be good
<mark_weaver>but I need to check what 'version<?' does exactly.
*mark_weaver looks
<civodul>sorry i got disconnected, then failed to reconnect, and then forgot
<mark_weaver>civodul: no worries :)
<mark_weaver>regarding the version numbers, you suggested "1007svn", to which I replied: but we want something that 'version<?' considers newer than 3.2.1 but older than 3.2.1.1 or 3.2.2, right?
<mark_weaver>sriharsha suggested "3.2.1+1007svn", which seems good to me, though I don't know how 'version<?' will order that w.r.t. 3.2.1 and 3.2.1.1
*mark_weaver looks
<mark_weaver>I just checked, and "3.2.1" < "3.2.1+1007svn" < "3.2.1.1" < "3.2.2" according to 'version>?'
<mark_weaver>civodul: what do you think of "3.2.1+1007svn" ?
<civodul>mark_weaver: looks good!
<civodul>(version>? "3.2.1+1007svn" "3.2.1") -> #t
<mark_weaver>right
<civodul>so that satisfies the requirement
<civodul>now, checkout-versions like this should be rare :-)
<civodul>anyway, we should probably add a note about it in "Version Numbers" in the manual
<mark_weaver>I hope so, but I suspect it will become increasingly common for developers to slack off on making releases.
<civodul>yeah, there seems to be a tendency :-/
<civodul>i have to go again but i'll be back later
<mark_weaver>okay, ttyl!
<bavier>can we package software for guix that is released under a "research" license?
<mark_weaver>what is a "research" license?
<mark_weaver>section 6.3.1 of the guix manual (Software Freedom) discusses what can go into guix.
<bavier>I'll take a look at that
<bavier>basically, software that says it's free to use for personal, educational, or research use, but requires a license for commercial use. e.g. ParMETIS
<mark_weaver>no, that's non-free software
<mark_weaver>(as you've described it; I'm not familiar with ParMETIS)
<bavier>ok, I need to look a bit more into the licensing. I was working on packaging gmsh, which includes many other packages with differnt licenses.
<mark_weaver>Free software is defined according to the four freedoms, described here: http://www.gnu.org/philosophy/free-sw.html
<mark_weaver>Freedom 0 is the freedom to run the program for any purpose.
<mark_weaver>if it's only free to use for certain purposes, then it violates freedom 0.
<bavier>right
<bavier>ok, I'll disable that interface then. the other licenses look fine.
<mark_weaver>bavier: is the non-free code included in the same tarball as the thing you're packaging?
<bavier>yes, as a subpackage
<bavier>but the build has an option to disable building that code
<mark_weaver>civodul: how do we deal with that?
<mark_weaver>(see above)
<zacts>lo
<civodul>bavier: as mark_weaver says, it must be free to use for any purpose
<civodul>so if you can disable that part, that's OK
<civodul>also please use a 'snippet' in origin to remove the non-free files
<bavier>civodul: sure, I can try to do that
<civodul>cool!
<civodul>colleagues at work develop http://www.labri.fr/perso/pelegrin/scotch/
<civodul>i don't understand much of that, but that seems similar in purpose
<bavier>I'm familiar with that package, but unfortunately it's not as popular as metis :(
<civodul>ah ok
<civodul>i was just curious :-)
<bavier>at my own work, I've spent a lot of time dealing with headaches caused by metis, so I like to promote scotch whenever I get a chance
<civodul>heh, interesting
<civodul>often, packages in applied maths don't really follow "software best practices", it seems
<bavier>that is very often true, unfortunately
<civodul>mark_weaver: could you push the pulseaudio patch?
<civodul>it's needed for Hydra too
<mark_weaver>civodul: okay. the thing is, you asked me to document what the timeout was before the patch, and I don't yet know the answer to that question. I'd have to dig into the test library code to find where the default timeout is.
<mark_weaver>I haven't had a chance to look into it yet.
<civodul>mark_weaver: oooh, i just found that Check provides $CK_TIMEOUT_MULTIPLIER
<civodul>and $CK_DEFAULT_TIMEOUT
<mark_weaver>ah, interesting.
<mark_weaver>if you have a nicer fix, go ahead and push it :)
<civodul>and DEFAULT_TIMEOUT is 4
<mark_weaver>ouch.
<civodul>4 seconds, i guess