<jxself>My understanding is that they have numerous games available to play, in essence acting as a store or maybe a repository. "...nor should the distribution refer to third-party repositories that are not committed to only including free software..." which is what it seems would kinda be happening. <jxself>So, I think it is not appropriate for inclusion in a free system unless all of their games were required to be free and they had a policy to remove non-free games if they were discovered to have been included by accident. <mark_weaver>my understanding is that it's okay if only the game artwork/maps are non-free.. but yeah, they'd have to be committed to including only free software. <mark_weaver>and I don't get the impression that they have any such commitment. <jxself>Indeed - the non-functional parts (sounds, pictures, etc.) don't need to be free but do need to allow for (at least) verbatim distribution both commerically & non-commercially. <mark_weaver>yeah, I forgot to mention the requirement to allow verbatim redistribution. <mark_weaver>actually, I'm not sure what RMS's position would be on whether it's okay for a free distro to merely _steer_ users toward downloading non-functional data that does not allow verbatim redistribution. <mark_weaver>but frankly, I'm not very enthusiastic about including such a package. <davexunit>I don't desurium would be a good fit for guix <davexunit>not unless it was changed to point to a server that recommended only free games. <jxself>Which means someone would need to maintain that. <davexunit>but isn't this what is done with browser addons and such already? <davexunit>there would have to be someone willing to do such work. <jxself>In a way, yes. But it's additional administrative work, so just pointing it out as something to consider. <gzg>jxself: That's an interesting prospect, but too a big if. That being said, as/if Guix gets a *lot* more popular -- I think it'd be good to have clear package guidelines out there, for those less familiar with such ideals/standards. We probably don't want to be flooded by commits which are some factor of unusable, if the platform gets picked up on/to any major degree. :^P <jxself>gzg: I think it's already clear enough in the FDSG on gnu.org/distros? <jxself>If not, a clarification can be brought up on the gnu-linux-libre mailing list? I understand that there is FSF staff subscribed there. <gzg>jxself: I'm saying, making such specifications more easily discoverable to those hacking on Guix. Not really an obvious place to find such info and if you are using Guix for a technical reason, then such prospects might not be active in one's mind. :^P <gzg>mark_weaver: Well yes, I know that -- but my concern is that it's not obvious for those in the future (if/when gets a flood of new contributors for packages) and we get a flood of patches for expressions that break these, because they aren't using/hacking GNU for ethical reasons, but technical ones "strictly" (primarily). Though, I might just be worrying for little to nothing. :^P <jxself>Yep, and hopefully people hacking Guix will at least read that, since I think it's linked to in the documentation? If not, perhaps it'll come up when patches are submitted to the mailing list and get caught there? Even if something that shouldn't be there makes it all the way in that's not necessarily a bad thing as long as the distro makes a good faith effort to only include appropriate stuff and removes stuff when it's discovered. <gzg>jxself: I might just be a bit anxious, with the "recent" gotcha with Emacs awhile back -- that there was a far amount of flack for. <jxself>Sure - The GNU Project is very visible. <jxself>davexunit: You missed out on the GPL problem? <jxself>It was fixed quickly, which is good. <mark_weaver>Section 6.3.1 of the Guix manual (GNU Distribution > Packaging Guidelines > Software Freedom) talks about this, and links to the same URL I gave before. <mark_weaver>do you have a specific suggestion about how to make this more clear? <gzg>mark_weaver: Okay good -- shame on me for skimming past this information then. <jmd>I wonder if there are download statistics available for hydra? <civodul>not that i know of, but it should be possible <civodul>not sure it'd be very impressive at this point ;-) <jmd>Sometimes it seems rather slow to me. <civodul>it is, and part of it is due to Guile's web client <civodul>i looked into it, but failed to find where the bottleneck is <jmd>Seems to be hosted by MIT so shouldbe super fast. <civodul>fixing it is really important for us, but i'd like to get help with that <jmd>What are "native-inputs" and how are they different to "inputs" ? ***jmd` is now known as jmd
<Steap>civodul: so, what happened with the eog patch series is that I was away from home :) <mark_weaver>jmd: the distinction between 'inputs' and 'native-inputs' is important when cross-compiling. 'native-inputs' are inputs that will run on the build machine at compile-time, and 'inputs' will run on the host at run-time. <civodul>Steap: so i assume you're back now :-) <Steap>civodul: yeah, so I'll have to resend <Steap>btw, I don't know if I should push the patch that adds eog, since running eog does not wor <civodul>that really needs to be fixed, it's not difficult <Steap>civodul: and may be because of other stuff :) <Steap>civodul: yes, the question is "should GNOME programs land in Guix before they can actually be used ?" <Steap>The guy running guix package -i eog && eog might be disappointed <Steap>like, I don't know, there might be other issues :) <Steap>Not sure if you managed to run it <civodul>as i said, we discussed how to fix it <Steap>I'll have to dive into the ml archives :) <civodul>to start with, you could resend all the patches up to eog, excluded <Steap>Knowing I also have to report a bunch of bugs to Debian, look at the Python test failures, and fix my Dad's Internet connection over the phone <civodul>though it's be great to have that for 0.5, it's OK if that happens after <jmd>Texinfo doesn't need TeX to build, so it is not an input. But it's not very useful without it. How should I declare this dependency? <Steap>I think the Ubuntu guys are sabotaging Guix by forcing me to spend 5 hours on the phone with my Dad <civodul>jmd: Texinfo can produce Info and HTML without TeX <civodul>jmd: so if you want to build PDFs with Texinfo, you need to add TeX Live as an input <jmd>civodul: OK. I'll do that. <jmd>hopefully the substutiter will work... <jmd>It would seem to me, that pkg-config should (almost) always be declared as a native-input (not input). <jmd>But that is not what I see ... <civodul>jmd: it might be faster to build it locally <civodul>jmd: right, pkg-config should be a native input <civodul>perhaps we made some mistakes in some places <jmd>I'll run a script to identify such instances, and post a patch then. <jmd>I think the same might be true for many uses of perl too. <jmd>How can I build texlive locally, rather than downloading it? <mark_weaver>jmd: add the --no-substitutes option to the command that builds or installs it. <jmd>Is --no-substitutes working now? <mark_weaver>I remember hearing about a bug on i686, but I don't have any i686 systems so I can't easily check its current status. <mark_weaver>I always pass --no-substitutes to the daemon, and that works for me on both x86_64 and mips64el anyway. <jmd>It has never seemed to make any difference for me. <mark_weaver>however, note that if you've already installed it from substitutes, then you'll have to delete those packages from your system. <jmd>But it'll just try to download it again, wont it? <mark_weaver>if you pass --no-substitutes to either the daemon or the install command, then it should not download any substitutes during that command. <jmd>But --no-substitutes is broken ... <mark_weaver>I've neither looked at nor used the substitutes code, and I don't have an i686 system, so it would be good if someone else could look into it. <mark_weaver>It's interesting that it doesn't happen on MIPS N32, even though that's also basically a 32-bit ABI (although it uses 64-bit registers internally). <mark_weaver>jmd, jxself: if you pass --no-substitutes to guix-daemon (not to guix build/package), does it work then? <jmd>I'll have to wait till I get home to try that. Remotely I don't have root access. <jxself>I don't know. I don't have sucha machine. My "on i686" comment was to jmd's "but But --no-substitutes is broken ..." comment. <jmd>It wouldn't be a bad idea to split texlive into at least two different outputs. <a_e>jmd: Agreed, it would be good to have a minimal texlive. But I do not know how to create it. What do you include? <jmd>Dunno. But one thing I would exclude would be the docus <jmd>How do I install a particular version of a package? <a_e>Indeed. This would save 1500 MB out of 3300. <a_e>guix package -i qt-4.8.5 <a_e>You use the package name, "-" and the exact version number. <a_e>This is independent of the scheme variable name, which is used for inputs to other packages. <a_e>And there are 1200 MB of fonts in texlive. <viric>hm Vimeo requires videos coded in h264 + aac... That's not very nice, is it <jxself>There are free programs to play such things.