IRC channel logs

<gzg>civodul: Yeah, with a full xorg metapackage -- so not sure what exactly it was acting on. (Just installed, and changed "exec stumpwm" to "exec guile-wm" on said Debian install).

<gzg>Not sure how "proper" just launching via xstart would be -- but I'm in process of appending it via xorg.scm.

<civodul>ok

<civodul>i should try it again

<civodul>until then, good night/day!

<gzg>civodul: o/

<gzg>Aw. :^(

<gzg>davexunit: o/

<davexunit>gzg: \\o

<handheldCar>guix configure wants guile-2.0 >= 2.0.5 even after I install 2.0.5+1-1 package.

<mark_weaver>handheldCar: you also need the guile-2.0-dev package

<mark_weaver>in general, whenever you build anything from source, you need the *-dev packages of the dependencies.

<handheldCar>In the documentation, http://bit.ly/18NQXEz, a for line is commented out. Shouldn't that be ran?

<jmd>I think the # is supposed to indicate the shell's prompt.

<handheldCar>oh, yeah probably

<klrr_># is indicating it's run by root

<jmd>But I agree it is confusing.

<civodul>Hello Guix!

<jmd>guix build takes a long time after you've touched gnu-build-system.scm !!

<civodul>jmd: changing gnu-build-system.scm triggers a world rebuild

<civodul>because everyone uses that file, on the build side

<civodul>so, if it has to be changed, that must be done in a core-updates branch

<civodul>howdy!

<jmd>civodul: Sometimes I am a slow learner.

<civodul>oh, what makes you say so?

<jmd>I have only just realised the origin of your /nick

<civodul>ah ah :-)

<civodul>a_e: so the ffmpeg thing worked, cool!

<a_e>Yes, it did, eventually!

<a_e>Now it would be good to package mplayer, but it is very unconventional. And when compiling it, I get asm errors.

<a_e>Some time ago, we had someone here on irc who worked on a fork of a fork (mplayer2) of mplayer. Do you remember what it was called?

<civodul>i think we have to be careful with that one

<civodul>noe

<civodul>nope

<a_e>Why careful?

<civodul>about its copyright and licensing status

<civodul>ISTR that it's not crystal clear

<a_e>I thought it was gpl.

<civodul>possibly, but i think it needs to be checked more closely

<civodul>how about vlc? :-)

<a_e>I am not used to vlc. It may have different key bindings ;-)

<jxself>It has a Preference windows where those can be changed.

<a_e>jxself: As a fan of free video codecs, would you feel like packaging some as additional inputs to ffmpeg?

<civodul>:-)

<a_e>"MPlayer is available under the GNU General Public License version 2. It is not available under any other licensing terms, not even for substantial amounts of money. If you have questions about the GNU GPL, consult the GPL FAQ. "

<civodul>or do you know about the status of mplayer?

<jxself>I've not looked into mplayer, no.

<civodul>ok

<a_e>Mplayer was the first video player that actually played more or less all videos. So I feel some emotional attachment...

<civodul>yeah, that's also the first one i used

<a_e>At a time where alsa was solving the issue of not working sound.

<jxself>What else needs packaging? libpx I assume for VP8 & VP9?

<jxself>libopus?

<jxself>For sound

<a_e>There is --enable-libvpx in ffmpeg.

<a_e>And --enable-libopus.

<jxself>Yes, I haven't looked to see if libvpx has in guix yet or not.

<a_e>Opus is part of the xiph codec family, no? These are usually easy to package, so it would be a good starting point.

<jxself>Yes, opus is easy. It has similiar dependencies to libvorbis (read: not much.)

<a_e>If you look in video.scm, you have all the --enable-*** flags for ffmpeg. All are free, I suppose, but potentially patented.

<a_e>Good, then it could be more or less copy-paste inside oggvorbis.scm.

<jxself>Was there ever a decision on what to do in relation to patents?

<jxself>As in, ignore, avoid, something else?

<a_e>It is not only the number of inputs, also the use of autotools etc..

<a_e>Since we packaged xorg and the mouse click is patented, I think we do not care ;-)

<jxself>A mouse click is probably not a good example.

<jxself>But OK.

<jxself>In that case most of the stuff in FFmpeg can be turned on then.

<a_e>Seriously, I understood that the official gnu and fsf position is since that virtually everything is patented, we are forced to not care about patents, unless there are lawsuits and so on?

<a_e>So far, in any case, we did not expend major efforts in packaging patented codecs.

<jxself>I think the FSF has a multi-pronged position: On one, push to eliminate software patents entirely. On the second, promote the use of things that don't have these issues until (or unless) the first prong is successful.

<a_e>That sounds like a good position.

<jxself>But there's probably a third, which is that people do need free programs to do the things that they need to do, even if that involves reading a Microsoft Word file in LibreOffice or a FAT-formatted disk in GNOME>

<a_e>But does not tell us exactly what to do with respect to our distribution.

<jxself>In the FSDG they leave the patent decision up to the distro.

<jxself>And plays no role in the endorsement criteria.

<jxself>But, at the very least, libvpx and libopus would be good to have, yes.

<a_e>Yes, to have the non-patented ones first would be good.

<jxself>I think I saw Theora was already there.

<jxself>So, progress :)

<a_e>Yes.

<a_e>Anyway, ffmpeg already includes patented codecs. I just transcoded some video from .wmv to .avi.

<jxself>Yes it does.

<jxself>Packaging libvpx might be challenging because I understand it's not currently possible to reference a particular tag in git?

<jxself>version 1.3.0 came out and exists only as a tag - http://git.chromium.org/gitweb/?p=webm/libvpx.githttp://git.chromium.org/gitweb/?p=webm/libvpx.git

<a_e>We usually only package releases.

<jxself>Yeah - That's where their releases are. As tags in git, if you scroll down to the tags section :)

<jmd>As I understood it, the FSF's position was to avoid patents only which are being actively enforced.

<jmd>... since there are patents on everything from linked lists, floating point numbers and the wheel.

<jxself>So I am not sure how libvpx would be packaged at this point.

<a_e>jmd: Yes, that was my interpretation; and all of them should be invalid in Europe, if I understand correctly.

<a_e>jxself: On the web page, they mention "versioned snapshots"; behind the link, there is a version 1.2.0.

<jxself>Yes, but that's a problem.

<a_e>Maybe 1.3.0 will come? Or are tarballs abandoned?

<jxself>Version 1.2 was released in December 2012 and only (in October 2013) did a tarball arrive.

<jmd>ghostscript is going to need a lot of patching to get it cross-compiling

<a_e>We can extend guix to download sources from git.

<a_e>Or we can also host tarballs on external servers, which I am not too fond of.

<jxself>That would be good, and reference the tag for version 1.3.

<a_e>Or bug the developers to create release tarballs.

<jxself>They may say "Why when I can just make a tag?"

*jxself shrugs

<a_e>How about signed tarballs?

<a_e>Can one signe a git tag?

<jxself>Git supports GPG signed stuff too.

<jxself>Commits can be signed for example.

<a_e>Is there a special url to obtain a tarball out of a git hash on git.chromium.org?

<a_e>With a deterministic result?

*jxself looks

<jxself>I am not seeing anything, unless I am missing it.

<a_e>Me neither.

<civodul>jmd: note that cross-compilation is not really a major goal at this point

<civodul>the main goal was to allow cross-compilation of bootstrap-tarballs, which was achieved

<civodul>of course the more the better, but don't consider it a top priority :-)

<jmd>fair enough.

<civodul>then again, if you have projects in mind using it, i have nothing against it

<jmd>I think it'd be rather cool to be able to say that guix can automatically compile the complete gnu system to <your-favourite-platform>

<civodul>the whole system?

<civodul>that's going to be very difficult

<civodul>even the toolchain sometimes needs workarounds

<civodul>let alone random applications

<civodul>so yes it'd be cool, but it'd be difficult, and a constant maintenance burden

<jxself>Debian is able to pull it off because they have people dedicated to working on arch-specific issues. Guix doesn't really have that (yet?) :)

<civodul>for now i think we should focus on the critical path to get to a standalone system

<civodul>jxself: yeah exactly :-)

<civodul>but Debian doesn't even cross-compile

<jmd>Well that might be true. But if we can do the more commonly used libraries, then it'd be a great development tool for porting applications.

<jxself>Yeah, AFAIK they build things natively on the relevant hardware.

<civodul>yes, i agree

<jmd>jxself: So far as I'm aware, Debian doesn't generally cross-compile things.

<civodul>jmd: it's just a matter of strategy and focus :-)

<jxself>I was referring more to supporting lots of CPU architectures.

<jxself>er; I can't type...

<jmd>civodul: Maybe I should read the roadmap too.

<civodul>heh :-)

<civodul>i think it's outdated

<civodul>well, not really, but the dates are a bit off

<civodul>:-)

<jxself>Oh, you mean the non-GUI installer didn't arrive in September? :)

<civodul>right, things like that :-)

<civodul>OTOH we had a number of unanticipated things that happened too

<civodul>like the MIPS port

<civodul>like many of the crazy big packages (TeX Live, IceCat, etc.)

<civodul>so i think we're doing pretty good :-)

<jxself>Yep yep.

<jxself>Oh, jmd ran away.

<jmd>No I didn't

<jxself>Oh, a different version of you did. I see...

<jmd>It's not clear to me how guix will achieve a bootable, standalone system.

<civodul>argh, we lost jmd again

<civodul>it's quite clear to me anyway :-)

<sirgazil>Great to hear that, civodul, because I can't wait to use GNU Guix in my daily computing activities.

<civodul>heh, good :-)

<civodul>sure it takes time etc., but i think we know how to get there

<civodul>and we've never been this close ;-)

<jxself>We're close?

<jxself>That's good.

<civodul>i just said: we've never been this close

<civodul>:-)

<jxself>Exactly, to which I responded that we're close?

<jxself>That's a good thing.

<civodul>heh

<sirgazil>By the way, I'm a gNewSense and Trisquel contributor. I can help with graphics, documentation, localization, and some Python scripting. I hope I can help the project in the future (or right now if there is anything I can do).

<civodul>sirgazil: thanks for the offer!

<civodul>i'm sure we can find ways to help

<civodul>by graphics, you meant "marketing-oriented" graphics?

IRC channel logs

2013-12-17.log