IRC channel logs
2015-02-24.log
back to list of logs
<davexunit>I seem to have gotten the attention of the rspec maintainer on twitter <davexunit>I think that we should maybe formalize some base search paths, like "PATH" <davexunit>right now, the user adds something like "export PATH=$HOME/.guix-profile/bin" to their bashrc or something <davexunit>but I think that "guix package --search-paths" should output that as well. <davexunit>I especially think so because packages may want to add to $PATH, and "guix package --search-paths" will print out something that would clobber the $PATH the user has setup. <davexunit>for example, Ruby programs aren't installed to /bin, but to /lib/ruby/gems/2.2.0/bin <davexunit>ugh, the golang folks just removed the C version of the Go compiler. <davexunit>now Go is self-hosted, and now we have more trust to trust. <jxself>You compile go with a compiler written in Go? Sounds perfect. <jxself>Do they use the idea of the Free Pascal compiler people where you're supposed to download a pre-compiled compiler to compile the compiler? <bavier>I just got a "guix: Argument list too long" error when trying to do `guix package -i emacs` with a modified (guix build utils) (i.e. re-building most things), and an empty store. My guess is the list of derivations to be built is somehow too big. Is there some way I could get a backtrace from guix? <mark_weaver>bavier: run "./pre-inst-env guile" from the build directory. then (use-modules (guix scripts package)) <mark_weaver>sounds like you're trying to pass an argument list that's too long to a subprocess. <mark_weaver>too many or too large environment variables might also cause it. <bavier>mark_weaver: thanks, I'll give that a try <mark_weaver>I doubt it's because of too many derivations being built. what change did you make to (guix build utils)? <bavier>I applied d5b3de6 from core-updates onto my master branch <mark_weaver>any change to (guix build utils) will cause essentially everything to be rebuilt <mark_weaver>you'd be better off starting with core-updates and cherry-picking from master, because at least you could benefit from hydra's substitutes for the core packages. <mark_weaver>but I'm still curious where the E2BIG is coming from <bavier>hmmm, I can't recreate it. I had blown away /gnu/store, but noticed I hadn't removed $localstatedir, now things seem alright <mark_weaver>removing one but not the other would certainly cause problems, though E2BIG is not the symptom I would have expected. <rekado->Can Go not be bootstrapped with gccgo? <rekado->Java also needs Java to be compiled, but at least it was possible to build OpenJDK 6 with GCC's Java 1.5 compiler. <civodul>i have to catch up with all the things that you folks have been doing <mark_weaver>bavier`: we need to not be advertising ways to get the "unpatched source", because in several cases that includes non-free software. <rekado->should I name the package and variable "timidity" or "timidity++" as it's called upstream? <rekado->Andreas had objections against "timidity++". <mark_weaver>I disagree with Andreas on both the name and his decision to change the location of the configuration file <mark_weaver>but I don't care enough to argue. I would wait and see what civodul says :) <rekado->the configuration file default location was easily changed with a configure option, so I don't have a problem with that. <rekado->I'll wait for civodul then before pushing. <mark_weaver>rekado-: is there a configuration option to change the location of the config file? <rekado->there is only a command-line option to read an *additional* configuration file. <rekado->it will always try to read the default config, though. <rekado->there's a configure flag "--with-default-path=" to set the default location; if unset it defaults to /share/timidity/timidity.cfg. <rekado->this file does not exist. We create this file in an additional build phase and make it source the freepats config file. *civodul is fine with timidity++ <civodul>i haven't quite caught up yet, working on it :-) <rekado->okay. Then I'll push the last version (as posted above). <a_e>mark_weaver: Any news on the freeness or non-freeness of python-markdown? <mark_weaver>a_e: not yet, but what about resources/viewer/mathjax? any idea why debian removed that one? <a_e>No idea. I think it is free. <a_e>Well, they replace the minified javascript by the more readable source. <a_e>If I remember correctly. <a_e>I contacted the debian maintainer, but got no reply so far. <a_e>Anyway, I think in a more recent release, the upstream author also put in the normal mathjax. <a_e>Now, inside the directory, there is a very readable MathJax.js which claims to be under the Apache license. <mark_weaver>jgay: what should we do about copying permission notices that attempt to put restrictions on use? e.g. language like "By obtaining, using, and/or copying this software and/or its associated documentation, you agree that you have read, understo\\ <mark_weaver>od, and will comply with the following terms and conditions:" <a_e>The package in debian is antediluvian. <a_e>Have a look at this: <jgay>mark_weaver, I'm not sure I know the answer off the top of my head. Wnat to send an email to licensing@gnu.org and we'll prioritize working on an a reply in the next day or two? <jgay>licensing@fsf.org I meant <a_e>Actually, no, this is for the current version. <a_e>And my answer on mathjax was wrong: The minification thing was for jquery. <a_e>Mathjax is simply removed because the system mathjax is used, see lines 48-50. <a_e>The same holds for python markdown with the strange addition; see lines 29-30 and 38. <mark_weaver>a_e: I think that's because the path to the module changes from 'calibre.ebooks.markdown' to just 'markdown'. <a_e>Yes, they patch it to change the path. <mark_weaver>which makes sense. calibre wanted to put their bundled copy in their private namespace, to prevent a collision with a possibly different version installed elsewhere. <a_e>Here is the copyright info for python-markdown in debian: <a_e>So they think it is okay. <mark_weaver>a_e: okay, I guess they removed both markdown and mathjax because they were using system versions. <mark_weaver>though remember that in general, the debian copyright file only includes anything that they didn't remove <mark_weaver>so it's not enough to just check the copyright file. if their original tarball is marked 'dfsg' then they trimmed it. <a_e>Are you going to write the e-mail to jgay? <a_e>I am in fact curious about this additonal sentence in python-markdown. <mark_weaver>a_e: there's another issue though. I don't think (license gpl3) is sufficient. <a_e>That should be the license of the combined work, no? <a_e>Apart from that, I added a remark that more details can be found in a file in the source distribution. <mark_weaver>that COPYRIGHT file at the top of calibre is clearly not reliable. they don't say a word about unrar, which is actually non-free software. <mark_weaver>and about mathjax that just say apache 2.0, but look at the debian copyright file for mathjax. <mark_weaver>note: I haven't checked to see whether the mathjax bundled with calibre is the same version as the file I cited in debian. <a_e>Apparently it is not exactly the same. <a_e>I do not find the fonts in the calibre distribution. <a_e>Still, the combined work is gpl3. no? <a_e>I think this is what we have done so far; we never copied all the licenses picked up by debian into our license field. <mark_weaver>given that I don't even recognize some of these licenses, I certainly can't agree with a statement like "the combined work is gpl3". <a_e>So what would you suggest? <rekado->I want to package Lilypond (music notation) and Solfege (music training) -- should they go to audio.scm or rather a new "music" module? <a_e>I am not a license specialist, and have no inclination to become one. I thought that whenever you combine a gpl-compatible non-copyleft license with the gpl, you end up with a gpl. <mark_weaver>a_e: I don't know, why don't you ask civodul and I'll let him decide for now. <a_e>In that they are compatible, I trust debian (and usually the author, except that packaging the non-free unrar does not inspire much trust). <mark_weaver>we can't trust upstream authors to summarize their own licenses. <a_e>Trusting debian should be a reasonable middle ground. <mark_weaver>okay, but trusting debian does not lead to the conclusion "the combined work is gpl3" <a_e>Do you think my previous statement is wrong? gpl + non-copyleft = gpl? <a_e>I do not know, actually. <mark_weaver>for one thing, there may be components in there that have a more restrictive license, but that are merely aggregated with the GPL'd code so there's no compatibility issue. <mark_weaver>well, rather than saying "more restrictive", let's say "imposes restrictions not found in the GNU GPL" <a_e>Actually, there is still the question: Are you going to write to jgay, or should I? <jgay>a_e, well write to licensing@fsf.org and not me ... and then you can refer to licensing and stop buzzing me into this channel ;-) <a_e>jgay: Yes, that was what I meant. <mark_weaver>a_e: here are some examples of restrictions added by the markdown license that are not in gpl3: <mark_weaver>"provided that the above copyright notice [...] and this permission <mark_weaver>"and that the name of Secret Labs AB or the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission." <mark_weaver>if someone trusts a summary of "the combined work is gpl3", they would not know about those restrictions. <mark_weaver>not to mention that they are attempting to say you can't even _use_ the software without agreeing to those restrictions, whereas there's no basis for them to make that demand unless you do something that would violate copyright law, e.g. redistribute. <mark_weaver>anyway, I'm not a lawyer, so I'll have to punt to someone more knowledgable. <a_e>No, I am having an SMTP problem! <rekado->I think there's a problem with python2-pygtk. Shouldn't it recommend a search path? <civodul>rekado-: what a funny idea to add a Stow package :-) <a_e>rekado-: Thanks for freepats and timidity! <rekado->re stow: well, I wanted to try it for config file management, so I packaged it. <rekado->civodul: search path: it uses the gnu-build-system so it doesn't automatically recommend to set the PYTHONPATH variable. <jxself>Isn't that suppose to be part of Guix? <a_e>550 invalid DNS A/AAAA resource record <rekado->Solfege depends on pygtk; when I add it as an input, install it and run "solfege" it fails with "ImportError: No module named gtk". <rekado->Or should the solfege package replace the "solfege" executable with a wrapper that sets the PYTHONPATH and then runs .solfege-real? <rekado->bavier`: pygtk is not installed to my profile. It's just in the store. <rekado->i.e. I would have to set a very ugly PYTHONPATH. And how would a user installing Solfege know about this? <bavier`>python-build-system automatically wraps executables, but I don't recall how it decides what to include <taylanub>maybe I should try that for nmap. I still have a wip branch lying around. <bavier`>but if solfege doesn't use python-build-system, a wrapper might be needed, unless solfege provides some other mechanism to set the load path <civodul>rekado-: the PYTHONPATH recommendation is given when both python and pygtk are installed in a given profile <civodul>(or when both are available in a build environment) <bavier`>I get a "No variable named declare-relative-uri-header! in #<directory (web http) 25e12d0>" when compiling (guix build download) with guile 2.0.5