Re: [PATCH] gnu: Add ffmpeg.
Ludovic Courtès asked: > Anyway, I agree that it’s a major inconvenience, but I wonder if we > should be concerned about shipping without testing. What do people > think? I have no objection.
Re: [PATCH] gnu: Add ffmpeg.
Andreas Enge skribis:
> On Sun, Dec 01, 2013 at 12:12:54AM +0100, Ludovic Courtès wrote:
>> The samples wouldn’t really have to be “packaged”: they’d just be an
>> input. For someone using substitutes, the samples are not going to be a
>> problem (because they’ll never be downloaded.) However, it is indeed a
>> problem when building things locally.
>
> Well, so far the only way I have been told to get them is via rsync.
> So one might need to create a .tar(.gz?) from the download.
Not necessarily. It could fetch the directory as is. There could be an
‘rsync-fetch’ method for , just like we have ‘url-fetch’. (A
little bit of work, but that seems doable, if we want to.)
> And in any case, an input means a package variable, no?
I would rather make it an (assuming there’s a way to get at an
immutable version of those samples), and it doesn’t need to be bound a
variable:
(define ffmpeg
(package
...
(inputs `(("samples" ,(origin
(method rsync-fetch)
...))
Back to the problem at hand: the short-term answer is to add
#:tests? #f with a link to this discussion. The longer term answer
may be to try to run those FATE tests.
WDYT?
Ludo’.
Re: [PATCH] gnu: Add ffmpeg.
On Sun, Dec 01, 2013 at 12:12:54AM +0100, Ludovic Courtès wrote: > The samples wouldn’t really have to be “packaged”: they’d just be an > input. For someone using substitutes, the samples are not going to be a > problem (because they’ll never be downloaded.) However, it is indeed a > problem when building things locally. Well, so far the only way I have been told to get them is via rsync. So one might need to create a .tar(.gz?) from the download. And in any case, an input means a package variable, no? Andreas
Re: [PATCH] gnu: Add ffmpeg.
On Sat, Nov 30, 2013 at 09:44:26PM +0100, Andreas Enge wrote: On Wed, Nov 27, 2013 at 11:50:54PM +0100, Andreas Enge wrote: > I just submitted a bug report for the failure on i686: >https://trac.ffmpeg.org/ticket/3177#no1 Well, it looks as if "make check" is not the preferred way of testing ffmpeg. Rather, one should download about 750 MB of video samples and run a specific test program on them (that can be built and run with "make fate"); see the replies to the bug report. For Guix, it does not seem to be reasonable to either download 750 MB of test data, or to package them, so I would suggest to disable the tests for now. What do you think? I think you should phone the mental health department and suggest the ffmpeg developers be sectioned, on by reason of public safety! J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. signature.asc Description: Digital signature
Re: [PATCH] gnu: Add ffmpeg.
Andreas Enge skribis: > On Wed, Nov 27, 2013 at 11:50:54PM +0100, Andreas Enge wrote: >> I just submitted a bug report for the failure on i686: >>https://trac.ffmpeg.org/ticket/3177#no1 > > Well, it looks as if "make check" is not the preferred way of testing ffmpeg. > Rather, one should download about 750 MB of video samples and run a specific > test program on them (that can be built and run with "make fate"); see the > replies to the bug report. Ouch, indeed. > For Guix, it does not seem to be reasonable to either download 750 MB of > test data, or to package them, so I would suggest to disable the tests > for now. > > What do you think? Is it really the case that that much needs to be downloaded before the slightest test can be run? The samples wouldn’t really have to be “packaged”: they’d just be an input. For someone using substitutes, the samples are not going to be a problem (because they’ll never be downloaded.) However, it is indeed a problem when building things locally. Anyway, I agree that it’s a major inconvenience, but I wonder if we should be concerned about shipping without testing. What do people think? Ludo’.
Re: [PATCH] gnu: Add ffmpeg.
On Wed, Nov 27, 2013 at 11:50:54PM +0100, Andreas Enge wrote: > I just submitted a bug report for the failure on i686: >https://trac.ffmpeg.org/ticket/3177#no1 Well, it looks as if "make check" is not the preferred way of testing ffmpeg. Rather, one should download about 750 MB of video samples and run a specific test program on them (that can be built and run with "make fate"); see the replies to the bug report. For Guix, it does not seem to be reasonable to either download 750 MB of test data, or to package them, so I would suggest to disable the tests for now. What do you think? Andreas
Re: [PATCH] gnu: Add ffmpeg.
I just submitted a bug report for the failure on i686: https://trac.ffmpeg.org/ticket/3177#no1 Unfortunately, there is not much information I could give. Andreas
Re: [PATCH] gnu: Add ffmpeg.
On Sat, Nov 02, 2013 at 12:37:20AM +0100, Ludovic Courtès wrote: > I have a test failure on x86_64 (for > /nix/store/iz59b5w12xj4p9yf2mn9vbg7i69vvnks-ffmpeg-2.1): This is the exact same hash that I compiled without problem. Could you try a few times to see whether it is deterministic? Or maybe disable parallel tests? Could it be that the output of yasm depends on the machine? Andreas
Re: [PATCH] gnu: Add ffmpeg.
I have a test failure on x86_64 (for /nix/store/iz59b5w12xj4p9yf2mn9vbg7i69vvnks-ffmpeg-2.1): --8<---cut here---start->8--- TESTlavf-xwd --- ./tests/ref/lavf/xwd2013-10-28 00:58:06.0 + +++ tests/data/fate/lavf-xwd2013-11-01 23:32:31.0 + @@ -2,7 +2,7 @@ ./tests/data/images/xwd/%02d.xwd CRC=0x6da01946 304239 ./tests/data/images/xwd/02.xwd 1cdb43599c956dc8563f1e09fac5df00 *./tests/data/images/xwd/02.xwd -./tests/data/images/xwd/%02d.xwd CRC=0xf07d29cd +./tests/data/images/xwd/%02d.xwd 405615 ./tests/data/images/xwd/02.xwd c0866e9e710fce735423594a93bee604 *./tests/data/images/xwd/02.xwd ./tests/data/images/xwd/%02d.xwd CRC=0x53209216 Test lavf-xwd failed. Look at tests/data/fate/lavf-xwd.err for details. make: *** [fate-lavf-xwd] Error 1 --8<---cut here---end--->8--- Ludo’.
Re: [PATCH] gnu: Add ffmpeg.
On Fri, Nov 01, 2013 at 12:38:23PM +0100, Ludovic Courtès wrote: > > +(synopsis "audio and video framework") > Start with a capital letter. Okay, I corrected and pushed it. Notice that there are plenty of optional inputs, so that people wishing to train their packaging skills have lots of opportunity to add the corresponding libraries to the distribution. For a beginner, I would in particular suggest opus: It is probably just a matter of copy-pasting a package from oggvorbis.scm. > Thus, I’m inclined to use FFmpeg by default in video applications. > Thoughts? Well, I would be inclined to do the same, as ffmpeg is the name I know, and with respect to functionality and security updates, it looks like they are a tiny bit ahead. Andreas
Re: [PATCH] gnu: Add ffmpeg.
Andreas Enge skribis: > From 4495e12c987a6a0749db8724e8d4d2a7ac546f6d Mon Sep 17 00:00:00 2001 > From: Andreas Enge > Date: Thu, 31 Oct 2013 23:15:46 +0100 > Subject: [PATCH] gnu: Add ffmpeg. > > * gnu/packages/video.scm: New file. > * gnu-system.am (GNU_SYSTEM_MODULES): Add module. Fine with me! > +(synopsis "audio and video framework") Start with a capital letter. To recap, there was a lengthy FFmpeg vs. libav debate on IRC. As a distro I think we should provide both (assuming there are noteworthy technical differences, or incompatibilities.) The question that heated the debate ;-) is which one should be used as the default dependency in applications (it’s only about the default; remember it’s easy to programmatically provide variants of the package that use the other one, for users who would want that.) My understanding of the discussion is that there is no big technical difference between the two, and no significant difference in the projects’ attitudes toward user freedom. Thus, I’m inclined to use FFmpeg by default in video applications. (It’s a choice we can always revisit as the situation evolves.) Thoughts? Ludo’.
[PATCH] gnu: Add ffmpeg.
Hello,
the attached patch add ffmpeg. Comments are welcome.
Andreas
>From 4495e12c987a6a0749db8724e8d4d2a7ac546f6d Mon Sep 17 00:00:00 2001
From: Andreas Enge
Date: Thu, 31 Oct 2013 23:15:46 +0100
Subject: [PATCH] gnu: Add ffmpeg.
* gnu/packages/video.scm: New file.
* gnu-system.am (GNU_SYSTEM_MODULES): Add module.
---
gnu-system.am | 1 +
gnu/packages/video.scm | 172 +
2 files changed, 173 insertions(+)
create mode 100644 gnu/packages/video.scm
diff --git a/gnu-system.am b/gnu-system.am
index f77bb03..eba1dce 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -178,6 +178,7 @@ GNU_SYSTEM_MODULES =\
gnu/packages/unrtf.scm \
gnu/packages/valgrind.scm\
gnu/packages/version-control.scm \
+ gnu/packages/video.scm \
gnu/packages/vim.scm \
gnu/packages/vpn.scm \
gnu/packages/w3m.scm \
diff --git a/gnu/packages/video.scm b/gnu/packages/video.scm
new file mode 100644
index 000..97287a5
--- /dev/null
+++ b/gnu/packages/video.scm
@@ -0,0 +1,172 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2013 Andreas Enge
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages video)
+ #:use-module ((guix licenses) #:select (gpl2+))
+ #:use-module (guix packages)
+ #:use-module (guix download)
+ #:use-module (guix build-system gnu)
+ #:use-module (gnu packages algebra)
+ #:use-module (gnu packages compression)
+ #:use-module (gnu packages fontutils)
+ #:use-module (gnu packages oggvorbis)
+ #:use-module (gnu packages openssl)
+ #:use-module (gnu packages perl)
+ #:use-module (gnu packages pkg-config)
+ #:use-module (gnu packages python)
+ #:use-module (gnu packages yasm))
+
+(define-public ffmpeg
+ (package
+(name "ffmpeg")
+(version "2.1")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "http://www.ffmpeg.org/releases/ffmpeg-";
+ version ".tar.bz2"))
+ (sha256
+ (base32
+ "1pv83nmjgipxwzy5s53834fq0mrqv786zz2w383ki6sfjzyh6rlj"
+(build-system gnu-build-system)
+(inputs
+ `(("bc" ,bc)
+ ("bzip2" ,bzip2)
+ ("fontconfig" ,fontconfig)
+ ("freetype" ,freetype)
+ ("libtheora" ,libtheora)
+ ("libvorbis" ,libvorbis)
+ ("perl" ,perl)
+ ("pkg-config" ,pkg-config)
+ ("python" ,python-2) ; scripts use interpreter python2
+ ("speex" ,speex)
+ ("yasm" ,yasm)
+ ("zlib", zlib)))
+(arguments
+ `(#:phases
+ (alist-replace
+ 'configure
+ ;; configure does not work followed by "SHELL=..." and
+ ;; "CONFIG_SHELL=..."; set environment variables instead
+ (lambda* (#:key outputs configure-flags #:allow-other-keys)
+(let ((out (assoc-ref outputs "out")))
+ (substitute* "configure"
+(("#! /bin/sh") (string-append "#!" (which "bash"
+ (setenv "SHELL" (which "bash"))
+ (setenv "CONFIG_SHELL" (which "bash"))
+;; possible additional inputs:
+;; --enable-avisynthenable reading of AviSynth script files [no]
+;; --enable-frei0r enable frei0r video filtering
+;; --enable-ladspa enable LADSPA audio filtering
+;; --enable-libaacplus enable AAC+ encoding via libaacplus [no]
+;; --enable-libass enable libass subtitles rendering [no]
+;; --enable-libbluray enable BluRay reading using libbluray [no]
+;; --enable-libcaca enable textual display using libcaca
+;; --enable-libcelt enable CELT decoding via libcelt [no]
+;; --enable-libcdio enable audio CD grabbing with libcdio
+;; --enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
+;;and libraw1394 [no]
+;;
