Re: Notice of mailing list closure: pkg-multimedia-maintainers

[Reinhard Tartler]

Thanks to both of you for your help. I'll add you as moderators shortly
after the list migration.

Best,
Reinhard

On Thu, Apr 12, 2018 at 5:20 PM Jonas Smedegaard  wrote:

> Excerpts from Reinhard Tartler's message of april 12, 2018 9:44 pm:
> > Hi Dominic,
> >
> > Based on the discussion on this list, please do migrate the
> > pkg-multimedia-maintainers list. Sorry for the short notice. I assume
> that
> > the list of current subscribers, as well as the rest of the mailman
> > configuration, will be retained, is that right?
> >
> > I'm OK to continue to serve as old and new list owner for the new mailing
> > list. I'd appreciate if other's would step up and help with weeding out
> the
> > moderation queue.
>
> Feel free to add me as moderator.
>
>  - Jonas
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136 <+45%2040%2084%2031%2036>  Website:
> http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Notice of mailing list closure: pkg-multimedia-maintainers

[Reinhard Tartler]

Hi Dominic,

Based on the discussion on this list, please do migrate the
pkg-multimedia-maintainers list. Sorry for the short notice. I assume that
the list of current subscribers, as well as the rest of the mailman
configuration, will be retained, is that right?

I'm OK to continue to serve as old and new list owner for the new mailing
list. I'd appreciate if other's would step up and help with weeding out the
moderation queue.

-rt



On Wed, Apr 11, 2018 at 4:22 PM Dominic Hargreaves  wrote:

> On Wed, Apr 11, 2018 at 09:05:41AM +0100, James Cowgill wrote:
> > Hi,
> >
> > On 02/04/18 16:21, alioth lists migration team wrote:
> > > Dear list subscribers,
> > >
> > > As per the announcement on debian-devel-announce[1] and as part of
> > > the shutdown of the alioth service, the migration of
> > > lists.alioth.debian.org mailing lists to alioth-lists.debian.net is
> now
> > > underway.
> > >
> > > We tried to contact the designated list owner via
> > > pkg-multimedia-maintainers-ow...@lists.alioth.debian.org but got
> either no reply,
> > > or a bounce message. Accordingly, this list will not be migrated to the
> > > new system and will stop working on 14th April.
> >
> > Given that the vast majority of packages are still on the old
> > lists.alioth.debian.org maintainer address, I think we will need the
> > list migrated otherwise the team will be screwed. Have I missed
> something?
>
> Would you like to be the new owner?
>
> Dominic.
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Notice of mailing list closure: pkg-multimedia-maintainers

[Reinhard Tartler]

Hi Mattia,

I am around, but am unsure what to do. Reading through the past mails on
this topic on the pkg-multimedia-maintainers mailing list, I thought the
plan was to move all packages to use "debian-multime...@lists.debian.org"
as maintainer, and we could safely let go of the alioth list. I may have
misunderstood something.

Best,
Reinhard

On Wed, Apr 11, 2018 at 5:10 AM Mattia Rizzolo  wrote:

> On Wed, Apr 11, 2018 at 09:05:41AM +0100, James Cowgill wrote:
> > Given that the vast majority of packages are still on the old
> > lists.alioth.debian.org maintainer address, I think we will need the
> > list migrated otherwise the team will be screwed. Have I missed
> something?
>
> Mhh, yes indeed.
>
> James: do you have time to either get ahold of siretart by tomorrow, or
> get formorer appoint you as an ML admin, so you can then ask the
> alioth-lists team to migrate it?
> Otherwise I can deal with formorer and become myself an admin.
>
> But rather, also that new ML is something temporary that will go away in
> few years, so really, please people remember to switch to the @l.d.o ML…
>
> --
> regards,
> Mattia Rizzolo
>
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Proposed multimedia team migration to salsa.d.o

[Reinhard Tartler]

On Mon, Jan 8, 2018 at 8:53 AM James Cowgill  wrote:

>
> > listmasters mentioned multiple times that they don't want something on
> > l.d.o to appear in the Maintainers field.
>
> I don't think they said that. They said that they don't want lots of
> mailing lists on lists.debian.org for purely for bugs/packaging things.
> My interpretation of the original announcement is that
> debian-multimedia@l.d.o qualifies because it is formally a list for all
> multimedia discussion as opposed to just packaging.
>
>
I just got an email as one of the "list owners" of
pkg-multimedia-maintainers@lists.alioth.debian.org - the basic question is
whether we want to continue using the list (on the new migration host) or
whether we abandon it in favor of debian-multime...@lists.debian.org

In the past, we used both lists with different emphasis. From the
discussion of this thread, I believe the answer the latter, but I wanted to
check for other opinions and thoughts on this.

Best,
Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#867115: smplayer crashes with "Error parsing option noquiet (option not found)"

[Reinhard Tartler]

Control: severity -1 important
Control: tags -1 moreinfo

Thank you for your bugreport. I had a look at the issue and have some
questions for you.

On Mon, Jul 3, 2017 at 6:09 PM Daniel 'DaB.' Baur 
wrote:

> Package: smplayer
> Version: 16.11.0~ds0-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> after the update to Debian Stretch, which makes smplayer using mpv instead
> of mplayer, the smplayer does not work anymore.
>
> Any file I try to open, smplayer crashes with "Error parsing option noquiet
> (option not found)". The problems seems to be, that mpv doesn’t have the
> same options that mplayer had, but smplayer does not respect this.
>

I can't reproduce that here. I've tested with these package versions:
siretart@debian:~$ dpkg -l mpv mplayer2 smplayer
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version
 Architecture Description
+++-==---=
un  mplayer2  
  (no description available)
ii  mpv0.23.0-2+b2  amd64
 video player based on MPlayer/mplayer2
ii  smplayer   16.11.0~ds0-1amd64
 Complete front-end for MPlayer and mpv


Invoking smplayer like this plays the video just fine:

siretart@debian:~$ smplayer
/tmp/20060131_dropping-pre-i686_jbailey-doko.ogg
This is SMPlayer v. 16.11.0 (revision 8242) running on Linux
siretart@debian:~$ echo $?
0

Please be more specific how to reproduce this issue. Do you have any local
versions of mpv in /usr/lo


Could this please be fixed or reverted back? Currently smplayer is pretty
useless in Debian.


Sincerely,
DaB.


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldstable-updates'), (300,
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored:
LC_ALL set to de_DE.UTF-8), LANGUAGE=de (charmap=UTF-8) (ignored: LC_ALL
set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages smplayer depends on:
ii  libc6 2.24-11+deb9u1
ii  libgcc1   1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5script5 5.7.1~20161021+dfsg-2
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxext6  2:1.3.3-1+b2
ii  mpv   0.23.0-2+b2
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages smplayer recommends:
ii  smplayer-l10n16.11.0~ds0-1
ii  smplayer-themes  1:16.8.0-1

smplayer suggests no packages.

-- no debconf information
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainerscal
or something?

Also, there is a new upstream version of smplayer in
experimental 17.3.0~ds0-1. Do you experience this issue also with that
version? If not, I'd propose to upload it to unstable.


>
> AFAIS you were told in #783401 that this would happen, but somehow this
> was ignored.
>

I don't know. That bug was marked fixed on Fri, 15 Jan 2016  and didn't see
any updates since then. I'd assume that the package worked fine for the
uploader back then, just like the current package works fine with mpv for
me.

It is certainly possible that I'm missing something here. In that case, any
clarifications would be much appreciated.

Best,
Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#864664: CVE-2017-9122 CVE-2017-9123 CVE-2017-9124 CVE-2017-9125 CVE-2017-9126 CVE-2017-9127 CVE-2017-9128

[Reinhard Tartler]

On Mon, Jun 12, 2017 at 12:06 PM Moritz Muehlenhoff  wrote:

> Source: libquicktime
> Severity: grave
> Tags: security
>
> Please see:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9122
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9123
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9124
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9125
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9126
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9127
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9128
>
>
I've just uploaded a patch that should fix this. See
https://anonscm.debian.org/cgit/pkg-multimedia/libquicktime.git/commit/?id=4728e38f2045d3d33be3d442a0ab9801990b4339

This is how I tested it:
reproducible with qtinfo:

vagrant@stretch:/tmp/42148$ ls -al
total 48
drwxr-xr-x  2 vagrant vagrant 4096 Jun  9 16:41 .
drwxrwxrwt 11 rootroot4096 Jun 30 20:27 ..
-rw-r--r--  1 vagrant vagrant 6148 Jun  7 09:00 .DS_Store
-rw---  1 vagrant vagrant 1967 May 17 03:52
libquicktime_1.2.4_lqt_frame_duration_heap-buffer-overflow.mp4
-rw---  1 vagrant vagrant 1987 May 17 03:11
libquicktime_1.2.4_lqt_frame_duration_invalid_memory_read.mp4
-rw---  1 vagrant vagrant 6841 May 17 03:11
libquicktime_1.2.4_quicktime_match_32_NULL_pointer_dereference.mp4
-rw---  1 vagrant vagrant 1338 May 17 07:13
libquicktime_1.2.4_quicktime_read_dref_table_heap-buffer-overflow.mp4
-rw-r--r--  1 vagrant vagrant 1259 Dec 16  2014
libquicktime_1.2.4_quicktime_read_moov_infinite_loop.mp4
-rw---  1 vagrant vagrant 1294 May 17 02:42
libquicktime_1.2.4_quicktime_user_atoms_read_atom_heap-buffer-overflow.mp4
-rw---  1 vagrant vagrant 1192 May 18 04:53
libquicktime_1.2.4_quicktime_video_width_heap-buffer-overflow.mp4
vagrant@stretch:/tmp/42148$ qtinfo  *.mp4
Type: MP4
  0 audio tracks.
  1 video tracks.
48x144, depth 24
rate 0.000369 [12:32541] not constant
length 0 frames
compressor avc1.
Native colormodel:  Undefined
Interlace mode: None (Progressive)
No timecodes available
supported.
  0 text tracks.
Type: MP4
  0 audio tracks.
  1 video tracks.
Segmentation fault
vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_lqt_frame_duration_heap-buffer-overflow.mp4
Type: MP4
  0 audio tracks.
  1 video tracks.
48x144, depth 24
rate 0.000367 [12:32660] not constant
length 0 frames
compressor avc1.
Native colormodel:  Undefined
Interlace mode: None (Progressive)
No timecodes available
supported.
  0 text tracks.
vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_lqt_frame_duration_invalid_memory_read.mp4
Type: MP4
  0 audio tracks.
  1 video tracks.
Segmentation fault
vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_quicktime_match_32_NULL_pointer_dereference.mp4
Segmentation fault
vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_quicktime_read_dref_table_heap-buffer-overflow.mp4
Segmentation fault
vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_quicktime_read_moov_infinite_loop.mp4
^C

vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_quicktime_user_atoms_read_atom_heap-buffer-overflow.mp4
[ffmpeg_video] Error: No avcC atom present, decoding is likely to fail
Type: MP4
  0 audio tracks.
  1 video tracks.
Segmentation fault
vagrant@stretch:/tmp/42148$ qtinfo
libquicktime_1.2.4_quicktime_video_width_heap-buffer-overflow.mp4
[codecs] Warning: Could not find video Decoder for fourcc
[codecs] Warning: quicktime_decode_video_stub called
Type: MP4
  0 audio tracks.
  1 video tracks.
Segmentation fault


With the patch applied:

vagrant@stretch:/tmp/42148$ for i in *.mp4; do echo $i; qtinfo $i; echo
; done
libquicktime_1.2.4_lqt_frame_duration_heap-buffer-overflow.mp4
[core] Error: Opening failed (unsupported filetype)
Couldn't open libquicktime_1.2.4_lqt_frame_duration_heap-buffer-overflow.mp4

libquicktime_1.2.4_lqt_frame_duration_invalid_memory_read.mp4
[core] Error: Opening failed (unsupported filetype)
Couldn't open libquicktime_1.2.4_lqt_frame_duration_invalid_memory_read.mp4

libquicktime_1.2.4_quicktime_match_32_NULL_pointer_dereference.mp4
[core] Error: Opening failed (unsupported filetype)
Couldn't open
libquicktime_1.2.4_quicktime_match_32_NULL_pointer_dereference.mp4

libquicktime_1.2.4_quicktime_read_dref_table_heap-buffer-overflow.mp4
[core] Error: Opening failed (unsupported filetype)
Couldn't open
libquicktime_1.2.4_quicktime_read_dref_table_heap-buffer-overflow.mp4

libquicktime_1.2.4_quicktime_read_moov_infinite_loop.mp4
[core] Error: Opening failed (unsupported filetype)
Couldn't open libquicktime_1.2.4_quicktime_read_moov_infinite_loop.mp4

libquicktime_1.2.4_quicktime_user_atoms_read_atom_heap-buffer-overflow.mp4
[core] Error: Opening failed (unsupported filetype)
Couldn't open
libquicktime_1.2.4_quicktime_user_atoms_read_atom_heap-buffer-overflow.mp4

Re: kodi on ci20 creator

[Reinhard Tartler]

Sounds good to me. Is there some friendly mips porter who could help us out
here?

-rt

On Sun, Apr 2, 2017 at 1:06 PM James Cowgill  wrote:

> Hi,
>
> [+CC multimedia team]
>
> On 02/04/17 17:38, Mathieu Malaterre wrote:
> > On Sun, Apr 2, 2017 at 6:03 PM, Mathieu Malaterre 
> wrote:
> >> Hi there,
> >>
> >> Does anyone knows what is going on with kodi dependencies on mipel ?
> >
> > OK I think I see the build dependencies loop:
> >
> >
> https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports
>
> With these binaries:
> libchromaprint-dev | 1.2-1| stable   | mipsel
> ffmpeg | 7:3.0.2-4~bpo8+1 | jessie-backports | mipsel
> x265   | 2.0-4~bpo8+1 | jessie-backports | mipsel
>
> And these sources:
> chromaprint | 1.3.2-2~bpo8+1   | jessie-backports | source
> ffmpeg  | 7:3.2.4-1~bpo8+1 | jessie-backports | source
> x265| 2.0-4~bpo8+1 | jessie-backports | source
>
> To build ffmpeg, we need chromapaint from jessie-backports. To build
> chromapaint we need a working ffmpeg from jessie-backports, but ffmpeg
> is broken due to the missing old x265.
>
> I don't see a way to resolve this without either a binary upload or some
> new bpo uploads (by eg temporarily disabling chromaprint in ffmpeg bpo).
>
> I propose:
> - Binary uploading chromaprint by manually installing the old x265
> binaries from snapshot.d.o.
> - Wait for ffmpeg to build on the buildds.
> - binNMU chromaprint
>
> Opinions? I probably won't get around to doing this until tomorrow.
>
> Thanks,
> James
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#859216: unblock: jackd2/1.9.10+20150825git1ed50c92~dfsg-5

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package jackd2

It fixes RC bug #858525.

diff --git a/debian/changelog b/debian/changelog
index 7bd384a..93111e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+jackd2 (1.9.10+20150825git1ed50c92~dfsg-5) unstable; urgency=medium
+
+  * Move libjackserver into package libjack-jackd2-0.  This avoids a
+dangling symbolic link in the package libjack-jackd2-dev.
+(Closes: #858525)
+
+ -- Reinhard Tartler <siret...@tauware.de>  Mon, 27 Mar 2017 22:44:11 -0400
+
 jackd2 (1.9.10+20150825git1ed50c92~dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 51dad7d..5547eed 100644
--- a/debian/control
+++ b/debian/control
@@ -62,7 +62,7 @@ Conflicts: jackd2 (>> ${binary:Version}),
  libjack-0.125
 Suggests: jackd2 (= ${binary:Version})
 Provides: libjack-0.116, libjack-0.125
-Replaces: libjack-0.116, libjack-0.125
+Replaces: libjack-0.116, libjack-0.125, jackd2 (<< 
1.9.10+20150825git1ed50c92~dfsg-5)
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Description: JACK Audio Connection Kit (libraries)
diff --git a/debian/jackd2.install b/debian/jackd2.install
index 9c48e99..44c00ce 100644
--- a/debian/jackd2.install
+++ b/debian/jackd2.install
@@ -1,5 +1,4 @@
 usr/bin/jack*
-usr/lib/*/libjackserver.so.*
 usr/lib/*/jack/netmanager.so
 usr/lib/*/jack/profiler.so
 usr/lib/*/jack/inprocess.so
diff --git a/debian/libjack-jackd2-0.install b/debian/libjack-jackd2-0.install
index 3d9c622..cc5e6b4 100644
--- a/debian/libjack-jackd2-0.install
+++ b/debian/libjack-jackd2-0.install
@@ -1,2 +1,3 @@
 usr/lib/*/libjack.so.*
 usr/lib/*/libjacknet.so.*
+usr/lib/*/libjackserver.so.*
diff --git a/debian/shlibs.local b/debian/shlibs.local
new file mode 100644
index 000..cffbce7
--- /dev/null
+++ b/debian/shlibs.local
@@ -0,0 +1,3 @@
+libjack 0 libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125
+libjacknet 0 libjack-jackd2-0 (>= 1.9.5~dfsg-14)
+libjackserver 0 libjack-jackd2-0 (>= 1.9.10+20150825git1ed50c92~dfsg-5)


unblock jackd2/1.9.10+20150825git1ed50c92~dfsg-5

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#858525: marked as pending

[Reinhard Tartler]

On 03/29/2017 06:20 AM, Andreas Beckmann wrote:
> On 2017-03-29 03:09, Reinhard Tartler wrote:
>> tag 858525 pending
>> thanks
>>
>> Hello,
>>
>> Bug #858525 reported by you has been fixed in the Git repository. You can
>> see the changelog below, and you can check the diff of the fix at:
>>
>> 
>> http://anonscm.debian.org/git/pkg-multimedia/jackd2.git/commit/?id=cbbda8d
> 
> That misses Breaks+Replaces for the moved library.

Thanks for the review.

The Conflicts is already in place, but the Replaces was indeed missing.
I'll add the Replaces, and avoid exposing libjackserver.so as public
library.

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#858525: libjack-jackd2-dev: Depend on jackd2

[Reinhard Tartler]

On 2017-03-28 04:04, Mattia Rizzolo wrote:

On Mon, Mar 27, 2017 at 11:22:41PM -0400, Reinhard Tartler wrote:

I think the approach of adding a 'depends' to jackd2 is the simplest.
Moving the shared library to the -dev packages doesn't work, because
/usr/bin/jackd2 and netserver.so link against it.


Why not moving the file to libjack-jackd2-0 instead?


I don't know what I was thinking, this is of course the correct 
solution.
Possibly I was confused by a dpkg-shlibdeps failure caused by me missing 
to

update the debian/libjack-jackd2-0.shlibs file.

I'll upload a fixed packages shortly. Thanks for your help!

Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#858525: libjack-jackd2-dev: Depend on jackd2

[Reinhard Tartler]

tags 858525 patch
stop

Hi,

I think the approach of adding a 'depends' to jackd2 is the simplest.
Moving the shared library to the -dev packages doesn't work, because
/usr/bin/jackd2 and netserver.so link against it.

The downside of this patch is that every package that depends on
libjack-jackd2-dev now also pulls jackd2. This might be a bit overkill
(and potentially starts a daemon). To resolve this, I think we would
need to introduce a new package (which I'd rather avoid at this point).

Let me know what you think about this.

modified   debian/control
@@ -90,7 +90,8 @@ Package: libjack-jackd2-dev
 Architecture: any
 Section: libdevel
 Multi-Arch: same
-Depends: libjack-jackd2-0 (= ${binary:Version}), 
+Depends: libjack-jackd2-0 (= ${binary:Version}),
+ jackd2 (= ${binary:Version}),
  ${asound:Depends},
  ${misc:Depends},
  ${shlibs:Depends},

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#834953: ams: Should this package be removed?

[Reinhard Tartler]

Package: ams
Severity: normal

Hi,

The package "ams" hasn't seen an upstream release since April 2014
(cf. http://alsamodular.sourceforge.net/). The last upload to debian
was on 2014-04-12.

It currently has one RC bug, and if I read popcon correctly, 46
installations: https://qa.debian.org/popcon.php?package=ams

I also checked that there are currently no reverse dependencies:

siretart@coccia:~$ dak rm -Rn ams
Will remove the following packages from unstable:

   ams |2.1.1-1 | source, amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, powerpc, ppc64el, s390x

Maintainer: Debian Multimedia Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


I would recommend removing this package. If you agree, please reassign
this bug to the "ftp.debian.org" pseudo package and retitle "RoM: dead upstream"

Thanks,
Reinhard

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Wheezy update of vlc?

[Reinhard Tartler]

On 2016-05-29 13:53, Thorsten Alteholz wrote:

Hello dear maintainer(s),

the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of vlc:
https://security-tracker.debian.org/tracker/CVE-2016-5108

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether 
you

have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

Thank you very much.

Thorsten Alteholz,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup


The following command should yield to a more or less good starting point 
for a new upload that addresses the issue mentioned in that CVE:


  git clone git://git.debian.org/pkg-multimedia/vlc
  git checkout wheezy
  git checkout master -- 
debian/patches/adpcm-reject-invalid-QuickTime-IMA-files.patch
  echo  adpcm-reject-invalid-QuickTime-IMA-files.patch >> 
debian/patches/series

  dch -i

I glanced over https://wiki.debian.org/LTS/Development, but that 
procedure seems pretty involved. I'd appreciate if someone else could 
take over the necessary bureaucracy. Note that I did not test the patch 
myself because I was unable to find accurate documentation about what 
the issue is, or what test sample can be used to verify the presence or 
absence of the bug.


Also note that 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5108 doesn't 
provide and useful information about this issue. Is that issue also 
known by a different identifier?


Cheers,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#794817: Should mplayer2 be removed from unstable?

[Reinhard Tartler]

On Thu, Aug 6, 2015 at 9:21 PM Sebastian Ramacher sramac...@debian.org
wrote:

 On 2015-08-06 23:05:58, Andreas Cadhalpun wrote:
  Package: mplayer2
  Severity: serious
 
  I think mplayer2 should be removed because:
   * It is dead upstream (even the homepage is gone).
   * mplayer is back in Debian, which can replace mplayer2.

 … and one copy of mplayer is surely enough. Alessio, Jonas, Reinhard: What
 is
 your opinion on that?


I don't think we have the resources (mostly manpower) to maintain mplayer2
without an active upstream. I'm therefore OK with removing it from
unstable. If the maintenance situation changes, we can always reconsider.

Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#794578: mplayer2: undefined symbol in libavcodec-ffmpeg

[Reinhard Tartler]

It appears that you have a local copy of libmp3lame in /usr/local/lib,
which is most likely the culprit. Please remove that local copy and try
again. Does the problem persist?

Best,
Reinhard

On Tue, Aug 4, 2015, 2:54 PM Alex Bernier alex.bern...@free.fr wrote:

 On Tue, Aug 04, 2015 at 06:49:14PM +0200, Sebastian Ramacher wrote:
  Control: tags -1 + moreinfo
 
  On 2015-08-04 17:31:25, Alex Bernier wrote:
   Package: mplayer2
   Version: 2.0-728-g2c378c7-4+b2
   Severity: important
  
   Dear Maintainer,
  
   *** Reporter, please consider answering these questions, where
 appropriate ***
  
  * What led up to the situation?
  
   Running mplayer fails with the following error message :
  
 mplayer: symbol lookup error:
 /usr/lib/x86_64-linux-gnu/libavcodec-ffmpeg.so.56: undefined symbol:
 lame_set_VBR_quality
 
  Please run ldd -r /usr/lib/x86_64-linux-gnu/libavcodec-ffmpeg.so.56 and
 attach
  the output. What version of libmp3lame0 do you have installed?

 With the attachment...

 Alex Bernier
 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org

 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#793085: ffmpeg: removal of ffmpeg makes files disappear from libav-tools

[Reinhard Tartler]

 On Tue, Jul 21, 2015, 4:51 AM Andreas Beckmann a...@debian.org wrote:

Package: ffmpeg
Version: 7:2.7.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts replaces-without-breaks
Control: affects -1 + libav-tools

Hi,

during a test with piuparts and DOSE tools I noticed your package causes
removal of files that also belong to another package.
This is caused by using Replaces without corresponding Breaks.

The installation sequence to reproduce this problem is

  apt-get install libav-tools
  # (1)
  apt-get install ffmpeg
  apt-get remove ffmpeg
  # (2)

The list of installed files at points (1) and (2) should be identical,
but the following files have disappeared:

  usr/bin/qt-faststart
  usr/share/man/man1/qt-faststart.1.gz

This is a serious bug violating policy 7.6, see
https
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
://
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
www.debian.org
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
/doc/
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
debian-policy
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces/
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
ch-relationships.html#s-replaces
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
and also see the footnote that describes this incorrect behavior
https https://www.debian.org/doc/debian-policy/footnotes.html#f53://
https://www.debian.org/doc/debian-policy/footnotes.html#f53www.debian.org
https://www.debian.org/doc/debian-policy/footnotes.html#f53/doc/
https://www.debian.org/doc/debian-policy/footnotes.html#f53debian-policy
https://www.debian.org/doc/debian-policy/footnotes.html#f53/
https://www.debian.org/doc/debian-policy/footnotes.html#f53
footnotes.html#f53
https://www.debian.org/doc/debian-policy/footnotes.html#f53

The ffmpeg package has the following relationships with libav-tools:

  Conflicts: n/a
  Breaks:libav-tools ( 6:9~), qt-faststart ( 7:2.7.1-3~)
  Replaces:  libav-tools ( 6:12~), qt-faststart ( 7:2.7.1-3~)

The Breaks was not bumped to match the Replaces.

From the attached log (scroll to the bottom...):

1m28.2s ERROR: FAIL: After purging files have disappeared:
  /usr/bin/qt-faststart  owned by: ffmpeg
  /usr/share/man/man1/qt-faststart.1.gz  owned by: ffmpeg

1m28.2s ERROR: FAIL: After purging files have been modified:
  /var/lib/dpkg/info/libav-tools.listnot owned




Well, that was actually the purpose, the idea is to replace qt-faststart
from libav-tools, and the problem is rather transitional until libav-tools
is uninstalled. I guess the bug is that we don't ensure that this actually
takes place. I've therefore made two commits in git:

- one that tightens the Breaks relationship as suggested
- one that renames libav-tools-links to libav-tools in src:ffmpeg.

This should ensure a comprehensive transition.

Feedback on these two commits are welcome. In particular, I saw a comment
suggesting to transition command-line interface separately from the library
interfaces. While this may make the transition slightly smaller, the
benefits don't outweigh the confusion here, and would rather suggest to
transition them both at the same time with the 2nd commit mentioned above.

Best,
Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Uploading ffmpeg 2.7.2-1

[Reinhard Tartler]

did you already coordinate this transition with the release team? What is
the transition tracking bug?

We must not start a transition of this size without coordination, in
particular given that we are aware of a couple of FTBFS. This all needs the
be documented first before we can proceed with uploads to unstable.

Balint, please don't upload this to unstable, experimental would be fine
though.

Best,
Reinhard

On Mon, Jul 20, 2015, 4:36 AM Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 Hi Bálint and Reinhard,

 I merged the experimental branch into the master branch and imported
 FFmpeg 2.7.2.
 It would be great if one of you would upload this for the transition.

 Best regards,
 Andreas

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Uploading ffmpeg 2.7.2-1

[Reinhard Tartler]

On Mon, Jul 20, 2015 at 7:59 AM Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 Hi,

 On 20.07.2015 13:48, Reinhard Tartler wrote:
  did you already coordinate this transition with the release team?

 Yes.

  What is the transition tracking bug?

 #792619 [1], see also the transition tracker [2].

  We must not start a transition of this size without coordination, in
  particular given that we are aware of a couple of FTBFS. This all needs
  the be documented first before we can proceed with uploads to unstable.
 
  Balint, please don't upload this to unstable, experimental would be fine
 though.

 Jonathan Wiltshire from the release team asked me to go ahead [3],
 so an upload to unstable is correct.


Thanks, I missed that email. I've just built and uploaded the package to
unstable.

Thanks for your work on it!

Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libav and FFmpeg: switch over

[Reinhard Tartler]

Keeping the libavcodec-extra packages makes very much sense to me, thank
you.

Do you need help with uploading to experiemental? As soon as it is in
experimental, we can start with filing bugs tracking FTBFS issues in
application packages. As usual, I'd suggest tracking them with usertags, so
that you can point to a dynamic list of todo items in the transition bug.
The release team is likely to insist that only if all bugs for packages
that are in testing have been addressed before allowing to upload to
unstable.

Regarding src:libav, I see little point in keeping it, so yes, let's just
request its removal when nothing depends on it anymore.



Reinhard


On Thu, Jul 9, 2015, 7:34 PM Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

Hi,

On 08.07.2015 10:39, Alessio Treglia wrote:
 After a careful review of all the pros and cons we, the Debian
 Multimedia Maintainers team, have finally decided to switch from Libav
 to FFmpeg as provider for the libav* multimedia libraries. We'll try
 our best to make this happen in time for stretch.

The next step is uploading the ffmpeg package taking over the lib*-dev
packages to experimental.
I've decided to keep the libavcodec-extra package instead of making it
transitional, as it might be useful for people wanting to always have
the latest version of the extra variant installed. Without that, one
would have to install the libavcodec-extraNN package after every
soname change. I've updated the experimental branch in the ffmpeg
repository accordingly.

I'd like to go forward with that, or did you have more comments,
Reinhard?

The next question is, what to do with the src:libav package.
Reinhard, did I understand you correctly that you think it would be
best to not rename its lib*-dev packages and just remove it after
the transition?
Otherwise an upload with the renamed lib*-libav-dev packages should
be made to experimental, as well.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#790918: libav-tools: bitrate 448 is not allowed in mp2 / convert to pal dvd with mp2 audio

[Reinhard Tartler]

The patch in the referenced ticket should only have any effect if you used
the (deprecated) argument -ab, which the command line in your original
report does not use. To be honest, I cannot see how the patch can possibly
fix the command invocation that you show.

Are you absolutely sure that the patch fixes the issue that you are seeing?
Have you tested it by recompiling src:libav with the patch?

Best,
Reinhard

On Thu, Jul 2, 2015, 9:00 PM Richard Gomes rgomes.i...@gmail.com wrote:


The command I tried was

avconv -loop 1 -f image2 -i
/home/rgomes/Videos/BBC4/dvd_1/movie/menu/menu_0_bg.png -i
/usr/local/share/devede_ng/silence.ogg -y -target pal-dvd -acodec mp2 -s
720x576 -g 12 -b:v 2500k -b:a 224k -aspect 4:3 -t 31
/home/rgomes/Videos/BBC4/dvd_1/movie/menu/menu_0.mpg

 which is produced by an application called DeVeDe NG.
https://github.com/rastersoft/devedeng

The command fails as described in the ticket
https https://trac.ffmpeg.org/ticket/3736://
https://trac.ffmpeg.org/ticket/3736trac.ffmpeg.org
https://trac.ffmpeg.org/ticket/3736/ticket/3736
https://trac.ffmpeg.org/ticket/3736
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Thu, Jun 18, 2015, 7:15 PM Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

Hi,

On 18.06.2015 18:57, Bálint Réczey wrote:
 2015-06-09 21:53 GMT+02:00 Andreas Cadhalpun 
andreas.cadhal...@googlemail.com:
 I have now implemented this and it works fine.
 It's in the extra branch of the ffmpeg git repository [1].
 I have tested the branch and it works nicely for me.

Thanks for testing it. :)

 Is there any other open issue?

The altivec optimizations on powerpc are still disabled, but I don't think
this should delay the transition. I intend to fix this one way or another
before stretch is released anyway.


It seems that you have now reimplemented the flavors logic in the ffmpeg
package. Nice.

The only thing that I spotted so far is the issue with libavcodec-extra.


I've put my transition plan on the wiki [1].

1:
https://wiki.debian.org/Debate/libav-provider/ffmpeg#How_Debian_should_switch_to_FFmpeg


I'm not sure if I understand that wiki correctly, but it seems to be that
you plan on keep on using the package names libavXXX-ffmpegNN. That seems
unnecessary to me, why wouldn't you want to co stright to libavXXXNN?

I guess the reason is because that matches the actual soname, that is,
libavcodec is currently installed with the SONAME libavcodec-ffmpeg.so.
This is to ensure co-installability with libav, but do we really need to
keep this? I think everyone is rather in favor of not having to have both
around.

Unless there is a good reason (such as making the transition significantly
easier, I'd rather avoid those names.

Best,
Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Jun 18, 2015 7:15 PM, Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 Hi,

 On 18.06.2015 18:57, Bálint Réczey wrote:
  2015-06-09 21:53 GMT+02:00 Andreas Cadhalpun 
andreas.cadhal...@googlemail.com:
  I have now implemented this and it works fine.
  It's in the extra branch of the ffmpeg git repository [1].
  I have tested the branch and it works nicely for me.

 Thanks for testing it. :)

  Is there any other open issue?

 The altivec optimizations on powerpc are still disabled, but I don't think
 this should delay the transition. I intend to fix this one way or another
 before stretch is released anyway.

That is something that the libav package handles just fine. May I ask how
you intend to address the altivec issue?

The new packaging for sure builds faster, but is build time really a
problem?

 And currently FFmpeg 2.7 failed to build on ppc64 (due to changes in
configure,
 fixed upstream) and sparc (unaligned access causing SIGBUS, problem has
been
 there for ages, but the test coverage increased recently, patch sent
upstream).
 I expect FFmpeg 2.7.1 will fix those, so once that is in unstable, it
would
 be a good time to upload the package for the transition to experimental.

I'm not sure if we had consensus on what packaging should be used.

  I would happily sponsor an upload to
  experimental with the new -extra package possibly with also providing
  libav-dev and friends to if libav maintainers agree and we decide to
  start the transition.
  Any thoughts?

In the new packaging, libavcodec-extra is a virtual package, while the
jessie shipped with a real package. How will that play with backports, that
is, is there any chance that apt would prefer the libavcodec-extra package
that drags in the old packages over the libavcodec-extra-NN package, which
provides libavcodec-extra?

Best,
Reinhard

Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Audacity 2.0.6-2 several GUI problems due to wxWidgets 3.x

[Reinhard Tartler]

On Thu, Jun 11, 2015 at 12:47 PM Peter P. peterpar...@fastmail.com wrote:

 Hi,

 thanks for maintaining and developing the audacity package!

 I am on Debian/testing and just upgraded to audacity version 2.0.6
 using apt. I just noticed two new problems:

 1.)
 The 'device bar' is suddenly empty, regardless of used audio backend
 (alsa/jack) it only shows the loudspeaker and microphone images, but no
 drop-down menu of audio driver system and available record and playback
 devices. The audio devices are recognized correctly in the
 Preferences/Devices, it is merely the 'device bar' toolbar that is
 empty.

 2.)
 When opening files from the command line, eg
 audacity somefile.wav
 the zoom level is not adjusted to fit project right after opening the
 file, but a very long timeline from -24hours to more than 216hours is
 displayed (and the imported waveform being literally invisible) and the
 user has to click Fit Project in order to see the waveform.
 This does not occur when opening files from the open dialog in the
 file menu.
 There are no extra messags posted on the command line when the error
 occurs.

 Both errors might be due to audacity being compiled against wxWidgets 3.x
 ttp://wiki.audacityteam.org/wiki/Incorrect_wxWidgets_Version
 It seems the audacity team is still trying to catch up with 3.x which in
 itself might be in a flux. So although audacity compiles against 3.x it
 is not really useable for end-users such as me. I have reported this to
 the audacity devels as well, but for now it seems to be of more help to
 debian users to stick to compiling the package against the older version
 of wxWidgets I think.

 The oldstable package of version 2.0.1-1 therefore works well.

 How can I further help here?


This has already been reported as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781866. Unfortunately,
the situation seems rather complicated.

The problem at hand is that in Debian, the wxwidgets maintainers are in the
process of phasing out wxwidgets 2.8. Please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749659 for the activity
that lead Debian compiling against wxwidgets 3.0. Also, please not that
wxwidgets is not included in jessie at all, see
https://wiki.debian.org/Teams/WxWidgets/Transition2.8to3.0, and it is also
scheduled to be removed from unstable.

This means that going back to wxwidgets 2.8 is not an option.   I'm
therefore closing #781866 with this email. Still, it seems that audacity
provides a poor user experience with wxwidgets 3.0, and judging from
http://wiki.audacityteam.org/wiki/Incorrect_wxWidgets_Version, there is
still a lot of work to do here. I would recommend to direct feedback,
comments, and ideally patches, to the audacity developers.

Sorry.

Best,
Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Sat, Jun 6, 2015 at 3:05 PM, Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:
 Hi Reinhard,

 On 06.06.2015 20:30, Reinhard Tartler wrote:
 On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey bal...@balintreczey.hu
wrote:
 The problem is that Debian users must be allowed to redistribute it,
 but as far as I understand it, it is not allowed to distribute e.g.
 a live DVD with hedgewars and libavcodec-extra installed.
 I also pointed this out in the previous discussion [1].
 I'm not absolutely sure, but IMO yes, such Live DVD-s would not be
 allowed, but it is a problem of live DVD makers to care about. Package
 maintainers can't and should not prevent this usage.

 Why would you think that distributing the packages libavcodec-extra
 and hedgewars on the same Live media would create a derived work that
 must fulfill all licenses?

 I fail to spot the problem here.

 The problem I see is run-time linking a GPLv2-only program with a GPLv3+
 library. I think this makes such a Live DVD undistributable, because the
 licenses are not compatible.

The problem is that neither of the involved licenses talk about run-time
nor compile-time linking. The point is the creation of a derived work.

You are right that in this situation, it is not clear at all of the live cd
is a derived work, or a compilation of independent works. The former would
be rather problematic, but my understanding is that a live cd is rather the
latter.


 If you want to be extra careful, just install the regular GPLv2+
 libavcodec package, which according to the dependencies of the
 hedgewars package should work just fine.

 This wouldn't work if you also want to install devede, which depends
 on libavcodec-extra. (This dependency should probably be a recommends
 at most, anyway.)

I tend to agree.



 I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible
 with the packages since I have no packages requiring it nor use-cases
 as a user requiring it, but I prefer the choice provided by by current
 libav packaging.

 Thanks for the support!

 Would it be hard to patch the build system?

 To do what exactly?

 To implement this in a dh7-style debian/rules file.

I do appreciate the dh7-style brevity for simple packages. But for complex
packages, such as libav that makes use of multiple compilation passes, I
found the provided abstractions that make it so attractive to use get
quickly in the way.


  The current libav packaging already implements
 this in a way that the user can choose what packages to install.

 On a personal note: The libav packaging can surely be improved and
 simplified. But throwing away years of work just because, and knowing
 about the regressions for the sake of simplicity feels wrong.

 The main modernization would be a rewrite of the debian/rules file
 in dh7-style. This naturally replaces the previous one.
 The rest of the packaging is mainly declarative and can't be varied
 that much anyway.

 Not having the libavcodec-extra flavor is not only a regression
 (having no AMR encoder), but also an improvement (simpler debian/rules,
 no license incompatibility to worry about, faster build, ...).
 I happen to think the improvement factor is bigger than the regression
 factor, but others may disagree.


As Fabian points out, it is not only AMR, but (currently) also libvo-aacenc.


 --
regards,
Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Sat, Jun 6, 2015 at 1:51 PM, Bálint Réczey bal...@balintreczey.hu wrote:
 The problem is that Debian users must be allowed to redistribute it,
 but as far as I understand it, it is not allowed to distribute e.g.
 a live DVD with hedgewars and libavcodec-extra installed.
 I also pointed this out in the previous discussion [1].
 I'm not absolutely sure, but IMO yes, such Live DVD-s would not be
 allowed, but it is a problem of live DVD makers to care about. Package
 maintainers can't and should not prevent this usage.

Why would you think that distributing the packages libavcodec-extra
and hedgewars on the same Live media would create a derived work that
must fulfill all licenses?

I fail to spot the problem here.

If you want to be extra careful, just install the regular GPLv2+
libavcodec package, which according to the dependencies of the
hedgewars package should work just fine.

 Since the hassle makes more work for active ffmpeg maintainers and
 while I sponsored a few uploads I don't consider myself one I should
 not make the call, but it would be really nice to provide the AMR
 encoder as well in Debian and also keeping hedgewars in the archive.

 Maybe there is a way of providing libavcodec-extra and having modern
 packaging scripts. Maybe patching the build could help, but I have not
 checked this idea.

 The AMR encoder is anyway just a wrapper around libopencore/libvo.
 Gstreamer also has similar wrappers and since they are plugins, the
 license is less of a problem.
 Thus anyone really wanting to encode AMR can use gstreamer.

Except those that want or need to use the avconv or ffmpeg
command-line utilities.

 I'm OK with disabling AMR encoder in ffmpeg and stay GPLv2 compatible
 with the packages since I have no packages requiring it nor use-cases
 as a user requiring it, but I prefer the choice provided by by current
 libav packaging.

Thanks for the support!

 Would it be hard to patch the build system?

To do what exactly? The current libav packaging already implements
this in a way that the user can choose what packages to install.

On a personal note: The libav packaging can surely be improved and
simplified. But throwing away years of work just because, and knowing
about the regressions for the sake of simplicity feels wrong.

Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

[short answer, I'm on the run]

On Thu, Jun 4, 2015 at 6:28 PM, Andreas Cadhalpun
andreas.cadhal...@googlemail.com wrote:

 I had considered producing optimized flavors, but I came to the conclusion
 that it would complicate debian/rules without much benefit, because
 the flavors are mostly unnecessary:

 That's not only because of optimization, but also for licensing
 issues: The lib*-extra-* packages are licensed with GPLv3+, which is
 not acceptable for the majority of applications in debian.

 Note that it does not matter whether or not there are GPLv3+
 applications in the archive. These -extra- package do provide
 additional functionality that users do appreciate. However, we cannot
 provide that in the standard libav* packages because we do have
 GPLv2-only applications that we must not link against a GPLv3
 libavcodec.

 The current implementation of the extra flavor doesn't prevent using it
 with a GPLv2-only program and thus is effectively nearly as bad as just
 enabling the GPLv3 code in the standard build.

The keyword in this sentence is using. I do NOT think we need to
prevent users from doing stupid things, but we must ensure that Debian
as a (re-)distributor does not violate any licenses. The dependencies
are set up in a way that ensures that all packages build against the
GPLv2+ variants, and nowhere on the buildds or on any other Debian
machine we distribute a piece of software that would be in violation
here. And that was the point of this exercise.

 Adding a mechanism to prevent this would make the extra flavor even
 more complex.

I don't think this is necessary. I doubt that many users would find
such a check actually helpful.

 As you can see from above numbers, even in the uttermost worst case,
 that is if both Michael and the Libav developers stopped working on
 the codebase, FFmpeg would still have more commits than Libav
 currently does.

Comparing an individual developer with a development team seems
inappropriate to me. Also, the chosen development processes of both
projects significantly affect the rate of commits. That comparison
does not appear useful.

Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Sun, May 31, 2015 at 7:21 AM, Andreas Cadhalpun
andreas.cadhal...@googlemail.com wrote:

 and would rather propose to just rename the current libav source
 package to ffmpeg and package the latest ffmpeg source tarball.

 Then that ffmpeg source package would take over the binary package
 names as well. If you think it's not necessary to preserve the
 development packages from src:libav, my proposal becomes even simpler:
 Just rename lib*-ffmeg-dev to lib*-dev in the current ffmpeg source
 package. That'd work, because src:ffmpeg has a higher epoch.

That's not what I'm proposing.


 I'd rather keep the packaging of the package that is currently called
 libav, because on many architectures, it compiles multiple flavors
 with hardware optimized flavors (on i386 for instance, there is a
 flavor without latest SEE, etc).

 I had considered producing optimized flavors, but I came to the conclusion
 that it would complicate debian/rules without much benefit, because
 the flavors are mostly unnecessary:

That's not only because of optimization, but also for licensing
issues: The lib*-extra-* packages are licensed with GPLv3+, which is
not acceptable for the majority of applications in debian.

Note that it does not matter whether or not there are GPLv3+
applications in the archive. These -extra- package do provide
additional functionality that users do appreciate. However, we cannot
provide that in the standard libav* packages because we do have
GPLv2-only applications that we must not link against a GPLv3
libavcodec.

  * On i386 all the SSE etc. optimizations are guarded by runtime
CPU detection, so that even when compiled with SSE the libraries work
fine on CPUs without SSE.
The only optimization were this doesn't apply are the i686 optimizations,
which currently amount to a dozen assembler lines. So I don't think
this justifies shipping two flavors.

Have a look at #688384 - the conclusion was to compile for i586, which
seems absurd to me for most users, even if most optimizations are
indeed the runtime selected hand-written assembler parts. The libav
packaging solves this with multiple compilation passes.

  * The situation for arm*, where the neon/vfp optimizations are runtime
guarded, is similar.

I don't think so, have a look at #657885, which shows a SIGILL in
cmdutils.c. This can hardly be caught at runtime.

  * Sparc is on it's way out, possibly going to be replaced by sparc64.
So building a sparc64 flavor on sparc isn't really useful.
  * This leaves powerpc, where configure would enable '-maltivec'
together with the hand-written altivec optimizations, which are guarded
by runtime CPU detection. This causes gcc to add some altivec
instructions, which are not guarded and thus cause SIGILL.
Looking into fixing this in the configure script is on my TODO list.

It is impossible to fix (or rather not worth the effort to fix
properly). Either you disable altivec completely, or you need need to
pass -maltivec which allows you to use the altivec optimizations and
break on non-altivec machines. So you either make all multimedia
package unusably slow for altivec machines because altivec is not
enabled, or you exclude all uses of non-altivec machines.

 Are there good reasons to produce these optimized flavors?

Yes, there are, at least on i386, arm and powerpc. I would consider
not having them a serious regression.

 Andreas, would that approach be acceptable to you?

 I'd rather continue with the packaging of the current ffmpeg source
 package, because the one from src:libav uses a pre-dh7 debian/rules,
 and a quite complicated one at that.

I'm happy to simplify or refactor the packaging, but I fear I have to
insist to continue using the current src:libav packaging.

It also seems easier to conduct the resulting transition if the
package names of what application packages depend on don't change.
Please let's not overcomplicate these things.


 If so, then I'd propose to get a test package ready in Git, and I'd
 then do a mass-rebuild on my amd64 box to see how many packages fail
 to build.

 I already did a mass-rebuild for my proposal and the results can be
 found in my mail [1] mentioned above.
 The blender and paraview FTBFS bugs have been resolved and the new mpd
 version is now in sid, so unless new, unrelated FTBFS bugs were
 introduced, only 7 packages would fail to build.
 Three of those FTBFS already (dvswitch has a patch in #747868,
 gstreamer0.10-ffmpeg should be removed and jitsi is fixed in NEW
 since 8 months).
 Two (gpac and xbmc) would require changes for the next Libav version
 as well, because they use private API, which was changed.
 The hardcoded sonames in taoframework have to be updated, like in every
 Libav transition. (Maybe someone can fix taoframework to use the sonames
 present in the build environment?)
 So only gst-libav1.0 needs a FFmpeg specific change, which is an additional
 build-dependency on libavresample-dev, because it 

Re: multiple uploaders

[Reinhard Tartler]

On Jun 1, 2015 7:11 AM, Felipe Sateler fsate...@debian.org wrote:

 On 31 May 2015 at 19:36, Reinhard Tartler siret...@gmail.com wrote:
  IMO, if there is no need for team commitment, then there is no need
  for the package to be under team maintenance in the first place. In
  this case, it really doesn't matter if the package has a dedicated
  maintainer or a team with a single uploader in the field.

 I disagree. There is a large range of options between
 fully active on package maintenance and don't even look at the
 package.

 As Fabian says, we do comment on each others bugs from time to time
 even if we are not formally tied to each package. I have received
 useful feedback on plenty of bugs. I have tried to provide same when
 possible and time permits. When I have more time, I look at the
 commits list and see if something could be improved, even if I have
 nothing to do with the package. I have even investigated bugs on
 packages that I am not an Uploader in.

 I would certainly do no such thing for packages not in the team
 umbrella, because:

 1. I already have enough lists to subscribe to yet another one
 2. By being a member of the team, there is an implicit ack to the idea
 of receiving unsolicited feedback from others, which is not the case
 otherwise.

 Last, but not least, having the package in the team makes it easier to
 solicit feedback (even if it does not come as readily as one would
 hope sometimes).

 I conclude the barriers to cross-contributions are greatly reduced by
 just having related packages in a single team.

Thank you and Fabian for detailing your positions so clearly.

Apparently has already grown quite big, and the addition of a package to
the the team has become only a small increment in the demand of team
resources. I count Fabian's suggestion to categorize our team packages as
indication for that.

Felipe, generalizing your line of argumentation, we should put all packages
in Debian in a single team, and have all bugs go to a common mailing list
that everyone reads. I believe there even is a mailing list for that. This
clearly doesn't scale, but what is a reasonable limit? I have the
impression that we are already way past that limit, and we have entered a
mode of operation that the Debian QA team does for orphaned packages.

I don't think I have any new input to add to this discussion. The majority
of participants seem to think that the two uploaders rule is not useful
as it hinders the adoption of new packages. While, I found this a desirable
property, I also realize that the majority disagrees.

In the end, dropping the rule probably won't make much of a difference
anyways, because it is hardly enforced. So I'm okay with dropping it as an
act to align rules with reality.

Thanks to everyone who provided input on this topic!

Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: multiple uploaders

[Reinhard Tartler]

On Jun 1, 2015 1:35 AM, Fabian Greffrath fab...@debian.org wrote:
 And by the current rule, would libav still qualify as being
 pkg-multimedia team-maintained?

I would say yes: Most recently, Sebastian has not only provided commits,
but even uploaded several packages to both unstable and stable-security. So
to me, libav qualifies both by the two-uploaders rule as well as my gut
impression of the level of contributions from multiple people.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: multiple uploaders

[Reinhard Tartler]

Hi Ross,

On Sun, May 31, 2015 at 1:32 PM, Ross Gammon r...@the-gammons.net wrote:
 On 05/31/2015 02:58 PM, Reinhard Tartler wrote:
 Well, it really boils down what we want the team's reputation to be.
 The rule tests whether or not there is *team* commitment, and for that
 you need *more than one person* actively caring for a package. If a
 package fails the two active uploaders test, how can you argue that
 the package was team maintained?

 Hi Reinhard,

 I agree in principle. But for me, having two uploaders does not test if
 there is team commitment.

I see two ways how to interpret this sentiment:

 a) the check is not strict enough, and misses many too many
situations were the package needs help
 b) the check is too strict, and catches too many actively team
maintained packages that do have commitment.

Reading through the comments so far, I don't think you had a) in mind,
but rather b). Please correct me if I'm wrong.

 It just makes sure that there is more than one
 person taking care of the package.

Which is the point of team maintenance, isn't it?

 And this is probably more important
 for the high profile packages than for some of the more obscure ones. I
 think it also helps prevent a new team member getting something
 sponsored into the team, and then running away.

 If someone suggests a new package is brought into the team, and it is
 accepted, then the team is making a commitment at that point.

How can you determine team commitment if only a single person is
working on the package? How is this better than having the package not
team maintained?

 When a package gets behind, it is usually because the uploader(s) is/are
 a bit busy. The team should notice this on the QA page/dashboard and
 ping the uploader(s) on the list to see what the problem is.

 If they are temporarily busy, maybe they would be happy with a Team
 Upload by someone else?

How is that different to a NMU?

 This is not meant to be a rant, it is just how I have observed some of
 the other packaging teams operating in Debian.

I think Debian already has way too many QA Teams. I'd rather see
packaging teams that are responsive and don't just use the team as an
easy way to divert responsibility.

 Can I suggest that for new packages:
 1. the one intending to ITP asks if the team are happy to bring in the
 new package
 2. there is an attempt to find someone else to also love the package?

It seems to me that the current rule already implements exactly that.
Can you elaborate how this would look like in practice, and how your
suggestions is different?

 I would be happy to try and draft a tweak to the policy if there was
 consensus (including some guidelines).

Maybe we could first clarify why the current rule was useless. Is it
that too many packages violate that rule? This can be fixed with two
means: relaxing the rule, or enforcing it. It appears to me that
people might argue that it is not strict enough, but I'd suggest that
we first focus on enforcing the rules.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: multiple uploaders

[Reinhard Tartler]

On Sun, May 31, 2015 at 2:34 PM, Ross Gammon r...@the-gammons.net wrote:

 If someone suggests a new package is brought into the team, and it is
 accepted, then the team is making a commitment at that point.

 How can you determine team commitment if only a single person is
 working on the package? How is this better than having the package not
 team maintained?

 I would say that if only one person has been uploading a package over a
 period of years and doing a good job, there is no need for team
 commitment because everything is fine. The team commitment comes if that
 person needs help at some point (technically or due to lack of time).

Thanks for clarifying your position, this is where I clearly disagree.
IMO, if there is no need for team commitment, then there is no need
for the package to be under team maintenance in the first place. In
this case, it really doesn't matter if the package has a dedicated
maintainer or a team with a single uploader in the field.

What does matter (at least to me) is the reputation of the team: A
team that groups a large amount of packages that are maintained by
individuals seems less than ideal. I'd like to see pkg-multimedia as a
team of people that collaborate, proactively help out, and learn from
each other. IME this only works if people actually look at each others
work, which in our case means subscribing to the commit mailing list
and actually looking at the commits.

However, pkg-multimedia has already have grown too big for that,
meaning, it is impossible to follow all of the teams work. Therefore,
we need to compromise. But I'd still love to think that pkg-multimedia
is still a responsive and reliable team that works together!

 When a package gets behind, it is usually because the uploader(s) is/are
 a bit busy. The team should notice this on the QA page/dashboard and
 ping the uploader(s) on the list to see what the problem is.

 If they are temporarily busy, maybe they would be happy with a Team
 Upload by someone else?

 How is that different to a NMU?

 Only the changelog entry is different, and there is a series of commits
 in the repo instead of a diff attached to a bug.

Oh, I think I see what you are saying: Pushing commits to a git
repository is easier than sending it to a bugreport? Hm, I think I can
follow that line of thought somehow:

Basically, the argument is that having an orphaned package that is
team maintained is easier to work on than a package that has a
dedicated maintainer because of the rules that the Debian Policy
applies to NMUs: You have to file a bug with a patch, figure out with
what delay to upload, etc. If that's the point, then this workaround
feels to me like admitting defeat to the Debian NMU rules.

 I think Debian already has way too many QA Teams. I'd rather see
 packaging teams that are responsive and don't just use the team as an
 easy way to divert responsibility.

 Agreed. But I haven't seen examples of that (diversion of
 responsibility) yet myself.

Oh, I think this can be seen all the time with packages that have a
team in the maintainer field, but nobody feels responsible for it.


 Can I suggest that for new packages:
 1. the one intending to ITP asks if the team are happy to bring in the
 new package
 2. there is an attempt to find someone else to also love the package?

 It seems to me that the current rule already implements exactly that.
 Can you elaborate how this would look like in practice, and how your
 suggestions is different?

 I think we are mixing 1  2 up, and they should be separate steps. That
 is, if the team accepts a new package is is best if there is more than
 one uploader, but not mandatory.

Uh? Are you suggesting to send two emails instead of one? Please
clarify, I'm having a hard time with understanding your suggestion
here.

 I would be happy to try and draft a tweak to the policy if there was
 consensus (including some guidelines).

 Maybe we could first clarify why the current rule was useless. Is it
 that too many packages violate that rule? This can be fixed with two
 means: relaxing the rule, or enforcing it. It appears to me that
 people might argue that it is not strict enough, but I'd suggest that
 we first focus on enforcing the rules.


 I don't think anyone thinks it is useless.

Uhm: 
http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/044558.html

 Everyone is probably happy
 to abide by it if required. I only felt the need to write something
 because I have observed IOhannes, Jaromir and Ruben have trouble
 introducing new packages recently because no-one quickly jumped in to be
 a second uploader. IOhannes stated in his recent ITP that he would push
 it to collab-maint if no-one came forward. This is a little sad if it is
 an obvious mutimedia application.

If IOhannes is the only one working on the package, then collab-maint
seems to me the better place to be honest.

 I know IOhannes would take good care
 of the package wherever it is. And I 

Re: multiple uploaders

[Reinhard Tartler]

On Tue, May 26, 2015 at 8:49 AM, Felipe Sateler fsate...@debian.org wrote:
 On 26 May 2015 at 09:38, Sebastian Ramacher sramac...@debian.org wrote:

 On 2015-05-26 14:33:41, IOhannes m zmölnig (Debian/GNU) wrote:
  hmm, nobody ever answered to this email.
 
  mira's recent mail regarding a 2nd uploader of qxgedit reminded me of
  that, and i would like to re-ask:
 
  How much do we want to enforce our =2 uploaders per package rule?
 
  If a package does not have a 2nd uploader (any longer), should it be
  removed from the team (e.g. after some grace period)?

 I think the rule is useless. It doesn't prevent us from having two persons on
 Uploaders and both are MIA.

 I have been thinking we should ditch the rule as well. I think having
 a common home (even if a single maintainers is currently active)
 should make it easier for third-parties interested in multimedia to
 collaborate, and that may as well mean co-maintaining previously
 singly-maintained packages. Plus, many packages do not require much
 activity anyway.

Well, it really boils down what we want the team's reputation to be.
The rule tests whether or not there is *team* commitment, and for that
you need *more than one person* actively caring for a package. If a
package fails the two active uploaders test, how can you argue that
the package was team maintained?

If the majority of the packages in team pkg-multimedia are effectively
taken care of by a single person, how is that package simply not team
maintained at all? I'd argue it is worse, because missing maintainers
and defacto orphaned packages are harder to identify. If this is to
become the norm, I'd argue to rather put the Debian QA Team as
maintainer of the package.

Do we really want team pkg-multimedia to become another Debian QA
Team with focus on multimedia packages? I would find that rather sad
and for sure would love pkg-multimedia to have, and maintain, a better
reputation than that.

 I'd rather orphan/remove the packages from the
 team that are clearly no longer maintained and nobody in the team cares about
 them anymore.

 Any idea how to determine clearly no longer maintained? I think the
 2-maintainers rule was intended to provide a way to demarcate that
 line, but it didn't fulfill its promise.

Because the rule isn't enforced properly.  I'd rather argue to take
the Maintainer field more seriously, that is, for packages that are
taken care of by a single person to have that person in that field, or
if such a person cannot be found, orphan the package properly.


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Fri, May 29, 2015 at 9:16 AM, Bálint Réczey bal...@balintreczey.hu wrote:
 Hi Dmitry,

 2015-05-29 12:22 GMT+02:00 Dmitry Smirnov only...@debian.org:
 Thanks for insight into upstream security situation, Balint.

 So what would be the next step? Mass bug filings? Shall we draft a template
 here?
 Andeas already proposed a transition plan [1] and already submitted
 several bugs.
 If we decide to switch to ffmpeg, I think this is the best proposal so far.

 [1] 
 http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-May/043980.html

That mail proposes to make changes to the libav source package so
that the ffmpeg source package can take over binary package names
currently produced by libav. That seems overly complicated to me,
and would rather propose to just rename the current libav source
package to ffmpeg and package the latest ffmpeg source tarball.

I'd rather keep the packaging of the package that is currently called
libav, because on many architectures, it compiles multiple flavors
with hardware optimized flavors (on i386 for instance, there is a
flavor without latest SEE, etc).

Andreas, would that approach be acceptable to you?

If so, then I'd propose to get a test package ready in Git, and I'd
then do a mass-rebuild on my amd64 box to see how many packages fail
to build. If that number seems acceptable, then first upload it to
experimental, and then coordinate with the release team to get a
transition slot.

Regarding the actual decision whether or not to abandon Libav in favor
of FFmpeg: After thinking about this very hard for a couple of weeks,
I find we are in a very uncomfortable situation. Neither of the two
competing projects is really ideal, but the reality is that there is
no one in Debian who has the capacity to significantly contribute to
either of those projects - we are effectively dependent on the
upstream project to provide a product that we can integrate and
redistribute. I have been doing that during the jessie's development,
but things have changed in my life and I'm no longer able to keep up
with that commitment. Libav has served us very well for years, but the
project lost much of its drive from its inception, which is very
unfortunate.

FFmpeg clearly provides more functionality and has definitely more
manpower available that provides also updates for earlier releases.
The drive for maintaining release branches is something rather new for
FFmpeg, and it remains to be seen if that enthusiasm can be held up
even without the competition from Libav.

What makes me most uncomfortable about this move is that it is rather
impossible to reverse - there is no going back. I certainly do hope
that we do not open pandora's box - at least
http://upstream-tracker.org/versions/ffmpeg.html looks promising, but
then FFmpeg comes with a codebase that is hard to maintain, has
competing (i.e., multiple) implementations for encoders and decoders,
and so on.

Bottom line: I still have some concerns with this move, but I can't
claim Libav to be superior to FFmpeg at this point. From the provided
product, I still do believe that Libav is the more promising code-base
for integrating into a large-scale distribution such as Debian because
it has a cleaner code-base that is easier to understand and extend.
From the development communities, Libav clearly can't keep up with
FFmpeg, who has a defacto full-time developer doing an outstanding
amount of work. There is, however, a significant risk in form of a
bus-factor: Is Michael replaceable? He has been working on FFmpeg for
over 15 years more or less full-time, but is this going to continue
like that forever? Most likely not; so is the risk for that acceptable
for Debian? - It appears that Balint, Allesandro and Andreas think it
clearly is - and I'm not sure why they appear to be so convinced on
this point; neither of them has been around when the things escalated
and Libav forked from FFmpeg after all.

For me, that is a par - and I think I stand with my rather neutral position.

On a personal note: I think the FFmpeg code base stems for a time
where performance was the top-priority - long-term maintainability and
security against malicious sources was clearly not. These new
requirements are best addressed with a general redesign - ideally in a
safer language such as Rust (http://www.rust-lang.org/), or similar.
Unfortunately, such a project is not currently in sight, so the best
option media playback applications have right now to provide secure
and versatile playback capabilities is to sandbox the decoding process
like the Chromium browser. This is challenging to implement and
not-portable, which is however a stated goal of both Libav and FFmpeg.

Also, I would feel much more comfortable if someone could convince me
that FFmpeg is really not a one man show, and is taking maintenance of
both internal and external APIs seriously.

Because of the significance of this issue (this move is rather
impossible to revert), I'd also like to 

Re: Select provider of libav* libraries

[Reinhard Tartler]

On May 15, 2015 4:56 PM, Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 Hi Reinhard,

 thanks for explaining your point of view here.

 On 15.05.2015 09:23, Reinhard Tartler wrote:
  Thanks for this insightful post, Dmitry,
 
  On Mon, May 11, 2015 at 5:44 AM, Dmitry Smirnov only...@debian.org
mailto:only...@debian.org wrote:
  On Sat, 9 May 2015 16:00:49 Andreas Cadhalpun wrote:
  What would you count as very compelling reasons if more features,
less bugs
   and better security support are not sufficient?
 
  More features is not necessary means less maintenance burden;
  Less bugs is not always means better software (it is a matter of how
upstream
  manages bugs);
  Quality of security support is something that remains to be seen.
 
  I think security is not a decisive topic where either project cannot
  clearly claim of having a clearly better handle.

 I disagree: FFmpeg is clearly better at fixing security issues.
 To take a random example, an out of bounds read in the bink decoder was
fixed
 in FFmpeg three years ago [1], while Libav git master is still vulnerable
 today.

 One can find more such examples, but I have better things to do with my
time.

I think this sea0¨˜j67

  These days, FFmpeg for
  sure asks for most (if not all) CVE numbers recently assigned, and
claims
  to provide patches for them.

 FFmpeg not only claims to provide patches, but actually does provide them:
 most CVEs link to the corresponding patch.

  What is less visible is what happens behind the scenes:
 
  Most of these issues originate from Google Guys that work on security
and
  conduct fuzzing tests on libavcodec/libavformat. Their main target is of
  course their own libavcodec/libavformat fork that they ship in Chrome,
but

 As far as I'm aware they use a git snapshot of FFmpeg that they update
 from time to time. They only change the build process to produce one
single
 libffmpegsumo library instead of libavcodec/libavformat/libavutil.

  they (of course) also share their samples with both Michael (FFmpeg) and
  Luca/Anton (Libav). Michael seems to have much more capacity and time,
and
  thus is usually faster with pushing patches for such crashers.

 Yes, Michael does an awesome job at fixing those [2].

  Libav takes
  the time to investigate, reproduce and understand those patches.

 That's a commendable idea, but if the result is that these patches
 don't get applied in a reasonable time frame, it's rather bad.

  Unfortunately, in the majority of cases, this is not trivial at all,
often
  because of terse (or even wrong) commit messages, or the fact that there
  are better places to fix a particular issue in the code.

 In that case it would probably help to ask the author of the patch.
 Did the Libav developers do that?

  Better usually
  means that more than a single instance of the issue is fixed.

 Can you give examples for this?

  Also, given that Libav supports significantly less codecs and formats
(and
  in some cases specific variants or features of codecs), many security
  issues simply don't apply.

 While it's true that some security issues only affect code not present in
 Libav, the majority of issues affect both projects (until they are fixed
in
 FFmpeg).
 Much of the additional code in FFmpeg poses nearly no security problem.
 For example, even if there was a potentially security relevant bug in one
 of the more than 100 additional filters in FFmpeg, it would be very hard
to
 exploit, since the filters generally have to be invoked manually.
 Only decoders/demuxers can be easily triggered automatically,
 e.g. by visiting a web site or opening a folder with images, for which
 thumbnails are created.
 Additionally it would be much easier to disable some rarely used features
 in Debian's FFmpeg than to enable desired features in Debian's Libav,
 when they are not present upstream.

  Libav could for sure do a much better job here by releasing faster. In
the
  past, I looked at doing new point releases about every 2-3 months, but
for
  family reasons, I wasn't able to keep that pace. Release frequency is
  clearly something that needs improvement. As far as for the release
  content, I am not aware of critical fixes being missed, so quality wise
I
  think we are good.

 You are wrong about the quality. Have a look at the bink example I gave
above.

  I have a feeling that Debian already became life support for libav.
  Ever since Debian chosen libav, ffmpeg remained alive and apparently
doing
  well without our help. I'm not too sure if libav would be able to stay
alive
  without Debian.
 
  That's an interesting take on the matter. I don't think it is accurate;
for
  instance OpenEmbedded or Gentoo also ship Libav (in favor of FFmpeg), so
  DebianUbuntu are clearly not alone.

 Interestingly Gentoo recently switched to FFmpeg by default [3] after
conducting
 a survey [4]. About 300 people participated in that survey and the outcome
 was rather clear:
 62%[ 189 ]I prefer

Re: Select provider of libav* libraries

[Reinhard Tartler]

Please excuse my previous unfinished reply, it was sent in accident.
I'm not sure if this post really adds to this discussion, please consider
it as clarifications to my previous post.

On May 15, 2015 4:56 PM, Andreas Cadhalpun
  I think security is not a decisive topic where either project cannot
  clearly claim of having a clearly better handle.

 I disagree: FFmpeg is clearly better at fixing security issues.
 To take a random example, an out of bounds read in the bink decoder was
fixed
 in FFmpeg three years ago [1], while Libav git master is still vulnerable
 today.

 One can find more such examples, but I have better things to do with my
time.

I think this attitude demonstrates a clear problem. Instead of properly
describing the issue through the appropriate channels, posts like this draw
a bad picture by providing anectodal references of issues that may or may
not affect Libav. The right thing to do would be file a bugreport that
collects references and information what the problem is and how to verify
the fix, but this is not how this fight is fought apparently.

But the issue is even more serious: Despite having the cleaner code-base,
which compared to FFmpeg is much more accessible and easier to work with,
there are a significant number of very vocal developers that argue that
FFmpeg was better in every thinkable way. Despite several calls for help,
people have shown very little response such has pointing to specific
patches and backporting/cherry picking missing functionality. There have
been a handful of instances where this worked out though!


  These days, FFmpeg for
  sure asks for most (if not all) CVE numbers recently assigned, and
claims
  to provide patches for them.

 FFmpeg not only claims to provide patches, but actually does provide them:
 most CVEs link to the corresponding patch.

In many many cases, the descriptions of the patches and the issues are
sub-standard, in many cases even misleading. In no case that I looked at,
the issue was immediately reproducible, because all of the referenced
samples are held back and it is not easy at all the get access to them. And
even if you do contact people via email and eventually are provided the
samples, reproducing the issue remains very challenging.

I stopped looking actively at them when I repeatedly came to the conclusion
that the issue can only be seen when seen when used in the test harnish
that Google uses for testing libavcodec within chrome.


  they (of course) also share their samples with both Michael (FFmpeg) and
  Luca/Anton (Libav). Michael seems to have much more capacity and time,
and
  thus is usually faster with pushing patches for such crashers.

 Yes, Michael does an awesome job at fixing those [2].

He does an awesome job at producing patches that only a handful of people
on this planet are capable of assessing what's going on. I cannot tell if
he is obfuscating them on purpose, most likely this is rather the way he
thinks and works on the issues: The work of a genius that takes a genius to
understand.

To me, this constitutes a serious bus-factor: Without Michael, (probably)
nobody is able to replace him. On the other hand, in such a scenario we
wouldn't have the forks competing with each other either.

 Interestingly Gentoo recently switched to FFmpeg by default [3] after
conducting
 a survey [4]. About 300 people participated in that survey and the outcome
 was rather clear:

It saddens me to see people organizing votes where people participate that
have no idea what they are voting about. How many of the 300 people that
participated have tried to cherry pick a fix to libavcodec, or can even
tell what the difference between libavcodec and libswscale is?

[...]
  I think the debate on the development methodology is the biggest
  disagreement between the two projects: FFmpeg insists on keeping its
  development velocity and allowing developers to get work done,
  compromising on maintainability and common understanding of the code
base
  in favor of more features.

 I don't think getting work done is bad, because if work (like bug fixes)
 doesn't get done, it is worse for maintainability.

  Libav on the other hand rather focuses on clean
  implementation and let's say better designed APIs.

 Let's say Libav focuses more on cosmetics like consistent indentation,
 use of spaces around brackets, a linear commit history and such.

Please refrain from polemics such as these insults. Not everyone on this
mailing list is as involved and familiar with both projects to clearly
identify such statements as what they are.

  This requires more work,
  which in effect significantly lowers the development velocity. For a
system
  integration job on the scale of Debian, less velocity seems more
appealing
  to me.

 Less velocity in fixing (security) issues seems everything but appealing.


It is true that manpower is a scarce resource, in particular for
volunteer-driven free software projects. In Debian, we are very aware of

Re: Select provider of libav* libraries

[Reinhard Tartler]

Thanks for this insightful post, Dmitry,

On Mon, May 11, 2015 at 5:44 AM, Dmitry Smirnov only...@debian.org wrote:
 On Sat, 9 May 2015 16:00:49 Andreas Cadhalpun wrote:
 What would you count as very compelling reasons if more features, less
bugs
 and better security support are not sufficient?

 More features is not necessary means less maintenance burden;
 Less bugs is not always means better software (it is a matter of how
upstream
 manages bugs);
 Quality of security support is something that remains to be seen.

I think security is not a decisive topic where either project cannot
clearly claim of having a clearly better handle. These days, FFmpeg for
sure asks for most (if not all) CVE numbers recently assigned, and claims
to provide patches for them. What is less visible is what happens behind
the scenes:

Most of these issues originate from Google Guys that work on security and
conduct fuzzing tests on libavcodec/libavformat. Their main target is of
course their own libavcodec/libavformat fork that they ship in Chrome, but
they (of course) also share their samples with both Michael (FFmpeg) and
Luca/Anton (Libav). Michael seems to have much more capacity and time, and
thus is usually faster with pushing patches for such crashers. Libav takes
the time to investigate, reproduce and understand those patches.
Unfortunately, in the majority of cases, this is not trivial at all, often
because of terse (or even wrong) commit messages, or the fact that there
are better places to fix a particular issue in the code. Better usually
means that more than a single instance of the issue is fixed.

Also, given that Libav supports significantly less codecs and formats (and
in some cases specific variants or features of codecs), many security
issues simply don't apply.

Libav could for sure do a much better job here by releasing faster. In the
past, I looked at doing new point releases about every 2-3 months, but for
family reasons, I wasn't able to keep that pace. Release frequency is
clearly something that needs improvement. As far as for the release
content, I am not aware of critical fixes being missed, so quality wise I
think we are good.

 I have a feeling that Debian already became life support for libav.
 Ever since Debian chosen libav, ffmpeg remained alive and apparently doing
 well without our help. I'm not too sure if libav would be able to stay
alive
 without Debian.

That's an interesting take on the matter. I don't think it is accurate; for
instance OpenEmbedded or Gentoo also ship Libav (in favor of FFmpeg), so
DebianUbuntu are clearly not alone. It is true that Libav owes the largest
portion of its userbase to DebianUbuntu, however even if Debian would stop
shipping Libav, then I doubt that this would threat Libav development in
any way.


 From maintenance prospective libav seems to be a liability. We have to
carry
 patches for packages where upstreams are not too concerned about
supporting
 libav.

This statement is a bit surprising to me. At the time Debian started to
ship Libav, there was absolutely *no* difference to FFmpeg. Since that,
many things have changed, and the two code-bases have diverged. While
FFmpeg started to merge as much functionality as possible, Libav focused on
maintainability, cleaned and straightened-up APIs and removed fringe codecs
and formats.

 Also in the light of past libav transitions and deprecations that required
 multiple changes in Debian and upstream I know no upstream who is happy to
 support libav.

In practice, maintainability means something different for an upstream
project and a distribution package. While upstream developers extend, fix
and refactor the code-base,as package maintainers we make sure that the
libavcodec package works fine with all applications that make use of it.

To be totally blunt: The libavcodec/libavformat API is horrible. This is
partly caused because of the aim to have a single library that covers every
thinkable container and codec flavor using a common API. Libav has
identified the development process as the culprit, where developers
submit unfinished and unreviewed work to the main codebase, which is then
used by applications and can basically never be fixed.

In an attempt to provide applications a better interface to
libavcodec/libavformat, Libav has in the past aggressively devised new
and deprecated old APIs for maintenance reasons, i.e., helping the
maintenance of the libav codebase.
For Debian with a large two digit number of reverse dependencies, this
caused a lot of fall-out that needed to be fixed. Libav developers were
instrumental with providing patches to make them build again. FFmpeg tries
hard to keep old APIs, which for sure lowers the effort for Linux
distributions, but is it really better to keep applications that use
obsolete and broken APIs? I'm not sure. In the long run, having
applications use less horrible APIs is for sure a good thing.

I think the debate on the development methodology is the biggest

Re: Select provider of libav* libraries

[Reinhard Tartler]

On 2015-05-09 11:19, Alessio Treglia wrote:

Hi,

Admittedly seems there is more activity on FFmpeg's than libav's side.
It does not necessarily reflect into higher quality though - plus,
libav is not dead at all as they're still releasing new versions and
providing support and fixes for a number of stable branches.
I'm personally getting very well with libav and apparently it is
enough to meet all my needs too. Nevertheless others are encountering
issues that they claim are solved with FFmpeg, so that might be a
solution which could make many users happy.

I'm not going to vote on this now as I really need to hear an opinion
from the libav's current maintainer, Reinhard Tartler.
I genuinely believe that we all need to hear an opinion from him
before taking any further action.


Thanks for copying me on this email. It seems that I was automatically
unsubscribed from that email on May 1 due to excessive bounces, and 
failed

to notice that. I've resubscribed myself now.

I've also started to read the mails that have been exchanged so far.
The main issue is that I'm currently travelling and need more time to
articulate my opinion on the matter[1] than I have right now.
Please give me a couple of days to catch up.

Best,
Reinhard


[1] it is much less black and white than Andreas suggests -
please don't put words in my mouth


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#781812: libav

[Reinhard Tartler]

Control: forwarded -1 libav-d...@lists.libav.org

Hi Mathieu,

I would appreciate if in future you could provide a bit more details
when reassigning bugs. The quote below was all that I had to start
working on this issue, which is terse.

My understanding of this we are talking about a curious feature in the
MKV container: apparently, you can attach cover art into the
container. Libavformat allows applications to access embedded images
by providing an extra stream.

Please someone correct me, but my understanding of
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=511585c is that
libavformat implements this inconsistently for different containers. I
wonder how did this happen, is there some deeper reason for  this
inconsistency? Minidlna seems to have stumbled over this inconsistency
and seems to work fine with that patch that was discussed with FFmpeg,
but not with Libav. This is a bit disappointing, maybe you could
forward such clearly upstream bugs yourself to avoid having the
package maintainers as extra round-trip? Thanks.

I do not use minidlna myself, so I cannot verify this issue myself.
However, I've tried to apply the patch that was submitted against
FFmpeg, which I have attached to this email. I've also compared the
output of avprobe on the suggested test sample
https://sourceforge.net/projects/matroska/files/test_files/cover_art.mkv
with and without the patch. It seems promising to me, but again, I
have no means to verify this issue, so please someone else take over
of testing it and getting the patch ready for submission in Libav.

Thanks,
Reinahrd

On Sat, Apr 4, 2015 at 11:09 AM, Mathieu Malaterre ma...@debian.org wrote:
 reassign 781812 libav 6:11.3-1
 thanks

 This has been fixed in ffmpeg:

 https://trac.ffmpeg.org/ticket/4423#comment:8

 Since minidlna currently uses libav, I am leaving this bug open.

 ___
 pkg-multimedia-maintainers mailing list
 pkg-multimedia-maintainers@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers



-- 
regards,
Reinhard
From 6338c434c62d748c95c958ab9b5eae26033f38c3 Mon Sep 17 00:00:00 2001
From: wm4 nfx...@googlemail.com
Date: Fri, 3 Apr 2015 16:11:53 +0200
Subject: [PATCH] matroskadec: export cover art correctly

Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.

Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.

Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.

Fixes trac #4423.

Signed-off-by: Michael Niedermayer michae...@gmx.at

Conflicts:
	libavformat/matroskadec.c
---
 libavformat/matroska.c|  9 +++--
 libavformat/matroska.h|  1 +
 libavformat/matroskadec.c | 48 ++-
 libavformat/matroskaenc.c |  5 +
 4 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 47fdea6..eca1e41 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -89,12 +89,17 @@ const CodecTags ff_mkv_codec_tags[]={
 { , AV_CODEC_ID_NONE}
 };
 
-const CodecMime ff_mkv_mime_tags[] = {
-{text/plain , AV_CODEC_ID_TEXT},
+const CodecMime ff_mkv_image_mime_tags[] = {
 {image/gif  , AV_CODEC_ID_GIF},
 {image/jpeg , AV_CODEC_ID_MJPEG},
 {image/png  , AV_CODEC_ID_PNG},
 {image/tiff , AV_CODEC_ID_TIFF},
+
+{   , AV_CODEC_ID_NONE}
+};
+
+const CodecMime ff_mkv_mime_tags[] = {
+{text/plain , AV_CODEC_ID_TEXT},
 {application/x-truetype-font, AV_CODEC_ID_TTF},
 {application/x-font , AV_CODEC_ID_TTF},
 
diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index d8f4f8e..a7a22a9 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -254,6 +254,7 @@ typedef struct CodecTags{
 
 extern const CodecTags ff_mkv_codec_tags[];
 extern const CodecMime ff_mkv_mime_tags[];
+extern const CodecMime ff_mkv_image_mime_tags[];
 extern const AVMetadataConv ff_mkv_metadata_conv[];
 
 int ff_mkv_stereo3d_conv(AVStream *st, MatroskaVideoStereoModeType stereo_mode);
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d352c8b..2f4f075 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1887,22 +1887,44 @@ static int matroska_read_header(AVFormatContext *s)
 

Bug#775593: Bug#773626: libav: multiple security issues

[Reinhard Tartler]

Control: forwarded -1 https://bugzilla.libav.org/show_bug.cgi?id=805

On Mon, Jan 19, 2015 at 8:42 AM, Bálint Réczey bal...@balintreczey.hu wrote:
 Probably asking FFmpeg upstream would help, maybe Libav upstream also
 have been notified about the details.

Great idea.

I've forwarded this bug to libav upstream. Please go ahead and ask
FFmpeg for more information where to obtain those samples.

Thanks,
Reinhard

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#775593: Bug#773626: libav: multiple security issues

[Reinhard Tartler]

Control: severity -1 important

On Sat, Jan 17, 2015 at 2:56 PM, Sebastian Ramacher
sramac...@debian.org wrote:
 On 2014-12-20 23:31:11, Michael Gilbert wrote:
 CVE-2014-8544[4]:
 | libavcodec/tiff.c in FFmpeg before 2.4.2 does not properly validate
 | bits-per-pixel fields, which allows remote attackers to cause a denial
 | of service (out-of-bounds access) or possibly have unspecified other
 | impact via crafted TIFF data.

 CVE-2014-8546[6]:
 | Integer underflow in libavcodec/cinepak.c in FFmpeg before 2.4.2
 | allows remote attackers to cause a denial of service (out-of-bounds
 | access) or possibly have unspecified other impact via crafted Cinepak
 | video data.

 CVE-2014-9316[10]:
 | The mjpeg_decode_app function in libavcodec/mjpegdec.c in FFMpeg
 | before 2.1.6, 2.2.x through 2.3.x, and 2.4.x before 2.4.4 allows
 | remote attackers to cause a denial of service (out-of-bounds heap
 | access) and possibly have other unspecified impact via vectors related
 | to LJIF tags in an MJPEG file.

 CVE-2014-9318[11]:
 | The raw_decode function in libavcodec/rawdec.c in FFMpeg before 2.1.6,
 | 2.2.x through 2.3.x, and 2.4.x before 2.4.4 allows remote attackers to
 | cause a denial of service (out-of-bounds heap access) and possibly
 | have other unspecified impact via a crafted .cine file that triggers
 | the avpicture_get_size function to return a negative frame size.

 CVE-2014-9319[12]:
 | The ff_hevc_decode_nal_sps function in libavcodec/hevc_ps.c in FFMpeg
 | before 2.1.6, 2.2.x through 2.3.x, and 2.4.x before 2.4.4 allows
 | remote attackers to cause a denial of service (out-of-bounds access)
 | via a crafted .bit file.

 [4] https://security-tracker.debian.org/tracker/CVE-2014-8544
 [6] https://security-tracker.debian.org/tracker/CVE-2014-8546
 [10] https://security-tracker.debian.org/tracker/CVE-2014-9316
 [11] https://security-tracker.debian.org/tracker/CVE-2014-9318
 [12] https://security-tracker.debian.org/tracker/CVE-2014-9319

 I'm cloning this bug report to keep track of the unfixed CVEs.

It seems to me that non of the above five entries have neither
publicly accessible samples nor any public discussion on neither
oss-sec nor fulldisc. It remains unclear whether or not they affect
libav at all.

While I agree that these issues should be investigated in more detail,
the lack of instructions how to confirm and reproduce the issue makes
working on this bug unreasonably hard. I'm therefore downgrading the
severity of this issue to the non-RC severity important; this bug
does not seem release critical to me at all.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Libav v11.2

[Reinhard Tartler]

Today, we update our release series 11 with the release of Libav
v11.2. This release contains several security and bug fixes.

This release contains many potentially security-relevant corrections.
For details, please refer to the verbose Changelog file at
https://git.libav.org/?p=libav.git;a=blob;f=Changelog;hb=refs/heads/release/11

We encourage distributors and system integrators to update, and share
their patches against our release branches.

Enjoy!


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#738760: libav: Add proper raspberry pi CPU detection

[Reinhard Tartler]

On January 6, 2015 8:16:51 AM EST, Sebastian Ramacher sramac...@debian.org 
wrote:
Control: tags -1 + patch

Hi Peter

On 2015-01-03 22:36:13, peter green wrote:
 Sebastian Ramacher wrote:
 there was a request to change the handling of the Raspberry Pi in
the
 libav package. Could you please explain the changes applied to the
 Raspbian version?
 In raspbian we have a checker that runs after all our autobuilds (and
I
 manually run a similar check when I do manual builds) that looks for
files
 tagged as armv7 (note: it seems using neon compiler options causes
files to
 be tagged as armv7 even if the CPU options aren't changed) and
prevents the
 autobuilder from uploading them.
 
 In general i've been adopting the principle that having armv7 code in
 raspbian is at best a pointless waste of space (if the code in
question is
 correctly guarded behind runtime CPU detection) and at worst a
serious
 problem (if it isn't). Therefore I have been responding to cases like
this
 by simply disabling the armv7/neon code. The raspbian libav package
got this
 treatment.
 
 It's possible that I dodn't selct the best combination of flags, I'm
no
 libav expert.
 
 I have not tested whether an unodified debian libav package built in
a
 raspbian chroot actually works on the Pi or not.

Thank you for the explanation. What about the attached patch? [1]

I've looked through the code and the only place where
--enable-runtime-cpudetect
makes a difference is on powerpc (libavutil/ppc/cpu.c). Special
handling for
Raspbian should not make a difference. Reinhard, is my reading of the
code
correct?

I don't know if it is correct, but skimmed over it and did not spot obvious 
mistakes. Nevertheless, I personally do not have a rpi, nor the infrastructure 
to test it. Peter, if that patch works for raspian, and if you would be willing 
to report breakage as it occurs, then I'd be happy to have this change in the 
Debian package. Otherwise I'd fear it would just bitrot.

Many thanks to Sebastian for working in this patch!

Reinhard



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#773055: Fwd: Bug#773055: libav-tools: avconv -target pal-svcd fails with Unable to parse option value scan_offset

[Reinhard Tartler]

Control: forwarded -1 libav-de...@libav.org

Hi,

This looks like an easy target to fix. Can someone have a look at
this? Is this critical and applicable for earlier releases as well?

Best,
Reinhard


-- Forwarded message --
From: Andreas Weber andy.weber...@gmail.com
Date: Sat, Dec 13, 2014 at 2:48 PM
Subject: Bug#773055: libav-tools: avconv -target pal-svcd fails with
Unable to parse option value scan_offset
To: Debian Bug Tracking System sub...@bugs.debian.org


Package: libav-tools
Version: 6:11-2
Severity: normal
Tags: upstream

Dear Maintainer,

avconv -i in.mp4 -target pal-svcd out.mpg

fails with:
[mpeg2video @ 0x14b63c0] [Eval @ 0x73fcfd50] Undefined constant or missing
'(' in 'scan_offset'
[mpeg2video @ 0x14b63c0] Unable to parse option value scan_offset
[mpeg2video @ 0x14b63c0] Error setting option flags to value +scan_offset.

Error while opening encoder for output stream #0:0 - maybe incorrect parameters
such as bit_rate, rate, width or height

After fixing avconv_opt.c:

--- avconv_opt.c_orig   2014-12-13 20:34:41.795060988 +0100
+++ avconv_opt.c2014-12-13 20:26:00.579042876 +0100
@@ -1825,7 +1825,7 @@
 opt_default(NULL, maxrate, 2516000);
 opt_default(NULL, minrate, 0); // 1145000;
 opt_default(NULL, bufsize, 1835008); // 224*1024*8;
-opt_default(NULL, flags, +scan_offset);
+opt_default(NULL, scan_offset, 1);


 opt_default(NULL, b:a, 224000);

avconv works as expected. Is it possible that patch
https://patches.libav.org/patch/19539/ got lost?


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libav-tools depends on:
ii  dpkg 1.17.21
ii  libavcodec56 6:11-2
ii  libavdevice556:11-2
ii  libavfilter5 6:11-2
ii  libavformat566:11-2
ii  libavresample2   6:11-2
ii  libavutil54  6:11-2
ii  libc62.19-13
ii  libsdl1.2debian  1.2.15-10+b1
ii  libswscale3  6:11-2
ii  libvdpau10.8-3
ii  libx11-6 2:1.6.2-3

libav-tools recommends no packages.

Versions of packages libav-tools suggests:
pn  frei0r-plugins  none

-- no debconf information

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


-- 
regards,
Reinhard
--- avconv_opt.c_orig	2014-12-13 20:34:41.795060988 +0100
+++ avconv_opt.c	2014-12-13 20:26:00.579042876 +0100
@@ -1825,7 +1825,7 @@
 opt_default(NULL, maxrate, 2516000);
 opt_default(NULL, minrate, 0); // 1145000;
 opt_default(NULL, bufsize, 1835008); // 224*1024*8;
-opt_default(NULL, flags, +scan_offset);
+opt_default(NULL, scan_offset, 1);
 
 
 opt_default(NULL, b:a, 224000);
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright

[Reinhard Tartler]

On Fri, Nov 28, 2014 at 1:34 AM, Niels Thykier ni...@thykier.net wrote:
 Control: tags -1 -wheezy-ignore

 On 2014-11-27 23:23, Jonas Smedegaard wrote:
 Quoting Niels Thykier (2014-11-27 22:14:25)
 [...]

 In prior similar bugreport https://bugs.debian.org/760171#10 -
 referenced from https://bugs.debian.org/771191#10 - distribution is
 documented as permitted only for research and education which I
 interpret as unacceptable for Debian.

 [...]

  - Jonas


FTR, this whole business feel incredibly silly. lena.pnm  has become
the *de-facto* standard image for every CS student to do his graphics
courses homework on, and is generally considered to public domain,
even without proper documentation. The copyright holder is going to
have a very hard time enforcing his right if he wanted to prevent
distribution of the image, in particular the low-quality scan that is
being used in the Libav source package. Also, even according to
https://en.wikipedia.org/wiki/File:Lenna.png#Licensing, the holder is
not interested in that to begin with. - I mean, really, don't we have
more important things to do?

Nevertheless, lena.pnm lacks proper licensing and some argue it
violates the DFSG, so I've taken the effort (and ridicule!) to replace
lena.pnm upstream with a new image reference.pnm, which I have
personally taken this summer and upon Jonas' suggestion provide it
under the expat license. This required to update all test reference
patterns, which took  most of the effort and is basically not
verifiable.

Jonas, would you mind taking over from here and upload
https://libav.org/releases/libav-11.1.tar.xz

to unstable?

Otherwise I can see if I can get to that this weekend.

Regarding stable: I've backported this change back to release/0.8
upstream. In the past, the security team has accepted libav point
releases in wheezy-security, and I trust that this is also an
acceptable change. It will be part of the next upload to
stable-security. (this may take some more weeks, as libav has been
notified about a couple of more CVEs, which need to be tested, fixed
and verified, which is incredibly laborsome to do correctly).

Does this plan work for everyone?

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Help with backporting Libav patches

[Reinhard Tartler]

Hi folks,

Luca, who is doing most of the security work these days in Libav, asks
which releases we need to support. To the best of my knowledge, this
would in Debian and Ubuntu:

release/0.8: wheezy, precise
release/9: trusty
release/11: jessie, utopic, vivid

AFAIUI, we can safely retire release/10. Moritz, I fear at some point
we are going to stop supporting libav in stable. I don't think that
this is going to happen anytime soon, but you have an opinion how long
we really should get release/0.8 in shape?

Luca is doing the admirable work of going through the reports, which
most come in form of fuzzed samples provided by the Google security
team, analyzing the crash and proposing and committing the fix with a
well-documenting commit message. All those patches are easily
identifiable by grepping for the string CC: libav-stable in git log
--grep.

It would be a really great help to identify and backport those patches
to earlier release branches. Luca and I are wondering if someone had
some spare cycles to help us out here? Ideally, we can make a
cross-distro effort for this (Gentoo, Debian  Ubuntu!).

Please email Luca and me for coordination.

Thanks,
Reinhard


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright

[Reinhard Tartler]

In order to address this, I've proposed to replace lena.pnm with a new
image, taken by me, at https://github.com/libav/libav/pull/17

I don't really care about the licensing. Is the declaration in the
commit message OK? How to declare that in debian/copyright?


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright

[Reinhard Tartler]

On Thu, Nov 27, 2014 at 1:08 PM, Jonas Smedegaard d...@jones.dk wrote:
 Hi Reinhard,

 Quoting Reinhard Tartler (2014-11-27 18:35:05)
 In order to address this, I've proposed to replace lena.pnm with a new
 image, taken by me, at https://github.com/libav/libav/pull/17

 Fun idea :-)


 I don't really care about the licensing. Is the declaration in the
 commit message OK? How to declare that in debian/copyright?

 I might get away with such custom set of licensing terms, but to ease
 processing (if not by lawyers in a later dispute then at least by fellow
 distro maintainers wanting to categorize, identify, verify etc.) it is
 recommended that you instead pick a common license.  Preferrably one of
 those tracked by SPDX as listed at
 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification.

 Seems what you want is as liberal and as briefly expressed license as
 possible.  A popular common license of that kind is Expat.  ideally
 you refer to that license by its canonical URL
 http://www.jclark.com/xml/copying.txt but since you seem to seek as
 brief as possible expression, you could simply state e.g. Licensed
 under the Expat license.

 I am not a lawyer, just interested in licensing and pay attention to
 licensing patterns commonly expressed by upstreams of Debian and
 approved in Debian.  YMMV.

Sure, if you believe that the expat license is appropriate, I'd
license it that way.

Thanks for the feedback.

Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#770665: libxvidcore4: Xvideo not working

[Reinhard Tartler]

On Sun, Nov 23, 2014 at 5:51 PM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
 When I was running Ubuntu and Xubuntu this was not an issue. I just
 yesterday moved to Debian Jesse. Below are my specs
 rican-linux@debian-ppc:~$ cat /proc/cpuinfo
 processor : 0
 cpu : 7447A, altivec supported
 clock : 833.333000MHz
 revision : 1.2 (pvr 8003 0102)
 bogomips : 36.86
 timebase : 18432000
 platform : PowerMac
 model : PowerBook5,6
 machine : PowerBook5,6
 motherboard : PowerBook5,6 MacRISC3 Power Macintosh
 detected as : 287 (PowerBook G4 15)
 pmac flags : 001b
 L2 cache : 512K unified
 pmac-generation : NewWorld
 Memory : 2048 MB

 rican-linux@debian-ppc:~$ lspci |grep VGA
 :00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
 [AMD/ATI] RV350/M10 [Mobility Radeon 9600 PRO Turbo]


Can you please paste the output of xvinfo? What graphics driver do
you use? Please also attach your Xorg logfile.

Thanks

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#770665: libxvidcore4: Xvideo not working

[Reinhard Tartler]

 [49.586] (--) evdev: Mouseemu virtual mouse: Vendor 0x1f Product 0x1e
 [49.586] (--) evdev: Mouseemu virtual mouse: Found 3 mouse buttons
 [49.586] (--) evdev: Mouseemu virtual mouse: Found scroll wheel(s)
 [49.586] (--) evdev: Mouseemu virtual mouse: Found relative axes
 [49.586] (--) evdev: Mouseemu virtual mouse: Found x and y relative axes
 [49.586] (II) evdev: Mouseemu virtual mouse: Configuring as mouse
 [49.586] (II) evdev: Mouseemu virtual mouse: Adding scrollwheel support
 [49.587] (**) evdev: Mouseemu virtual mouse: YAxisMapping: buttons 4 and
 5
 [49.587] (**) evdev: Mouseemu virtual mouse: EmulateWheelButton: 4,
 EmulateWheelInertia: 10, EmulateWheelTimeout: 200
 [49.587] (**) Option config_info
 udev:/sys/devices/virtual/input/input5/event5
 [49.587] (II) XINPUT: Adding extended input device Mouseemu virtual
 mouse (type: MOUSE, id 11)
 [49.587] (II) evdev: Mouseemu virtual mouse: initialized for relative
 axes.
 [49.588] (**) Mouseemu virtual mouse: (accel) keeping acceleration
 scheme 1
 [49.588] (**) Mouseemu virtual mouse: (accel) acceleration profile 0
 [49.588] (**) Mouseemu virtual mouse: (accel) acceleration factor: 2.000
 [49.588] (**) Mouseemu virtual mouse: (accel) acceleration threshold: 4
 [49.589] (II) config/udev: Adding input device Mouseemu virtual mouse
 (/dev/input/mouse1)
 [49.589] (II) No input driver specified, ignoring this device.
 [49.589] (II) This device may have been added with another device file.
 rican-linux@debian-ppc:~$



Best,
Reinhard




 On Sun, Nov 23, 2014 at 6:03 PM, Reinhard Tartler siret...@gmail.com
 wrote:

 On Sun, Nov 23, 2014 at 5:51 PM, Herminio Hernandez, Jr.
 herminio.hernande...@gmail.com wrote:
  When I was running Ubuntu and Xubuntu this was not an issue. I just
  yesterday moved to Debian Jesse. Below are my specs
  rican-linux@debian-ppc:~$ cat /proc/cpuinfo
  processor : 0
  cpu : 7447A, altivec supported
  clock : 833.333000MHz
  revision : 1.2 (pvr 8003 0102)
  bogomips : 36.86
  timebase : 18432000
  platform : PowerMac
  model : PowerBook5,6
  machine : PowerBook5,6
  motherboard : PowerBook5,6 MacRISC3 Power Macintosh
  detected as : 287 (PowerBook G4 15)
  pmac flags : 001b
  L2 cache : 512K unified
  pmac-generation : NewWorld
  Memory : 2048 MB
 
  rican-linux@debian-ppc:~$ lspci |grep VGA
  :00:10.0 VGA compatible controller: Advanced Micro Devices, Inc.
  [AMD/ATI] RV350/M10 [Mobility Radeon 9600 PRO Turbo]
 

 Can you please paste the output of xvinfo? What graphics driver do
 you use? Please also attach your Xorg logfile.

 Thanks

 --
 regards,
 Reinhard





-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: x264-10bit wrapper script

[Reinhard Tartler]

On Nov 20, 2014 12:41 AM, Fabian Greffrath fab...@greffrath.com wrote:

 [changed subject line]

 Hi Julian,

 Am Mittwoch, den 19.11.2014, 20:01 + schrieb Julian Cable:
  Perhaps you can just say:
  This wrapper script has no options.

 thanks again! I improved the wording as you suggested.

 @Reinhard: I don't quite understand your recent changes to the script.
 Regardless of what arguments I give it, I never got to read the Failed
 to execute .. line. I think the wrapper script should just exit with
 the exit status of the program that it calls, if any.

That error message is only for the case that the exec call fails (e.g.
insufficient resources, bad program, etc. If all goes well, the wrapper
becomes the called program, so it doesn't return anything in the successful
code path.

Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: faad2 and faac

[Reinhard Tartler]

On Mon, Nov 10, 2014 at 5:38 AM, Fabian Greffrath fab...@greffrath.com wrote:
 Hey Julian,

 I've just tested your approach with the faad2 package and it works just
 as expected. I'll add the necessary changes to the Debian packaging soon
 [tm]. But please note that we are not in a hurry: testing is currently
 frozen and I see zero chance that faad2 will get a freeze exception with
 a change as intrusive as this.

 BTW, I have decided to put the renamed library into the regular libfaad2
 package. It has a different name and weights only ~250kB. So, you only
 need to take care to link your own application against the correct
 library name.

 @team: Does anyone remember why we put the 10bit-libx264 into a
 subdirectory instead of renaming the library? One has to use LD_PRELOAD
 magic, anyway, to use it.

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667573#29,
setting LD_LIBRARY_PATH would do just fine. According to the buglog, I
proposed the idea of shipping a shell wrapper that sets that for you,
but it seems I never got around doing is.

I have attached the shell wrapper that I had to this email. it seems
to even work as expected:

./x264-10bit ldd /usr/bin/x264 | grep libx264.so
libx264.so.142 = /usr/lib/x86_64-linux-gnu/x264-10bit/libx264.so.142
(0x7fd32d4e7000)

Julien, Fabian, do you think this would be helpful to have in the x264
package under /usr/bin?

-- 
regards,
Reinhard


x264-10bit
Description: Binary data
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Ardour FTBFS hurd-i386

[Reinhard Tartler]

On Tue, Oct 21, 2014 at 4:46 AM, Jaromír Mikeš mira.mi...@gmail.com wrote:


 2014-10-21 10:45 GMT+02:00 Jaromír Mikeš mira.mi...@gmail.com:

 Hi,

 ardour FTBFS on hurd-i386
 Should we build it only linux-any kfreebsd-any ?


 https://buildd.debian.org/status/package.php?p=ardoursuite=unstable

AFAIUI, hurd has no support for soundcards. I am baffled why people
spend time on fixing packages such as vlc or ardour without any hope
that the package on that arch would be useful to anyone.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#742896: Blank screen on all videos with VDPAU and nVidia card (xbmc)

[Reinhard Tartler]

On Mon, Oct 13, 2014 at 5:46 PM, Wojciech Kuranowski
wojci...@kuranowski.pl wrote:
 Yes, VDPAU acceleration fails with the latest package [xbmc with Anton's 
 patch compiled against libav]. But it's a bit
 better than before, because I have one example of working movie which
 was not working with previous libav based xbmc packages. All other
 tested movies fails with VDPAU. But everything works fine with ffmpeg
 based xbmc.

Can you provide samples of movies that do work and those that don't work?

I've also CC'ed Anton from Libav, who kindly provided patches and
suggestions in the context of this bug.


 This is my card:
 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce
 GTX 650] (rev a1)

 Driver:
 nvidia-vdpau-driver:amd64340.46-1

 How can I help?

We need to find out why some videos break and others work so that the
problem can be identified and fixed in the code.

Thanks,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Reinhard Tartler]

On Sun, Oct 12, 2014 at 11:47 AM, Alessio Treglia ales...@debian.org wrote:
 On Sat, Oct 11, 2014 at 9:49 PM, Reinhard Tartler siret...@gmail.com wrote:
 FWIW, I personally think we should not mention any of lame,
 xvidcore, x264 or mplayer2. All of these packages are already in
 stable, so the text as current is not exactly news.

 Sounds absolutely sensible.

Dropped in Revision 131. Feel free to revert if you disagree.

 What about the debian-multimedia task? [1]
 Do you think it's worth mentioning?

I would think that it is worth clarifying the scope and intention of
the task. Unfortunately, those are not really clear to me. I'm not
sure who is currently pushing that task.

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bits from the Debian Multimedia Team [RELOADED]

[Reinhard Tartler]

On Sat, Oct 11, 2014 at 7:27 AM, Alessandro Ghedini gh...@debian.org wrote:
 On Fri, Oct 10, 2014 at 07:01:09PM +0100, Alessio Treglia wrote:
 Folks,

 If you want to add some last bits, please do it by tomorrow morning,

 I updated the mplayer2 section and added mplayer to the dropped section (I 
 also
 slightly edited the mpv description). They all probably need some 
 proof-reading
 though.

Thanks for the update. I do have a comment about the last two sentences:


 Note that while mplayer2 adds a few new features, others (such as mencoder) 
 have been dropped as well. Also note that mplayer2 is not maintained upstream 
 anymore (differently from e.g. mpv).

I'm not sure if it makes sense to mention its upstream support status,
because you might ask the question well, why do you keep it then in
the first place?. Fact is that Debian is going to support the package
for wheezy, and the statement as written is rather confusing.


 Also, I noticed that a lot of the changes mentioned are mostly relevant to
 wheezy (e.g. lame, x264, libav, xvidcore, ...), so maybe the fact that the
 changes presented are not only relevant to jessie should be mentioned (the 
 first
 paragraph kinda does this, but IMO it's not very clear).

FWIW, I personally think we should not mention any of lame,
xvidcore, x264 or mplayer2. All of these packages are already in
stable, so the text as current is not exactly news.

Also, I'm a bit weary with advertising that Debian now ships with
fancy modern decoders, because I fear of trolls that ask questions
about legality, patents, etc. I've therefore avoided references
regarding that in my proposed text for libavcodec/libav.


 Also^2, the libav section IMO should be more about what version are we going 
 to
 release and what new changes it brings since wheezy. This can be compiled from
 libav release notes [0] [1] [2], though I'll leave that to the libav 
 maintainer
 judgment. The fact that we switched from ffmpeg is, I think, pretty clear to
 everyone already.

Exactly. I've just updated the section.

BTW, the maintainer of libav is (currently) the pkg-multimedia team ;-)





-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#764169: libav-tools: can transcode but not copy Speex audio from Matroska container

[Reinhard Tartler]

Control: Tag -1 upstream

On Sun, Oct 5, 2014 at 9:03 PM, Jonas Smedegaard d...@jones.dk wrote:
 Package: libav-tools
 Version: 6:11-1
 Severity: normal


 Speex audio in Matroska container behaves oddly: Codec needs to be
 explicitly declared, even though avconv lists the codec in extracted
 metadata.  More annoyingly, it is only possible to transcode into other
 codecs, not use pseudo-codec copy to e.g. repackage to Ogg container.

That sounds like an upstream issue. Would you mind filing this issue
at bugzilla.libav.org, and mention the upstream bug number here?

Thanks!

Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Sat, Oct 4, 2014 at 11:46 AM, Bálint Réczey bal...@balintreczey.hu wrote:

 I would also like to add that since Libav and FFmpeg offer different
 features they are different enough to consider them as alternates
 which have the place in Debian on their own right.

This is the part that makes me very uneasy, because that is a
statement that neither FFmpeg nor Libav upstream hold (Libav largely
ignores what FFmpeg says or does, and FFmpeg claims to have all
features of Libav because of the daily merges).

I think it is fair to say that both ffmpeg and libav share a large set
of common functionality. This can be seen by the fact that both
provide a set of competing shared libraries. I am not really convinced
that this sort of competition is helpful to Debian. In fact, I see it
rather harmful, as it fragments our archive in packages in two camps.

I claim that the majority of packages involved in the last two
libavformat/libavcodec library transitions do not care what package
provides libavformat.so/libavcodec.so (and their dependencies). In
what way does the choice between the libavcodec.so provide help them?
I see a great potential for confusion here, for rather little gain.

I would rather see people help with improving Libav, which provides a
cleaner and leaner codebase and is supported by an upstream with a
much more responsible development process. Just take the recent
shellshock drama as an example for what happens if you integrate
questionable (or simply too much) functionality in a widely used piece
of software.

I do understand that VDPAU doesn't work with XBMC when using libav.
Note that this seems to be specific to XBMC, because both mpv and vlc
seem to use libav's VDPAU capabilities just fine. I've raised this on
IRC a few hours ago and it is being looked at. For the future, VDPAU
is currently being overhauled in libav/master. I think it is fair to
say that this issue is being taken seriously, although the reaction
could definitely be more rapid.


 PS: I would like to see the Libav and FFmpeg forks merging under any
 name they pick, but this is unlikely to happen before Jessie's freeze.
 Maybe before Jessie+1...

I fully agree here, and would love to help on making that happen. But
before that can happen, both projects need to sort out the outstanding
trust issues, and agree on a common development process. At least
that's my take-away from the most recent discussion threads on
debian-devel@ and elsewhere.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: RFS: chromaprint 1.2-1

[Reinhard Tartler]

On Sun, Sep 28, 2014 at 2:48 PM, Simon Chopin chopin.si...@gmail.com wrote:
 Hi,

 I'd love it if someone (Reinhard ?) would upload the new version of
 chromaprint sitting in the eponymous pkg-multimedia git repo. As usual,
 I haven't updated the changelog in case there are still some changes
 needed.

looking at the changes in cmakelists.txt, it seems that the
SOVERSION_REVISION bumped from 2 to 3. Does that mean that we have a
SONAME bump here?



-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: RFS: chromaprint 1.2-1

[Reinhard Tartler]

On Sun, Sep 28, 2014 at 3:12 PM, Simon Chopin chopin.si...@gmail.com wrote:
 Quoting Reinhard Tartler (2014-09-28 20:58:00)
 On Sun, Sep 28, 2014 at 2:48 PM, Simon Chopin chopin.si...@gmail.com wrote:
  Hi,
 
  I'd love it if someone (Reinhard ?) would upload the new version of
  chromaprint sitting in the eponymous pkg-multimedia git repo. As usual,
  I haven't updated the changelog in case there are still some changes
  needed.

 looking at the changes in cmakelists.txt, it seems that the
 SOVERSION_REVISION bumped from 2 to 3. Does that mean that we have a
 SONAME bump here?

 No, this field is basically the patch version. It gets bump at each
 release, and doesn't impact the major SOVERSION. I have no idea why is
 this system so convoluted, but hey...

 BTW, upstream and pristine-tar branches pushed.


Thanks,
uploaded

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#762492: libav-tools: Audio/video encoding produces an audio encoding error with openshot/kdenlive

[Reinhard Tartler]

Control: tag -1 upstream

Thank you for your bug report.

On Mon, Sep 22, 2014 at 3:47 PM, Charles Laws
charles.debian.bug.repo...@gmail.com wrote:
 Package: libav-tools
 Version: 6:11-1
 Severity: important

 Dear Maintainer,

 My last video project was about 7 weeks ago. Sometime between then and now, I 
 lost the ability to export audio. I have tried a handful of different 
 encoding combinations with
 both openshot and kdenlive. Running openshot --debug and doing an export 
 gives me this:

 [libx264 @ 0x7fac29e0] [Eval @ 0x7fac39ffa500] Undefined constant or
 missing '(' in 'dct8x8'
 [libx264 @ 0x7fac29e0] Unable to parse option value dct8x8
 [aac @ 0x7fac002caec0] [Eval @ 0x7fac39ffa4b0] Undefined constant or
 missing '(' in 'dct8x8'
 [aac @ 0x7fac002caec0] Unable to parse option value dct8x8
 [mp4 @ 0x7fac24a0] Using AVStream.codec.time_base as a timebase hint
 to the muxer is deprecated. Set AVStream.time_base instead.
 on_frmExportVideo_destroy
 [consumer avformat] error writing flushed audio frame

That sounds like an issue that upstream should have a look at.
Would you mind filing this bug at the upstream bugtracker at
http://bugzilla.libav.org, and let us know the bugzilla bug number?
Also, cf https://libav.org/bugreports.html.

Thank you.
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#760763: fixed in libav 6:11~beta1-3

[Reinhard Tartler]

Control: reopen -1
Control: tag -1 help

On Fri, Sep 19, 2014 at 2:22 AM, Paul Wise p...@debian.org wrote:
 Package: libav-tools
 Version: 6:11-1
 Followup-For: Bug #760763

 On Sat, 2014-09-13 at 13:20 +, Reinhard Tartler wrote:

* Remove /etc/avserver.conf (Closes: #760763)

 This does not appear to have worked:

 pkg=libav-tools ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
 grep obsolete
 libav-tools: obsolete-conffile /etc/avserver.conf
 $ /etc/avserver.conf 43e9d812fb6ca7464d13eec57d6b3c17 obsolete

 This was my upgrade history:

 9.8-2+b1, 9.8-2+b2
 9.8-2+b2, 9.10-1
 9.10-1, 9.10-2
 9.10-2, 9.11-1
 9.11-1, 9.11-3
 9.11-3, 9.11-3+b1
 9.11-3+b1, 9.11-3+b2
 9.11-3+b2, 9.11-3+b3
 9.11-3+b3, 9.13-1
 9.13-1, 10.1-1
 10.1-1, 10.2-1
 10.2-1, 10.2-2
 10.2-2, 10.3-1
 10.3-1, 10.4-1
 10.4-1, 11~beta1-2,
 11~beta1-2, 11-1

I am puzzled. What's wrong with this change:

http://anonscm.debian.org/cgit/pkg-multimedia/libav.git/commit/debian/libav-tools.maintscript?id=1234c1184d0c3065ff791b984636b7925448fc9b

?

Help appreciated

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#749659: audacity + wxWidgets 3.0 — Proposing patch

[Reinhard Tartler]

On Sun, Sep 14, 2014 at 3:23 PM, Martin Steghöfer mar...@steghoefer.eu wrote:
 On 09/09/2014 12:56 PM, Olly Betts wrote:

 On Tue, Sep 09, 2014 at 12:43:26PM +0200, Martin Steghöfer wrote:

 If it helps, I can post a new version of the patch including Olly's
 proposed change. Would that help?

 That would be very useful - then it will be clearer exactly what the
 currently proposed changes are.


 On 09/09/2014 01:19 PM, Reinhard Tartler wrote:

 Can you maybe attach a debdiff, please? (BTW, I wouldn't mind a NMU)


 Please find attached a debdiff including the currently proposed version of
 the patches, the necessary changes to the debian/control file and an updated
 changelog explaining both.

 In the end I haven't included Olly's original patch (renaming of the FD
 constants) because it only patches the original FileDialog code that isn't
 used after applying my patch. I did, however, include my patching of the
 configure files because it seems that the solution to the dh_autoreconf
 problem will only be available after a new upstream Release.

Please remind me, what was the autoreconf problem, and how has it been
fixed upstream? I'm really not comfortable with uploading an about
500kb diff.

Benjamin, I wonder what your thoughts on this patch are?

Cheers,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#760433: libav: FTBFS on x32: Invalid inline assembly

[Reinhard Tartler]

On Wed, Sep 3, 2014 at 11:45 PM, Daniel Schepler dschep...@gmail.com wrote:
 Source: libav
 Version: 6:11~beta1-2
 Severity: important
 Justification: blocker for kde builds
 X-Debbugs-CC: Thorsten Glaser t...@mirbsd.de

 When I try building libav in an x32 schroot (without the build dependencies on
 frei0r, opencv, x264 which have also all failed to build on x32), I get this:

 ...
 /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c: Assembler 
 messages:
 /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:798: Error: 
 operand type mismatch for `push'
 /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:860: Error: 
 operand type mismatch for `push'
 /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:861: Error: 
 operand type mismatch for `push'
 ...
 /tmp/libav/libav-11~beta1/libswscale/x86/swscale_template.c:1380: Error: 
 operand type mismatch for `pop'
 /tmp/libav/libav-11~beta1/Makefile:44: recipe for target 
 'libswscale/x86/swscale.o' failed
 make[1]: *** [libswscale/x86/swscale.o] Error 1
 make[1]: Leaving directory '/tmp/libav/libav-11~beta1/debian-static'
 debian/rules:81: recipe for target 'build-stamp-static' failed
 make: *** [build-stamp-static] Error 2
 rm configure-stamp-static
 dpkg-buildpackage: error: debian/rules build gave error exit status 2

 I'm attaching the debdiff I'm using for an upload to debian-ports/unreleased.
 You can ignore the debian/control part, and as the debian/rules changes could
 be considered a horrible hack, I'm not tagging this as patch.

I don't think that this is the right solution, the fix should really
go to configure directly. Looking at configure, it already seems to
support --arch=x86_32. Can you confirm that the package calls
configure with that already? If not, then I guess that's the only
thing that we should fix in the packaging.

If the configure gets things wrong, then that's what should get fixed
and upstreamed. Upstream is usually very responsive to porting
patches, and obviously has even thought about x32, so let's join that
effort instead of disabling it.

Regarding porting, please have a look at
http://anonscm.debian.org/cgit/pkg-multimedia/libav.git/tree/debian/README.source:


Circular Build-Depends and bootstrapping libav on new architectures
===

libav is involved in several circular build-dependencies that give porters a
hard time (c.f. #671302) at bootstrapping, e.g.:

 libav - frei0r - opencv - libav
 libav - opencv - libav
 libav - x264 - libav
 libav - x264 - gpac - libav

However, please note that all these libraries are strictly optional to libav
and are only enabled at build time if available. For bootstrapping purposes
it is thus perfectly sufficient to remove all *-dev packages from the
Build-Depends field in debian/control and generate packages with a reduced
feature set that are still usable to build other packages.

Using the nomenclature of the EmdebianSprint2011 [0,1] one would write e.g.:

 Build-Depends-Bootstrap1:
  debhelper (= 9)

[0] http://wiki.debian.org/DebianBootstrap/EmdebianSprint2011
[1] http://lists.debian.org/debian-devel-announce/2011/03/msg0.html


 -- Fabian Greffrath fabian+deb...@greffrath.com  Tue, 19 Jun 2012
16:06:05 +0200



-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#749659: audacity + wxWidgets 3.0 — Proposing patch

[Reinhard Tartler]

On Tue, Sep 9, 2014 at 6:49 AM, Olly Betts o...@survex.com wrote:
 Control: severity -1 serious

 On Mon, Sep 08, 2014 at 10:12:37PM -0400, Reinhard Tartler wrote:
 I wonder what's the status of this bug. The most recent email did not
 help to clarify, so I test-compiled wx3.0.patch as proposed in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749659#35, and can
 confirm that the package builds fine. However, I noticed this in
 configure.log:

 checking for wx-config... /usr/bin/wx-config
 configure: Checking that the chosen version of wxWidgets is 2.8.x or
 3.0.x
 Great, you're using wxWidgets 2.8.12!

 I guess that is because the build dependencies needs updating. So I
 guess given that the proposed patch to the package is incomplete at
 best, I've removed the patch tag, as clearly more clarification is
 needed.

 Olly, I noticed that you raised the severity of this bug to Serious
 without further explanation. Can you please elaborate here?

 Justification was in the mail which updated the severity:

 # blocks the on-going wxwidgets3.0 transition
 severity 749659 serious
 thanks

 You can see that from the BTS if you click on the Full text link:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30;bug=749659

 https://wiki.debian.org/Teams/ReleaseTeam/Transitions says to use
 severity serious once the transition starts, which it officially
 did on 2014-05-27:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=24;bug=748169

Oh, that's the part I missed. Sorry.


 This situation claims that audacity should be removed from testing
 because of this issue. Is this really your intention?

 Very much so - the wxwidgets3.0 transition is close to complete and
 audacity is one of the stragglers:

 https://release.debian.org/transitions/html/wxwidgets3.0.html

 In fact, it's the only one still in testing, which is only because it
 is on the list which autorm won't touch due to popcon score.

 Of those, grass has an somewhat bogus build dependency (it really
 wants to check the wxPython version, so should do that directly)
 and 5 more the maintainer has said to remove.  Of the remaining 8,
 most have a fix in progress.

Thanks for the status update. It seems that audacity is really one of
the remaining packages blocking this transition. This was not clear to
when reading the bug. This transition has been going on for a really
unhealthy amount of time.

 Please correct me and clarify if I got something wrong, but AFAIUI,
 there are no reason for pressing on this bug because jessie will ship
 with wxWidgets 2.8.  Martin, may I recommend you getting in touch with
 upstream about this patch?

 I suppose the release team have the final say, but my intention is that
 jessie will not ship with wxwidgets2.8.  It is a large and complex
 library, and now unmaintained upstream.  Even before 3.0 was released,
 2.8 was neglected - the last release was 2011-03-28.  So by the time
 jessie releases, wx2.8 will be close to 4 years old.  By the EOL of
 jessie (assuming no LTS), it'll be close to 6 years old.

 And given (thanks to Martin's superlative efforts) we have a patch for
 audacity, why are we even having this discussion?

Well, I would appreciate a patch that is a) uptodate and b) complete
(what changes to the packaging are required to satisfy this
transition).

Can you maybe attach a debdiff, please?

(BTW, I wouldn't mind a NMU)

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#702762: Fwd: Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

There seems to be at least some activity here.  Maybe we can update the
Debian libpostproc package to Michael's new branch.

Derek, just to clarify since you worked on the branch the package is
currently based on: What are your thoughts on this? Are you interested in
continuing this effort? What would you recommend to use for the Debian
package? Is it useful to have libpostproc in Debian? (see also the backlog
of this bug).

Please advise.

Thanks
 On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote:
 On 05.09.2014, at 03:46, Reinhard Tartler siret...@gmail.com wrote:
  On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer michae...@gmx.at
wrote:
  At the end of the day, I need a source tarball that contains
  maintained sources of a stand-alone libpostproc. I don't care too much
  how it is created, as long as it doesn't result in code-duplication
  with existing sources in Debian.
 
  would it work if libpostproc could be build and installed
  standalone from ffmpeg git / ffmpeg release tarballs?
 
  That would be exactly the code-duplication I referred to in the text
  you've quoted.

 Combined with a release script doing rm of libav*?
 I think the problem is that libpostproc just isn't a viable stand-alone
program, mostly due to complete lack of stand-alone testability not to
mention test infrastructure.
 Keeping the separate git up-to-date certainly is an option but involves
extra effort (though a lot less than making libpostproc testable
stand-alone).
 I don't see a good way to split the libraries into separate repositories
that does not involve either at least maintaining configure in each or
seriously harming bisecting/regression testing.
 Release scripts that generate multiple tarballs seems more realistic than
splitting the repository, in case that sounds like helpful to anyone...

Heres a proof of concept updated libpostproc

https://github.com/michaelni/FFmpeg/tree/separated_libpostproc

this is simply a clone of ffmpeg with everything unneeded
droped and the build system from the libpostproc repository
it builds successfully but is completely untested beyond that

It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this
would need to be added, as well as updating README and all that as
well as testing

also the differences in aboves repo could possibly be used to
construct a script to create a split out libpostproc for debian
if thats whats wanted.


[...]

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


signature.asc
Description: PGP signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

On Sun, Sep 7, 2014 at 5:30 PM, Michael Niedermayer michae...@gmx.at wrote:
 On Fri, Sep 05, 2014 at 08:18:57AM +0200, Reimar Döffinger wrote:
 On 05.09.2014, at 03:46, Reinhard Tartler siret...@gmail.com wrote:
  On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer michae...@gmx.at 
  wrote:
  At the end of the day, I need a source tarball that contains
  maintained sources of a stand-alone libpostproc. I don't care too much
  how it is created, as long as it doesn't result in code-duplication
  with existing sources in Debian.
 
  would it work if libpostproc could be build and installed
  standalone from ffmpeg git / ffmpeg release tarballs?
 
  That would be exactly the code-duplication I referred to in the text
  you've quoted.

 Combined with a release script doing rm of libav*?
 I think the problem is that libpostproc just isn't a viable stand-alone 
 program, mostly due to complete lack of stand-alone testability not to 
 mention test infrastructure.
 Keeping the separate git up-to-date certainly is an option but involves 
 extra effort (though a lot less than making libpostproc testable 
 stand-alone).
 I don't see a good way to split the libraries into separate repositories 
 that does not involve either at least maintaining configure in each or 
 seriously harming bisecting/regression testing.
 Release scripts that generate multiple tarballs seems more realistic than 
 splitting the repository, in case that sounds like helpful to anyone...

 Heres a proof of concept updated libpostproc

 https://github.com/michaelni/FFmpeg/tree/separated_libpostproc

 this is simply a clone of ffmpeg with everything unneeded
 droped and the build system from the libpostproc repository
 it builds successfully but is completely untested beyond that

 It seems the old buildsystem lacks HAVE_MMX*_INLINE support, this
 would need to be added, as well as updating README and all that as
 well as testing

That repo looks promising. However, the README and installations
instructions still refer to FFmpeg which seems rather confusing to me.
Also, the licensing needs to be clarified. AFAIUI, libpostproc is GPL
only, so adding a LGPL license is also confusing at best.

 also the differences in aboves repo could possibly be used to
 construct a script to create a split out libpostproc for debian
 if thats whats wanted.

Debian already does ship a split out libpostproc. I'm happy to upgrade
it to some newer version if a tarball appeared.

May I ask out of curiosity, what in FFmpeg actually uses libpostproc
other than than libavfilter/vf_pp.c? You said that you prefer to
maintain libpostproc inside FFmpeg because that way you can apply the
FFmpeg test system on it. I wonder what automated tests cover code in
libpostproc?

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#760763: libav-tools: conffiles not removed

[Reinhard Tartler]

On Sun, Sep 7, 2014 at 1:06 PM, Paul Wise p...@debian.org wrote:
 Package: libav-tools
 Version: 6:11~beta1-2
 Severity: normal
 Usertags: conffile
 User: debian...@lists.debian.org
 Usertags: obsolete-conffile adequate

 The recent upgrade did not deal with obsolete conffiles properly.
 Please use the dpkg-maintscript-helper support provided by dh_installdeb
 to remove these obsolete conffiles on upgrade.

 http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
 http://manpages.debian.net/man/1/dh_installdeb

 This bug report brought to you by adequate:

 http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

 $ pkg=libav-tools ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | 
 grep obsolete
 libav-tools: obsolete-conffile /etc/avserver.conf
 /etc/avserver.conf 43e9d812fb6ca7464d13eec57d6b3c17 obsolete

Actually, that configuration file should just get removed. Is there a
better way than rm -r /etc/avserver.conf in postinst?


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#749659: audacity + wxWidgets 3.0 — Proposing patch

[Reinhard Tartler]

Control: tag -1 -patch
Control: severity -1 normal

Hi,

I wonder what's the status of this bug. The most recent email did not
help to clarify, so I test-compiled wx3.0.patch as proposed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749659#35, and can
confirm that the package builds fine. However, I noticed this in
configure.log:

checking for wx-config... /usr/bin/wx-config
configure: Checking that the chosen version of wxWidgets is 2.8.x or
3.0.x
Great, you're using wxWidgets 2.8.12!


I guess that is because the build dependencies needs updating. So I
guess given that the proposed patch to the package is incomplete at
best, I've removed the patch tag, as clearly more clarification is
needed.

Olly, I noticed that you raised the severity of this bug to Serious
without further explanation. Can you please elaborate here? This
situation claims that audacity should be removed from testing because
of this issue. Is this really your intention?

The wxwidgets transition tracking bug seems to be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748169. Given that
the transition did not start before the September 5, I think it is
fair to assume that this transition is not going to happen for
Debian/jessie, and that it is also appropriate to downgrade the
severity of this bug.

Please correct me and clarify if I got something wrong, but AFAIUI,
there are no reason for pressing on this bug because jessie will ship
with wxWidgets 2.8.  Martin, may I recommend you getting in touch with
upstream about this patch?

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#760763: libav-tools: conffiles not removed

[Reinhard Tartler]

AFAIUI, I should add a debian/libav-tools.maintscript with the
following content:

rm_conffile /etc/avserver.conf 6:10.2-1~

Does this sound good to you?


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#760639: mplayer2: PGS subtitle format won't appear

[Reinhard Tartler]

Control: tag -1 upstream
Control: forwarded -1 u...@mplayer2.org

On Sat, Sep 6, 2014 at 7:26 AM, Axel Angel axel-...@vneko.ch wrote:
 Package: mplayer2
 Version: 2.0-728-g2c378c7-2+b2
 Severity: normal

 Dear Maintainer,

 [...]
 Playing videos (eg: mkv) containing correctly recognized S_HDMV/PGS
 subtitles with mplayer2 but they are not displayed at all in this new
 build [, which is compiled against libav11]. [...]
 Downgrading to 2.0-728-g2c378c7-2+b1 [compiled against libav10] works fine.

Please provide unshortened debug logs, i.e., mplayer -v «filename»

 I tried to compile mplayer2 from the debian git but no change. Moreover
 I tried mpv which works fine on the same file, although it's using the
 same versions of libav.

well, the matroska decoders in mpv and mplayer2 stem from a common
source, yet are quite different:

http://sources.debian.net/src/mpv/0.5.1-1/demux/demux_mkv.c
http://sources.debian.net/src/mplayer2/2.0-728-g2c378c7-2/libmpdemux/demux_mkv.c

Uoti, any clue what's going on here?

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer michae...@gmx.at wrote:
 Hi Reinhard

 On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote:
 On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote:
  On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
  On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at 
  wrote:
   On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
   Hi,
  
   as discussed in IRC, I was trying to minimal-invasively port
   libpostproc (the Debian source package) to x32¹. I could not
   test it (for lack of a stand-alone test program) yet, but at
   least I got it to build.
  
   you could try to test by buiding ffmpeg as a whole but disable asm
   everywhere except libpostproc
   that might allow easy testing though fate or ffmpeg with libavfilter
 
  Is http://git.videolan.org/?p=libpostproc.git still maintained?
 
  AFAIK, no, it seems the last commit is 2 years ago
 
 
 
  The Debian package tracks that repository, and ideally we could
  collect the postproc patches there.
 
  libpostproc was and is maintained in
  git://source.ffmpeg.org/ffmpeg.git

 So the promise given in
 https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
 doesn't hold anymore?

 Can you be a bit more specific ? what promise by whom exactly do
 you speak of ?


The promise of having a maintained stand-alone libpostproc.


 Any chance to make you reconsider reviving the standalone libpostproc.git?

 From what i remember there where some problems with that repository
 so actually maintaining it would probably imply first recreating it

 for example try to build a old revission:

 git checkout a792a836e3d9ef6f1f311604b38095e587282ca7
 (this is libpostproc/master~20 ATM)
 ./configure
 -bash: ./configure: No such file or directory

 this is a problem for anyone maintaining the code as for example
 git bisect
 would not be usable at all

 or if you do a git show
 commit a792a836e3d9ef6f1f311604b38095e587282ca7
 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c

 Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6
 ancestors

 So really, if someone wants to maintain or use libpostproc.git, first
 these things need to be fixed

 but i dont understand why you dont just take libpostproc
 from where its developed, tested and used ?

 but if it helps i guess we could copy the libpostproc from FFmpeg
 over the one in libpostproc.git (which is what reimar suggested)
 libpostproc.git was only intended to be a copy of FFmpeg with libs
 other than libpostproc removed anyway.

 Would this help you ?

At the end of the day, I need a source tarball that contains
maintained sources of a stand-alone libpostproc. I don't care too much
how it is created, as long as it doesn't result in code-duplication
with existing sources in Debian.


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer michae...@gmx.at wrote:
 At the end of the day, I need a source tarball that contains
 maintained sources of a stand-alone libpostproc. I don't care too much
 how it is created, as long as it doesn't result in code-duplication
 with existing sources in Debian.

 would it work if libpostproc could be build and installed
 standalone from ffmpeg git / ffmpeg release tarballs?

That would be exactly the code-duplication I referred to in the text
you've quoted.

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote:
 On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
 Hi,

 as discussed in IRC, I was trying to minimal-invasively port
 libpostproc (the Debian source package) to x32¹. I could not
 test it (for lack of a stand-alone test program) yet, but at
 least I got it to build.

 you could try to test by buiding ffmpeg as a whole but disable asm
 everywhere except libpostproc
 that might allow easy testing though fate or ffmpeg with libavfilter

Is http://git.videolan.org/?p=libpostproc.git still maintained?

The Debian package tracks that repository, and ideally we could
collect the postproc patches there.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [FFmpeg-devel] patch for x32 for libpostproc

[Reinhard Tartler]

On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote:
 On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote:
 On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote:
  On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote:
  Hi,
 
  as discussed in IRC, I was trying to minimal-invasively port
  libpostproc (the Debian source package) to x32¹. I could not
  test it (for lack of a stand-alone test program) yet, but at
  least I got it to build.
 
  you could try to test by buiding ffmpeg as a whole but disable asm
  everywhere except libpostproc
  that might allow easy testing though fate or ffmpeg with libavfilter

 Is http://git.videolan.org/?p=libpostproc.git still maintained?

 AFAIK, no, it seems the last commit is 2 years ago



 The Debian package tracks that repository, and ideally we could
 collect the postproc patches there.

 libpostproc was and is maintained in
 git://source.ffmpeg.org/ffmpeg.git

So the promise given in
https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
doesn't hold anymore?

Any chance to make you reconsider reviving the standalone libpostproc.git?

 please use that for the debian package

I fear that's not feasible at this point.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#758543: fixed in libdvdnav 5.0.1-1

[Reinhard Tartler]

On Sun, Aug 31, 2014 at 6:38 AM, Fufu Fang fangfufu2...@gmail.com wrote:
 Dear Maintainer,
 The problem is still there. I have upgraded to 5.0.1-1, I still can't run
 mplayer. The error message is still the same. I checked the file list
 (https://packages.debian.org/sid/amd64/libdvdnav4/filelist),
 libdvdnavmini.so.4 is not in the file list.

What exact version of the mplayer package do you have installed?

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#759866: Please package version 5.0.1

[Reinhard Tartler]

Package: libdvdnav

21:23 j-b and I did a libdvdnav 5.0.1 to fix a crash
21:26 j-b 
https://mailman.videolan.org/pipermail/libdvdnav-devel/2014-August/000222.html

[libdvdnav] [branch: refs/tags/5.0.1]
Tag:916101a1ec4b50d929cb1fd5729764f4b1a1657e
 http://git.videolan.org/gitweb.cgi/libdvdnav.git?a=tag;h=916101a1ec4b50d929cb1fd5729764f4b1a1657e

Tagger: Jean-Baptiste Kempf jb at videolan.org
Date:   Thu Aug 28 08:58:34 2014 +0200

libdvdnav 5.0.1

This release is a minor release of libdvdnav, fixing important bugs
present in 5.0.0.

The important fixes include double-free in dvdnav_free_dup, integer overflow,
data race condition and improved compatibility with some DVDs.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#759866: Please package version 5.0.1

[Reinhard Tartler]

On Sat, Aug 30, 2014 at 3:28 PM, Reinhard Tartler siret...@gmail.com wrote:
 Package: libdvdnav

 21:23 j-b and I did a libdvdnav 5.0.1 to fix a crash
 21:26 j-b 
 https://mailman.videolan.org/pipermail/libdvdnav-devel/2014-August/000222.html

 [libdvdnav] [branch: refs/tags/5.0.1]
 Tag:916101a1ec4b50d929cb1fd5729764f4b1a1657e
 http://git.videolan.org/gitweb.cgi/libdvdnav.git?a=tag;h=916101a1ec4b50d929cb1fd5729764f4b1a1657e

 Tagger: Jean-Baptiste Kempf jb at videolan.org
 Date:   Thu Aug 28 08:58:34 2014 +0200

 libdvdnav 5.0.1

 This release is a minor release of libdvdnav, fixing important bugs
 present in 5.0.0.

 The important fixes include double-free in dvdnav_free_dup, integer overflow,
 data race condition and improved compatibility with some DVDs.

J-B,

any chance that this new release fixes any bug listed at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libdvdnav or
https://launchpad.net/ubuntu/+source/libdvdnav/+bugs ?

Thanks a lot for the new release and letting us know about it!

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Aug 27, 2014 10:43 AM, Fabian Greffrath fab...@greffrath.com wrote:

 Am Mittwoch, den 27.08.2014, 09:52 +0200 schrieb Matteo F. Vescovi:
  Libav for me, of course.

 I am for libav for the next stable release. However, I am open for
 anything else after that. To be honest, I recently find the sheer number
 of my bug instantly vanished once I replaced libav with ffmpeg reports
 a bit emberrassing.

Did you check how many of those bugs are fixed in a later libav upstream
release? Note that even the current libav release frequency is tough for
Debian, even faster releases won't make integration any easier.

  I've spent too much time on getting it working fine with Blender
  that it'd be crazy to change it now. ;-)

 Then Bálint must clearly be crazy to do all the porting work the other
 way round for XBMC. ;)

Xbmc works best with its embedded copy of FFmpeg. I predict similar
problems with an outdated system copy of FFmpeg.  The time spent in fixing
that does not seem significantly smaller than fixing bugs in libav.

Best Reinhard
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#757917: transition: libav11

[Reinhard Tartler]

On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort
po...@debian.org wrote:
 On 18/08/14 21:33, Andrew Kelley wrote:
 On Aug 18, 2014 12:22 PM, Emilio Pozuelo Monfort po...@debian.org wrote:

 I want to get perl in first. Ping me again when that happens if I haven't
 replied.

 Pardon my ignorance but why can't those both happen at the same time?

 https://release.debian.org/transitions/html/auto-libav.html

 Collisions:
 xmms2 → perl5.20

Now with perl in testing, are we good to proceed with me uploading
libav11 to unstable?

Best,
Reinhard


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#757917: transition: libav11

[Reinhard Tartler]

On Tue, Aug 26, 2014 at 4:29 PM, Emilio Pozuelo Monfort
po...@debian.org wrote:
 On 26/08/14 16:05, Reinhard Tartler wrote:
 On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort
 po...@debian.org wrote:
 On 18/08/14 21:33, Andrew Kelley wrote:
 On Aug 18, 2014 12:22 PM, Emilio Pozuelo Monfort po...@debian.org 
 wrote:

 I want to get perl in first. Ping me again when that happens if I haven't
 replied.

 Pardon my ignorance but why can't those both happen at the same time?

 https://release.debian.org/transitions/html/auto-libav.html

 Collisions:
 xmms2 → perl5.20

 Now with perl in testing, are we good to proceed with me uploading
 libav11 to unstable?

 I got lost with all the small partial updates. Can you give a summary of how
 things are standing? i.e. what can be binnmued, what FTBFS...

AFAIUI, everything can be binnmu'ed right now.

 Also vlc needs fixing.

A fixed VLC entered unstable today fixes that.

As noted on irc, it turns out that vlc FTBFS on mips. I'm sure we'll
be able to find a solution for that during the transition, though.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

[Reinhard Tartler]

On Tue, Aug 26, 2014 at 6:36 PM, Benjamin Drung bdr...@debian.org wrote:
 Hi,

 there was a discussion on the debian-devel mailing list about
 reintroducing FFmpeg to Debian [1]. The security team made clear [2]
 that they will only support one provider of the libav* libraries. So
 either libav or FFmpeg could go in the release and the other library has
 to stay in experimental (or unstable with a RC bug). The maintainer of
 libav is the Debian Multimedia team and therefore it is up to us to
 decide whether we want libav or FFmpeg in Debian 8 (jessie).

 So I am asking you: Should we ship libav or FFmpeg?

Libav, see my previous emails that I posted on this mailing list on
this topic for rationale.

 Can we reach a consensus on this topic?

So far I don't see disagreement on this within our team.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#759199: mencoder: depends on libdvdnavmini.so.4 which is not found

[Reinhard Tartler]

On Mon, Aug 25, 2014 at 9:21 AM, Stuart Prescott stu...@debian.org wrote:
 Control: reassign -1 libdvdnav4
 Control: forcemerge 758543 -1

 Hi Marco,

 thanks for your report -- unfortunately mencoder is not available for sid at
 all as it has been removed from the archive. The package you have been using
 is left over from wheezy. At best, we should be making other package
 dependencies such that the old mencoder package you had is removed from your
 system by apt as part of a dist-upgrade.

 If you are looking for alternatives to mencoder, then the avconv utility
 from the libav-tools package is probably the best place to start.

 regards
 Stuart

 (libdvdnav4 maintainers: should this have been a soname change? or some other
 conflict to force users of libdvdnavmini to be removed?)

I don't think that a version bump would have fixed that. libdvdnavmini
should have never been in the libdvdnav4 binary package, and in fact,
it has now been removed in the current upstream release. AFAIUI,
mplayer/mencoder is also the only application that used libdvdnavmini
(for not entirly convincing reasons).

If libdvdnavmini was used by lots of packages in Debian, we might
argue that we should have renamed the package to make this an explicit
transition. However, mplayer was the only affected package, so I'm not
sure what's left to do here.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#759199: mencoder: depends on libdvdnavmini.so.4 which is not found

[Reinhard Tartler]

On Mon, Aug 25, 2014 at 7:45 PM, Stuart Prescott stu...@debian.org wrote:

 How about adding to libdvdnav4:

 Breaks: mplayer ( 2:1.0), mencoder ( 2:1.0)

 it tells apt that the packages are broken by the new libdvdnav4 package and
 apt will act accordingly. The version restriction is there on the probably
 mistaken belief that there's no point in forcing these packages off the system
 if they come from a source other than Debian such as one that is well known to
 use epochs to ensure that its packages sort higher.

That sounds like a good idea to me, let's get this change into jessie
to help with the upgrade process.

Can you implement this change in git?

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: git-packaging workflows

[Reinhard Tartler]

On Fri, Aug 22, 2014 at 11:08 AM, Felipe Sateler fsate...@debian.org wrote:
 Resurrecting an old thread

 On Sat, Apr 6, 2013 at 4:32 AM, Reinhard Tartler siret...@gmail.com wrote:
 Hi,

 Recently, Russ' blog post was echoed on http://planet.debian.org:

 http://www.eyrie.org/~eagle/journal/2013-04/001.html

 In that post, he describes how to combine both the import tarball
 and the have upstream history available in the upstream packaging
 branch. AFAIUI, the heavy work is implemented in git-buildpackage's
 --upstream-vcs-tag tag option.

 While that option is news to me, I wonder if maybe anyone else already
 experiments with this? Does the team feel that making it mandatory for
 our package would be beneficial and appropriate?

 I know some in the team have experimented with this new workflow.
 Could you share your experiences with it? I'm thinking that we should
 encourage this workflow a bit more: it makes collaboration with
 upstream easier (in both directions). However I'm still not too clear
 on what would it look like, so I'd like to hear from people that have
 been using it about their thoughts.

I've been using that for libav, and am comfortable with it. The
caveats that I've found so far:

1. you need to manually add a named remote (git remote add upstream
«upstream_git_url»  git remote update upstream)
2. you need to identify the upstream tag and must not forget to pass
it to git-import-orig --upstream-vcs-tag

The first one could be scripted, I guess.


 Questions of interest: are you using gbp pq? If not, how do you pick
 patches from upstream? How do you post patches back to upstream?

 I do think we need to somehow restrict the commits that get posted on
 the commit list. Sometimes we get a mailbomb of new commits... :p

Yes, that's the third caveat. I promised at some point to have a look
at the mail hook, but didn't find the time. Sorry

Best,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: vlc/vlc-nox distinction

[Reinhard Tartler]

On Mon, Aug 18, 2014 at 8:13 PM, Sebastian Ramacher
sramac...@debian.org wrote:
 (Dropping J-B from CC. I think this is purely Debian related now.)

 On 2014-08-18 22:37:42, Sebastian Ramacher wrote:
 On 2014-08-17 23:22:02, Jean-Baptiste Kempf wrote:
  On 16 Aug, Reinhard Tartler wrote :
   I believe that upstream doesn't care that much about this, because
 
  I remember the idea.
 
  Basically, the idea was to split so that servers using VLC to do
  streaming wouldn't need libX11 and all the rest.
 
   otherwise I'd expect the Makefiles to be a bit more helpful with
   determining this. J-B, I'd like you to confirm if I'm right here.
 
  This idea indeed failed, because libavcodec, one of the main codec
  library, can depend on vdpau/vaapi, and both of those acceleration
  libraries thought it was cool to use libX11...
  Therefore, a vlc-noX wouldn't have avcodec plugin...
 
  Some other distributions split the VLC free-stack (Xiph formats)
  from the rest, for patent reasons.
 
  For 3rd party programs using libvlc, an idea was to do a vlc-plugins
  splitted from vlc, so that they don't get libQt in.
  So, something like:
   - libvlccore
   - libvlc
   - vlc-core-plugins
   - vlc

 I'll see if I can come up with something here and prototype a possible
 split. As soon as I've got something, I'll post a link to a branch.

 I've pushed a work-in-progress feature/vlc-plugins branch [1]. vlc-nox
 has been left alive. Looking at the popcon data there seems to be
 interest in the package (vlc: 51349 installs vs. vlc-nox: 53687
 installs).

The problem I initially experienced was how to come up with commits
such as 
http://anonscm.debian.org/cgit/pkg-multimedia/vlc.git/commit/?h=feature/vlc-pluginsid=3909306d196dff05726cf3c800fa62bf2f8e7ad8
without spending hours trying to figure out what renames, additions
and removals of vlc plugins happend upstream. I started with a hit and
miss, but after 5 recompilations of VLC *sic* I got tired of failing
builds at package assembly time and started to grep and diff
buildlogs. I am therefore wondering if that effort is really worth the
trouble. I seems that you think it is. OK. Maybe I can come up with
scripts to grep  the build logs to streamline this process.

 I've done the following instead:

  - Improved the check if plugins in vlc-nox link against libX11 or
libxcb.

http://anonscm.debian.org/cgit/pkg-multimedia/vlc.git/commit/?h=feature/vlc-pluginsid=318ef48b70b3cb2d2f85755766418eb97f7bf5a8

Awesome, that makes very much sense to me!

  - Moved the RDP plugin to vlc as it is linked to libX11 via
libfreerdp1.

Yes.

  - Killed vlc-plugin-pulse and moved the PulseAudio plugins to vlc.
Xfce, KDE and Gnome all pull in libpulse0 anyway, so I think there is
no need for the split.

I don't have a strong opinion on this. I feel that users might
complain, but we can surely wait for those bug reports to happen (if
they happen)

  - Added vlc-plugin-samba package and moved the Samba plugin there. I
think it makes much more sense to split this from vlc-nox (~50 MiB of
extra dependencies) and it's been requested.

Yikes! - That makes very much sense to me.

 The vlc-plugin-samba and vlc-plugin-pulse changes can be reverted of
 course if they are to controversial. The other changes should make it
 possible to handle the plugin split a bit better for the time being. I
 think it's better to revisit this after the jessie release and get vlc
 ready for the libav transition for now.

 Let me know what you think.

Awesome work, thank you very much!

The only piece that I'm missing is what Fabian mentioned: A more
declarative way to describe what plugin goes to vlc-nox and what to
vlc. See above.

Given that vlc is currently in NEW anyway, I guess uploading to
unstable as 2.2.0~pre2-2 would hurt.

Best,
Reinhard


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#757917: transition: libav11

[Reinhard Tartler]

On Sat, Aug 16, 2014 at 11:24 AM, Reinhard Tartler siret...@gmail.com wrote:

 vlc FAIL (silly configure check fail, will sort out with upstream)

 Turns out to be sligtly more complicated as thought. After
 consultation with j-b (videolan upstream), we decided that we really
 should go with vlc 2.2 for jessie. This, however, requires new
 upstream releases of libdvdread and libdvdnav (j-b blogged on this:
 http://www.jbkempf.com/blog/post/2014/dvdread-dvdnav-and-dvdcss)

 I've uploaded both packages, the next step would be to update vlc to 2.2.

VLC 2.2 pre2 is now uploaded to unstable. Because of a SONAME bump of
libvlccore, it requires going through, but I expect that to be really
trivial.

Now with all packages fixed, are we good to proceed with libav11 in
unstable now?

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: vlc/vlc-nox distinction

[Reinhard Tartler]

On Sun, Aug 17, 2014 at 12:47 AM, Jean-Baptiste Kempf j...@videolan.org wrote:
 Hello,

 On 16 Aug, Reinhard Tartler wrote :
 I'm currently fighting with upgrading to VLC 2.2, and noticed that a
 lot of plugins were shuffled around. I noticed that I'm spending way
 to much time figuring out what plugin should go to vlc and what plugin
 should go to vlc-nox. I wonder if having this split is really worth
 the effort. How would you feel with just dropping vlc-nox and just be
 done with it?

 I believe that upstream doesn't care that much about this, because
 otherwise I'd expect the Makefiles to be a bit more helpful with
 determining this. J-B, I'd like you to confirm if I'm right here.

 I personnaly do not care, and think you could drop those splits.
 If libavcodec depends on X11, having a vlc-noX without libavcodec is of
 limited usage.

Since libavcodec nowadays depends on x11 libraries because of
vaapi/vdpau, I tend to agree, but I am still wondering if we could do
better than throwing everything into a big tarball.

In any  case, I've managed to update the installation lists by diffing
the buildlogs from a 2.1.5 to a 2.2.0-pre1 build, and the resulting
vlc-nox package still doesn't depend on libx11.

However, it turns out that libvlccore dropped some symbols and needs a
SONAME bump: 
https://mailman.videolan.org/pipermail/vlc-devel/2014-August/099358.html.

Once we have a -pre2, we can proceed with uploading to unstable, I guess.

Reinhard

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: vlc/vlc-nox distinction

[Reinhard Tartler]

On Sun, Aug 17, 2014 at 12:28 PM, Mateusz Łukasik mat...@linuxmint.pl wrote:
 +1 to drop vlc-nox, albo I think we should making samba plugin as a separate
 package (#729238) it is pretty unnecessary plugin installation on embedded
 systems.

We need to go through NEW anyway, so now would be a great time for
that. Can you please implement that change in git?

Thanks



-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Bug#757917: transition: libav11

[Reinhard Tartler]

On Wed, Aug 13, 2014 at 9:07 PM, Reinhard Tartler siret...@gmail.com wrote:

 linphone FAIL,

 #758017, NMU uploaded to 5/days

 vlc FAIL (silly configure check fail, will sort out with upstream)

Turns out to be sligtly more complicated as thought. After
consultation with j-b (videolan upstream), we decided that we really
should go with vlc 2.2 for jessie. This, however, requires new
upstream releases of libdvdread and libdvdnav (j-b blogged on this:
http://www.jbkempf.com/blog/post/2014/dvdread-dvdnav-and-dvdcss)

I've uploaded both packages, the next step would be to update vlc to 2.2.


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#737534: vlc: unsafe use of libtar

[Reinhard Tartler]

Control: tag -1 upstream

On Mon, Feb 3, 2014 at 10:08 AM, Raphael Geissert geiss...@debian.org wrote:
 Package: vlc
 Severity: important
 Tags: security

 Hi,

 vlc uses libtar to unpack skins, however, its use on untrusted data
 exposes it to CVE-2013-4420 (#731860).

 Changing the behaviour of libtar appears to be problematic because
 some applications have relied on the, lack of, path sanitation (cf.
 https://lists.feep.net:8080/pipermail/libtar/2013-October/000359.html
 and the follow-ups).
 What appears to be the safe way to handle this issue is making sure
 that libtar is not used on untrusted data without file path validation
 - that would mean that vlc would have to check for every file that is
 about to be extracted that none contains a ../, and something similar
 for symlinks.

 Alternatively, vlc could just use tar(1) to unpack the tarballs, or
 drop support for skins or skins in tarballs.

 What do you think?

 This should probably be forwarded to upstream.

I totally agree.

J-B, do you have any opinion on this issue?

Thanks,
Reinhard

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#755749: vlc: segfault when playing .avi file

[Reinhard Tartler]

Control: tag -1 upstream moreinfo
Control: severity -1 normal

On Tue, Jul 22, 2014 at 6:40 PM, Simon Frei freisi...@gmail.com wrote:
 Package: vlc
 Version: 2.1.4-1+b3
 Severity: important

 Dear Maintainer,

 Playing an .avi file results in seemingly random crashes at non reproducable 
 points. Sometimes there is even no crash while playing a whole file.


That sounds like a race condition with multithreaded decoding.

Can you reproduce this crash with avplay -threads N .../media.avi
(with various values of N)?

Also, this is an issue that needs to be looked at upstream. Please
forward this issue with full backtrace as described at
https://wiki.debian.org/HowToGetABacktrace.

Thanks
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

vlc/vlc-nox distinction

[Reinhard Tartler]

Hi,

I'm currently fighting with upgrading to VLC 2.2, and noticed that a
lot of plugins were shuffled around. I noticed that I'm spending way
to much time figuring out what plugin should go to vlc and what plugin
should go to vlc-nox. I wonder if having this split is really worth
the effort. How would you feel with just dropping vlc-nox and just be
done with it?

I believe that upstream doesn't care that much about this, because
otherwise I'd expect the Makefiles to be a bit more helpful with
determining this. J-B, I'd like you to confirm if I'm right here.

Thanks,

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: vlc/vlc-nox distinction

[Reinhard Tartler]

On Sat, Aug 16, 2014 at 9:28 PM, Reinhard Tartler siret...@gmail.com wrote:
 Hi,

 I'm currently fighting with upgrading to VLC 2.2, and noticed that a
 lot of plugins were shuffled around. I noticed that I'm spending way
 to much time figuring out what plugin should go to vlc and what plugin
 should go to vlc-nox. I wonder if having this split is really worth
 the effort. How would you feel with just dropping vlc-nox and just be
 done with it?

For reference, I've diffed the buildlogs for 2.1.5 and 2.2.0 to see
the difference in installed vlc modules, and have to say, the
situation is quite a mess:


--- 2.1.5.modules.list 2014-08-16 21:56:57.882764474 -0400
+++ 2.2.0.modules.list 2014-08-16 21:57:06.850764890 -0400
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_attachment_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_avio_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_ftp_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_http_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_imem_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_rar_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_sftp_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_smb_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_tcp_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_udp_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libaccess_vdr_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libattachment_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libavio_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libftp_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libhttp_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libimem_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/librar_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libstream_filter_rar_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libsmb_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libtcp_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libudp_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/access/libvdr_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libdirac_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libhwdummy_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libjpeg_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libsubstx3g_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libvaapi_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libvdpau_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libvaapi_drm_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/codec/libvaapi_x11_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/control/libglobalhotkeys_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/control/libxcb_hotkeys_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/demux/libcaf_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/demux/libdirac_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/demux/libdiracsys_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/demux/libhevc_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/misc/libaddonsfsstorage_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/misc/libaddonsvorepository_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/mmx/libi420_rgb_mmx_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/mmx/libi420_yuy2_mmx_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/mmx/libi422_yuy2_mmx_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/packetizer/libpacketizer_hevc_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/sse2/libi420_rgb_sse2_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/sse2/libi420_yuy2_sse2_plugin.so
-/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/sse2/libi422_yuy2_sse2_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/stream_out/libstream_out_stats_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/vdpau/libvdpau_adjust_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/vdpau/libvdpau_avcodec_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/vdpau/libvdpau_chroma_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/vdpau/libvdpau_deinterlace_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/vdpau/libvdpau_display_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/vdpau/libvdpau_sharpen_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/video_chroma/libchain_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/video_chroma/libi420_rgb_mmx_plugin.so
+/«PKGBUILDDIR»/debian/tmp/usr/lib/vlc/plugins/video_chroma/libi420_rgb_sse2_plugin.so

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reinhard Tartler]

On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs matth...@urlichs.de wrote:
 Hi,

 Jean-Yves Avenard:
 Including rename of constants (code enums id for example).

 Another nail in libav's coffin, then.

That's one way to see it. To me, this makes mythtv unsuitable for
inclusion into Debian. Let me explain why:

 IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
 deprecated interfaces around for another release or two.

This is exactly what Libav is doing: The deprecation process for
symbols, APIs, enums, etc. takes *years*, because so many software
packages in Debian and else where use them, and it is so believably
painful to change them. Just have a look at the last two Libav
transitions, and the massive amount of patches it took to get packages
fixed and eventually to get Debian to the new Libav release.

Now enter FFmpeg.

FFmpeg has a significant higher release frequency, (it seems to me
about every 3-4 months), so that you would get a deprecation cycle
that is considerably less than a year. In practice, the deprecation
cycle more or less seems to match Libav's cycle, because at least
right now, FFmpeg  tracks Libav's API. If that were not the case (and
I promise you FFmpeg would stop tracking Libav as soon as it replaces
Libav in Debian), I can almost guarantee [1] you that FFmpeg would
very much prefer to resume to the deprecation cycle the project
before: None, i.e., every piece of software is expected to keep up
with FFmpeg's master branch for reasons Jean-Yves outlines.

[1] at least statements such as
https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html
strongly suggest this (at least if you have followed  the
libavresample/libswresample mess).

 Keeping your own static version is the only reasonable approach.

 That may be OK on Windows. However, a proper Linux distribution is supposed
 to be an integrated whole and not a haphazard collection of programs, each
 bringing along their own copy of core libraries and their own un- or
 semi-fixed security problems.


BTW Jean-Yves outlines an approach that used to be very common on the
past: Pick some particular snapshot of FFmpeg and maintain that in a
downstream project, and expect users to use that because it is too
much effort to keep up with FFmpeg's release frequency. Prominent
examples of projects that did this (and actually, still do) include
xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess
I was talking about in my previous email: dozens of embedded
code-copies that were accepted into the Debian archive.

Over many years, I've spearheaded a significant effort in Debian with
packaging and in upstream with introducing a release culture in FFmpeg
(as release manager) to get to somewhat same release frequencies, so
that downstream projects at least had a chance to agree on common
versions of FFmpeg. At the time of the split, I was worried that this
work would have been in vain. Considering that most active developers
of FFmpeg at that time (which coincidentally supported my approach to
release management and frequency) joined what is now known as Libav, I
continued my work as upstream release manager in Libav, because I
consider Libav as much more suited for Debian than FFmpeg. Today, I
still firmly believe that this was the right move for Debian as a
project.

I do strongly believe that projects that require people to use FFmpeg
actually mean to use their own private fork (cf. the mythtv debacle),
and given the amount of packages in Debian, it would significantly
much more effort to port (or patch as Andreas is phrasing it) them
to some common version of FFmpeg than doing what we are doing now:
Making sure they work with the version of Libav's libavcodec.so
implementation. This thread has shown a couple of examples that
support this argument: Mythtv, but also mplayer that claims to work
with a system libavcodec.so, which is true as long as it matches the
version that is was built against. This is what makes mplayer so hard
to package, and was ultimately the reason why I requested mplayer's
removal (which is more than ironic, given that back then, I fought
with ftp-master for many years to get it included into Debian in the
first place).

On a related note: Most  Libav developers are very tired of the
constant flamewars and defamation attempts that arises from FFmpeg.
Over years, Libav tries to convinced everyone by providing usable
software releases. Nevertheless, this particular debate is very
worrisome: The silence from the Libav camp seems to not to be taken as
consent. Quite the contrary is true.

How to proceed from here? TBH, I'm not sure. Ideally, both projects
would find some common ground and just merge (however that would
technically look like). However, this very debate within Debian shows
that this is unlikely to happen anytime soon: There is way to much
disagreement on very fundamental questions that require agreement
within a free software project, and the hostile and 

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reinhard Tartler]

On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote:
 Hi,

 Andreas Cadhalpun:
 Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It
 has been removed from sid, since it fails to build against Libav, but it
 builds fine against FFmpeg.
 (It uses some of the features only provided by FFmpeg.)

 Yet another reason why solely depending on libav is a bad idea.

 That leaves the question of the official opinion of the libav
 maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org).
 Did none of them write anything in defense of libav, or have I simply
 missed it?

I intended to come up with a more timely full response, but I just
didn't get to it so far.

For now, please refer to http://lwn.net/Articles/607662/,
http://codecs.multimedia.cx/?p=370 (rather old, but still true), and
http://codecs.multimedia.cx/?p=674 (recent update on that matter)

Regarding Marco's argument that libav had few friends, well, let me
point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948
for instance.

 IMHO the best idea at this point would be to toss out libav, and rebuild
 the rdeps with ffmpeg. Now, before it's too late for jessie.

I think that is totally out of question: Uploading FFmpeg to our
archive will break the Debian archive so hard that it will take months
to get everything back to testing, if it works at all.

To the best of my knowledge, there are only two high-profile projects
that play hardball to require FFmpeg: Mplayer and mythtv. Neither of
those do that (again to the best of my knowledge) mainly because of
technical but rather very political reasons. The case of mplayer has
been elaborated extensively in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the
following discussion with Reimar - my conclusion from that is while
technically possible, nobody wants to make mplayer work with Libav -
and that's why it was removed, not because of the FFmpeg dependency).
For Mythtv I can only say that they didn't even bother engaging any
discussion.

(All) other high-profile downstream projects, including VLC or XBMC
(now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may
provide them with extra features, but why on earth would anyone want 3
different implementations of a ProRes encoder (seriously, and FFmpeg
seems to claim to provide security support for each of them), or
support for fringe codecs such as Wing Command 3 (yes, you can decode
the videos from that video game).

There are a number of legitimate requested backports, such as for some
of FFmpeg's additional filters in libavfilter, and similar. All of
them are rather easy to backport, and this is done on a regular basis.
However, with the due diligence and attention such a widely used and
high-profile library requires.

Which brings me to my next point: Release frequency. FFmpeg has an
insane frequency of releases, and still seems to support (at least
providing updates) to all of them, including 0.5 which is currently in
oldstable (needless to say none of these patches made it to
oldstable-security, why is still a mystery to me). The effect of that
is that downstream projects have a hard time to choose what version of
FFmpeg they want to support. This brings effectively back to the
situation I was in when I took over maintenance of the package many
years ago: Back then, Michael Niedermeyer strongly recommended all
downstreams to avoid shared libraries and just link statically against
libavcodec.a to avoid problems regarding incompatible library
versions. I see exactly this problem arising again: Both mythtv and
mplayer upstream (btw, xbmc as well) bundle some copy of ffmpeg in
their sources and recommend everyone to just use the internal copy to
avoid problems.

Needless to say that this is not acceptable for use in Debian.

Yes, I agree that this situation is a mess. A big mess. My fear is
that switching to FFmpeg will bring us back to the mess we where 8
years ago, and I worked on for years.

Libav is far from being perfect. That's true. I don't know why exactly
FFmpeg seems to have more manpower, but it's not all black or white.
For instance, there are a number of developers that actively
contribute to both projects and are essential in keeping both projects
in good health. Also I don't really buy the security argument. True,
FFmpeg has more security updates, but backporting them to Libav turned
out to be difficult because many if not most of them turn out to be
either incomplete, invalid or require further clarification. Libav
developers prefer to go the unpleasant road of fully understanding the
issue, which takes extra time. For all these reasons, I do not see the
necessity to do any drastic and dangerous steps right now.


I now seriously wonder if the last 45 minutes in which I wrote this
email wouldn't have been better spent with preparing the next upload
for stable-security. YMMV.


-- 
regards,
Reinhard

Bug#756648: Fwd: Bug#756648: mplayer2: add support for ppc64el

[Reinhard Tartler]

Control: forwarded -1 u...@mplayer2.org
Control: tag -1 upstream

Hi Uoti,

The proposed patch (attached to this email) makes sense to me for
inclusion into your mplayer2.git. Can you incorporate it?

Thanks,
Reinhard

-- Forwarded message --
From: Breno Leitao bren...@br.ibm.com
Date: Thu, Jul 31, 2014 at 2:50 PM
Subject: Bug#756648: mplayer2: add support for ppc64el
To: Debian Bug Tracking System sub...@bugs.debian.org


Package: mplayer2
Version: 2.0-728-g2c378c7-2
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: ppc64el

Dear Maintainer,

Currently mplayer2 doesn't built on ppc64el because this architecture/processor
is not known by the configure script, causing the following failure:

Error: unsupported architecture UNKNOWN
The architecture of your CPU (UNKNOWN) is not supported by
this configure script

It seems nobody has ported MPlayer to your OS or CPU type yet.

Check config.log if you do not understand why it failed.
make[1]: *** [override_dh_auto_configure] Error 1
make[1]: Leaving directory `/«PKGBUILDDIR»'
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

This patch simply add ppc64le as a ppc64 architecture. It enable the package to
be built from source on ppc64el then.

Thank you
Breno

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers


-- 
regards,
Reinhard
Index: mplayer2-2.0-728-g2c378c7/configure
===
--- mplayer2-2.0-728-g2c378c7.orig/configure
+++ mplayer2-2.0-728-g2c378c7/configure
@@ -222,7 +222,7 @@ x86() {
 
 ppc() {
   case $host_arch in
-ppc|ppc64|powerpc|powerpc64) return 0;;
+ppc|ppc64le|ppc64|powerpc|powerpc64) return 0;;
 *) return 1;;
   esac
 }
@@ -1098,6 +1098,7 @@ if test -z $_target ; then
   ia64) host_arch=ia64 ;;
   macppc|ppc) host_arch=ppc ;;
   ppc64) host_arch=ppc64 ;;
+  ppc64le) host_arch=ppc64 ;;
   alpha) host_arch=alpha ;;
   sparc) host_arch=sparc ;;
   sparc64) host_arch=sparc64 ;;
@@ -1764,12 +1765,12 @@ case $host_arch in
 iproc='sh4'
 ;;
 
-  ppc|ppc64|powerpc|powerpc64)
+  ppc|ppc64|ppc64le|powerpc|powerpc64)
 arch='ppc'
 def_fast_unaligned='#define HAVE_FAST_UNALIGNED 1'
 iproc='ppc'
 
-if test $host_arch = ppc64 -o $host_arch = powerpc64 ; then
+if test $host_arch = ppc64 -o $host_arch = ppc64le -o $host_arch = powerpc64 ; then
   subarch='ppc64'
   def_fast_64bit='#define HAVE_FAST_64BIT 1'
 fi
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756174: jackd2 building without any of the required build flags

[Reinhard Tartler]

On Sun, Jul 27, 2014 at 1:54 AM, Steve Langasek
steve.langa...@canonical.com wrote:
 Package: jackd2
 Version: 1.9.10+20140610git97e0e80b~dfsg-1
 Severity: important
 Tags: patch
 User: ubuntu-de...@lists.ubuntu.com
 Usertags: origin-ubuntu utopic ubuntu-patch

 The jackd2 package in Debian unstable does not properly pass dpkg-buildflags
 values to waf.  As a result, the package is built without optimizations
 (-O2), has no debugging symbols available at build time (-g), and doesn't
 use any of the hardening flags that are exported by dpkg-buildflags by
 default on Debian.

 The first two of these are violation of a policy should (10.1), the last
 is bad for the security of the package.

 The attached patch is a minimally-invasive fix for this, which uses
 DEB_MAKE_EXTRA_ARGS to pass the variables to waf.  However, waf is not make,
 so this isn't strictly correct.  There is a waf class in cdbs (available
 since cdbs 0.4.90); I don't know why you're not using it, perhaps you want
 to switch to using that instead.

Jonas, can you take a look at this patch, please?


 I would offer a patch to convert the package to dh(1), but considering the
 contents of the Uploaders field I suspect it would not be accepted.

I'm inclined to agree. I guess the right CDBS philosophy would be to
have waf support in CDBS, so that debian/rules could be significantly
shortened.

Given that this support is not in place, I wonder if CDBS is the best
helper infrastructure for this package.


-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#756174: jackd2 building without any of the required build flags

[Reinhard Tartler]

On Sun, Jul 27, 2014 at 2:08 PM, Jonas Smedegaard d...@jones.dk wrote:
 Quoting Reinhard Tartler (2014-07-27 16:24:11)

 Given that this support is not in place, I wonder if CDBS is the best
 helper infrastructure for this package.

 I don't follow your logic here, Reinhard.  CDBS _does_ have support for
 waf (this package just doesn't make use of that) and (from a brief look)
 it seems to me that short-form dh does _not_ have support for waf, so I
 fail to understand how CDBS should be ditched for this reason.

 Did you perhaps simply misread Steve's email?

Quite likely that's the case. I was not aware of waf.mk, and I
wouldn't have suggested the above if I had known. I have to apologize.

Maybe you could perhaps help with revising the jackd2 packaging to use wak.mk?

Again, sorry for any confusion I might have caused.

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Reinhard Tartler]

On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun
andreas.cadhal...@googlemail.com wrote:

  * Does it make sense for me to switch my package?
The rule of thumb is, if your upstream uses FFmpeg for development
you probably want to switch to using it, too.

In [1], Moritz from the security team clearly stated that he is more
than uncomfortable with having more than one copy of libavcodec in
debian/testing. In consequence this means that any package that builds
against the ffmpeg packages currently in NEW won't make it into
testing either. I am therefore surprised about the given answer to the
question above.

I think it would be best if ftp-master left the ffmpeg package in NEW
until an answer to this problem has been found.

[1] https://lists.debian.org/debian-devel/2014/02/msg00668.html

 The FFmpeg version currently in NEW has been there for more than
 2 months and is thus outdated. If you want to test the current
 packages, you can build them from the repository on Alioth [17]
 (e.g. using git-buildpackage).

 Furthermore, we'd like to move the FFmpeg packaging under the umbrella
 of the pkg-multimedia team, because this would facilitate future FFmpeg
 transitions.

I am curious why this is your first email about this matter to
pkg-multimedia, and why do you write this email only now?

Moreover, I am curious why I haven't seen you working on libavcodec
bugs in Debian before, and why do you believe you can do a better job
with the ffmpeg package currently on NEW?

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#755540: libav: FTBFS on ppc64el architecture

[Reinhard Tartler]

Control: tag -1 -patch +moreinfo

Hi Breno,

On Tue, Jul 22, 2014 at 7:56 AM, Reinhard Tartler siret...@gmail.com wrote:
 On Mon, Jul 21, 2014 at 9:46 PM, Breno Leitao bren...@br.ibm.com wrote:


 I am attaching a patch to disable altivec on ppc64el at the moment.
 Ubuntu is also using the same patch.

 It seems Ubuntu doesn't disable altivec at all:
 https://launchpad.net/ubuntu/+source/libav/6:10.2-2/+build/6199083

 In fact, it seems in ubuntu the package builds with altivec just fine:
 hmm, doesn't Ubuntu has the workaround you provided here?

 https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263802

 A better solution was found upstream:

 http://anonscm.debian.org/cgit/pkg-multimedia/libav.git/commit/?h=upstreamid=0ec75a04e5fc714bc3cd6e2a6b783e6df834ad01

 This was part of libav 10.2, which was uploaded to Debian first, and
 then copied over to Ubuntu. This is why I'm so confused that you are
 experiencing this problem in Debian, but claim the problem was fixed
 in Ubuntu.

 Can you please recheck that you are in fact trying to use Libav 10.2
 and not 10.1, and clarify what's going on?

 Note that upstream was not 100% sure if that is the right fix, as we
 lack the hardware to test this properly. Feedback to
 libav-de...@libav.org on the patch is very welcome.

Any news  on this?

TBH, I don't believe that there is anything to do for this in the
Debian package, but before closing this bugreport, I'd like to hear a
word from you first.

Thanks!

-- 
regards,
Reinhard

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers