IRC channel logs


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>How is it bootstrapped?
<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>then (guix-package "-i" "emacs")
<mark_weaver>I think that's errno E2BIG
<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.
<bavier>I was thinking that
<mark_weaver>but I'm still curious where the E2BIG is coming from
<bavier>me too ;)
<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.
<mark_weaver>but anyway, I'm glad it's working now :)
<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>Hello Guix!
<taylanub>civodul: welcome back! :-)
<civodul>i have to catch up with all the things that you folks have been doing
<civodul>it's nice to see all this!
<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->I have a short question about this patch:
<rekado->should I name the package and variable "timidity" or "timidity++" as it's called upstream?
<rekado->Andreas had objections against "timidity++".
<mark_weaver>we call it "gtk+"
<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->thanks for the data point.
<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?
<mark_weaver>sorry, I meant is there a command-line option.
<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.
<mark_weaver>okay, sounds reasonable
*civodul is fine with timidity++
<mark_weaver>welcome back, civodul!
<davexunit>back in the saddle
<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>a_e: I'd like to know why Debian removed it
<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 and we'll prioritize working on an a reply in the next day or two?
<mark_weaver>jgay: okay, thanks!
<jgay> 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.
<mark_weaver>a_e: ah yes
<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>Yes, agreed.
<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>take a look at the debian copyright file for just mathjax, for example:
<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.
<mark_weaver>s/that just say/they just say/
<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.
<mark_weaver>almost everyone is sloppy about legal matters
<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>I think that's far too simplistic, yes.
<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>Hm, I see. Vaguely.
<a_e>Actually, there is still the question: Are you going to write to jgay, or should I?
<mark_weaver>if you're willing, go ahead :)
<jgay>a_e, well write to 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: could you CC me?
<a_e>mark_weaver: Sure!
<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>notice appear in supporting documentation"
<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>E-Mail sent.
<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 :-)
<civodul>rekado-: search path for what?
<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?
<jxself>Indeed funny then. :)
<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".
<bavier`>rekado-: did you set PYTHONPATH?
<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?
*rekado- has to go now.
<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