Bug#851490: ITA: virglrenderer -- virtual GPU for KVM virtualization

[Andreas Cadhalpun]

Control: retitle -1 ITA: virglrenderer -- virtual GPU for KVM virtualization

On 15.01.2017 16:10, Daniel Pocock wrote:
> For virgl support in qemu
> 
> slides:
> 
> http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
> 
> http://www.linux-kvm.org/images/3/36/Kvm-forum-2013-virgilpres.pdf
> 
> Upstream:
> 
> https://virgil3d.github.io/
> 
> This is a package worth retaining in Debian, but I personally haven't
> had the time to update it in over 6 months and it would be better for
> somebody who has time to follow upstream releases and test against qemu,
> maybe somebody from the pkg-qemu-de...@lists.alioth.debian.org team.

I'd like to adopt this package.
Is the pkg-qemu team interested in co-maintenance?

Best regards,
Andreas

Bug#855230: RM: virglrenderer -- RoQA; many security bugs, orphaned without new maintainer

[Andreas Cadhalpun]

Hi,

On 15.02.2017 19:48, Salvatore Bonaccorso wrote:
> virglrenderer was orphaned, since qemu, one of the consumers reverted
> the corresponding support. virglrenderer is collecting an increasing
> amount of security issues detected, cf. [1].
> 
> Please remove virglrenderer from the archive. It can be included in a
> later stage again once it has an active maintainer and virglrenderer
> going to stabilize more.

Please don't remove virglrenderer, since it's planned to re-enable
the virgl support in qemu for buster [2]. Removing it now, just to
add it back again soon seems quite pointless.
All the known security issues are fixed upstream with the 0.6.0 release.

Best regards,
Andreas

2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813658#184

Bug#855095: gcc-6: [hppa] regression: trivial program segfaults

[Andreas Cadhalpun]

Control: retitle -1 binutils: [hppa] regression: trivial program segfaults
Control: reassign -1 binutils 2.27.90.20170205-1

Hi,

On 14.02.2017 02:11, John David Anglin wrote:
> On 2017-02-13, at 7:44 PM, Andreas Cadhalpun wrote:
>> It looks like gcc miscompiles the most trivial program, so that it segfaults 
>> when run,
>> but gcc-6 6.3.0-3 worked fine three weeks ago [2].
> 
> Essentially, the problem is caused by the switch to using hardening options.  
> The problem isn't gcc.  It's
> binutils and possibly glibc.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=21132
> https://sourceware.org/bugzilla/show_bug.cgi?id=21000
> https://sourceware.org/bugzilla/show_bug.cgi?id=21131
> 
> Until these issues are resolved, the hardening options aren't going to work 
> on hppa.

OK, then let's reassign this to binutils. The problem was probably triggered by:
binutils (2.27.90.20170205-1) unstable; urgency=medium
[...]
- Fix PR ld/21000, support -z relro on hppa. Other hppa updates.
[...]
 -- Matthias Klose <d...@debian.org>  Sun, 05 Feb 2017 21:05:07 +0100

Best regards,
Andreas

Bug#855095: gcc-6: [hppa] regression: trivial program segfaults

[Andreas Cadhalpun]

Package: gcc-6
Version: 6.3.0-6
Severity: important
Control: affects -1 ffmpeg
X-Debbugs-Cc: debian-h...@lists.debian.org

Dear Maintainer,

ffmpeg 7:3.2.4-1 failed to build on hppa, because configure's C compiler test 
failed [1]:
BEGIN /tmp/ffconf.JlfWXo0F.c
1   int main(void){ return 0; }
END /tmp/ffconf.JlfWXo0F.c
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
-O2 -fdebug-prefix-map=/<>=. -Wformat -Werror=format-security 
-fno-strict-overflow -fstack-protector-all -fPIE -c -o /tmp/ffconf.vzRvJxAo.o 
/tmp/ffconf.JlfWXo0F.c
cc1: warning: -fstack-protector not supported for this target
gcc -Wl,-z,relro -Wl,-z,now -fPIE -pie -o /tmp/ffconf.lZtBYrZt 
/tmp/ffconf.vzRvJxAo.o
Segmentation fault

It looks like gcc miscompiles the most trivial program, so that it segfaults 
when run,
but gcc-6 6.3.0-3 worked fine three weeks ago [2].

Best regards,
Andreas


1: 
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=hppa=7%3A3.2.4-1=1486914964=0
2: 
https://buildd.debian.org/status/fetch.php?pkg=ffmpeg=hppa=7%3A3.2.2-2=1485133476=0

Bug#840823: execnet test failures

[Andreas Cadhalpun]

Control: tags -1 patch

Hi,

On 08.01.2017 18:27, Rebecca N. Palmer wrote:
> (I had never heard of this package before your d-d post: I'm looking at it
> because of the number of to-be-autoremoved reverse dependencies)

(Me too.)

> I can't reproduce any of these test failures:
> dpkg-buildpackage -us -uc -A in a sid/amd64 cowbuilder --login chroot
> (build-deps + ccache eatmydata lintian fakeroot) works for me.
> 
> This raises the obvious question of what is different:
> single vs multiple CPU core (this submitter has reported several other
> single-CPU-only FTBFSs [0])?  Network (allowed in cowbuilder, blocked on 
> buildds)?

I think the answer is that you were lucky. ;)
The problem can be reproduced by running:
$ python -m pytest -v -x -rs testing/test_gateway.py

I did that 100 times and it failed 78 times, working only 22 times.

The failing test contains:
for i in range(10):
status = gw.remote_status()
if status.numexecuting == 0:
break
else:
pytest.fail("did not get correct remote status")

Apparently there is a race condition, so it is tried 10 times.
However, it is tried in a tight loop, thus not much time passes
between the first and the last try. Making it sleep inside the
loop helps.

There is a similar construct in test_status_with_threads,
which fails in a similar way, but after changing both to wait
a bit (with attached patch), the test succeeded 100 times
for 100 tries.

That should be good enough to call this bug fixed.

Best regards,
Andreas
--- a/testing/test_gateway.py
+++ b/testing/test_gateway.py
@@ -2,6 +2,7 @@
 mostly functional tests of gateways.
 """
 import os
+import time
 import py
 import pytest
 import execnet
@@ -84,6 +85,7 @@ class TestBasicGateway:
 status = gw.remote_status()
 if status.numexecuting == 0:
 break
+time.sleep(0.1)
 else:
 pytest.fail("did not get correct remote status")
 # race condition
@@ -358,6 +360,7 @@ class TestThreads:
 rstatus = gw.remote_status()
 if rstatus.numexecuting == 0:
 return
+time.sleep(0.1)
 assert 0, "numexecuting didn't drop to zero"
 
 

Bug#851026: ffmpeg: FTBFS: ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'

[Andreas Cadhalpun]

Hi Bálint.

On 22.01.2017 10:48, Bálint Réczey wrote:
> 2017-01-22 0:05 GMT+01:00 Andreas Cadhalpun 
> <andreas.cadhal...@googlemail.com>:
>> The next FFmpeg upstream release will probably not be in time for the freeze,
>> so I've just cherry-picked this patch.
> 
> Thanks!
> 
> I see you have finalized the changelog. Is it ready for upload?

Yes. Sorry for not being clear about that.

Best regards,
Andreas

Bug#851026: ffmpeg: FTBFS: ffconf.bVIjAhhQ.c:2: undefined reference to `dlopen'

[Andreas Cadhalpun]

Hi,

On 19.01.2017 00:05, Bálint Réczey wrote:
> 2017-01-14 23:54 GMT+01:00 Adrian Bunk :
>> No, you should only look at the first compile error in that file:
>>
>> src/libavformat/chromaprint.c:42:24: error: field 'ctx' has incomplete type
>>  ChromaprintContext ctx;
>> ^~~
>> This is the actual error.
>>
>> Whatever the compiler comes up with for cpr->ctx in the place you quoted
>> might be garbage, but at that point it is already game over.
>>
>> Upstream fix:
>>   
>> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=581f93f37ef2e7a00662828ed0348d1edb9041fe
>>
> 
> Is there a new FFmpeg upstream release on the horizon or I should just
> update the package with a cherry-picked patch?

The next FFmpeg upstream release will probably not be in time for the freeze,
so I've just cherry-picked this patch.

Best regards,
Andreas

Bug#849840: libavformat57: enable libopenmpt support

[Andreas Cadhalpun]

Hi James,

On 01.01.2017 02:12, James Cowgill wrote:
> I think that libopenmpt should be enabled in the Debian ffmpeg package.
> libopenmpt-dev is in the archive right now.
> 
> libopenmpt is designed to be a replacement for libmodplug as it handles
> the same types of files. There is an FAQ documenting the differences
> here: https://lib.openmpt.org/libopenmpt/#sec_faq. The major advantage
> is that it has a fairly active upstream compared to libmodplug and
> certain modules play better with it.
> 
> I don't know if libmodplug has to be disabled, but presumably ffmpeg
> will choose one over the other for the vast majority of cases so I'm not
> sure it's worth it having both enabled.

Thanks for filing such a detailed bug report.

I'm all for replacing libmodplug with a better maintained alternative,
however, the ffmpeg libopenmpt demuxer currently has bug causing
head-buffer-overflows in libopenmpt. I expect that the fix [1] will
make it into the next ffmpeg bugfix release, so I intend to switch
to libopenmpt when importing that.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/205182.html

Bug#849484: libavformat57 has circular Depends on libchromaprint1

[Andreas Cadhalpun]

Control: reassign -1 libchromaprint1 1.4.1-1
Control: severity -1 serious

Hi Bill,

On 27.12.2016 19:06, Bill Allombert wrote:
> There is a circular dependency between libavformat57 and libchromaprint1:
> 
> libavformat57 :Depends: libchromaprint1 (>= 1.3.2)
> libchromaprint1   :Depends: libavformat57 (>= 7:3.2.2)
> 
> Circular dependencies involving shared libraries are known to cause problems
> during upgrade between stable releases, so we should try to avoid them.

Thanks for catching that.

Libavformat uses libchromaprint since version 7:3.0-1, while libchromaprint
started linking libavformat only in the last uploaded version 1.4.1-1.
Previously only libchromaprint-tools used libavformat.

While it would be easy to disable chromaprint support in ffmpeg, that
would be a feature regression, so I'd rather not do that.

Hence I'm reassigning this to chromaprint.
As this is not the time in the release cycle to let such issues slip
into testing, I'm raising the severity to serious to prevent testing
migration of the new chromaprint, until this issue is solved.

Now the question is, why did libchromaprint start using libavformat?
Can this functionality be moved to libchromaprint-tools or at least
be disabled?

Best regards,
Andreas

Bug#847819: [performous] update the ffmpeg and continue the issue

[Andreas Cadhalpun]

Hi Fernando,

On 24.12.2016 18:58, ftol...@docksud.com.ar wrote:
> I test in a new machine (no external repos and differnte hardware) and have 
> same issue.
> The graphics freeze and the sound continue. 
> 
> i wait if another people can reproducte it.

I suspect the issue is rather in the graphics stack than in performous itself.

Did this work for you previously?

If so, you could try using older versions of linux/mesa/Xorg/etc. to narrow down
the culprit.

Best regards,
Andreas

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

[Andreas Cadhalpun]

On 22.11.2016 20:35, Andreas Cadhalpun wrote:
> That's fine. I'll also wait with fixing ffmpeg for the next upstream
> bugfix release that is expected soon.
> 
> I've now filed bugs #845361 - #845366 about the other packages.

This is now all done and the fixes migrated to testing.

Thus I've requested the removal of schroedinger (see #848828).

Best regards,
Andreas

Bug#848828: RM: schroedinger -- RoQA; security issues, dead upstream

[Andreas Cadhalpun]

Package: ftp.debian.org
Severity: normal

Dear ftp-masters,

please remove schroedinger from unstable.

It has security issues and is no longer maintained upstream, thus it was
decided to remove it (see #845037).

No reverse-dependencies remain in unstable or testing.

Best regards,
Andreas

Bug#842840: nmu: libavfilter6 reverse-dependencies

[Andreas Cadhalpun]

Hi Emilio,

On 02.11.2016 20:09, Andreas Cadhalpun wrote:
> On 02.11.2016 09:22, Emilio Pozuelo Monfort wrote:
>> Is there a minimum ffmpeg version that is needed here? Wondering if I need to
>> add some dep-wait to this.
> 
> The libavfilter-extra flavor was added in ffmpeg 7:3.1.3-2. A newer version
> is already available on all architectures except sh4, where ffmpeg is 
> currently
> BD-uninstallable.

A few days ago a recent version of ffmpeg was built on sh4, so there should be
no dep-wait needed anymore. Also a few packages were uploaded meanwhile and thus
don't need to be binNMU'ed anymore.

Please schedule the following binNMUs:
nmu ffdiaporama_1.5-5+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu ffmpeg2theora_0.30-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu ffmpegthumbnailer_2.1.1-0.1+b2 . ANY . unstable . -m "rebuild to add 
alternative libavfilter-extra6 dependency"
nmu libgroove_4.3.0-2+b2 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu obs-studio_0.15.4+dfsg1-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu pianobar_2016.06.02-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"

Best regards,
Andreas

Bug#847819: [performous] update the ffmpeg and continue the issue

[Andreas Cadhalpun]

Control: reopen -1
Control: tags -1 moreinfo

Hi Fernando,

On 13.12.2016 15:49, Fernando Toledo wrote:
> Hi i try and update to 3.2 ffmpeg version from sid (remove the old deb
> multimedia packages with purge and install fresh from sid), the issue
> continue
> 
> the debug log do not show nothing when freeze the video
> the only lines relates can be this (when startup performous):
> 
> opengl/error: Shader dancenote: 0:49(14): warning: `lightDir' used
> uninitialized
> 
> and:
> 
> ffmpeg/error: header/lib version mismatch:
> avutil:55.34.100(ff)/55.34.100(ff) avcodec:57.64.100(ff)/57.64.101(ff)
> avformat:57.56.100(ff)/57.56.100(ff) avresample:3.1.0(lav)/3.1.0(lav)
> swscale:4.2.100(ff)/4.2.100(ff)
> 
> i paste the log at end.
> 
> please can you reopen the bug?

I've done that now.

> --- System information. ---
> Architecture: Kernel:   Linux 4.8.0-1-amd64
> 
> Debian Release: stretch/sid
>   500 unstablerepo.huayragnulinux.com.ar   500 testing
> repo.huayra.conectarigualdad.gob.ar   500 testing
> http.debian.net   500 stable  dl.google.com   500 sid
>  linux.dropbox.com   500 huayra-torbellino repo.bbs.docksud.com.ar

You have quite a few external repositories enabled.
Can you reproduce the issue on a fresh installation, e.g. in a virtual machine?

Best regards,
Andreas

Bug#847640: clamav-freshclam: apt-get remove clamav-freshclam leaves clamav-freshclam.service

[Andreas Cadhalpun]

Hi Heinrich,

On 11.12.2016 23:27, Heinrich Schuchardt wrote:
> please, find an installation and removal log below for
> Debian Stretch arm64
> Kernel 4.9-rc8 next-20161209.
> 
> apt-get remove clamav-freshclam creates
> 
> /etc/systemd/system/clamav-freshclam.service
> 
> apt-get purge clamav-freshclam removes it.

Indeed, but this is just a link:
# file /etc/systemd/system/clamav-freshclam.service
/etc/systemd/system/clamav-freshclam.service: symbolic link to /dev/null

This is due to 'deb-systemd-helper mask clamav-freshclam.service >/dev/null',
which dh_systemd_enable adds to the postinst and which should tell systemd
that the service is unavailable.

And looking again at your original report I see:
> systemd[1]: clamav-freshclam.service: Cannot add dependency job, ignoring: 
> Unit clamav-freshclam.service is masked.

That's systemd saying that the service is unavailable.
I think the cause for this log message is that multi-user.target.wants still
contains clamav-freshclam.service.
However all of this is handled by debhelper, so if that's a bug it's in
debhelper, not clamav-freshclam.

Aside from this log message, does it cause any problem?

Best regards,
Andreas

Bug#847640: clamav-freshclam: apt-get remove clamav-freshclam leaves clamav-freshclam.service

[Andreas Cadhalpun]

Control: tags -1 moreinfo unreproducible

Hi Heinrich,

On 10.12.2016 07:27, Heinrich Schuchardt wrote:
> I have uninstalled clamav-freshclam.

Did you use 'apt remove clamav-freshclam' or something else?

> dmesg now shows the following error on boot:
> 
> systemd[1]: clamav-freshclam.service: Cannot add dependency job, ignoring: 
> Unit clamav-freshclam.service is masked.
> 
> Uninstalling freshclam should remove the service definition.

It does that for me.

On 10.12.2016 07:36, Heinrich Schuchardt wrote:
> This is the list of all files clamav-freshclam leaves behind after being
> uninstalled.
> 
> /etc/rc1.d/K01clamav-freshclam
> /etc/rc3.d/K01clamav-freshclam
> /etc/rc2.d/K01clamav-freshclam
> /etc/network/if-up.d/clamav-freshclam-ifupdown
> /etc/network/if-down.d/clamav-freshclam-ifupdown
> /etc/rc0.d/K01clamav-freshclam
> /etc/rc5.d/K01clamav-freshclam
> /etc/clamav/freshclam.conf
> /etc/logcheck/ignore.d.server/clamav-freshclam
> /etc/logrotate.d/clamav-freshclam
> /etc/rc4.d/K01clamav-freshclam
> /etc/rc6.d/K01clamav-freshclam
> /etc/ppp/ip-up.d/clamav-freshclam-ifupdown
> /etc/ppp/ip-down.d/clamav-freshclam-ifupdown
> /etc/systemd/system/multi-user.target.wants/clamav-freshclam.service
> /etc/init.d/clamav-freshclam
> /etc/apparmor.d/local/usr.bin.freshclam
> /etc/apparmor.d/usr.bin.freshclam

These are expected, as they are configuration files.
If you want to remove them, you have to 'apt purge clamav-freshclam'.

> /etc/systemd/system/clamav-freshclam.service

This file doesn't come from the clamav-freshclam package, which ships
the service file in /lib:
$ dpkg -L clamav-freshclam | grep service
/lib/systemd/system/clamav-freshclam.service

Best regards,
Andreas

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

[Andreas Cadhalpun]

On 22.11.2016 10:55, Sebastian Dröge wrote:
> On Mon, 2016-11-21 at 23:46 +0100, Andreas Cadhalpun wrote:
>> I will take care of ffmpeg myself and I assume you will take care of
>> gst-plugins-bad1.0.
> 
> Yeah, will do in the next days! Some other things to handle first

That's fine. I'll also wait with fixing ffmpeg for the next upstream
bugfix release that is expected soon.

I've now filed bugs #845361 - #845366 about the other packages.
(vlc got already fixed before I had the chance to file a bug.)

Best regards,
Andreas

Bug#845365: mplayer: removal of libschroedinger

[Andreas Cadhalpun]

Package: src:mplayer
Version: 2:1.3.0-4
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

libschroedinger was disabled already anyway due to:
Checking for libschroedinger ... no (ffmpeg (static) is required by 
libschroedinger, sorry)

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -57,7 +57,6 @@ Build-Depends:
  libpostproc-dev (>= 7:3.0~),
  libpulse-dev,
  librtmp-dev,
- libschroedinger-dev,
  libsdl1.2-dev,
  libsmbclient-dev [!hurd-any],
  libspeex-dev,

Bug#845364: lives: removal of libschroedinger

[Andreas Cadhalpun]

Package: src:lives
Version: 2.8.0-1
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,6 @@ Build-Depends:
  libogg-dev,
  libpulse-dev,
  libraw1394-dev [linux-any],
- libschroedinger-dev,
  libsdl1.2-dev,
  libswscale-dev,
  libtheora-dev,

Bug#845366: ocaml-schroedinger: removal of libschroedinger

[Andreas Cadhalpun]

Package: src:ocaml-schroedinger
Version: 0.1.0-3
Severity: serious
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Since this package is not useful without libschroedinger, the plan is
to remove it along with that library. This is just an advance notice.

Best regards,
Andreas

Bug#845362: libquicktime: removal of libschroedinger

[Andreas Cadhalpun]

Package: src:libquicktime
Version: 2:1.2.4-8
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,6 @@ Build-Depends:
  libpng-dev,
  libpopt-dev,
  libraw1394-dev [linux-any],
- libschroedinger-dev,
  libsdl1.2-dev,
  libswscale-dev (>= 6:10~),
  libvorbis-dev,

Bug#845363: liquidsoap: removal of libschroedinger

[Andreas Cadhalpun]

Package: src:liquidsoap
Version: 1.1.1-7.1
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on
libschroedinger-ocaml-dev and the liquidsoap-plugin-schroedinger package,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,6 @@ Build-Depends:
  libportaudio-ocaml-dev (>= 0.2.0),
  libpulse-ocaml-dev (>= 0.1.2),
  libsamplerate-ocaml-dev (>= 0.1.2),
- libschroedinger-ocaml-dev (>= 0.1.0-3),
  libsdl-ocaml-dev,
  libshine-ocaml-dev,
  libsoundtouch-ocaml-dev (>= 0.1.7),
@@ -142,7 +141,6 @@ Depends:
  liquidsoap-plugin-portaudio,
  liquidsoap-plugin-pulseaudio,
  liquidsoap-plugin-samplerate,
- liquidsoap-plugin-schroedinger,
  liquidsoap-plugin-sdl,
  liquidsoap-plugin-shine,
  liquidsoap-plugin-soundtouch,
@@ -497,7 +495,7 @@ Description: audio streaming language -- Ogg plugin
  .
  This package provides support for Ogg stream decoding and encoding in
  Liquidsoap. This plugin is only useful when used with one of vorbis,
- speex, flac, theora or schroedinger plugin.
+ speex, flac or theora plugin.
 
 Package: liquidsoap-plugin-opus
 Architecture: any
@@ -587,24 +585,6 @@ Description: audio streaming language -- Samplerate plugin
  This package provides support for audio samplerate conversion using
  libsamplerate in Liquidsoap.
 
-Package: liquidsoap-plugin-schroedinger
-Architecture: any
-Depends:
- liquidsoap (= ${binary:Version}),
- ${misc:Depends},
- ${ocaml:Depends},
- ${shlibs:Depends}
-Description: audio streaming language -- Schroedinger plugin
- Liquidsoap is a powerful tool for building complex audio streaming systems,
- typically targeting internet radios (e.g. icecast streams).
- .
- It consists of a simple script language, in which you can create, combine and
- transform audio sources. Its design makes liquidsoap flexible and easily
- extensible.
- .
- This package provides support ogg/dirac video decoding and encoding using
- libschroedinger in Liquidsoap.
-
 Package: liquidsoap-plugin-sdl
 Architecture: any
 Depends:
--- a/debian/liquidsoap-plugin-schroedinger.install
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib/liquidsoap/*/plugins/schroedinger.cm*
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ DEB_PYTHON2_MODULE_PACKAGES := liguidsoap
 DEFAULT_FONT := /usr/share/fonts/truetype/ttf-liberation/LiberationSans-Regular.ttf
 
 DEB_CONFIGURE_EXTRA_FLAGS := \
-  --enable-ogg-dynamic-plugin --enable-schroedinger-dynamic-plugin --enable-flac-dynamic-plugin \
+  --enable-ogg-dynamic-plugin --enable-flac-dynamic-plugin \
   --enable-speex-dynamic-plugin --enable-vorbis-dynamic-plugin --enable-theora-dynamic-plugin \
   --enable-sdl-dynamic-plugin --enable-gavl-dynamic-plugin --enable-mad-dynamic-plugin \
   --enable-faad-dynamic-plugin --enable-xmlplaylist-dynamic-plugin --enable-lastfm-dynamic-plugin \
@@ -41,7 +41,7 @@ else
 -Nliquidsoap-plugin-ladspa -Nliquidsoap-plugin-lastfm -Nliquidsoap-plugin-mad \
 -Nliquidsoap-plugin-ogg -Nliquidsoap-plugin-oss -Nliquidsoap-plugin-portaudio \
 -Nliquidsoap-plugin-pulseaudio -Nliquidsoap-plugin-samplerate \
--Nliquidsoap-plugin-schroedinger -Nliquidsoap-plugin-soundtouch -Nliquidsoap-plugin-speex \
+-Nliquidsoap-plugin-soundtouch -Nliquidsoap-plugin-speex \
 -Nliquidsoap-plugin-taglib -Nliquidsoap-plugin-theora -Nliquidsoap-plugin-voaacenc \
 -Nliquidsoap-plugin-vorbis -Nliquidsoap-plugin-xmlplaylist -Nliquidsoap-plugin-lame \
 -Nliquidsoap-plugin-dssi -Nliquidsoap-plugin-lo -Nliquidsoap-plugin-camlimages \

Bug#845361: gmerlin-avdecoder: removal of libschroedinger

[Andreas Cadhalpun]

Package: src:gmerlin-avdecoder
Version: 1.2.0~dfsg-7
Severity: serious
Tags: patch
Control: block 845037 by -1

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs and is
no longer maintained upstream. Therefore it has been decided to remove
it from Debian. (see bug #845037)

Before it can be removed, all reverse dependencies have to stop using it.

Attached is a patch dropping the build-dependency on libschroedinger-dev,
which is sufficient to achieve this.

Best regards,
Andreas
--- a/debian/control
+++ b/debian/control
@@ -36,7 +36,6 @@ Build-Depends:
  libmpeg2-4-dev,
  libpng-dev,
  libpostproc-dev,
- libschroedinger-dev,
  libsmbclient-dev,
  libspeex-dev,
  libswscale-dev,

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

[Andreas Cadhalpun]

Hi Sebastian,

On 21.11.2016 08:22, Sebastian Dröge wrote:
> On Sun, 2016-11-20 at 11:57 +0100, Moritz Muehlenhoff wrote:
> 
>>> Thus I think stretch would be better of without this library.
>>>
>>> As replacement, ffmpeg has a decent dirac decoder and also a
>>> vc2 encoder, which is the intra-only subset of dirac that
>>> got standardized by the SMPTE.
>>
>> Andreas, thanks for filing this bug. Fully agreed from my side.
> 
> I tend to agree here.

OK, then it's agreed to remove libschroedinger.

> Note however that VC2 is only a subset of Dirac,
> so we'll definitely lose some (probably unimportant) functionality
> here.

That's true, but I also think that the functionality going to be lost
is rather unimportant.

> Current reverse dependencies are
>  ffmpeg
>  gmerlin-avdecoder
>  gst-plugins-bad1.0
>  libquicktime
>  liquidsoap
>  lives
>  ocaml-schroedinger
>  vlc

There is also mplayer, which has a build-dependency on libschroedinger-dev,
however no run-time dependency due to:
Checking for libschroedinger ... no (ffmpeg (static) is required by 
libschroedinger, sorry)

> Except for the ocaml bindings, this should all be a matter of simply
> disabling the functionality.

Yes. The ocaml bindings have a very low popcon (14), so I think it's
OK to just remove them together with libschroedinger.

I will take care of ffmpeg myself and I assume you will take care of
gst-plugins-bad1.0.
I intend to file bugs for the other packages and block this bug by
them.

Best regards,
Andreas

Bug#845037: libschroedinger-1.0-0: is this package fit for stretch?

[Andreas Cadhalpun]

Package: libschroedinger-1.0-0
Version: 1.0.11-2.1
Severity: serious
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

libschroedinger contains various possibly security relevant bugs
(see #787957 for the tip of the iceberg).

Furthermore it is no longer maintained upstream:
 * last release from 2012
 * homepage vanished

Thus I think stretch would be better of without this library.

As replacement, ffmpeg has a decent dirac decoder and also a
vc2 encoder, which is the intra-only subset of dirac that
got standardized by the SMPTE.

Best regards,
Andreas


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libschroedinger-1.0-0 depends on:
ii  libc6  2.24-5
ii  libgcc11:6.2.0-13
ii  liborc-0.4-0   1:0.4.26-2
ii  libstdc++6 6.2.0-13
ii  multiarch-support  2.24-5

libschroedinger-1.0-0 recommends no packages.

libschroedinger-1.0-0 suggests no packages.

-- no debconf information

Bug#813658: virglrenderer support before the freeze?

[Andreas Cadhalpun]

On 14.11.2016 11:02, Michael Tokarev wrote:
> 10.11.2016 00:00, Andreas Cadhalpun wrote :
>> If you want to use virgl with virt-manager you don't need to enable
>> gtk3 or sdl2, only virglrenderer and opengl.
> 
> This does not help, unfortunately. Yesterday I wrote a quick hack
> to made gtk3 display modular, this works fine.  However, linking
> with virglrenderer brings half of the X/drm stack back again.
> I've no idea how virglrenderer works and why it needs CLIENT
> libs on a display-less program... :(

The only additional dependencies compared to the current
qemu-system-x86 package are:
libdrm2 libepoxy0 libexpat1 libgbm1 libvirglrenderer0
libwayland-client0 libwayland-server0

That doesn't seem excessive to me.

> Anyone know how this is supposed to work or to be used?
> As far as I can see, virglrenderer usage in qemu is "headless",
> as in, it doesn't do actual displaying (when omitting gtk/sdl
> display). Why it needs libwayland, libdrm and various drm-radeon
> and similar? Maybe virglrenderer should be split up into two
> parts, say, headless and headful? :)

I've no idea how it works, but how to use it is described on
various websites, e.g. [1].

>> However, you also need a newer libspice-server-dev (0.13.2).
>> With qemu built that way virgl works fine for virt-manager and
>> even gnome-boxes.
> 
> 0.13 is a beta release, should it be pushed to Debian at this
> time?

I'm aware that it is a development release and I don't know
what that implies for ABI/API stability.
However, I'd be delighted to have qemu supporting virgl over
spice in stretch.

Best regards,
Andreas


1: https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/

Bug#813658: virglrenderer support before the freeze?

[Andreas Cadhalpun]

Hi intrigeri,

On 09.11.2016 17:43, intrigeri wrote:
> Michael Tokarev:
>> I looked at this matter a bit more.  I switched from sdl1 to gtk3
>> and enabled gl and virglrenderer.  It works.
> 
> Thanks a lot for looking into it! I'm interested in this because
> a number of people run Tails in virtual machines, and virt-manager +
> QEMU is our best supported platform so far.

If you want to use virgl with virt-manager you don't need to enable
gtk3 or sdl2, only virglrenderer and opengl.
However, you also need a newer libspice-server-dev (0.13.2).
With qemu built that way virgl works fine for virt-manager and
even gnome-boxes.

Best regards,
Andreas

Bug#843144: #843144 is a problem in ffmpeg

[Andreas Cadhalpun]

Control: tags -1 pending

Hi,

On 05.11.2016 21:51, Nelson A. de Oliveira wrote:
> I am hitting this same issue but from what I could inspect, it's
> something related with ffmpeg (and not vokoscreen)
> 
> For example, directly calling ffmpeg like this, it fails:
> 
> ffmpeg -f x11grab -draw_mouse 1 -framerate 25 -video_size 1920x1080 -i
> :0+0,0  -pix_fmt yuv420p -c:v libx264 -preset veryfast -q:v 1 -s
> 1920x1080 video.mkv
> 
> The above example is basically what vokoscreen is using.
> We can see a lot of frames being dropped.
> 
> When using -report it's possible to see a lot of messages like this:
> 
> =
> cur_dts is invalid (this is harmless if it occurs once at the start per 
> stream)
> [rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
> Clipping frame in rate conversion by 0.08
> cur_dts is invalid (this is harmless if it occurs once at the start per 
> stream)
> [rawvideo @ 0x562345919700] PACKET SIZE: 8294400, STRIDE: 7680
> (...)
> =

This isn't much use for debugging. More informative output is obtained with 
adding
'-loglevel debug -debug_ts':
$ ffmpeg -loglevel debug -debug_ts -f x11grab -i :0.0 -f framecrc -
[...]
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:133464 frame_pts_time:0.133464 
best_effort_ts:133464 best_effort_ts_time:0.133464 keyframe:1 frame_type:1 
time_base:1/100
filter -> pts:4 pts_time:0.133467 exact:3.16 time_base:1001/3
Clipping frame in rate conversion by 0.84
encoder <- type:video frame_pts:4 frame_pts_time:0.133467 time_base:1001/3
encoder -> type:video pkt_pts:4 pkt_pts_time:0.133467 pkt_dts:4 
pkt_dts_time:0.133467
Last message repeated 1 times
muxer <- type:video pkt_pts:4 pkt_pts_time:0.133467 pkt_dts:4 
pkt_dts_time:0.133467 size:1228800
0,  4,  4,1,  1228800, 0x54c249aa

The first 4 frames are encoded correctly.

demuxer -> ist_index:0 type:video next_dts:166830 next_dts_time:0.16683 
next_pts:166830 next_pts_time:0.16683 pkt_pts:0 pkt_pts_time:0 pkt_dts:0 
pkt_dts_time:0 off:0 off_time:0
demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:0 pkt_pts_time:0 pkt_dts:0 
pkt_dts_time:0 off:0 off_time:0

But then for some reason pts is suddenly 0 again, causing all following frames
to be dropped.

[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:0 frame_pts_time:0 best_effort_ts:0 
best_effort_ts_time:0 keyframe:1 frame_type:1 time_base:1/100
filter -> pts:0 pts_time:0 exact:-0.08 time_base:1001/3
demuxer -> ist_index:0 type:video next_dts:1 next_dts_time:1e-06 next_pts:1 
next_pts_time:1e-06 pkt_pts:1 pkt_pts_time:1e-06 pkt_dts:1 pkt_dts_time:1e-06 
off:0 off_time:0
demuxer+ffmpeg -> ist_index:0 type:video pkt_pts:1 pkt_pts_time:1e-06 pkt_dts:1 
pkt_dts_time:1e-06 off:0 off_time:0
[rawvideo @ 0x5619d3ef17c0] PACKET SIZE: 1228800, STRIDE: 2560
decoder -> ist_index:0 type:video frame_pts:1 frame_pts_time:1e-06 
best_effort_ts:1 best_effort_ts_time:1e-06 keyframe:1 frame_type:1 
time_base:1/100
filter -> pts:0 pts_time:0 exact:0.38 time_base:1001/3
*** dropping frame 5 from stream 0 at ts 0

> While this work:
> 
> ffmpeg -f x11grab -draw_mouse 1 -r 25 -s 1920x1080 -i :0.0+0 -vcodec
> libx264 video.mkv

Using the '-r' option here is at most a work-around, as it simply tells ffmpeg
to ignore the timestamps from the input stream and assume a constant frame rate.

> Tested with ffmpeg 7:3.1.5-1 and latest 7:3.2-2.
> I am unsure if this could be a problem with some lib that ffmpeg uses
> (and I don't know how to test this)

The actual problem is a missing build-dependency on libxcb-shm0-dev, which
used to be pulled in via libopencv-dev (which also pulled in 170 MB of
unnecessary other dependencies).

It seems to me that it should fail so weirdly without libxcb-shm enabled,
but since simply adding this build-dependency is enough to fix it, I'm
not really interested in debugging this further.
If someone wants to look deeper into this, configuring ffmpeg with
'--enable-libxcb --disable-lixcb-shm' should make the problem easy to
reproduce.

Anyway, the next Debian upload will have the build-dependency added,
so tagging this bug as pending.

Best regards,
Andreas

Bug#831591: ffmpeg: kodi crash

[Andreas Cadhalpun]

Hi Bálint,

On 03.11.2016 13:00, Bálint Réczey wrote:
> 2016-11-03 12:54 GMT+01:00 Balint Reczey :
>> Thank you for the triaging and extensive description of the problem.
>> I have now forwarded the patch to upstream under your name since I did
>> not really add anything to the patch.

The patch looks good, thanks for forwarding it upstream. (Even though
one of the upstream developers has some peculiar ideas about correct
code.)

> If someone having the test file could test latest kodi in unstable
> that  would be geat.

There is a test file[1] in one of the merged bugs.
However, testing the latest kodi in unstable is of limited use, since
it was built against the same ffmpeg version currently in unstable.

If you want to verify that the problem is fixed, you'd have to recompile
kodi against 3.0.1 and test it with the current ffmpeg libraries (or
the ones from 3.1.1).

Best regards,
Andreas


1: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=832364;filename=test2.ts.gz;msg=67

Bug#842840: nmu: libavfilter6 reverse-dependencies

[Andreas Cadhalpun]

Hi Emilio,

On 02.11.2016 09:22, Emilio Pozuelo Monfort wrote:
> Is there a minimum ffmpeg version that is needed here? Wondering if I need to
> add some dep-wait to this.

The libavfilter-extra flavor was added in ffmpeg 7:3.1.3-2. A newer version
is already available on all architectures except sh4, where ffmpeg is currently
BD-uninstallable.

Best regards,
Andreas

Bug#842840: nmu: libavfilter6 reverse-dependencies

[Andreas Cadhalpun]

Control: retitle -1 nmu: libavfilter6 reverse-dependencies
Control: severity -1 normal
Control: tags -1 - moreinfo
Control: reassign -1 release.debian.org

Hi,

On 01.11.2016 20:56, Jonas Smedegaard wrote:
> Quoting Andreas Cadhalpun (2016-11-01 19:21:50)
>> So the effective conflict between libavfilter6 and libavfilter-extra6 
>> can and should be solved by rebuilding all packages depending solely 
>> on libavfilter6.
> 
> Right.
> 
> Seems to be these:
> 
>  * ffdiaporama
>  * ffmpeg2theora
>  * forked-daapd
>  * gstreamer1.0-libav
>  * kodi-bin
>  * libffmpegthumbnailer4v5
>  * libgroove4
>  * libmlt6
>  * obs-plugins
>  * pianobar

This list looks correct, thanks.

>> Aside from this one-time problem, are there any benefits of the 
>> approach to use versioned provides?
> 
> Not sure.  I have not yet explored that.

OK, I think the current shlibs method is good enough.
Thus I'm reassigning this bug to the release team.

Dear release team, please schedule the following binNMUs so that
these packages gain an alternative libavfilter-extra6 dependency
in order to become co-installable with it:
nmu ffdiaporama_1.5-5+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu ffmpeg2theora_0.30-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu forked-daapd_24.1-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu gst-libav1.0_1.10.0-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu kodi_16.1+dfsg1-2+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu ffmpegthumbnailer_2.1.1-0.1+b2 . ANY . unstable . -m "rebuild to add 
alternative libavfilter-extra6 dependency"
nmu libgroove_4.3.0-2+b2 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu mlt_6.2.0-1+b1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu obs-studio_0.15.4+dfsg1-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"
nmu pianobar_2016.06.02-1 . ANY . unstable . -m "rebuild to add alternative 
libavfilter-extra6 dependency"

Best regards,
Andreas

Bug#842840: libavfilter-extra6: should provide libavfilter6

[Andreas Cadhalpun]

Control: tags -1 moreinfo

Hi Jonas,

On 01.11.2016 17:52, Jonas Smedegaard wrote:
> libavfilter-extra6 is a superset of libavfilter6, and should therefore
> declare that it "Provides: libavfilter6" to not effectively conflict
> with all consumers of libavfilter6.

That wouldn't help, because the dependencies on libavfilter6 are versioned.
So it would have to be generated dynamically, e.g.:
"Provides: libavfilter6 (= $(DEB_VERSION))"

I'd rather avoid that complexity.

However, currently this is implemented differently (also for libavcodec-extra).
Packages depending on libavfilter6 should depend alternatively on the extra
flavor e.g.:
"Depends: libavfilter6 (>= 7:3.1.5) | libavfilter-extra6 (>= 7:3.1.5)"

This is done automatically via shlibs.

So the effective conflict between libavfilter6 and libavfilter-extra6 can
and should be solved by rebuilding all packages depending solely on
libavfilter6.

Aside from this one-time problem, are there any benefits of the approach
to use versioned provides?

Best regards,
Andreas

Bug#842595: src:hdf5: [powerpcspe] FTBFS due to missing symbols

[Andreas Cadhalpun]

Package: src:hdf5
Version: 1.8.16+docs-8
X-Debbugs-CC: debian-powe...@lists.debian.org

Dear maintainer,

hdf5 fails to build on powerpcspe due to missing symbols [1]:

--- debian/libhdf5-openmpi-10.symbols (libhdf5-openmpi-10_1.8.16_powerpcspe)
+++ dpkg-gensymbolsE_8dvU   2016-10-10 11:34:52.737750251 +
@@ -2117,19 +2117,19 @@
  H5T__conv_ldouble_double@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_float@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_int@HDF5_MPI_1.8.10 1.8.13
- (arch=!powerpc !ppc64)H5T__conv_ldouble_llong@HDF5_MPI_1.8.10 1.8.13
+#MISSING: 1.8.16# (arch=!powerpc 
!ppc64)H5T__conv_ldouble_llong@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_long@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_schar@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_short@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_uchar@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_uint@HDF5_MPI_1.8.10 1.8.13
- (arch=!powerpc !ppc64)H5T__conv_ldouble_ullong@HDF5_MPI_1.8.10 1.8.13
+#MISSING: 1.8.16# (arch=!powerpc 
!ppc64)H5T__conv_ldouble_ullong@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_ulong@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_ldouble_ushort@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_llong_double@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_llong_float@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_llong_int@HDF5_MPI_1.8.10 1.8.13
- (arch=!powerpc !ppc64)H5T__conv_llong_ldouble@HDF5_MPI_1.8.10 1.8.13
+#MISSING: 1.8.16# (arch=!powerpc 
!ppc64)H5T__conv_llong_ldouble@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_llong_long@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_llong_schar@HDF5_MPI_1.8.10 1.8.13
  H5T__conv_llong_short@HDF5_MPI_1.8.10 1.8.13
@@ -2397,6 +2397,7 @@
  H5Z_NBIT@HDF5_MPI_1.8.7 1.8.13
  H5Z_SCALEOFFSET@HDF5_MPI_1.8.7 1.8.13
  H5Z_SHUFFLE@HDF5_MPI_1.8.7 1.8.13
+ H5Z_SZIP@Base 1.8.16
  H5Z_all_filters_avail@HDF5_MPI_1.8.7 1.8.13
  H5Z_append@HDF5_MPI_1.8.7 1.8.13
  H5Z_can_apply@HDF5_MPI_1.8.7 1.8.13

Since the missing symbols are already excluded from powerpc and ppc64 it makes 
sense
to exclude them also from powerpcspe.

Best regards,
Andreas


1: 
https://buildd.debian.org/status/fetch.php?pkg=hdf5=powerpcspe=1.8.16%2Bdocs-8=1476099322

Bug#837478: "PIE by default" transition is underway -- wiki needs updating

[Andreas Cadhalpun]

On 26.10.2016 22:34, Bill Allombert wrote:
> On Wed, Oct 26, 2016 at 08:57:52PM +0200, Andreas Cadhalpun wrote:
>> I'd rather not built everything twice, so I think I'll just drop the
>> static libraries in the next upload and only worry about this again,
>> when/if someone files a bug about missing the static libraries.
> 
> It is customary to build everything twice, one with -fPIC, one without.
> 
> Waiting for a bug report to do something is unfriendly to people using
> the stable release.

Oh well, I'll just consider your reply as said bug report. ;)

Best regards,
Andreas

Bug#837478: "PIE by default" transition is underway -- wiki needs updating

[Andreas Cadhalpun]

Hi,

On 26.10.2016 05:26, Guillem Jover wrote:
> On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote:
>> On 25.10.2016 13:55, Guillem Jover wrote:
>>> For many static libraries,
>>> making them embeddable into other shared libraries is really not
>>> desirable. And those should be using the shared libraries instead.
>>
>> If that's the reason why it shouldn't be done, policy should mention it.
>> The current policy does not list this as reason not to use -fPIC, merely:
>> "since there is no benefit"
> 
> I don't think it's "the reason", but personally I think it's one
> important reason.

If there are more, they could be mentioned in policy, too.

> Embedding static libraries into shared libraries can be very
> problematic if the shared libraries do not take precautions, such as
> explicit symbol visibility or symbol versioning, etc. Which most
> shared libraries do not do. And even then it's still prone to symbol
> conflicts, etc, even inside the shared library being linked itself in
> case of namespace issues, if the static library is sloppy.

A (possibly shortened) version of this paragraph would be a good addition
to the policy. :)

> So I think this should be in general discouraged.
> 
>>> I still think the current policy is fine, and if someone wants to build
>>> a static library with PIC it should be brought up here.
>>
>> The current ffmpeg packages builds shared and static libraries, the
>> latter because they are used in the test suite. Both are built from
>> the same object files compiled with -fPIC.
>> Do you really think those static libraries should not be included
>> in the binary lib*-dev packages just because they are not incompatible
>> with including in other shared libraries?
> 
> Well, I guess depends on how "clean" they are, what's the intended
> usage, etc. But given that in this case the usage is inside the same
> project, that seems pretty safe!

There might be some confusion here. The ffmpeg package uses these
static libraries only for build-time testing, so doesn't need to
have them included in the binary packages.
I don't know if anyone is using these shipped static libraries.

> I'd personally probably not ship them, 
> and would instead provide non-PIC ones there. Or at most ship them in
> addition as _pic.a libraries, to require explicit invocation.

I'd rather not built everything twice, so I think I'll just drop the
static libraries in the next upload and only worry about this again,
when/if someone files a bug about missing the static libraries.

Best regards,
Andreas

Bug#837478: "PIE by default" transition is underway -- wiki needs updating

[Andreas Cadhalpun]

Hi,

On 25.10.2016 13:55, Guillem Jover wrote:
> I don't think the reasoning there is sound (as I've mentioned
> elsewhere), and the policy bug should be closed.
> 
> Switching from no-PIE to PIE by default preserves our current behavior
> WRT static libraries vs shared libraries.

The current policy says:
"As to the static libraries, the common case is not to have relocatable code"

As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
enables PIE by default, which means it produces relocatable code.
This should definitely be updated to reflect reality.

> For many static libraries,
> making them embeddable into other shared libraries is really not
> desirable. And those should be using the shared libraries instead.

If that's the reason why it shouldn't be done, policy should mention it.
The current policy does not list this as reason not to use -fPIC, merely:
"since there is no benefit"

> I still think the current policy is fine, and if someone wants to build
> a static library with PIC it should be brought up here.

The current ffmpeg packages builds shared and static libraries, the
latter because they are used in the test suite. Both are built from
the same object files compiled with -fPIC.
Do you really think those static libraries should not be included
in the binary lib*-dev packages just because they are not incompatible
with including in other shared libraries?

Best regards,
Andreas

Bug#841977: libomxil-bellagio0: binaries shipped in shared library package

[Andreas Cadhalpun]

Package: libomxil-bellagio0
Version: 0.9.3-3
Severity: serious
Justification: Debian Policy section 8.2

Dear Maintainer,

libomxil-bellagio0 includes binaries and manual pages:
 * /usr/bin/omxregister-bellagio
 * /usr/bin/omxregister-bellagio-0
 * /usr/share/man/man1/omxregister-bellagio.1.gz
 * /usr/share/man/man1/omxregister-bellagio-0.1.gz

These filenames are not versioned. After a soname bump, the new
library package will thus conflict with libomxil-bellagio0.
Such behavior is forbidden by Debian Policy section 8.2:
"If your package contains files whose names do not change with each
change in the library shared object version, you must not put them
in the shared library package. Otherwise, several versions of the
shared library cannot be installed at the same time without filename
clashes, making upgrades and transitions unnecessarily difficult."

Also libomxil-bellagio0 runs omxregister-bellagio upon installation,
which means it is not installable on a foreign architecture.

Best regards,
Andreas

Bug#841827: liborc-0.4-dev: cannot run orcc during cross compilation of reverse dependencies

[Andreas Cadhalpun]

Hi Helmut,

On 23.10.2016 21:25, Helmut Grohne wrote:
> Control: affects -1 = src:pulseaudio
> 
> On Sun, Oct 23, 2016 at 09:03:46PM +0200, Andreas Cadhalpun wrote:
>> Are you sure this affects ffmpeg?
> 
> Actually, no. I only managed to reproduce it for pulseaudio now, though
> I vaguely remember another practical reproducer.
> 
>> As far as I can tell its build doesn't execute orcc.
>> The cross-build currently fails due to:
>> ERROR: tesseract not found using pkg-config
> 
> Yes, that's #841845.

I see. With the patch from that bug it still doesn't work, because
tesseract.pc requires lept.pc, which is also not in the multi-arch
location. I've filed #841968 about that.
With both these fixed, ffmpeg can be cross-built successfully,
so it is definitely not affected by #841827.

By the way, thanks for all your work on cross-build support!

Best regards,
Andreas

Bug#841968: libleptonica-dev: please move lept.pc to a multiarch location

[Andreas Cadhalpun]

Package: libleptonica-dev
Version: 1.73-5+b1
Tags: patch
Control: affects -1 + src:ffmpeg

Dear Maintainer,

lept.pc is installed into /usr/lib/pkgconfig. That directory is not
searched by pkg-config during cross compilation and thus makes ffmpeg
fail to cross build, since it uses tesseract.pc, which requires lept.pc.
Please move tesseract.pc to a multiarch location.
Consider applying the attached patch.

Best regards,
Andreas
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-5
+10
--- a/debian/liblept5.dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib
--- a/debian/liblept5.install
+++ b/debian/liblept5.install
@@ -1 +1 @@
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
--- a/debian/libleptonica-dev.dirs
+++ /dev/null
@@ -1,2 +0,0 @@
-usr/lib
-usr/include
--- a/debian/libleptonica-dev.install
+++ b/debian/libleptonica-dev.install
@@ -1,4 +1,4 @@
 usr/include/*
-usr/lib/lib*.a
-usr/lib/lib*.so
-usr/lib/pkgconfig/*
+usr/lib/*/lib*.a
+usr/lib/*/lib*.so
+usr/lib/*/pkgconfig/*
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ build-stamp:
 	dh_testdir
 	dh_autoreconf
 	# Add here commands to compile the package.
-	./configure --prefix=/usr $(shell dpkg-buildflags --export=configure)
+	dh_auto_configure
 	$(MAKE)
 	touch build-stamp
 

Bug#841827: liborc-0.4-dev: cannot run orcc during cross compilation of reverse dependencies

[Andreas Cadhalpun]

Hi Helmut,

On 23.10.2016 17:48, Helmut Grohne wrote:
> Package: liborc-0.4-dev
> Version: 1:0.4.26-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:buzztrax src:ffmpeg src:gnuradio src:gst-libav1.0 
> src:gst-plugins-base1.0 src:gst-plugins-good1.0 src:libquicktime src:lives 
> src:mplayer src:pulseaudio src:schroedinger src:uhd
> 
> Cross compiling the packages listed above results in a failure to
> execute orcc.

Are you sure this affects ffmpeg?

As far as I can tell its build doesn't execute orcc.
The cross-build currently fails due to:
ERROR: tesseract not found using pkg-config

Best regards,
Andreas

Bug#841501: ffmpeg-doc: faq.html link to local copy of manual

[Andreas Cadhalpun]

Control: forwarded -1 
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201567.html

Hi Kevin,

I've sent a patch fixing this upstream.

Best regards,
Andreas

Bug#839542: typo: Send/Que command to all matching filters

[Andreas Cadhalpun]

Control: tags -1 fixed-upstream

Hi Mathieu,

On 14.10.2016 08:33, Mathieu Malaterre wrote:
> On Thu, Oct 13, 2016 at 11:29 PM, Andreas Cadhalpun
> <andreas.cadhal...@googlemail.com> wrote:
>> Thanks for reporting this. I've forwarded the fix upstream together
>> with a couple of other spelling fixes. I hope you don't mind that.
> 
> This is the only way to have it fixed in the long term, so definitely:
> thanks for doing it ! :)

It is now fixed upstream:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=c8a6eb58d7ebc9c1585bc450aa9e0358f6822df0

Best regards,
Andreas

Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s

[Andreas Cadhalpun]

Control: tags -1 fixed-upstream

Hi Cris,

On 29.06.2016 21:56, Christoph Anton Mitterer wrote:
> Andreas, anything new on this? What happened to your proposed patch?

Jon Toohill managed to write a proper patch for this and it is now
fixed upstream [1].

Best regards,
Andreas


1: 
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=3b02f6dd7be880fd6c1bcaf2fd0c1314dcee7aa6

Bug#839941: whishlist ffmpeg

[Andreas Cadhalpun]

Control: tags -1 upstream
Control: retitle -1 enable decklink

Hi Marc,

On 17.10.2016 10:35, Struminski, Marc wrote:
> Decklink from here: https://www.blackmagicdesign.com/de/support
> (https://www.blackmagicdesign.com/de/support/download/197eba8afa194f03829ea
> 6fdf7d7c163/Linux) Version 1.8 Desktop Video SDK
> 
> Nvenc from here: https://developer.nvidia.com/nvidia-video-codec-sdk
> (https://developer.nvidia.com/designworks/video_codec_sdk/downloads/v7.0)

The nvenc page requires one to sign up a DEVELOPER PROGRAM AGREEMENT,
while the decklink page requires accepting an EULA...

In particular the decklink EULA says:
"1.4 The Licensee must not lease, rent, distribute or sub-license the Software"

Thus it seems to me that re-distribution of these headers is not allowed,
no matter what license is mentioned in the files.
(Even though it seems rather stupid to distribute a file with a free-software
license header under such an EULA.)

The nvenc agreement has an exception for such cases:
"Certain Materials provided to You by NVIDIA are accompanied by a separate
license agreement; You acknowledge and agree that such license agreement
shall govern Your use of such Materials, in addition to this Agreement.
You further agree that in the event of any inconsistency between this
Agreement and the corresponding provisions in the license agreement, the
license agreement shall govern."

So it is possible to re-distribute the nvenc headers and in fact they have
been included in the ffmpeg source repository upstream [1].

The decklink EULA lacks such an exception.

So if you want us to enable decklink in Debian's ffmpeg, I suggest you
contact blackmagic and ask them for a clarification of the license for
their headers.
If they are in fact freely re-distributable, you can then contact ffmpeg
upstream (ffmpeg-de...@ffmpeg.org) and ask them to include these
headers similarly to the nvenc headers.

Best regards,
Andreas


1: 
https://git.videolan.org/?p=ffmpeg.git;a=commit;h=325e56479ff64c884f3bcccf922a7f7163488b89

Bug#528080: ffmpeg-debian: ffmpeg still has shlib-with-non-pic-code lintian errors

[Andreas Cadhalpun]

On 16.10.2016 13:31, Niels Thykier wrote:
> Andreas Cadhalpun:
>> By the way, do you happen to know what problems these text relocations
>> cause from a security point of view?
>> (I thought they were incompatible with NX, but that seems not to be
>> the case [1].)
> 
> I wish I did.  For an executable, the absence if PIE makes the linker
> load the binary at a fixed offset, making it very easy to determine
> (some) addresses for ROP attacks.

Yes, PIE makes ASLR useful for executables.

>   AFAICT, for non-PIC shared-libraries the linker still has to relocate
> it, but I cannot quite figure out if that method is easier to exploit or
> not.
> 
> I suspect you might be derive it from reading the following two articles[1]:
> 
>  *
> http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries/
>  *
> http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
> 
> 
> ~Niels
> 
> [1] The PIC one mentions "lazy binding optimization" as an
> (optimization) advantage.  As I recall, that feature is effectively
> negated when using the "relro" (default) and the "bindnow" (suggested as
> a default) hardening flags.

That's correct. It also says:
"Moving relocations from the code section, however, allows to make it read-only
 and share it between processes."

I've seen similar statements elsewhere on the web, however, Michael's example
shows that even with text relocations, the text section is read-only when the
program runs.

So the remaining advantage is that the text section of PIC shared libraries
can be shared between processes, which is nice, but IMHO faster decoding
speed is even nicer. ;)

Best regards,
Andreas

Bug#528080: ffmpeg-debian: ffmpeg still has shlib-with-non-pic-code lintian errors

[Andreas Cadhalpun]

Hi Niels,

On 16.10.2016 08:45, Niels Thykier wrote:
> Do you know if upstream has re-evaluated this choice after gcc-5 fixed
> one of the major performance issues with PIC on i386?
> 
> Source:
> https://software.intel.com/en-us/blogs/2014/12/26/new-optimizations-for-x86-in-upcoming-gcc-50-32bit-pic-mode

That's great! Thanks for sharing this information.

However, in the case of ffmpeg the really performance critical part is
optimized in hand-written assembler code, which for i386 contains text
relocations.
So the ffmpeg libraries will contain text relocations on i386 even when
built with -fPIE/-fPIC (which will be the case in the next release, since
pie was enabled upstream).

By the way, do you happen to know what problems these text relocations
cause from a security point of view?
(I thought they were incompatible with NX, but that seems not to be
the case [1].)

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201103.html

Bug#835293: Log file shows additional information

[Andreas Cadhalpun]

Control: tags -1 moreinfo

Hi Gavin,

On 24.08.2016 13:01, Gavin Donald wrote:
> I am not sure if this is relevant but reinstalling clamav-daemon
> (for the third time) shows the following log file entry:

Reinstalling causes the config script to run, so the configured
TCP socket should have worked at that point.

> LOCAL: No local AF_UNIX SOCK_STREAM socket received from systemd

This is expected if you're only using a TCP socket.

> Looking at this report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771911
> 
> suggests that /etc/systemd/system/clamav-daemon.socket.d/extend.conf should 
> contain:
> 
> [Socket]
> ListenStream=127.0.0.1:3310
> 
> Mine contains:
> 
> [Socket]
> ListenStream=
> SocketUser=clamav
> ListenStream=127.0.0.1:3310
> 
> Which seems similar enough.

That is good and should work. Does it not?

What is the output of:
$ sudo systemctl status clamav-daemon

Best regards,
Andreas

Bug#839941: whishlist ffmpeg

[Andreas Cadhalpun]

Hi Marc,

On 07.10.2016 11:01, Struminski, Marc wrote:
> I compiled ffmpeg with ‹enable-decklink without nonfree.
> All you need are the header files.

>From where did you get these headers?

Best regards,
Andreas

Bug#831591: ffmpeg: kodi crash

[Andreas Cadhalpun]

Control: reopen -1
Control: reassign -1 kodi 16.1+dfsg1-2
Control: severity -1 important

Hi,

The relevant backtrace from the kodi_crashlog is:

Thread 1 (Thread 0x7f1b6bffe700 (LWP 16893)):
#0  0x7f1ba92991c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f1ba929a64a in __GI_abort () at abort.c:89
#2  0x7f1ba92d4f4a in __libc_message (do_abort=do_abort@entry=2, 
fmt=fmt@entry=0x7f1ba93cdb30 "*** Error in `%s': %s: 0x%s ***\n") at 
../sysdeps/posix/libc_fatal.c:175
#3  0x7f1ba92da6b6 in malloc_printerr (action=3, str=0x7f1ba93ca909 
"free(): invalid pointer", ptr=, ar_ptr=) at 
malloc.c:5004
#4  0x7f1ba92dae9e in _int_free (av=0x7f1ba9601b20 , 
p=, have_lock=0) at malloc.c:3865
#5  0x7f1baa6d4a9d in av_buffer_unref () from 
/usr/lib/x86_64-linux-gnu/libavutil.so.55
#6  0x7f1baa6e15d2 in av_frame_unref () from 
/usr/lib/x86_64-linux-gnu/libavutil.so.55
#7  0x7f1bab93cf10 in avcodec_decode_video2 () from 
/usr/lib/x86_64-linux-gnu/libavcodec.so.57
#8  0x0090b26c in CDVDDemuxFFmpeg::ParsePacket(AVPacket*) ()
#9  0x0090d0c2 in CDVDDemuxFFmpeg::Read() ()
#10 0x01079b53 in CDVDPlayer::ReadPacket(DemuxPacket*&, CDemuxStream*&) 
()
#11 0x0107ecd7 in CDVDPlayer::Process() ()
#12 0x012103ff in CThread::Action() ()
#13 0x012106bf in CThread::staticThread(void*) ()
#14 0x7f1bb23e5464 in start_thread (arg=0x7f1b6bffe700) at 
pthread_create.c:333
#15 0x7f1ba934d30d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Looking at the ParsePacket function reveals [1]:
AVFrame picture;
memset(, 0, sizeof(AVFrame));
picture.pts = picture.pkt_dts = picture.pkt_pts = 
picture.best_effort_timestamp = AV_NOPTS_VALUE;
picture.pkt_pos = -1;
picture.key_frame = 1;
picture.format = -1;

This is using non-public ABI, e.g. the size of AVFrame, while the documentation
explicitly says "sizeof(AVFrame) is not a part of the public ABI" [2].
What's worse is that it doesn't use av_frame_alloc as required [3]:
"AVFrame must be allocated using av_frame_alloc()."

The whole block quoted above should be replaced with:
AVFrame *picture = av_frame_alloc().

Then the following code should use picture instead of :
avcodec_decode_video2(st->codec, picture, _picture, pkt);

And at the end it can be freed (instead of using av_frame_unref) with:
av_frame_free();

In the experimental kodi branch there is another occurrence of this bug
in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.

Best regards,
Andreas


1: 
https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git/tree/xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.cpp?id=8d5cf423001aa4e7f850c20b158b2811e637e607#n1665
2: 
https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n174
3: 
https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n154

Bug#833722: ffmpeg: can hear music but no sound/dialogs from movie

[Andreas Cadhalpun]

Control: tags -1 unreproducible

Hi shirish,

On 08.08.2016 11:39, shirish शिरीष wrote:
> Last few days, I have been able to hear the audio/songs/singing
> background but no dialogs.
> 
> I see the following on the CLI -

Next time please also copy the command line, or at least mention the
program producing the output. I guess the below comes from mpv.

> [ffmpeg/audio] ac3: Channel layout '5.1(side)' with 6 channels does
> not match specified number of channels 2: ignoring specified channel
> layout
> AO: [pulse] 48000Hz stereo 2ch float
> VO: [opengl] 720x304 yuv420p
> AV: 00:00:00 / 01:30:22 (0%) A-V:  0.000
> [ffmpeg/audio] ac3: exponent 26 is out-of-range
> [ffmpeg/audio] ac3: error decoding the audio block

This looks like the sample is broken/corrupted.

> AV: 00:01:48 / 01:30:22 (1%) A-V:  0.000
> 
> Does this mean the only fix for such movies is a 5.1 output or there
> could be some other fix ?

No. Both ffplay and mpv usually just downmix the audio automatically.
This works fine here without any warnings.

Can you share a sample reproducing the problem?

Otherwise I'm afraid I won't be able to help you.

Best regards,
Andreas

Bug#839542: typo: Send/Que command to all matching filters

[Andreas Cadhalpun]

Control: forwarded -1 
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201062.html

Hi Mathieu,

On 01.10.2016 21:14, Mathieu Malaterre wrote:
> I do not believe this is proper english. Patch attached.

Thanks for reporting this. I've forwarded the fix upstream together
with a couple of other spelling fixes. I hope you don't mind that.

Best regards,
Andreas

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

[Andreas Cadhalpun]

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69714
Control: tags -1 patch

Hi Aurelien,

On 08.02.2016 23:59, Aurelien Jarno wrote:
> On 2016-02-06 02:38, Andreas Cadhalpun wrote:
>> This works correctly with gcc-5 5.3.1-6, so it is a regression in 5.3.1-7.
> 
> In my case I am able to reproduce the issue with both version 5.3.1-6
> and 5.3.1-7, as well as 5.3.1-8.

This is very strange, as ffmpeg 7:2.8.5-1 built successfully with gcc-5 5.3.1-6
on the mips buildd.

> That said I don't think that GCC is broken here, instead the source code is 
> wrong.

I beg to differ.

>> static uint32_t av_bswap32(uint32_t x)
>> {
>> return x) << 8 & 0xff00) | ((x) >> 8 & 0x00ff)) << 16 | x) >> 
>> 16) << 8 & 0xff00) | (((x) >> 16) >> 8 & 0x00ff)));
>> }
> 
> Note that this doesn't really produce optimized code.  has a
> better code which calls __builtin_bswap32 on a (not that) recent GCC.

ffmpeg has it's own optimized versions for more common architectures.

>> return av_bswap32(*((uint32_t *) ([2])));
> 
> This is dereferencing a type-punned pointer, as reported by using -Wall.
> This means that GCC can now assume that the value to fetch in preamble is
> 32-bit aligned, and that's why it generates code to bswap the aligned
> 32-bit code starting at position 4 instead of the one starting at position
> 2.
> 
> Note that this undefined behavior can be reproduced on amd64 by using
> the -fsanitize=undefined option (ubsan):
> 
> | test.c:32:12: runtime error: load of misaligned address 0xffdf50da for type 
> 'uint32_t', which requires 4 byte alignment
> | 0xffdf50da: note: pointer points here
> |  04 08  21 10 f0 2d 00 00 00 00  48 d1 df ff 60 c1 75 f7  eb 15 74 f7 d4 99 
> 04 08  00 00 00 00 c0 84
> | 
> |   ^ 

These warnings are a red herring, as they are only an artifact from reducing
the testcase. They don't happen with the ffmpeg code and avoiding them in
the testcase, e.g. with the following diff, doesn't fix the problem:
--- a/test.c
+++ b/test.c
@@ -16,6 +16,8 @@
 void *a;
 } AVPacket;
 
+union unaligned_32 { uint32_t l; } __attribute__((packed)) 
__attribute__((may_alias));
+
 static uint32_t av_bswap32(uint32_t x)
 {
 return x) << 8 & 0xff00) | ((x) >> 8 & 0x00ff)) << 16 | x) >> 16) 
<< 8 & 0xff00) | (((x) >> 16) >> 8 & 0x00ff)));
@@ -29,5 +31,5 @@
 preamble[i] = s->pb->buf_ptr[0];
 s->pb->buf_ptr += 1;
 }
-return av_bswap32(*((uint32_t *) ([2])));
+return av_bswap32(((const union unaligned_32 *) ([2]))->l);
 }

On the other hand, gcc-5 5.3.1-7 also regressed on hppa, causing different test 
failures
of ffmpeg. I've reported this to debian-hppa, where it was analyzed and 
forwarded
upstream. The patch [1] fixing that also fixes the regression on mips.

Best regards,
Andreas


1: https://gcc.gnu.org/bugzilla/attachment.cgi?id=37655=diff

Bug#814026: ITP: dcadec -- DTS Coherent Acoustics decoder - shared library

[Andreas Cadhalpun]

Hi Bálint,

On 07.02.2016 18:16, Balint Reczey wrote:
> * Package name: dcadec
>   Version : 0.2.0
> * URL : https://github.com/foo86/dcadec
> * License : LGPL-2.1
>   Programming Lang: C
>   Description : DTS Coherent Acoustics decoder - shared library
> 
> A free DTS Coherent Acoustics decoder with support for HD extensions.

Why do you want to package this library? Is it a dependency for something else?

I'm asking because this decoder recently replaced ffmpeg's previous native
dca decoder [1], so it will be part of the next ffmpeg release.

Best regards,
Andreas


1: 
https://git.videolan.org/?p=ffmpeg.git;a=commit;h=ae5b2c52501d5009fe712334428138a9b758849b

Bug#810020: aptitude: sometimes crashes when reading changelogs

[Andreas Cadhalpun]

Hi Manuel,

On 05.02.2016 20:47, Manuel A. Fernandez Montecelo wrote:
> 2016-01-12 23:39 Axel Beckert:
>> Andreas Cadhalpun wrote:
>>> On 05.01.2016 18:46, Andreas Cadhalpun wrote:
>>> > since upgrading to apt > 1.1 aptitude sometimes crashes, when reading 
>>> > changelogs.
>>> > So far it happened four times in the last month.
>>>
>>> I have found a quite reliable way to reproduce the crash:
>>>  * open the aptitude ncurses interface
>>>  * select one package (e.g. aptitude)
>>>  * press 'C' multiple times (at least twice) in a row, fast
>>>  * watch the segfault...
>>
>> Indeed. With those instructions I can reproduce the issue with
>> aptitude 0.7.5-3 on amd64.
>>
>> Thanks for bug report and the followup with more details.
> 
> This turned out to be incredibly complicated to debug, and I couldn't
> find out in the end the exact cause of the crash after several
> afternoons and evenings looking into it.  Threading make this kind of
> debugging very complicate.

I can understand your pain.

> I believe that the crashes don't happen anymore with this fix, though.

Thanks for fixing it!

Best regards,
Andreas

Bug#803813: ffmpegthumbs: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: forwarded -1 https://git.reviewboard.kde.org/r/126992/

Hi Maximiliano,

On 05.02.2016 11:20, Maximiliano Curia wrote:
> On 07/01/16 23:42, Andreas Cadhalpun wrote:
>> I'm wondering what the status of this bug is:
> 
>>  * Are you aware of the patch I provided?
> Sorry, I'm still trying to catch up from the holidays vacations.

I see.

>>  * Do you plan an upload soon?
> ffmpegthumbs 15.12.1 was uploaded to experimental together with all the rest
> of the kde applications, but it can be uploaded to unstable at any time.
> The patch is now commited in the git repository.
> 
>>  * Is upstream aware of the problem?
> I've just forwarded your patch as a new review request here:
> https://marc.info/?l=kde-multimedia=145466658009944=2

Thanks for committing the patch and forwarding upstream.
Have you done any runtime-testing?
I'm asking since I don't know how to do that and the patch isn't trivial.

Best regards,
Andreas

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

[Andreas Cadhalpun]

Control: affects -1 tokyocabinet

Hi Tobias,

On 06.02.2016 15:37, Tobias Frost wrote:
> I also see something like this for tokyocabinet, see #813880 for an
> analysis... 
> 
> I see those failures on powerpc, ppc64 and s390x, but not on mips.

Well, 1.4.48-5 and 1.4.48-6 also failed to build on mips [1].

> So this might be indeed a differnt bug as well, but I guess related to
> optimization.
> 
> After seeing this bug, I tried -fno-expensive-optimizations on
> partch.d.o -- and this fixes also the regression I was experiencing.

I tried making the argument of av_bswap32 in my test case volatile and
that also fixed the problem. So it seems to me that these really are
the same bug. Thus I've added this to the bug metadata.

Best regards,
Andreas


1: 
https://buildd.debian.org/status/fetch.php?pkg=tokyocabinet=mips=1.4.48-6=1454770843

Bug#813858: gcc-5: [mips] regression: miscompilation caused by -fexpensive-optimizations

[Andreas Cadhalpun]

Package: gcc-5
Version: 5.3.1-7
Severity: serious
Justification: causes ffmpeg to FTBFS
Control: affects -1 ffmpeg
X-Debbugs-Cc: debian-m...@lists.debian.org

Dear Maintainer,

ffmpeg 7:2.8.6-1 failed to build on mips due to test failures.

I investigated the problem and it turns out to be caused by a compiler bug
that can be avoided by using '-fno-expensive-optimizations'.
(Somehow this feels like Déjà vu... #800318)

Attached is a reduced test case:
$ ls
Makefile  main.c  test.c
$  make
cc -fPIC -g -O2 -fno-expensive-optimizations -c -o working.o test.c
cc -shared -o libworking.so working.o
cc -fPIC -g -o working main.c -L. -lworking
cc -fPIC -g -O2 -c -o broken.o test.c
cc -shared -o libbroken.so broken.o
cc -fPIC -g -o broken main.c -L. -lbroken
LD_LIBRARY_PATH=. ./working || true
chunk_size: 11760
working
LD_LIBRARY_PATH=. ./broken || true
chunk_size: 0
broken

This works correctly with gcc-5 5.3.1-6, so it is a regression in 5.3.1-7.
The difference between broken.o compiled by 5.3.1-6 and 5.3.1-7 is shown
by diffoscope as:
├── objdump --line-numbers --disassemble --section=.text {}
│ @@ -17,23 +17,23 @@
│18:24420001addiu   v0,v0,1
│1c:24630001addiu   v1,v1,1
│20:aca2000csw  v0,12(a1)
│  ./test.c:28 (discriminator 3)
│24:1446fffbbne v0,a2,14 
│28:a064sb  a0,-1(v1)
│  ./test.c:32
│ -  2c:8ba4000alwl a0,10(sp)
│ -  30:97a2000clhu v0,12(sp)
│ -  34:9ba4000dlwr a0,13(sp)
│ -  38:7c0210a0wsbhv0,v0
│ +  2c:8ba3000alwl v1,10(sp)
│ +  30:97a4000clhu a0,12(sp)
│ +  34:9ba3000dlwr v1,13(sp)
│ +  38:7c0420a0wsbha0,a0
│  ./test.c:33
│3c:27bd0010addiu   sp,sp,16
│  ./test.c:32
│ -  40:00021c00sll v1,v0,0x10
│ -  44:00041202srl v0,a0,0x8
│ -  48:00042602srl a0,a0,0x18
│ -  4c:3042ff00andiv0,v0,0xff00
│ -  50:00621025or  v0,v1,v0
│ +  40:3084andia0,a0,0x
│ +  44:00031200sll v0,v1,0x8
│ +  48:7c633a00ext v1,v1,0x8,0x8
│ +  4c:00431825or  v1,v0,v1
│ +  50:00031400sll v0,v1,0x10
│  ./test.c:33
│54:03e8jr  ra
│58:00441025or  v0,v0,a0
│5c:nop
├── readelf --wide --decompress --string-dump=.comment {}
│ @@ -1,4 +1,4 @@
│  
│  String dump of section '.comment':
│ -  [ 1]  GCC: (Debian 5.3.1-6) 5.3.1 20160114
│ +  [ 1]  GCC: (Debian 5.3.1-7) 5.3.1 20160121
│  
╵

I hope that helps to fix this bug soon.

Best regards,
Andreas


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: mips

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gcc-5 depends on:
ii  binutils  2.26-3
ii  cpp-5 5.3.1-7
ii  gcc-5-base5.3.1-7
ii  libc6 2.21-7
ii  libcc1-0  5.3.1-7
ii  libgcc-5-dev  5.3.1-7
ii  libgcc1   1:5.3.1-7
ii  libgmp10  2:6.1.0+dfsg-2
ii  libisl15  0.16.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-2
ii  libstdc++65.3.1-7
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.21-7

Versions of packages gcc-5 suggests:
pn  gcc-5-doc 
pn  gcc-5-locales 
pn  gcc-5-multilib
pn  libasan2-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx0-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information
#include 
#include 

typedef struct AVIOContext {
uint8_t a[4];
uint8_t *buffer;
int32_t buffer_size;
uint8_t *buf_ptr;
} AVIOContext;

typedef struct AVFormatContext {
uint8_t a[15];
AVIOContext* pb;
} AVFormatContext;

typedef struct AVPacket {
void *a;
} AVPacket;

int roq_read_packet(AVFormatContext *s, AVPacket *pkt);

int main()
{
AVPacket pkt = { 0 };
AVFormatContext s = { 0 };
AVIOContext pb = { 0 };
uint8_t buffer[32768] = { 0x84, 0x10, 0xff, 0xff, 0xff, 0xff, 0x1e, 0x00,
  0x21, 0x10, 0xf0, 0x2d, 0x00, 0x00, 0x00, 0x00,
  0 };

pb.buffer = buffer;
pb.buffer_size = 32768;
pb.buf_ptr = [8];
s.pb = 

int chunk_size = roq_read_packet(, );
printf("chunk_size: %u\n", chunk_size);
if (chunk_size == 0x2df0) {
printf("working\n");
return 0;
}
else {
printf("broken\n");
return 1;
}
}
CFLAGS += 

Bug#811921: ffmpeg: FTBFS with GCC 6: misc errors

[Andreas Cadhalpun]

Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69320
Control: tags -1 fixed-upstream

Hi,

On 21.01.2016 08:13, Timothy Gu wrote:
> On Thu, Jan 21, 2016 at 02:39:41AM +0100, Andreas Cadhalpun wrote:
>> Interestingly these tests pass upstream [1] when building with
>> "gcc 6.0.0 (GCC) 20160119 (experimental)".
>> So this either got fixed between 17. and 19. January, or it is a
>> Debian specific problem.
> 
> It’s definitely not a Debian-specific problem. See [1]: a build with GCC
> 6.0.0 20160116 failed as well [2].

Indeed, thanks for the pointer. Actually James Almer reported this upstream
on the 16. and it got fixed on the 19. January.
So it'll get fixed in Debian with the next gcc-6 snapshot.

It was just an unfortunate timing that the test-rebuilt was done with
a gcc-6 exhibiting this bug.

Best regards,
Andreas

Bug#811921: ffmpeg: FTBFS with GCC 6: misc errors

[Andreas Cadhalpun]

Control: reassign -1 gcc-6 6-20160117-1
Control: affects -1 ffmpeg

Hi Martin,

On 20.01.2016 04:44, Martin Michlmayr wrote:
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> 
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> You may be able to find out more about this issue at
> https://gcc.gnu.org/gcc-6/changes.html
> 
>> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
> ...
>> cc -I. -I/<>/ -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE 
>> -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 
>> -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
>> -DZLIB_CONST -g -O2 -fstack-protector-strong -Wformat 
>> -Werror=format-security -fno-strict-overflow -fstack-protector-all   
>> -std=c99 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 
>> -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/fribidi 
>> -I/usr/include/freetype2  -I/usr/include/bs2b  -I/usr/include/freetype2 
>> -I/usr/include/freetype2 -I/usr/include/fribidi  -I/usr/include/opencv 
>> -I/usr/include/opus -D_REENTRANT -I/usr/include/p11-kit-1 
>> -I/usr/include/schroedinger-1.0 -I/usr/include/orc-0.4 
>> -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL  -g 
>> -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith 
>> -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes 
>> -Wno-pointer-to-int-cast -Wstrict-prototypes
>>  -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length 
>> -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize 
>> -Werror=format-security -Werror=implicit-function-declaration 
>> -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat 
>> -fdiagnostics-color=auto -Wno-maybe-uninitialized-c -o ffmpeg_opt.o 
>> /<>/ffmpeg_opt.c
>> /<>/ffplay.c:3217:46: error: missing binary operator before 
>> token "("
>>  #if defined(__APPLE__) && SDL_VERSION_ATLEAST(1, 2, 14)
>>   ^
>> cc -I. -I/<>/ -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE 
>> -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 
>> -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
>> -DZLIB_CONST -DHAVE_AV_CONFIG_H -MM 
>> /<>/libavfilter/avf_showvolume.c | sed -e "/^#.*/d" -e 
>> "s,^[[:space:]]*avf_showvolume\\.o,libavfilter/avf_showvolume.o," > 
>> libavfilter/avf_showvolume.d
>> /<>/libavfilter/avf_showcqt.c:38:10: error: #include expects 
>> "FILENAME" or 
>>  #include FT_FREETYPE_H
>>   ^
> ...
>> -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch 
>> -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno 
>> -fno-signed-zeros -fno-tree-vectorize -Werror=format-security 
>> -Werror=implicit-function-declaration -Werror=missing-prototypes 
>> -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto 
>> -Wno-maybe-uninitialized   -c -o libavfilter/vf_drawbox.o 
>> /<>/libavfilter/vf_drawbox.c
>> /<>/libavfilter/vf_drawtext.c:69:10: error: #include expects 
>> "FILENAME" or 
>>  #include FT_FREETYPE_H
>>   ^
>>
>> /<>/libavfilter/vf_drawtext.c:70:10: error: #include expects 
>> "FILENAME" or 
>>  #include FT_GLYPH_H
>>   ^~
>>
>> /<>/libavfilter/vf_drawtext.c:71:10: error: #include expects 
>> "FILENAME" or 
>>  #include FT_STROKER_H
>>   ^~~~
>>
>> /<>/libavfilter/vf_drawtext.c:275:10: error: #include expects 
>> "FILENAME" or 
>>  #include FT_ERRORS_H
>>   ^~~

These "errors" are a red herring: they happen during dependency
generation and are thus harmless. They can also be seen when building
in unstable. (They now get suppressed upstream.)

The real problems are test failures:
[...]
Test vsynth1-svq1 failed. Look at tests/data/fate/vsynth1-svq1.err for details.
[...]
Test vsynth3-svq1 failed. Look at tests/data/fate/vsynth3-svq1.err for details.
[...]
Test vsynth2-svq1 failed. Look at tests/data/fate/vsynth2-svq1.err for details.

These worked fine when I tested building with gcc-6 6-20151211-1.
So this seems to be a regression introduced during the last month.

Interestingly these tests pass upstream [1] when building with
"gcc 6.0.0 (GCC) 20160119 (experimental)".
So this either got fixed between 17. and 19. January, or it is a
Debian specific problem.

The problem is in svq1_encode_plane in libavcodec/svq1enc.c.
For P-frames, the decoded_plane buffer gets overwritten with wrong
values:
$ cd debian/standard
$ export 
LD_LIBRARY_PATH="libavcodec:libavdevice:libavfilter:libavformat:libavresample:libavutil:libpostproc:libswresample:libswscale"
$ gdb --args ./ffmpeg -nostdin -nostats -cpuflags all -f rawvideo -s 352x288 
-pix_fmt yuv420p -threads 1 

Bug#803868: vlc: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Rémi,

On 19.01.2016 20:53, Rémi Denis-Courmont wrote:
> On Tuesday 19 January 2016 20:32:50 Andreas Cadhalpun wrote:
>> Why did you not disable frame-threading when using hwaccel, as the ffmpeg
>> commit message suggests?
> 
> I don´t think that it would be that easy at all on VLC side, without breaking 
> either hwaccel or threaded decoding. I don´t want to spend my free time on 
> this given that libav´s libavcodec still works just fine.

I can understand that reason...

> Patch welcome.

Unfortunately I'm also short on free time, so I suggested ffmpeg upstream
to reduce the error to a warning for the time being [1].

Thanks for bringing this problem to my attention.

Best regards,
Andreas


1: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/187471.html

Bug#803868: vlc: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Rémi,

On 18.01.2016 21:37, Rémi Denis-Courmont wrote:
> On Friday 08 January 2016 01:01:05 Andreas Cadhalpun wrote:
>> The next version of FFmpeg is planned to be released this month
>> (and it might be called 3.0 instead of 2.9).
>>
>> What are the current release plans for VLC 3.0?
> 
> They are unchanged. VLC releases always slips by several months. I´d be very 
> surprised if VLC 3.0 actually comes out this semester.

That's unfortunate.

> But at this point, this is moot for the purpose of this bug report. FFmpeg 
> 2.9 
> breaks compatibility with VLC regardless of versions. For the time being, if 
> you want something more recent than FFmpeg 2.8, you need VLC 3.0 *and* libav.

I guess you're referring to your vlc commit e57d32f [1] as a reaction to
ffmpeg commit 31741ae [2].

Why did you not disable frame-threading when using hwaccel, as the ffmpeg
commit message suggests?

If you have a good reason for that the change in ffmpeg can be re-evaluated.

Best regards,
Andreas


1: 
https://git.videolan.org/?p=vlc.git;a=commitdiff;h=e57d32f664ff63ead57dca1fed7aedd59edac9fb
2: 
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31741aecbf9938194b25f14de434104be33f5809

Bug#811519: vlc: avio plugin leaks file content

[Andreas Cadhalpun]

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

Hi,

On 19.01.2016 17:27, Sebastian Ramacher wrote:
> On 2016-01-19 18:11:01, Rémi Denis-Courmont wrote:
>> With a carefully crafted URL, the VLC avio plugin can be made to leak
>> content of local files to remote parties.
>> The root cause is the same as CVE-2016-1897.
>>
>> See also:
>>
>> https://mailman.videolan.org/pipermail/vlc-devel/2016-January/105718.html
> 
> There is nothing to be done in the vlc package. Reassigning to ffmpeg. It 
> needs
> to be built with --disable-protocol=concat.

How is CVE-2016-1897 not fully fixed?

Rémi, please share details about any remaining vulnerability with
.

Best regards,
Andreas

Bug#803822: gst-libav1.0: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 19.01.2016 08:45, Sebastian Dröge wrote:
> On Di, 2016-01-19 at 00:14 +0100, Andreas Cadhalpun wrote:
>> However, I don't understand your reasoning for not applying the patch
>> removing use of FF_API_EMU_EDGE.
>> It's only used in ffmpeg for backwards compatibility and thus
>> removing this from gst-libav1.0 now should work fine.
>> Or did you encounter any problems?
> 
> snowenc.c is still using it in some way, look for FF_API_EMU_EDGE in
> the code. I didn't look closer though, maybe it can be removed, maybe
> not.

However, that doesn't matter for gst-libav1.0, because it never sets
CODEC_FLAG_EMU_EDGE.
It only checks this flag when decoding, which is not necessary anymore.
So I still think applying this patch wouldn't cause any problem.

>> It would be nice to apply this patch now, as it seems to be the only
>> API still used by gst-libav1.0, which is going to be removed on the
>> next soversion bump.
> 
> In version.h
> #define FF_API_EMU_EDGE  (LIBAVCODEC_VERSION_MAJOR < 58)
> 
> master is still at 57 so it probably will be after 2.9 (or will it be
> called 3.0?) that this happens.

Yes, it will only happen after the next release (which will probably
be called 3.0).

> In any case, once that is removed it's
> also trivial to make gst-libav build again.

Sure. But I fear it'll require me to open a bug again next time, someone
to review the diff again, and finally to upload a fixed version.

It would be so much smoother if this was just fixed as part of the natural
flow of new upstream versions way before the deprecated APIs get removed...

>> For the bump after the next one, there are some more deprecated APIs
>> to deal with:
>>  * FF_API_MPV_OPT
>>  * FF_API_QUANT_BIAS
>>  * FF_API_RC_STRATEGY
>>  * FF_API_CODED_FRAME
> 
> done
> 
>>  * FF_API_MOTION_EST
>>  * FF_API_AVPICTURE
> 
> done

There's (a lot) more to be done about this one:
gstavdeinterlace.c, gstavdemux.c, gstavmux.c, gstavscale.c and gstavviddec.c
still use AVPicture.
Also gstavutils.c seems to contain (modified) copies of avpicture_* functions,
which should be replaced with av_image_* functions.

>>  * FF_API_AVPACKET_OLD_API
> 
> done
> 
>> Just mentioning it, in case you get bored again. ;)
> 
> The others can get done once it's time, it's mostly a matter of
> removing some lines of code in those cases. Unless you feel like
> providing patches :)

I might write some patches, when I get bored. :)

>> What remains is to get a fixed gst-libav1.0 version into sid.
>> Can you give an estimate, when this will happen?
> 
> We're going to release 1.6.3 some time this week, when I upload that to
> sid I'll include the patches.

Thanks.

> Why so impatient? ffmpeg 2.9/3.0 is not
> even released yet, no snapshot is in experimental, nothing :)

Sorry, I didn't want to seem impatient.
However, my goal is to have most (if not all) reverse dependencies fixed,
when the new upstream version gets released, so that the transition can
happen soon after.

Best regards,
Andreas

Bug#811519: vlc: avio plugin leaks file content

[Andreas Cadhalpun]

On 19.01.2016 20:32, Rémi Denis-Courmont wrote:
> On Tuesday 19 January 2016 19:06:54 Andreas Cadhalpun wrote:
>> How is CVE-2016-1897 not fully fixed?
>>
>> Rémi, please share details about any remaining vulnerability with
>> <ffmpeg-secur...@ffmpeg.org>.
> 
> This is a VLC vulnerability and I can´t share it with my own self.

However, you suggest that the underlying problem is in libavformat.

> Besides the 
> underlying issue has already been discussed with upstream libav.

But they haven't applied any fix for it, yet.

> There is plenty of information available already to reproduce the problem.

I can reproduce the problem with ffmpeg 2.8.4, but not with 2.8.5.

> I don´t want to publish an exact proof-of-concept against "my" own software, 
> especially not before VLC 2.2.2 gets released.

<ffmpeg-secur...@ffmpeg.org> is a private mailing list that can deal with
embargoed information. So please provide more details there.

Best regards,
Andreas

Bug#803843: motion: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Ximin,

On 19.01.2016 20:43, Ximin Luo wrote:
> I'm testing this now against 2.8, will upload as soon as I confirm that 
> everything still works.

Thanks!

> Do you also have a APT repo somewhere I can use to test against provisional 
> ffmpeg 2.9 / 3.0 packages?

I'm building ffmpeg from upstream git master.
I've just tested motion from commit bc90f28 of your packaging repository
with ffmpeg from git master and it compiled fine.

The runtime behavior should be the same as with ffmpeg 2.8.

Best regards,
Andreas

Bug#803822: gst-libav1.0: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: tag -1 fixed-upstream

Hi Sebastian,

On 18.01.2016 08:21, Sebastian Dröge wrote:
> I was bored at the airport on Saturday and merged all but one of the
> patches upstream now plus two additional ones. Take a look at the
> upstream bug report for details.

That's great! (I'm glad it helped relieve your boredom. ;)

> This now works with 2.8 and ffmpeg git master just fine without
> possibly breaking with either version. Let me know if you still see
> anything problematic.

I cherry-picked these four patches onto 1.6.2-1 (in sid) and it
built fine with ffmpeg git master.

However, I don't understand your reasoning for not applying the patch
removing use of FF_API_EMU_EDGE.
It's only used in ffmpeg for backwards compatibility and thus removing
this from gst-libav1.0 now should work fine.
Or did you encounter any problems?

It would be nice to apply this patch now, as it seems to be the only
API still used by gst-libav1.0, which is going to be removed on the next
soversion bump.

For the bump after the next one, there are some more deprecated APIs
to deal with:
 * FF_API_MPV_OPT
 * FF_API_QUANT_BIAS
 * FF_API_RC_STRATEGY
 * FF_API_CODED_FRAME
 * FF_API_MOTION_EST
 * FF_API_AVPICTURE
 * FF_API_AVPACKET_OLD_API

Just mentioning it, in case you get bored again. ;)

>>> testing will be easier once there are packages though.
>>
>> How so? The replacements of the deprecated APIs have been present
>> for years, so you can test the patch with any recent version.
>>
>> Once the new version is packaged, it will be a bit late to start
>> investigating this bug, as gst-libav1.0 will fail to build then.
> 
> Well, at that point it would be easier to fix than building all of
> ffmpeg myself, right? :)

Except that you don't need to build ffmpeg yourself to fix this. :)

What remains is to get a fixed gst-libav1.0 version into sid.
Can you give an estimate, when this will happen?

Best regards,
Andreas

Bug#803869: vtk6: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 13.01.2016 14:54, Andreas Tille wrote:
> I pinged ftpmaster yesterday to consider accepting VTK.  Hope this
> helps ...

Thanks. Unfortunately it got rejected meanwhile...

Best regards,
Andreas

Bug#803815: fuse-emulator-utils: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 13.01.2016 01:02, Alberto Garcia wrote:
> On Tue, Jan 12, 2016 at 11:48:28PM +0100, Andreas Cadhalpun wrote:
> 
>>> The patch to build against the new FFmpeg is waiting in my repository,
>>> when as the new packages are out I can upload fuse-utils immediately.
>>
>> Unless you think the new upstream version is going to be released
>> this month, you could just upload as well now...
> 
> Oh, somehow I got the idea that the patched fuse would only build with
> the new FFmpeg and not with the old one!

It still works with FFmpeg 2.8 (and it should also work with any other
version from the past two years).

> I guess I can just upload fuse now, then.

Yes, thanks. :)

Best regards,
Andreas

Bug#803815: fuse-emulator-utils: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Alberto,

On 11.01.2016 17:28, Alberto Garcia wrote:
> I'll talk to upstream and see what they think about this, but in
> principle I'd rather stick to the official release as much as possible
> and rebuild it with FFmpeg 2.9/3.0 when it's out.

I don't mind either way, as long as this bug is fixed soon. :)

Best regards,
Andreas

Bug#803858: renpy: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Markus,

On 12.01.2016 22:27, Markus Koschany wrote:
> I have uploaded the new revision a few minutes ago, so this bug should
> be closed very soon. The new upstream release requires a new, yet
> unpackaged, build-dependency and more work from our side but I will
> forward this patch upstream anyway.

That's great, thanks a lot!

Best regards,
Andreas

Bug#803858: renpy: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Markus,

On 11.01.2016 21:43, Markus Koschany wrote:
> I am working on updating this package. This issue will hopefully be
> fixed soon.

Thanks!

By the way, I had a quick look at the new upstream version and this
bug doesn't seem to be fixed there. So it would be great if you could
forward the patch upstream.

Best regards,
Andreas

Bug#803797: amarok: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: forwarded -1 https://git.reviewboard.kde.org/r/126682/#review90866

Hi Diane,

On 11.01.2016 20:34, Diane Trout wrote:
> Any chance you could weigh in on this KDE review? It's where I forwarded your 
> patch to upstream.
> 
> https://git.reviewboard.kde.org/r/126682/#review90866

Thanks for forwarding this upstream, I'm marking the bug accordingly.

The patch works with recent FFmpeg versions, i.e. since 2.0.
If you really need to support older versions, you can guard
av_frame_alloc/av_frame_unref/av_frame_free e.g. with:
#if LIBAVUTIL_VERSION_MAJOR >= 54

Also, it would be nice to (literally) replace the newly deprecated
av_free_packet with av_packet_unref, which can be guarded with:
#if LIBAVCODEC_VERSION_MAJOR >= 55
(av_free_packet will probably be removed in about two years.)

I hope you can understand that I won't follow up on the upstream tracker,
as I've filed a lot of patches for this transition and following up
on all of the different upstream trackers would be asking too much of me.

Best regards,
Andreas

Bug#810557: cmus: FTBFS with FFmpeg 2.9/3.0

[Andreas Cadhalpun]

Hi Sebastian,

On 11.01.2016 16:58, Sebastian Ramacher wrote:
> I really meant for you to follow up on Github. I don't intend to play the
> messenger for n iterations on this patch.

Sorry, but I don't intend to follow up on N different upstream trackers
for all these FFmpeg transition patches. I hope you can understand that this
would be asking too much of me.

Best regards,
Andreas

Bug#803815: fuse-emulator-utils: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: tag -1 pending

Hi Alberto,

On 12.01.2016 23:41, Alberto Garcia wrote:
> On Tue, Jan 12, 2016 at 10:13:16PM +0100, Andreas Cadhalpun wrote:
> 
>>> I'll talk to upstream and see what they think about this, but in
>>> principle I'd rather stick to the official release as much as
>>> possible and rebuild it with FFmpeg 2.9/3.0 when it's out.
>>
>> I don't mind either way, as long as this bug is fixed soon. :)
> 
> The patch to build against the new FFmpeg is waiting in my repository,
> when as the new packages are out I can upload fuse-utils immediately.

Unless you think the new upstream version is going to be released
this month, you could just upload as well now...
Anyway, I'm tagging this bug as pending, to reflect that fact that
the fix is just waiting for an upload.

Best regards,
Andreas

Bug#810020: aptitude: sometimes crashes when reading changelogs

[Andreas Cadhalpun]

Hi,

On 05.01.2016 18:46, Andreas Cadhalpun wrote:
> since upgrading to apt > 1.1 aptitude sometimes crashes, when reading 
> changelogs.
> So far it happened four times in the last month.

I have found a quite reliable way to reproduce the crash:
 * open the aptitude ncurses interface
 * select one package (e.g. aptitude)
 * press 'C' multiple times (at least twice) in a row, fast
 * watch the segfault...

In jessie, aptitude doesn't crash, but instead shows a warning (in addition to
opening the changelog a few times):
"Failed to download the changelog of aptitude: Download queue destroyed."

Best regards,
Andreas

Bug#810706: RM: avbin -- RoQA; unmaintained, outdated, FTBFS with ffmpeg 2.9/3.0

[Andreas Cadhalpun]

Package: ftp.debian.org
Severity: normal

Hi,

avbin has only ever seen one maintainer upload (in 2009) and since
then required constant QA work (the following 8 uploads).
Now it would need an update for FFmpeg API changes (#803800).

The current upstream version is 10 (from 2012), while we still have
version 7 in the archive.
Thus the removal of avbin was suggested two years ago in #741935.
It has been orphaned meanwhile.

The only user of avbin, psychopy, found sufficient alternatives [1].

Since avbin is already not in testing or stable it's of not much use
to keep it in unstable either. So please remove it.

Best regards,
Andreas


1: https://bugs.debian.org/741935#56

Bug#741935: Bug#803800: avbin: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Jon,

On 11.01.2016 11:24, Jonathan Peirce wrote:
> Thanks for the note Andreas. I think for the psychopy package we now
> have sufficient alternatives that we can live without avbin.

Thanks for the confirmation. I requested the removal of avbin now
in bug #810706 [1].

Best regards,
Andreas


1: https://bugs.debian.org/810706

Bug#803861: spek: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Alexander,

On 11.01.2016 03:49, Alexander Kojevnikov wrote:
> On Sun, Jan 10, 2016 at 2:14 AM, Andreas Cadhalpun
> <andreas.cadhal...@googlemail.com> wrote:
>>
>> [...]
>>
>>> feel free to update and NMU the Debian package.
>>
>> I think it would be better if you made a maintainer upload,
>> as the package otherwise looks a bit unmaintained with only
>> two NMUs in the last two years...
>> (I'm sure Felipe Sateler would be willing to sponsor such an upload,
>> like he did for dvbcut[1].)
> 
> Felipe, could you sponsor the upload? It's on m.d.n:
> http://mentors.debian.net/package/spek

Thanks for preparing the upload. I confirm that it builds with FFmpeg
from git master.

There are two things that would be nice to get fixed, though:
 * obsolete-url-in-packaging: The watchfile should use github instead
   of the obsolete code.google.com.
 * FFmpeg upstream introduced new deprecations in git master,
   in particular deprecating av_free_packet in favor of av_packet_unref.
   Since the replacement has been available already since quite some
   time (libavcodec 55.25.100 / 55.16.0) it would be nice if you
   would use it. That way spek should be API compatible with FFmpeg
   for at least the next two years. Patch:
--- spek-0.8.2.orig/src/spek-audio.cc
+++ spek-0.8.2/src/spek-audio.cc
@@ -224,7 +224,7 @@ AudioFileImpl::~AudioFileImpl()
 this->packet.data -= this->offset;
 this->packet.size += this->offset;
 this->offset = 0;
-av_free_packet(>packet);
+av_packet_unref(>packet);
 }
 if (this->format_context) {
 if (this->audio_stream >= 0) {
@@ -299,7 +299,7 @@ int AudioFileImpl::read()
 this->packet.data -= this->offset;
 this->packet.size += this->offset;
 this->offset = 0;
-av_free_packet(>packet);
+av_packet_unref(>packet);
 }
 
 int res = 0;
@@ -307,7 +307,7 @@ int AudioFileImpl::read()
 if (this->packet.stream_index == this->audio_stream) {
 break;
 }
-av_free_packet(>packet);
+av_packet_unref(>packet);
 }
 if (res < 0) {
 // End of file or error.

Best regards,
Andreas

Bug#810557: cmus: FTBFS with FFmpeg 2.9/3.0

[Andreas Cadhalpun]

Hi Sebastian,

On 11.01.2016 13:38, Sebastian Ramacher wrote:
> I have forwarded your patch upsteram (https://github.com/cmus/cmus/pull/383).

Thanks!

> Could you please follow up to the questions asked there?

The patch should work fine with all releases from the past two years.
If there is need to support older environments, there is no way
around ugly preprocessor guards.

Attached is a patch using those and also replacing the newly deprecated
av_free_packet, which is going to be removed in two years.

Best regards,
Andreas
diff --git a/debian/patches/ffmpeg-2.9.patch b/debian/patches/ffmpeg-2.9.patch
new file mode 100644
index 000..d365fb2
--- /dev/null
+++ b/debian/patches/ffmpeg-2.9.patch
@@ -0,0 +1,120 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
+Last-Update: <2016-01-11>
+
+--- cmus-2.7.1.orig/ffmpeg.c
 cmus-2.7.1/ffmpeg.c
+@@ -39,7 +39,11 @@
+ #include 
+ #include 
+ #include 
++#if LIBAVUTIL_VERSION_MAJOR >= 53
++#include 
++#else
+ #include 
++#endif
+ #ifndef AVUTIL_MATHEMATICS_H
+ #include 
+ #endif
+@@ -115,7 +119,11 @@ static struct ffmpeg_input *ffmpeg_input
+ 
+ static void ffmpeg_input_free(struct ffmpeg_input *input)
+ {
++#if LIBAVCODEC_VERSION_MAJOR >= 56
++	av_packet_unref(>pkt);
++#else
+ 	av_free_packet(>pkt);
++#endif
+ 	free(input);
+ }
+ 
+@@ -235,7 +243,11 @@ static int ffmpeg_open(struct input_plug
+ 
+ 		codec = avcodec_find_decoder(cc->codec_id);
+ 		if (!codec) {
++#if LIBAVCODEC_VERSION_MAJOR >= 54
++			d_print("codec not found: %d, %s\n", cc->codec_id, avcodec_get_name(cc->codec_id));
++#else
+ 			d_print("codec not found: %d, %s\n", cc->codec_id, cc->codec_name);
++#endif
+ 			err = -IP_ERROR_UNSUPPORTED_FILE_TYPE;
+ 			break;
+ 		}
+@@ -248,7 +260,11 @@ static int ffmpeg_open(struct input_plug
+ #else
+ 		if (avcodec_open2(cc, codec, NULL) < 0) {
+ #endif
++#if LIBAVCODEC_VERSION_MAJOR >= 54
++			d_print("could not open codec: %d, %s\n", cc->codec_id, avcodec_get_name(cc->codec_id));
++#else
+ 			d_print("could not open codec: %d, %s\n", cc->codec_id, cc->codec_name);
++#endif
+ 			err = -IP_ERROR_UNSUPPORTED_FILE_TYPE;
+ 			break;
+ 		}
+@@ -347,7 +363,11 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ 			  struct ffmpeg_output *output, SwrContext *swr)
+ {
+ #if (LIBAVCODEC_VERSION_INT >= ((53<<16) + (25<<8) + 0))
++#if LIBAVCODEC_VERSION_MAJOR >= 56
++	AVFrame *frame = av_frame_alloc();
++#else
+ 	AVFrame *frame = avcodec_alloc_frame();
++#endif
+ 	int got_frame;
+ #endif
+ 	while (1) {
+@@ -359,10 +379,16 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ 		int len;
+ 
+ 		if (input->curr_pkt_size <= 0) {
++#if LIBAVCODEC_VERSION_MAJOR >= 56
++			av_packet_unref(>pkt);
++#else
+ 			av_free_packet(>pkt);
++#endif
+ 			if (av_read_frame(ic, >pkt) < 0) {
+ /* Force EOF once we can read no longer. */
+-#if (LIBAVCODEC_VERSION_INT >= ((53<<16) + (25<<8) + 0))
++#if LIBAVCODEC_VERSION_MAJOR >= 56
++av_frame_free();
++#elif (LIBAVCODEC_VERSION_INT >= ((53<<16) + (25<<8) + 0))
+ avcodec_free_frame();
+ #endif
+ return 0;
+@@ -399,7 +425,11 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ 			av_new_packet(, input->curr_pkt_size);
+ 			memcpy(avpkt.data, input->curr_pkt_buf, input->curr_pkt_size);
+ 			len = avcodec_decode_audio4(cc, frame, _frame, );
++#if LIBAVCODEC_VERSION_MAJOR >= 56
++			av_packet_unref();
++#else
+ 			av_free_packet();
++#endif
+ 		}
+ #endif
+ 		if (len < 0) {
+@@ -426,7 +456,11 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ res = 0;
+ 			output->buffer_pos = output->buffer;
+ 			output->buffer_used_len = res * cc->channels * sizeof(int16_t);
++#if LIBAVCODEC_VERSION_MAJOR >= 56
++			av_frame_free();
++#else
+ 			avcodec_free_frame();
++#endif
+ 			return output->buffer_used_len;
+ 		}
+ #endif
+@@ -566,7 +600,11 @@ static long ffmpeg_current_bitrate(struc
+ 	long bitrate = -1;
+ #if (LIBAVFORMAT_VERSION_INT > ((51<<16)+(43<<8)+0))
+ 	/* ape codec returns silly numbers */
++#if LIBAVCODEC_VERSION_MAJOR >= 55
++	if (priv->codec->id == AV_CODEC_ID_APE)
++#else
+ 	if (priv->codec->id == CODEC_ID_APE)
++#endif
+ 		return -1;
+ #endif
+ 	if (priv->input->curr_duration > 0) {
diff --git a/debian/patches/series b/debian/patches/series
index c2cfb69..cb3676a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 01_config.mk.diff
 02_link_avcodec.patch
 11-fix_modplug_detection.patch
+ffmpeg-2.9.patch

Bug#803834: libde265: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: forwarded -1 https://github.com/strukturag/libde265/pull/133

Hi Joachim,

On 11.01.2016 16:06, Joachim Bauch wrote:
> thanks for the heads-up. I just pushed your patch to the packaging
> and notified pkg-multimedia-maintainers to build a new version of the
> package.
> 
> Reported upstream as https://github.com/strukturag/libde265/pull/133

Thanks, marking the as forwarded.

Best regards,
Andreas

Bug#803830: lebiniou: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Olivier,

On 10.01.2016 03:57, Olivier Girondel wrote:
> Your patch is to be applied for the next release

Thanks!

> We're quite busy now but you can expect this release by the end of
> the month

I would prefer an upload sooner, but at the end of the month might
still be just in time.

Best regards,
Andreas

Bug#803811: ffmpeg2theora: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: tags -1 fixed-upstream

Hi Jan,

On 10.01.2016 06:43, Jan Gerber wrote:
> thanks for the patch. Applied to git and released a new version (0.30)

That's great!
Now we just need to update the Debian package to this version.

Best regards,
Andreas

Bug#803861: spek: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Alexander,

On 10.01.2016 02:38, Alexander Kojevnikov wrote:
> I committed your patch upstream[0],

Thanks!

> feel free to update and NMU the Debian package.

I think it would be better if you made a maintainer upload,
as the package otherwise looks a bit unmaintained with only
two NMUs in the last two years...
(I'm sure Felipe Sateler would be willing to sponsor such an upload,
like he did for dvbcut[1].)

> Thank you and sorry it took so long to get back.

Don't worry, it's still in time.

Best regards,
Andreas


1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803809#20

Bug#803797: amarok: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Diane,

On 10.01.2016 01:12, Diane Trout wrote:
> After I emailed you I found the KDE bug that the musicbrainz tagging was 
> crashing on https://bugs.kde.org/show_bug.cgi?id=328359
> 
> Also it appears they fixed that bug in git master. After building that I was 
> able to view tags, so I think everything's fine.

That's good news. :)

> I went ahead and released the 2.8.0-4 version with your patch in it.

Thanks!

Best regards,
Andreas

Bug#807853: k3b: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Control: forwarded -1 https://git.reviewboard.kde.org/r/122569

Hi Pino,

On 09.01.2016 01:33, Pino Toscano wrote:
> In data venerdì 8 gennaio 2016 21:50:33, Andreas Cadhalpun ha scritto:
>> Could you please post links to upstream discussion about this or mark
>> the bug as forwarded?
> 
> I saw these two patches:

Thanks, marking the bug as forwarded accordingly.

> https://git.reviewboard.kde.org/r/122569/

I can confirm that this patch fixes compilation with current FFmpeg git.
But it's slightly wrong:
ifdef HAVE_FFMPEG_AVCODEC_DECODE_AUDIO4
#  if LIBAVCODEC_BUILD < AV_VERSION_INT(55,28,1)
av_free(d->frame);

Since libavcodec 54.28.0 this should be av_frame_free(>frame).
Otherwise it can leak memory.

#  else
av_frame_free(>frame);
#  endif
#endif

> https://git.reviewboard.kde.org/r/122601/

This one is trivially correct and also part of the above one.

If you want to avoid having this problem again next year (or the year after
that), you also need to replace the newly deprecated av_free_packet with
av_packet_unref, which is available since libavcodec 55.25.100 / 55.16.0:
--- k3b-2.0.3a.orig/plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp
+++ k3b-2.0.3a/plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp
@@ -378,7 +378,11 @@ int K3bFFMpegFile::fillOutputBuffer()
 #endif
 
 if( d->packetSize <= 0 || len < 0 )
+#if LIBAVCODEC_VERSION_MAJOR >= 56
+::av_packet_unref( >packet );
+#else
 ::av_free_packet( >packet );
+#endif
 if( len < 0 ) {
 kDebug() << "(K3bFFMpegFile) decoding failed for " << m_filename;
 return -1;

Anyway, do you know how to runtime test this code path?

> they refer to the master branch of k3b, but the code in
> plugins/decoder/ffmpeg/ is the same in both the 2.0 branch (from where
> the 2.0.x releases like the latest 2.0.3a are taken) and master.
> Would it be possible for you to check them, and maybe also comment on
> the reviewboard?

I'm no KDE developer, so I don't have a login on that review board.

>>> Let me take this opportunity to "reverse the issue": is your upstream
>>> aware that the continuous API breaks in each new stable series only
>>> waste time on the users' side?
>>
>> I sense frustration in these words, but let's get the facts straight:
>>  * The last four stable series (2.5.*-2.8.*) didn't break the API.
> 
> Possibly, but IIRC only 2.7 was used back in Debian, so what 2.5 and 2.6
> did is generally not relevant for me. Before it was libav, yes, but from
> a Debian maintainer POV it was "whatever provided libav* libraries".

I just wanted to be exact here. And it's still mainly Libav were the
deprecations (and the nice new APIs) come from, which get merged into FFmpeg.
The difference here is that FFmpeg has more stable releases. ;)
You could have said "API breaks once a year" and would have been mostly
correct. [1]

>>  * Adapting to the new APIs is no waste of time, rather maintenance cost,
>>also improving the API using program in the process, as the old APIs
>>were deprecated for a reason.
> 
> The ffmpeg decoding plugin in k3b is doing the same job for the latest
> 6+ years, so at least to me all these API changes look like they brought
> nothing.

Maybe, but e.g. an mpv developer will see this quite differently.

> And well, changing the code to newer APIs that don't bring
> anything new to what was already done is a cost that, as developer, I'd
> rather not pay.

Well, tell that e.g. the Qt/Gtk developers, or try your luck with the LLVM
developers, who like to gratuitously move headers around every half
a year...
At least FFmpeg has a reasonable deprecation period (usually > 2 years).
Keeping all old API forever is just not feasible for many important
libraries.

And while we're at that, someone should probably fix all those deprecation
warnings coming from Qt...

> There is not an active k3b upstream,

That's the real problem, I'm afraid.
Seriously, the patches on the review board are almost a year old...

But why is k3b not developed anymore?
Are there better alternatives?

> so I'm afraid the new ffmpeg
> support code should be as much as conservative as possible (that is,
> support the new version but keep supporting older ones as done now).

I don't see what that has to do with having no active upstream.

What are the oldest libavcodec/libavformat versions used for compiling this?

Or are you seriously claiming anyone still uses this code with a libavformat
version from before 2005?
(I'm referring to LIBAVFORMAT_BUILD < 4629.)

Best regards,
Andreas


1: http://abi-laboratory.pro/tracker/timeline/ffmpeg/

Bug#810564: libgroove: FTBFS with FFmpeg 2.9/3.0 (Werror)

[Andreas Cadhalpun]

Package: libgroove
Version: 4.3.0-1
Severity: important
Tags: patch
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: ffmpeg2.9

Dear Maintainer,

your package fails to build with the upcoming version
of ffmpeg, which is planned to be released this month
(and will be called 2.9 or 3.0).
This bug will become release-critical at some point when this
ffmpeg transition gets closer.

Attached is a patch removing the use of -Werror, which is
a good practice for development builds, but just causes
unnecessary build failures for release builds.
Please apply this patch soon.

Best regards,
Andreas
diff --git a/debian/patches/no-Werror.patch b/debian/patches/no-Werror.patch
new file mode 100644
index 000..323b2b1
--- /dev/null
+++ b/debian/patches/no-Werror.patch
@@ -0,0 +1,19 @@
+Description: remove Werror 
+ It is harmful in distributions as it causes unnecessary build failures.
+
+Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
+Last-Update: <2015-01-09>
+
+--- libgroove-4.3.0.orig/CMakeLists.txt
 libgroove-4.3.0/CMakeLists.txt
+@@ -136,8 +136,8 @@ configure_file (
+   "${PROJECT_BINARY_DIR}/config.h"
+   )
+ 
+-set(LIB_CFLAGS "${C99_C_FLAGS} -pedantic -Werror -Wall -Werror=strict-prototypes -Werror=old-style-definition -Werror=missing-prototypes -D_REENTRANT -D_POSIX_C_SOURCE=200809L")
+-set(EXAMPLE_CFLAGS "${C99_C_FLAGS} -pedantic -Werror -Wall -g")
++set(LIB_CFLAGS "${C99_C_FLAGS} -pedantic -Wall -Werror=strict-prototypes -Werror=old-style-definition -Werror=missing-prototypes -D_REENTRANT -D_POSIX_C_SOURCE=200809L")
++set(EXAMPLE_CFLAGS "${C99_C_FLAGS} -pedantic -Wall -g")
+ set(EXAMPLE_INCLUDES "${PROJECT_SOURCE_DIR}")
+ 
+ add_library(groove SHARED ${LIBGROOVE_SOURCES} ${LIBGROOVE_HEADERS})
diff --git a/debian/patches/series b/debian/patches/series
index 815548a..18ec44d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 gnu-install-dirs.patch
+no-Werror.patch

Bug#810563: bs1770gain: FTBFS with FFmpeg 2.9/3.0 (Werror)

[Andreas Cadhalpun]

Package: bs1770gain
Version: 0.4.8-2
Severity: important
Tags: patch
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: ffmpeg2.9

Dear Maintainer,

your package fails to build with the upcoming version
of ffmpeg, which is planned to be released this month
(and will be called 2.9 or 3.0).
This bug will become release-critical at some point when this
ffmpeg transition gets closer.

Attached is a patch removing the use of -Werror, which is
a good practice for development builds, but just causes
unnecessary build failures for release builds.
For the change in configure.ac to take effect, autoreconf
is enabled, as well.
Please apply this patch soon.

Best regards,
Andreas
diff --git a/debian/patches/no-Werror.patch b/debian/patches/no-Werror.patch
new file mode 100644
index 000..c814e4b
--- /dev/null
+++ b/debian/patches/no-Werror.patch
@@ -0,0 +1,45 @@
+Description: remove Werror 
+ It is harmful in distributions as it causes unnecessary build failures.
+
+Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
+Last-Update: <2015-01-09>
+
+--- bs1770gain-0.4.8.orig/bs1770gain/Makefile.am
 bs1770gain-0.4.8/bs1770gain/Makefile.am
+@@ -1,4 +1,3 @@
+-CFLAGS+=-Werror
+ CFLAGS+=-Wall
+ CFLAGS+=-Wformat
+ CFLAGS+=-Wpointer-arith
+--- bs1770gain-0.4.8.orig/configure.ac
 bs1770gain-0.4.8/configure.ac
+@@ -27,7 +27,7 @@
+ # AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])
+ 
+ AC_INIT([bs1770gain], [0.4.8], [pbelk...@users.sf.net], [], [http://bs1770gain.sourceforge.net/])
+-AM_INIT_AUTOMAKE([-Wall -Werror foreign])
++AM_INIT_AUTOMAKE([-Wall foreign])
+ AC_PROG_CC
+ AC_PROG_RANLIB
+ 
+--- bs1770gain-0.4.8.orig/lib1770-2/Makefile.am
 bs1770gain-0.4.8/lib1770-2/Makefile.am
+@@ -1,4 +1,3 @@
+-CFLAGS+=-Werror
+ CFLAGS+=-Wall
+ CFLAGS+=-Wformat
+ CFLAGS+=-Wpointer-arith
+--- bs1770gain-0.4.8.orig/libffsox-2/Makefile.am
 bs1770gain-0.4.8/libffsox-2/Makefile.am
+@@ -1,4 +1,3 @@
+-CFLAGS+=-Werror
+ CFLAGS+=-Wall
+ CFLAGS+=-Wformat
+ CFLAGS+=-Wpointer-arith
+--- bs1770gain-0.4.8.orig/libpbutil/Makefile.am
 bs1770gain-0.4.8/libpbutil/Makefile.am
+@@ -1,4 +1,3 @@
+-CFLAGS+=-Werror
+ CFLAGS+=-Wall
+ CFLAGS+=-Wformat
+ CFLAGS+=-Wpointer-arith
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..cb2e199
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+no-Werror.patch
diff --git a/debian/rules b/debian/rules
index 3c2a477..73cc9e8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 %:
-	dh $@
+	dh $@ --with=autoreconf
 
 override_dh_strip:
 	dh_strip --dbg-package=bs1770gain-dbg

Bug#810558: webcamoid: FTBFS with FFmpeg 2.9/3.0

[Andreas Cadhalpun]

Package: webcamoid
Version: 6.2.0-3
Severity: important
Tags: patch
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: ffmpeg2.9

Dear Maintainer,

your package fails to build with the upcoming version
of ffmpeg, which is planned to be released this month
(and will be called 2.9 or 3.0).
This bug will become release-critical at some point when this
ffmpeg transition gets closer.

Attached is a patch replacing the deprecated functionality.
It also works with ffmpeg 2.8.
Please apply this patch and forward it upstream, if necessary.

These changes have little regression potential.

Best regards,
Andreas
diff --git a/debian/patches/ffmpeg-2.9.patch b/debian/patches/ffmpeg-2.9.patch
new file mode 100644
index 000..b209ce8
--- /dev/null
+++ b/debian/patches/ffmpeg-2.9.patch
@@ -0,0 +1,63 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
+Last-Update: <2016-01-09>
+
+--- webcamoid-6.2.0.orig/Qb/Plugins/VCapsConvert/include/convertio.h
 webcamoid-6.2.0/Qb/Plugins/VCapsConvert/include/convertio.h
+@@ -35,10 +35,10 @@ class ConvertIO: public QObject
+ 
+ Q_PROPERTY(int iWidth READ iWidth)
+ Q_PROPERTY(int iHeight READ iHeight)
+-Q_PROPERTY(PixelFormat iFormat READ iFormat)
++Q_PROPERTY(AVPixelFormat iFormat READ iFormat)
+ Q_PROPERTY(int oWidth READ oWidth)
+ Q_PROPERTY(int oHeight READ oHeight)
+-Q_PROPERTY(PixelFormat oFormat READ oFormat)
++Q_PROPERTY(AVPixelFormat oFormat READ oFormat)
+ Q_PROPERTY(QList check READ check)
+ 
+ public:
+@@ -49,19 +49,19 @@ class ConvertIO: public QObject
+ 
+ Q_INVOKABLE int iWidth() const;
+ Q_INVOKABLE int iHeight() const;
+-Q_INVOKABLE PixelFormat iFormat() const;
++Q_INVOKABLE AVPixelFormat iFormat() const;
+ Q_INVOKABLE int oWidth() const;
+ Q_INVOKABLE int oHeight() const;
+-Q_INVOKABLE PixelFormat oFormat() const;
++Q_INVOKABLE AVPixelFormat oFormat() const;
+ Q_INVOKABLE QList check() const;
+ 
+ private:
+ int m_iWidth;
+ int m_iHeight;
+-PixelFormat m_iFormat;
++AVPixelFormat m_iFormat;
+ int m_oWidth;
+ int m_oHeight;
+-PixelFormat m_oFormat;
++AVPixelFormat m_oFormat;
+ };
+ 
+ #endif // CONVERTIO_H
+--- webcamoid-6.2.0.orig/Qb/Plugins/VCapsConvert/src/convertio.cpp
 webcamoid-6.2.0/Qb/Plugins/VCapsConvert/src/convertio.cpp
+@@ -93,7 +93,7 @@ int ConvertIO::iHeight() const
+ return this->m_iHeight;
+ }
+ 
+-PixelFormat ConvertIO::iFormat() const
++AVPixelFormat ConvertIO::iFormat() const
+ {
+ return this->m_iFormat;
+ }
+@@ -108,7 +108,7 @@ int ConvertIO::oHeight() const
+ return this->m_oHeight;
+ }
+ 
+-PixelFormat ConvertIO::oFormat() const
++AVPixelFormat ConvertIO::oFormat() const
+ {
+ return this->m_oFormat;
+ }
diff --git a/debian/patches/series b/debian/patches/series
index 20a4ea3..ec3e94a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -64,3 +64,4 @@ depre_utf_key.patch
 qb_lowercase_ACapsConvert.patch
 qb_lowercase_Aging.patch
 qb_lowercase_AudioInput.patch
+ffmpeg-2.9.patch

Bug#810557: cmus: FTBFS with FFmpeg 2.9/3.0

[Andreas Cadhalpun]

Package: cmus
Version: 2.7.1-1
Severity: important
Tags: patch
User: pkg-multimedia-maintain...@lists.alioth.debian.org
Usertags: ffmpeg2.9

Dear Maintainer,

your package fails to build with the upcoming version
of ffmpeg, which is planned to be released this month
(and will be called 2.9 or 3.0).
This bug will become release-critical at some point when this
ffmpeg transition gets closer.

Attached is a patch replacing the deprecated functionality.
It also works with ffmpeg 2.8.
Please apply this patch and forward it upstream, if necessary.

These changes have little regression potential.

Best regards,
Andreas
diff --git a/debian/patches/ffmpeg-2.9.patch b/debian/patches/ffmpeg-2.9.patch
new file mode 100644
index 000..c67c49c
--- /dev/null
+++ b/debian/patches/ffmpeg-2.9.patch
@@ -0,0 +1,69 @@
+Description: Replace deprecated FFmpeg API
+Author: Andreas Cadhalpun <andreas.cadhal...@googlemail.com>
+Last-Update: <2016-01-09>
+
+--- cmus-2.7.1.orig/ffmpeg.c
 cmus-2.7.1/ffmpeg.c
+@@ -39,7 +39,7 @@
+ #include 
+ #include 
+ #include 
+-#include 
++#include 
+ #ifndef AVUTIL_MATHEMATICS_H
+ #include 
+ #endif
+@@ -235,7 +235,7 @@ static int ffmpeg_open(struct input_plug
+ 
+ 		codec = avcodec_find_decoder(cc->codec_id);
+ 		if (!codec) {
+-			d_print("codec not found: %d, %s\n", cc->codec_id, cc->codec_name);
++			d_print("codec not found: %d, %s\n", cc->codec_id, avcodec_get_name(cc->codec_id));
+ 			err = -IP_ERROR_UNSUPPORTED_FILE_TYPE;
+ 			break;
+ 		}
+@@ -248,7 +248,7 @@ static int ffmpeg_open(struct input_plug
+ #else
+ 		if (avcodec_open2(cc, codec, NULL) < 0) {
+ #endif
+-			d_print("could not open codec: %d, %s\n", cc->codec_id, cc->codec_name);
++			d_print("could not open codec: %d, %s\n", cc->codec_id, avcodec_get_name(cc->codec_id));
+ 			err = -IP_ERROR_UNSUPPORTED_FILE_TYPE;
+ 			break;
+ 		}
+@@ -347,7 +347,7 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ 			  struct ffmpeg_output *output, SwrContext *swr)
+ {
+ #if (LIBAVCODEC_VERSION_INT >= ((53<<16) + (25<<8) + 0))
+-	AVFrame *frame = avcodec_alloc_frame();
++	AVFrame *frame = av_frame_alloc();
+ 	int got_frame;
+ #endif
+ 	while (1) {
+@@ -363,7 +363,7 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ 			if (av_read_frame(ic, >pkt) < 0) {
+ /* Force EOF once we can read no longer. */
+ #if (LIBAVCODEC_VERSION_INT >= ((53<<16) + (25<<8) + 0))
+-avcodec_free_frame();
++av_frame_free();
+ #endif
+ return 0;
+ 			}
+@@ -426,7 +426,7 @@ static int ffmpeg_fill_buffer(AVFormatCo
+ res = 0;
+ 			output->buffer_pos = output->buffer;
+ 			output->buffer_used_len = res * cc->channels * sizeof(int16_t);
+-			avcodec_free_frame();
++			av_frame_free();
+ 			return output->buffer_used_len;
+ 		}
+ #endif
+@@ -566,7 +566,7 @@ static long ffmpeg_current_bitrate(struc
+ 	long bitrate = -1;
+ #if (LIBAVFORMAT_VERSION_INT > ((51<<16)+(43<<8)+0))
+ 	/* ape codec returns silly numbers */
+-	if (priv->codec->id == CODEC_ID_APE)
++	if (priv->codec->id == AV_CODEC_ID_APE)
+ 		return -1;
+ #endif
+ 	if (priv->input->curr_duration > 0) {
diff --git a/debian/patches/series b/debian/patches/series
index c2cfb69..cb3676a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 01_config.mk.diff
 02_link_avcodec.patch
 11-fix_modplug_detection.patch
+ffmpeg-2.9.patch

Bug#803797: amarok: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

On 09.01.2016 07:10, Diane Trout wrote:
>>> though I'd ike to build and run it first.
>>
>> That's always a good idea.
> 
> Ok I built it and ran it and I think I tested the chunk of code that you 
> modified and it crashed.

Thanks for runtime testing this!

> However I then ran the version without your patch and it also crashed, so I'm 
> going to send your patch to upstream along with my test plan and see if we 
> can 
> figure out whats broken.

Can you share a link or mark this bug as forwarded?
If the crash is related to FFmpeg functionality, I might be able to help.

Best regards,
Andreas

Bug#803811: ffmpeg2theora: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Tiago,

thanks for your reply.

On 09.01.2016 20:27, Tiago Bortoletto Vaz wrote:
> I'm (slowly) coming back to my Debian work after a period in VAC.

That's great!

> I'll
> check this issue very soon, thanks for reporting. I have no problem at
> with with NMU's in my packages, so if you think it needs more urgent
> action please go ahead. I still need a few days to go over this.

A few days are no problem, as this transition is going to start only
in a few weeks. And I'd really appreciate if you could do some
runtime testing of the changed code, as I don't know how to do that
and the change involving avpicture_deinterlace is not trivial.

By the way, I just noticed that this got disabled upstream [1].
I'm CC'ing the author of that commit to make him aware of my patch [2]
replacing avpicture_deinterlace with libavfilter functionality.

Best regards,
Andreas


1: 
https://git.xiph.org/?p=ffmpeg2theora.git;a=commitdiff;h=f4800440119849d6d2544e2aea41efca24f1c264
2: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803811;att=1;msg=5;filename=ffmpeg2theora_ffmpeg-2.9.patch

Bug#803822: gst-libav1.0: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Sebastian,

Thanks for your quick reply.

On 08.01.2016 13:49, Sebastian Dröge wrote:
> I had no chance of looking closer yet,

That's unfortunate.

> testing will be easier once there are packages though.

How so? The replacements of the deprecated APIs have been present
for years, so you can test the patch with any recent version.

Once the new version is packaged, it will be a bit late to start
investigating this bug, as gst-libav1.0 will fail to build then.

Best regards,
Andreas

Bug#803869: vtk6: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Anton,

On 08.01.2016 06:35, Anton Gladky wrote:
> Hi Andreas, I uploaded it 20/12/2015. So we
> need just to wait for a FTP-masters, to get it
> approved.

Yes, I realized that when looking at the package tracker yesterday.
I'm just saying that a short mail informing me about the upload
(and tagging the bug pending) would have been a nice Christmas
present for me. ;)

On a related note: What are your plans for paraview (#803852)?

Best regards,
Andreas

Bug#803833: libavg: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Dimitri,

Thanks for your fast reply.

On 08.01.2016 13:41, Dimitri John Ledkov wrote:
> All my packages should be marked as LowNMU and I expect and hope for
> everyone to fix and upload things =)
> 
> So instead of filing a bug report and/or attaching a patch, you could
> have simply uploaded this build fix =)

If I were a DD, that is. Though, of course, I could ask you to sponsor
such an upload. ;)

> Please upload it, otherwise I shall test and upload it at some point
> in the future when it becomes critical...

I guess that should work, but I certainly would appreciate an upload
before this gets critical: That means less stress for you, me and the
Release Team.

Best regards,
Andreas

Bug#803849: openscenegraph: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Manuel,

Thanks for your quick reply.

On 08.01.2016 14:31, Manuel A. Fernandez Montecelo wrote:
> I think that Alberto was planning since many months ago to upload
> 3.4.0, and he mentioned it the last time that we met (about 3 weeks
> ago), but different issues (like the big GCC-5/C++11 transition, and
> smaller transitions after that) prevented him from doing that at the
> times when he had the time to prepare the whole move/transition.  (OSG
> releases usually require SONAME/VERSION bumps if not source changes,
> even sometimes between -RC and final releases).

OK.

> openscenegraph is not a leaf package, but much further behind in
> priority than giflib, gdal, xine or ffmepg (and openscenegraph depends
> on a vast number of basic libraries), so in the end the transitions of
> all of these take precedence.  3.4.0 will probably require a
> transition for which maybe all rdeps are not ready, so would be a
> problem for the more important transitions that might get entangled
> with.

I see, it's better not to entangle transitions.

> I don't know if the fact of not including the patch of ffmpeg 2.9/3.0
> was an oversight or on purpose because the plan to upload 3.4, or if
> upstream patches take care of this.  If you plan to start the
> transition of ffmpeg imminently, maybe at this point it's better to
> include the patch than to start a transition also with OSG-3.4.0.

Well, this is imminent in Debian timescales, that is this month,
but not this week. ;)

> ... all of this is subject to Alberto's opinion, who is better
> informed about all of this and follows upstream development closer.  I
> just wanted to chime in because he might be busy and not reply for a
> few days, and specially to explain that moving to 3.4 might not be
> straightforward.

Thanks, this is much appreciated.

Best regards,
Andreas

Bug#807853: k3b: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Pino,

Thanks for your quick reply.

On 08.01.2016 18:12, Pino Toscano wrote:
> Yes, I've seen the patch in #807853, and a couple of review requests on
> KDE's reviewboard.

Could you please post links to upstream discussion about this or mark
the bug as forwarded?

> Let me take this opportunity to "reverse the issue": is your upstream
> aware that the continuous API breaks in each new stable series only
> waste time on the users' side?

I sense frustration in these words, but let's get the facts straight:
 * The last four stable series (2.5.*-2.8.*) didn't break the API.
 * Adapting to the new APIs is no waste of time, rather maintenance cost,
   also improving the API using program in the process, as the old APIs
   were deprecated for a reason.

And yes, the upstream developers are aware of that maintenance cost,
I made sure of that. Please go and read the discussion upstream [1][2].
And I can understand your frustration, after all, I'm the one who wrote
patches for all affected Debian packages.

> Just look at the affected code in k3b,
> plugins/decoder/ffmpeg/k3bffmpegwrapper.cpp: many defines and ifdef's,
> just to make the very same code do the very same job, nothing less and
> nothing more.

I'm well aware how this file looks, as I wrote a patch for it.
And most of these ifdef's could just be removed, unless you need to
build this in ancient environments...

> Sure, if I don't get around to test your patch or to integrate eventual
> upstream fixes the plugin will need to be disabled, but honestly I don't
> see how this would be in favour of our users.

That's why I provided a patch, which should be more than enough to fix
this issue properly for any reasonably maintained software.

Best regards,
Andreas


1: https://lists.libav.org/pipermail/libav-devel/2015-July/071229.html
2: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176439.html

Bug#803876: yorick-av: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Thibaut,

On 08.01.2016 03:38, Thibaut Paumard wrote:
> thanks for the heads up. The package is on its way, thanks for the patch.

Thanks for the quick upload.

> I initially wanted to include it directly upstream but I realise that I
> don't have the time to do so right know.

I see.

Best regards,
Andreas

Bug#803844: mplayer: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Miguel,

On 08.01.2016 03:02, Miguel A. Colón Vélez wrote:
> I was waiting for a clear idea of when FFmpeg was going to release to
> decide if I should patch 1.2 or just take an upstream snapshot. Most
> of the new bugs reports are fixed upstream so I will probably use an
> upstream snapshot.

Wouldn't it be better if all relevant fixes were included in the 1.2.1
release? Packaging snapshots is always a bit problematic as one never
knows when a good time for packaging the next snapshot is and upstream
doesn't really know which version of their code is used.

> Thanks for the reminder.

You're welcome and thanks for the quick reply. :)

Best regards,
Andreas

Bug#803797: amarok: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Diane,

On 08.01.2016 08:47, Diane Trout wrote:
> No I hadn't seen the previous bug report. Thank you for emailing me directly.

Thanks for your quick reply.

> I just looked at your patch and it seems pretty simple

Yes, they are mostly search and replace, though the patch also fixes memory
leaks. (Previously the correct way to free a frame was avcodec_free_frame,
not av_free.)

> though I'd ike to build and run it first.

That's always a good idea.

> Could you point me to any ffmpeg documentation about the deprecations in 2.9

To prevent any misunderstanding: This patch is not about deprecations introduced
in 2.9, but about deprecations from the 2.0 era. The APIs deprecated back then
got removed now. These API changes are documented in the APIchanges document 
[1].
(It's installed in ffmpeg-doc, as well.)
Also there is a Libav website about the (similar) changes in Libav 12 [2].

> If it works I should be able to upload a new version of amarok over the 
> weekend.

That would be great.

> I'm not sure if upstream is aware. They're in beta for a new release so I'll 
> need to go look at their new version. I'll try to do that over the weekend as 
> well.

Thanks.

Best regards,
Andreas


1: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/tree/doc/APIchanges
2: https://wiki.libav.org/Migration/12

Bug#803846: opal: FTBFS with FFmpeg 2.9

[Andreas Cadhalpun]

Hi Eugen,

On 08.01.2016 09:12, Eugen Dedu wrote:
> The release have not happened and will not happen certainly this month.
> So I will very soon apply the path in debian.

Thanks.

Best regards,
Andreas