IRC channel logs
2014-03-31.log
back to list of logs
<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. <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: 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>(i'm trying locally but i need to rebuild some stuff) <dfgd3>civodul: I specified the commit above. <sriharsha>should version numbers of packages follow xx.xx.xx convention? *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. <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) <civodul>pastebin.com isn't available over tor <civodul>this restriction is due to the way the version number is inferred from strings like "foo-1.0" <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>oh, can we put string after the first number then? <civodul>see "guix package -A|cut -f2|grep '[a-z]$'" <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>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 <mark_weaver>right, I was thinking something along those lines would be good <civodul>sorry i got disconnected, then failed to reconnect, and then forgot <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>I just checked, and "3.2.1" < "3.2.1+1007svn" < "3.2.1.1" < "3.2.2" according to 'version>?' <civodul>(version>? "3.2.1+1007svn" "3.2.1") -> #t <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 <bavier>can we package software for guix that is released under a "research" license? <mark_weaver>section 6.3.1 of the guix manual (Software Freedom) discusses what can go into guix. <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>(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>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>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>but the build has an option to disable building that code <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>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 :( <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>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? <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. <civodul>mark_weaver: oooh, i just found that Check provides $CK_TIMEOUT_MULTIPLIER