Re: hello! I would like to join the pkg-multimedia team

[Andrew Kelley]

themill on IRC informed me that Uploader means co-maintainer, not sponsor,
so I fixed those Lintian warnings by adding myself as Uploader.


On Sun, Feb 16, 2014 at 10:59 PM, Andrew Kelley wrote:

> Oops, I'm sorry I forgot to include a link to the changes:
>
>
> https://github.com/andrewrk/debian-pkg-libebur128/commit/eab9dc6b2cd66972ae38a37511037b4b0209a461
>
> Also, after setting the maintainer field to Debian Multimedia Maintainers <
> pkg-multimedia-maintainers@lists.alioth.debian.org> I'm getting these
> Lintian issues:
>
> E: libebur128 source: no-human-maintainers
> W: libebur128 source: changelog-should-mention-nmu
> W: libebur128 source: source-nmu-has-incorrect-version-number 1.0.1-1
>
> I'm not sure how to resolve them.
>
>
>
>
> On Sun, Feb 16, 2014 at 10:50 PM, Andrew Kelley wrote:
>
>> Thank you for your feedback. I have addressed everything so far (in my
>> own repository).
>>
>> I tried to create a repository on alioth like this:
>>
>> $ ssh git.debian.org /git/pkg-multimedia/setup-repository libebur128.git
>> Permission denied (publickey).
>>
>> I put my public key into alioth.debian.org - is there a missing step
>> that I or someone else needs to do to get these permissions working?
>>
>> A couple notes below:
>>
>> On Thu, Feb 13, 2014 at 9:26 AM, Sebastian Ramacher > > wrote:
>>
>>> debian/control:
>>>  - Why Priority: extra?
>>>
>>
>> I looked at another package as an example; I must have chosen a bad
>> example. Anyway I changed it to optional.
>>
>>
>>> There are warnings during the build:
>>>
>>> dpkg-shlibdeps: warning: symbol tan used by
>>> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
>>> libraries
>>> dpkg-shlibdeps: warning: symbol pow used by
>>> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
>>> libraries
>>> dpkg-shlibdeps: warning: symbol log used by
>>> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
>>> libraries
>>>
>>> libebur128 needs to be linked against -lm.
>>>
>>
>> I submitted an upstream patch to fix this:
>> https://github.com/jiixyj/libebur128/pull/27
>>
>>
>>
>>
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: hello! I would like to join the pkg-multimedia team

[Andrew Kelley]

Oops, I'm sorry I forgot to include a link to the changes:

https://github.com/andrewrk/debian-pkg-libebur128/commit/eab9dc6b2cd66972ae38a37511037b4b0209a461

Also, after setting the maintainer field to Debian Multimedia Maintainers <
pkg-multimedia-maintainers@lists.alioth.debian.org> I'm getting these
Lintian issues:

E: libebur128 source: no-human-maintainers
W: libebur128 source: changelog-should-mention-nmu
W: libebur128 source: source-nmu-has-incorrect-version-number 1.0.1-1

I'm not sure how to resolve them.




On Sun, Feb 16, 2014 at 10:50 PM, Andrew Kelley wrote:

> Thank you for your feedback. I have addressed everything so far (in my own
> repository).
>
> I tried to create a repository on alioth like this:
>
> $ ssh git.debian.org /git/pkg-multimedia/setup-repository libebur128.git
> Permission denied (publickey).
>
> I put my public key into alioth.debian.org - is there a missing step that
> I or someone else needs to do to get these permissions working?
>
> A couple notes below:
>
> On Thu, Feb 13, 2014 at 9:26 AM, Sebastian Ramacher 
> wrote:
>
>> debian/control:
>>  - Why Priority: extra?
>>
>
> I looked at another package as an example; I must have chosen a bad
> example. Anyway I changed it to optional.
>
>
>> There are warnings during the build:
>>
>> dpkg-shlibdeps: warning: symbol tan used by
>> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol pow used by
>> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
>> libraries
>> dpkg-shlibdeps: warning: symbol log used by
>> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
>> libraries
>>
>> libebur128 needs to be linked against -lm.
>>
>
> I submitted an upstream patch to fix this:
> https://github.com/jiixyj/libebur128/pull/27
>
>
>
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: hello! I would like to join the pkg-multimedia team

[Andrew Kelley]

Thank you for your feedback. I have addressed everything so far (in my own
repository).

I tried to create a repository on alioth like this:

$ ssh git.debian.org /git/pkg-multimedia/setup-repository libebur128.git
Permission denied (publickey).

I put my public key into alioth.debian.org - is there a missing step that I
or someone else needs to do to get these permissions working?

A couple notes below:

On Thu, Feb 13, 2014 at 9:26 AM, Sebastian Ramacher wrote:

> debian/control:
>  - Why Priority: extra?
>

I looked at another package as an example; I must have chosen a bad
example. Anyway I changed it to optional.


> There are warnings during the build:
>
> dpkg-shlibdeps: warning: symbol tan used by
> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
> libraries
> dpkg-shlibdeps: warning: symbol pow used by
> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
> libraries
> dpkg-shlibdeps: warning: symbol log used by
> debian/libebur128-1/usr/lib/libebur128.so.1.0.1 found in none of the
> libraries
>
> libebur128 needs to be linked against -lm.
>

I submitted an upstream patch to fix this:
https://github.com/jiixyj/libebur128/pull/27
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736108: New upstream release

[Jackson Doak]

It's packaged, just needs a sponsor


On Mon, Feb 17, 2014 at 1:11 PM, Jonathan McCrohan wrote:

> Package: gmusicbrowser
> Version: 1.1.11-1
> Followup-For: Bug #736108
>
> Hi,
>
> gmusicbrowser 1.1.12 is now available.
>
> Please consider packaging it.
>
> Thanks,
> Jon
>
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (650, 'testing'), (600, 'unstable'), (450, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> Versions of packages gmusicbrowser depends on:
> ii  libgstreamer-perl  0.19-1
> ii  libgtk2-perl   2:1.249-1
> ii  libgtk2.0-02.24.22-1
> ii  perl   5.18.2-2
>
> Versions of packages gmusicbrowser recommends:
> ii  libcairo-perl   1.104-1
> pn  libdigest-crc-perl  
> ii  libgtk2-notify-perl 0.05-3+b2
> ii  libgtk2-trayicon-perl   0.06-1+b3
> ii  libhtml-parser-perl 3.71-1+b1
> ii  libintl-perl1.23-1
> ii  liblocale-gettext-perl  1.05-7+b2
> ii  libnet-dbus-perl1.0.0-2+b1
> ii  perl [libio-compress-perl]  5.18.2-2
>
> Versions of packages gmusicbrowser suggests:
> ii  alsa-utils1.0.27.2-1
> pn  libgnome2-wnck-perl   
> pn  libgstreamer-interfaces-perl  
> pn  libgtk2-mozembed-perl 
> ii  mpg3210.3.2-1.1
> pn  mplayer   
> ii  vorbis-tools  1.4.0-1
>
> -- no debconf information
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#736108: New upstream release

[Jonathan McCrohan]

Package: gmusicbrowser
Version: 1.1.11-1
Followup-For: Bug #736108

Hi,

gmusicbrowser 1.1.12 is now available.

Please consider packaging it.

Thanks,
Jon

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (450, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gmusicbrowser depends on:
ii  libgstreamer-perl  0.19-1
ii  libgtk2-perl   2:1.249-1
ii  libgtk2.0-02.24.22-1
ii  perl   5.18.2-2

Versions of packages gmusicbrowser recommends:
ii  libcairo-perl   1.104-1
pn  libdigest-crc-perl  
ii  libgtk2-notify-perl 0.05-3+b2
ii  libgtk2-trayicon-perl   0.06-1+b3
ii  libhtml-parser-perl 3.71-1+b1
ii  libintl-perl1.23-1
ii  liblocale-gettext-perl  1.05-7+b2
ii  libnet-dbus-perl1.0.0-2+b1
ii  perl [libio-compress-perl]  5.18.2-2

Versions of packages gmusicbrowser suggests:
ii  alsa-utils1.0.27.2-1
pn  libgnome2-wnck-perl   
pn  libgstreamer-interfaces-perl  
pn  libgtk2-mozembed-perl 
ii  mpg3210.3.2-1.1
pn  mplayer   
ii  vorbis-tools  1.4.0-1

-- no debconf information

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 7:28 PM, peter green  wrote:
> Reinhard Tartler wrote:
>>
>> I mean line 55
>
> I've just looked at ./configure --help and AIUI there are four possible
> values of --with-cpu for arm systems
>
> --with-cpu=generic_fpu  Use generic processor code with floating point
> arithmetic
> --with-cpu=generic_nofpu  Use generic processor code with fixed point
> arithmetic (p.ex. ARM, experimental)
> --with-cpu=generic_dither Use generic processor code with floating point
> arithmetic and dithering for 1to1 16bit decoding.
> --with-cpu=neon Use code optimized for ARM NEON SIMD engine
> (Cortex-A series)
> --with-cpu=arm_nofpuUse code optimized for ARM processors with fixed
> point arithmetic (experimental)
>
> We can't use the neon option because no arm port of debian gaurantees that
> neon will be available. So I belive until the no-fpu options are made
> compatible with audacious and/or some form of runtime detection is
> implemeted (either using ld.so.hwcaps to load different versions of the
> library) we need to keep using --with-generic-fpu on all our arm ports.

I see. In that case, I'll have to leave the package as it until
something along those lines is implemented.

Thanks for your input!

-- 
regards,
Reinhard

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[peter green]

Reinhard Tartler wrote:
I mean line 55 
  
I've just looked at ./configure --help and AIUI there are four possible 
values of --with-cpu for arm systems


--with-cpu=generic_fpu  Use generic processor code with floating 
point arithmetic
--with-cpu=generic_nofpu  Use generic processor code with fixed 
point arithmetic (p.ex. ARM, experimental)
--with-cpu=generic_dither Use generic processor code with floating 
point arithmetic and dithering for 1to1 16bit decoding.
--with-cpu=neon Use code optimized for ARM NEON SIMD engine 
(Cortex-A series)
--with-cpu=arm_nofpuUse code optimized for ARM processors with fixed 
point arithmetic (experimental)


We can't use the neon option because no arm port of debian gaurantees 
that neon will be available. So I belive until the no-fpu options are 
made compatible with audacious and/or some form of runtime detection is 
implemeted (either using ld.so.hwcaps to load different versions of the 
library) we need to keep using --with-generic-fpu on all our arm ports.


>to limit the effect of not using a FPU to just armel.
Assuming generic_fpu uses the standard floating point functionality in 
the C compiler it WILL use the FPU on Debian armhf and raspbian (but not 
on armel)


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

Bug#734100: #734100: vlc: Video stuttering with ALSA output

[Adam Cécile (Le_Vert)]

Hello,

I can confirm this issue. It's really annoying because it renders VLC 
unusable. I had to switch to mplayer...


Regards, Adam.

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 7:02 PM, peter green  wrote:
> Reinhard Tartler wrote:
>>
>> With this explanation, I think it would help a lot to all armhf users
>> if the following line was restricted to the armel port:
>>
>>
>> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpg123.git;a=blob;f=debian/rules;h=afb018502621352914e757338a2dace6b65522cb;hb=HEAD#l25
>>
>
> Umm that link just goes to a page with a copy of your whole debian/rules
> file, can you tell us what line you are reffering to?

I mean line 55 to limit the effect of not using a FPU to just armel.



-- 
regards,
Reinhard

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[peter green]

Reinhard Tartler wrote:

With this explanation, I think it would help a lot to all armhf users
if the following line was restricted to the armel port:

http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpg123.git;a=blob;f=debian/rules;h=afb018502621352914e757338a2dace6b65522cb;hb=HEAD#l25
  
Umm that link just goes to a page with a copy of your whole debian/rules 
file, can you tell us what line you are reffering to?


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

Bug#739238: FTBFS with libav10

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 6:12 PM, Moritz Muehlenhoff  wrote:
> Source: blender
> Severity: important
>
> Hi,
> your package fails to build from source against libav 10 (currently
> packaged in experimental). This bug will become release-critical
> at some point when the libav10 transition starts.
>
> Migration documentation can be found at
> https://wiki.libav.org/Migration/10
>
> Cheers,
> Moritz
>
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c: 
> In function 'BKE_ffmpeg_image_type_verify':
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1578:28:
>  error: 'CODEC_ID_MPEG2VIDEO' undeclared (first use in this function)
> rd->ffcodecdata.codec = CODEC_ID_MPEG2VIDEO;
> ^
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1589:32:
>  error: 'CODEC_ID_H264' undeclared (first use in this function)
>if (rd->ffcodecdata.codec != CODEC_ID_H264) {
> ^
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1601:32:
>  error: 'CODEC_ID_THEORA' undeclared (first use in this function)
>if (rd->ffcodecdata.codec != CODEC_ID_THEORA) {
> ^
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c: 
> In function 
> 'BKE_ffmpeg_alpha_channel_is_supported':/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1622:15:
>  error: 'CODEC_ID_QTRLE' undeclared (first use in this function)
>   if (codec == CODEC_ID_QTRLE)
>^
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1625:15:
>  error: 'CODEC_ID_PNG' undeclared (first use
> in this function)
>   if (codec == CODEC_ID_PNG)
>^
> /home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1629:15:
>  error: 'CODEC_ID_FFV1' undeclared (first use in this function)
>   if (codec == CODEC_ID_FFV1)
>^
> cc1: some warnings being treated as errors
> make[3]: *** 
> [source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/writeffmpeg.c.o]
>  Error 1
> make[3]: Leaving directory `/home/jmm/av10/blender-2.69/obj-x86_64-linux-gnu'
> make[2]: *** [source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/all] 
> Error 2
> make[2]: Leaving directory `/home/jmm/av10/blender-2.69/obj-x86_64-linux-gnu'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/jmm/av10/blender-2.69/obj-x86_64-linux-gnu'
> dh_auto_build: make -j1 returned exit code 2
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>

These two upstream patches should fix this:

http://git.blender.org/gitweb/gitweb.cgi/blender.git/commitdiff/8c3b27ce279f1f0904af3c220d92acfa1f20a70e
http://git.blender.org/gitweb/gitweb.cgi/blender.git/commitdiff/b7f8bfef2506dfd44d638e2280f00e301823fb2c

-- 
regards,
Reinhard

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 6:37 PM, peter green  wrote:
> Reinhard Tartler wrote:
>>
>> Dear ARM porters,
>>
>> Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
>> for full context. I've uploaded a patch proposed by Riku that AFAIUI
>> makes mpg123 really slow on all arm targets, while unbreaking it on
>> some others.
>>
>> As one of the maintainers of the mpg123 without familiarity about the
>> scope of the Debian arm port
>
> Debian has TWO official arm ports.
>
> Armel has a minimum CPU requirement of armv4t with no gaurantee that there
> will be any floating point hardware at all.
> Armhf has a minimum CPU requirement of armv7-a with vfpv3-d16, neon is not
> gauranteed to be available (but it is very likely to be in pratice).
>
> As well as the two official arm ports there is also Raspbian which targets
> armv6 with vfpv2, raspbian also uses the armhf architecture name but can be
> distinguished by using dpkg-vendor.

With this explanation, I think it would help a lot to all armhf users
if the following line was restricted to the armel port:

http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpg123.git;a=blob;f=debian/rules;h=afb018502621352914e757338a2dace6b65522cb;hb=HEAD#l25

Does anyone disagree that this is a good move, at least until
something like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981#25
is implemented?

-- 
regards,
Reinhard

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[peter green]

Reinhard Tartler wrote:

Dear ARM porters,

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
for full context. I've uploaded a patch proposed by Riku that AFAIUI
makes mpg123 really slow on all arm targets, while unbreaking it on
some others.

As one of the maintainers of the mpg123 without familiarity about the
scope of the Debian arm port

Debian has TWO official arm ports.

Armel has a minimum CPU requirement of armv4t with no gaurantee that 
there will be any floating point hardware at all.
Armhf has a minimum CPU requirement of armv7-a with vfpv3-d16, neon is 
not gauranteed to be available (but it is very likely to be in pratice).


As well as the two official arm ports there is also Raspbian which 
targets armv6 with vfpv2, raspbian also uses the armhf architecture name 
but can be distinguished by using dpkg-vendor.



-- Forwarded message --
From: Thomas Orgis 
Date: Sun, Feb 16, 2014 at 5:46 AM
Subject: Bug#738981: Switch to use generic_fpu for ARM
To: 738...@bugs.debian.org


Sorry for being late to the party, but I have to say that this is a
rather unfortunate situation now. Not using the assembly-optimized
fixed-point ARM code of the arm_nofpu decoder and resorting to the
generic_fpu one (all plain C) will make mpg123 really slow in
comparison. I'm not sure what hardware we are targeting here ... is it
armel with softfloat? With gcc -mfpu=vfp, generic_fpu might be fine,
although using the neon decoder is still preferred on supporting CPUs.

There is no runtime detection in mpg123 for this and at least for the
decision of fixed or floating point decoding, it likely will never be
as that is a very basic decision on the whole decoder code, not just
some optimization. I can imagine combining generic_fpu and neon builds
with run-time detection,
That would seem like it would be a good approach for Debian armhf if it 
was implemented.



 but this still assumes a hardware floating
point unit to make sense. We have arm_nofpu and generic_nofpu for the
cases without one.

Something which is possible right now is to produce one libmpg123.so with
the standard build to please users using slow ARM machines who just
want plain 16 bit playback and produce one libmpg123_float.so for people
using beefy machines and who are using audacious as a media player.
  
Seems like a good approach if the so files can be gauranteed to be ABI 
compatible. There is already a mechanism for loading different versions 
of libraries based on hardware capabilities.

I could implement a conversion step to floating point with the
arm_nofpu decoder. That would make audacious work (although wasting
precision on machines that have hardware floating point, or even NEON)
and have the benefit of the command-line mpg123 still being fast with
16 bit output.
Seems like a reasoanable idea for armel, frankly people who have vfp 
hardware probablly shouldn't be running armel anyway.


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

Bug#739243: FTBFS with libav10

[Moritz Muehlenhoff]

Package: fuse-emulator-utils
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

fmfconv_ff.c: In function 'ffmpeg_resample_audio':
fmfconv_ff.c:136:5: warning: implicit declaration of function 
'audio_resample_close' [-Wimplicit-function-declaration]
 audio_resample_close( audio_resample_ctx );
 ^
fmfconv_ff.c:148:5: warning: implicit declaration of function 
'av_audio_resample_init' [-Wimplicit-function-declaration]
 audio_resample_ctx = av_audio_resample_init( out_chn, snd_chn,
 ^
fmfconv_ff.c:148:24: warning: assignment makes pointer from integer without a 
cast [enabled by default]
 audio_resample_ctx = av_audio_resample_init( out_chn, snd_chn,
^
fmfconv_ff.c:163:3: warning: implicit declaration of function 'audio_resample' 
[-Wimplicit-function-declaration]
   len = audio_resample( audio_resample_ctx,
   ^
fmfconv_ff.c: At top level:
fmfconv_ff.c:227:24: warning: 'enum CodecID' declared inside parameter list 
[enabled by default]
 add_audio_stream( enum CodecID codec_id, int freq, int stereo )
^
fmfconv_ff.c:227:24: warning: its scope is only this definition or declaration, 
which is probably not what you want [enabled by
default]
fmfconv_ff.c:227:32: error: parameter 1 ('codec_id') has incomplete type
 add_audio_stream( enum CodecID codec_id, int freq, int stereo )
^
fmfconv_ff.c: In function 'ffmpeg_add_sound_ffmpeg':
fmfconv_ff.c:346:7: warning: implicit declaration of function 
'avcodec_encode_audio' [-Wimplicit-function-declaration]
   pkt.size = avcodec_encode_audio( c, audio_outbuf, audio_outbuf_size, 
audio_inpbuf );
   ^
fmfconv_ff.c: At top level:
fmfconv_ff.c:443:24: warning: 'enum CodecID' declared inside parameter list 
[enabled by default]
 add_video_stream( enum CodecID codec_id, int w, int h, int timing )
fmfconv_ff.c: In function 'alloc_picture':
fmfconv_ff.c:508:3: warning: 'avcodec_alloc_frame' is deprecated (declared at 
/usr/include/libavcodec/avcodec.h:3110) [-Wdeprecated-declarations]
   picture = avcodec_alloc_frame();
   ^
fmfconv_ff.c: In function 'ffmpeg_add_frame_ffmpeg':
fmfconv_ff.c:625:5: warning: implicit declaration of function 
'avcodec_encode_video' [-Wimplicit-function-declaration]
 out_size = avcodec_encode_video( c, video_outbuf, video_outbuf_size, 
ffmpeg_pict );
 ^
fmfconv_ff.c: In function 'out_write_ffmpegheader':
fmfconv_ff.c:677:16: error: storage size of 'acodec' isn't known
   enum CodecID acodec, vcodec;
^
fmfconv_ff.c:677:24: error: storage size of 'vcodec' isn't known
   enum CodecID acodec, vcodec;
^
fmfconv_ff.c:728:41: error: 'CODEC_ID_NONE' undeclared (first use in this 
function)
   if( out_t == TYPE_FFMPEG && vcodec != CODEC_ID_NONE ) {
 ^
fmfconv_ff.c:728:41: note: each undeclared identifier is reported only once for 
each function it appears in
fmfconv_ff.c:677:24: warning: unused variable 'vcodec' [-Wunused-variable]
   enum CodecID acodec, vcodec;
^
fmfconv_ff.c:677:16: warning: unused variable 'acodec' [-Wunused-variable]
   enum CodecID acodec, vcodec;
^
make[3]: *** [fmfconv_ff.o] Error 1
make[3]: Leaving directory `/home/jmm/av10/fuse-emulator-utils-1.1.1'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jmm/av10/fuse-emulator-utils-1.1.1'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/fuse-emulator-utils-1.1.1'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#739242: FTBFS with libav10

[Moritz Muehlenhoff]

Source: freerdp
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz


[ 79%] Building C object 
channels/drdynvc/tsmf/ffmpeg/CMakeFiles/tsmf_ffmpeg.dir/tsmf_ffmpeg.c.o
cd 
/home/jmm/av10/freerdp-1.0.2/obj-x86_64-linux-gnu/channels/drdynvc/tsmf/ffmpeg 
&& /usr/bin/cc  -Dtsmf_ffmpeg_EXPORTS -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2  
-Wall -Wno-unused-result -Wno-unused-but-set-variable -fPIC 
-I/home/jmm/av10/freerdp-1.0.2/obj-x86_64-linux-gnu 
-I/home/jmm/av10/freerdp-1.0.2/include 
-I/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/.. 
-I/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/.. 
-I/usr/include/libavcodec -I/usr/include/libavutil-o 
CMakeFiles/tsmf_ffmpeg.dir/tsmf_ffmpeg.c.o   -c 
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:42:15: 
error: field 'codec_id' has incomplete type
  enum CodecID codec_id;
   ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c: In 
function 'tsmf_ffmpeg_init_context':
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:57:2: 
warning: implicit declaration of function 'avcodec_alloc_context' 
[-Wimplicit-function-declaration]
  mdecoder->codec_context = avcodec_alloc_context();
  ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:57:26: 
warning: assignment makes pointer from integer without a cast [enabled by 
default]
  mdecoder->codec_context = avcodec_alloc_context();
  ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c: In 
function 'tsmf_ffmpeg_init_video_stream':
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:77:2: 
warning: 'avcodec_alloc_frame' is deprecated (declared at 
/usr/include/libavcodec/avcodec.h:3110) [-Wdeprecated-declarations]
  mdecoder->frame = avcodec_alloc_frame();
  ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c: In 
function 'tsmf_ffmpeg_init_audio_stream':
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:92:25: 
error: 'AVCodecContext' has no member named 'dsp_
  mdecoder->codec_context->dsp_mask = AV_CPU_FLAG_SSE2 | AV_CPU_FLAG_MMX2;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c: In 
function 'tsmf_ffmpeg_prepare':
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:177:2: 
warning: implicit declaration of function 'avcodec_open' 
[-Wimplicit-function-declaration]
  if (avcodec_open(mdecoder->codec_context, mdecoder->codec) < 0)
  ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c: In 
function 'tsmf_ffmpeg_set_format':
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:206:25: 
error: 'CODEC_ID_VC1' undeclared (first use in this function)
mdecoder->codec_id = CODEC_ID_VC1;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:206:25: 
note: each undeclared identifier is reported only once for each function it 
appears in
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:209:25: 
error: 'CODEC_ID_WMAV2' undeclared (first use in this function)
mdecoder->codec_id = CODEC_ID_WMAV2;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:212:25: 
error: 'CODEC_ID_WMAPRO' undeclared (first use i
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:215:25: 
error: 'CODEC_ID_MP3' undeclared (first use in this function)
mdecoder->codec_id = CODEC_ID_MP3;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:218:25: 
error: 'CODEC_ID_MP2' undeclared (first use in this function)
mdecoder->codec_id = CODEC_ID_MP2;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:221:25: 
error: 'CODEC_ID_MPEG2VIDEO' undeclared (first use in this function)
mdecoder->codec_id = CODEC_ID_MPEG2VIDEO;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:224:25: 
error: 'CODEC_ID_WMV3' undeclared (first use in
this function)
mdecoder->codec_id = CODEC_ID_WMV3;
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:227:25: 
error: 'CODEC_ID_AAC' undeclared (first use in this function)
mdecoder->codec_id = CODEC_ID_AAC;
 ^
/home/jmm/av10/freerdp-1.0.2/channels/drdynvc/tsmf/ffmpeg/tsmf_ffmpeg.c:239:25: 
error: 'CODEC_ID_H264' undeclared (first use in
this function)
mdecoder->codec_id = CODEC_ID_H264;

Bug#739239: FTBFS with libav10

[Moritz Muehlenhoff]

Package: forked-daapd
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

filescanner_ffmpeg.c:616:20: error: use of undeclared identifier 
'CODEC_ID_WMALOSSLESS'; did you mean 'AV_CODEC_ID_WMALOSSLESS'?  || 
(codec_id == CODEC_ID_WMALOSSLESS))
  ^~~~
  AV_CODEC_ID_WMALOSSLESS
/usr/include/libavcodec/avcodec.h:408:5: note: 'AV_CODEC_ID_WMALOSSLESS' 
declared here
AV_CODEC_ID_WMALOSSLESS,
^
filescanner_ffmpeg.c:624:28: error: use of undeclared identifier 
'CODEC_ID_FLAC'; did you mean 'AV_CODEC_ID_FLAC'?
  else if (codec_id == CODEC_ID_FLAC)
   ^
   AV_CODEC_ID_FLAC
/usr/include/libavcodec/avcodec.h:379:5: note: 'AV_CODEC_ID_FLAC' declared here
AV_CODEC_ID_FLAC,
^
filescanner_ffmpeg.c:633:29: error: use of undeclared identifier 
'CODEC_ID_MUSEPACK7'; did you mean 'AV_CODEC_ID_MUSEPACK7'?
  else if ((codec_id == CODEC_ID_MUSEPACK7)
^~
AV_CODEC_ID_MUSEPACK7
/usr/include/libavcodec/avcodec.h:395:5: note: 'AV_CODEC_ID_MUSEPACK7' declared 
here
AV_CODEC_ID_MUSEPACK7,
^
filescanner_ffmpeg.c:634:25: error: use of undeclared identifier 
'CODEC_ID_MUSEPACK8'; did you mean 'AV_CODEC_ID_MUSEPACK8'?
   || (codec_id == CODEC_ID_MUSEPACK8))
   ^~
   AV_CODEC_ID_MUSEPACK8
/usr/include/libavcodec/avcodec.h:404:5: note: 'AV_CODEC_ID_MUSEPACK8' declared 
here
AV_CODEC_ID_MUSEPACK8,
^
1 warning and 12 errors generated.
make[4]: *** [forked_daapd-filescanner_ffmpeg.o] Error 1
make[4]: Leaving directory `/home/jmm/av10/forked-daapd-0.19gcd/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/jmm/av10/forked-daapd-0.19gcd/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jmm/av10/forked-daapd-0.19gcd'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/forked-daapd-0.19gcd'
make: *** [build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#739238: FTBFS with libav10

[Moritz Muehlenhoff]

Source: blender
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c: In 
function 'BKE_ffmpeg_image_type_verify':
/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1578:28:
 error: 'CODEC_ID_MPEG2VIDEO' undeclared (first use in this function)
rd->ffcodecdata.codec = CODEC_ID_MPEG2VIDEO;
^
/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1589:32:
 error: 'CODEC_ID_H264' undeclared (first use in this function)
   if (rd->ffcodecdata.codec != CODEC_ID_H264) {
^
/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1601:32:
 error: 'CODEC_ID_THEORA' undeclared (first use in this function)
   if (rd->ffcodecdata.codec != CODEC_ID_THEORA) {
^
/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c: In 
function 
'BKE_ffmpeg_alpha_channel_is_supported':/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1622:15:
 error: 'CODEC_ID_QTRLE' undeclared (first use in this function)
  if (codec == CODEC_ID_QTRLE)
   ^
/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1625:15:
 error: 'CODEC_ID_PNG' undeclared (first use
in this function)
  if (codec == CODEC_ID_PNG)
   ^
/home/jmm/av10/blender-2.69/source/blender/blenkernel/intern/writeffmpeg.c:1629:15:
 error: 'CODEC_ID_FFV1' undeclared (first use in this function)
  if (codec == CODEC_ID_FFV1)
   ^
cc1: some warnings being treated as errors
make[3]: *** 
[source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/intern/writeffmpeg.c.o] 
Error 1
make[3]: Leaving directory `/home/jmm/av10/blender-2.69/obj-x86_64-linux-gnu'
make[2]: *** [source/blender/blenkernel/CMakeFiles/bf_blenkernel.dir/all] Error 
2
make[2]: Leaving directory `/home/jmm/av10/blender-2.69/obj-x86_64-linux-gnu'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/blender-2.69/obj-x86_64-linux-gnu'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#739237: FTBFS with libav10

[Moritz Muehlenhoff]

Package: ffmpeg2theora
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

Checking for oggkate... (cached) yes
Checking for C header file iconv.h... yes
Checking for C library iconv... no
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/subtitles.o -c -DPACKAGE_VERSION=\"0.29\" 
-DPACKAGE_STRING=\"ffmpeg2theora-0.29\" -DPACKAGE=\"ffmpeg2theora\" 
-D_FILE_OFFSET_BITS=64 -DHAVE_KATE -DHAVE_OGGKATE -DHAVE_ICONV -I. 
src/subtitles.c
In file included from src/subtitles.h:7:0,
 from src/subtitles.c:39:
src/ffmpeg2theora.h:65:5: error: unknown type name 'ReSampleContext'
 ReSampleContext *audio_resample_ctx;
 ^
scons: *** [src/subtitles.o] Error 1
scons: building terminated because of errors.
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/ffmpeg2theora-0.29'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Processed: jack-tools: diff for NMU version 20101210-2.1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 724395 + pending
Bug #724395 [src:jack-tools] Please stop build depending on automake1.4, 
automake1.9 and automake1.10
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
724395: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724395
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#724395: jack-tools: diff for NMU version 20101210-2.1

[Eric Dorland]

tags 724395 + pending
thanks

Dear maintainer,

I've prepared an NMU for jack-tools (versioned as 20101210-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com

diff -Nru jack-tools-20101210/debian/changelog jack-tools-20101210/debian/changelog
--- jack-tools-20101210/debian/changelog	2012-01-10 14:02:12.0 -0500
+++ jack-tools-20101210/debian/changelog	2014-02-16 15:27:09.0 -0500
@@ -1,3 +1,11 @@
+jack-tools (20101210-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control, debian/rules: Switch to automake1.11. (Closes:
+#724395)
+
+ -- Eric Dorland   Sun, 16 Feb 2014 15:27:09 -0500
+
 jack-tools (20101210-2) unstable; urgency=low
 
   * Team upload.
diff -Nru jack-tools-20101210/debian/control jack-tools-20101210/debian/control
--- jack-tools-20101210/debian/control	2012-01-10 14:22:05.0 -0500
+++ jack-tools-20101210/debian/control	2014-02-16 15:25:50.0 -0500
@@ -6,7 +6,7 @@
  Jonas Smedegaard 
 Build-Depends: cdbs,
  libtool,
- automake1.10,
+ automake1.11,
  autoconf,
  debhelper (>= 6),
  bzip2,
diff -Nru jack-tools-20101210/debian/rules jack-tools-20101210/debian/rules
--- jack-tools-20101210/debian/rules	2012-01-10 13:43:57.0 -0500
+++ jack-tools-20101210/debian/rules	2014-02-16 15:26:03.0 -0500
@@ -18,9 +18,9 @@
 # along with this program.  If not, see .
 
 DEB_AUTO_UPDATE_LIBTOOL = pre
-DEB_AUTO_UPDATE_ACLOCAL = 1.10
+DEB_AUTO_UPDATE_ACLOCAL = 1.11
 DEB_AUTO_UPDATE_AUTOCONF = 2.60
-DEB_AUTO_UPDATE_AUTOMAKE = 1.10
+DEB_AUTO_UPDATE_AUTOMAKE = 1.11
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/utils.mk


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

Processing of jack-tools_20101210-2.1_amd64.changes

[Debian FTP Masters]

jack-tools_20101210-2.1_amd64.changes uploaded successfully to localhost
along with the files:
  jack-tools_20101210-2.1.dsc
  jack-tools_20101210-2.1.debian.tar.xz
  jack-tools_20101210-2.1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

Re: [DVBCUT-devel] Qt4 port and further directions

[Reinhard Tartler]

On Sun, Apr 21, 2013 at 5:51 PM, Wolfgang Baron  wrote:
> On 04/20/2013 08:04 AM, Reinhard Tartler wrote:
>> On Fri, Apr 19, 2013 at 1:59 AM, Wolfgang Baron  
>> wrote:
>>> Hi all,
>>>
>>> I started porting dvbcut from Qt3 to Qt4 on 2013-03-29, based on the
>>> most current svn sources late at night in my free time using mercurial
>>> for storing the history. My first aim was to port dvbcut to Qt4 and add
>>> multiple source videos.
>> Please let me in the role of one of the Debian/Ubuntu package
>> maintainers of the dvbcut package say you a big, big thank you for
>> working on that. Qt3 is really a showstopper for distribution
>> use-cases.
> Now I know what you must be going through. This was my first Qt3->Qt4
> port and I hope it will be my last :)
>> I also wanted to point you out to the patches that we apply in Debian
>> to the dvbcut package:
>>
>> http://patch-tracker.debian.org/package/dvbcut/0.5.4+svn178-3
>>
>> Maybe you find one or the other patch useful, espc. the gcc 4.7 and
>> Libav 9 patches.
>>
>> Please do not hesitate to write me an email if you have any questions.
>>
> Thank you for your helpful information. That was exactly what I was
> looking for. I will try to make this project as easy to package as
> possible and I will appreciate any help with accomplishing that. First
> of all, I will have to get the project up and running, and then I will
> definately contact you.
>
> Cheers,

Hi Wolfgang.

I wonder how is it going with dvbcut? Are you still working on it?

In debian, we are currently trying to move to libav10, and dvbcut
fails to compile against it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739220

Before spending too much time on dvbcut, I wonder if it made sense to
keep dvbcut in Debian? We currently carry quite a number of patches:
http://patch-tracker.debian.org/package/dvbcut/0.5.4+svn178-4 that
really should go upstream.

Thanks for any input,
Reinhard



-- 
regards,
Reinhard

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

Bug#732159: Should this package be removed?

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
 wrote:
> On Sun, Feb 16, 2014 at 12:16:59PM -0500, Reinhard Tartler wrote:

>> In lack of any *constructive* comments about this, I would say yes,
>> let's remove them.
>
> What would constitute a constructive comment?

Ideally "I am interested in making mplayer work against the libavcodec
that we have in Debian, and this is my work in progress".

> mplayer2 is unmaintained and as far as I can tell mpv has completely
> different command-line syntax at the least (though I am not well
> informed about either).

It was my sincere hope that this would be a sufficient incentive and
motivation to work on keeping mplayer/mencoder in debian.
Unfortunately, it seems I was wrong.

> Libav compatibility is not intentionally broken upstream, but it
> is not tested in any systematic way either (possibly not at all).

This is not the primary concern or reason in the context of whether or
not to remove mplayer/mencoder from Debian. The reason is that there
is nobody who is interested enough to work on making it suitable in
Debian. Otherwise we wouldn't have to remove the package from
Debian/testing (jessie).

Personal remark here: mplayer was always problematic in Debian. Up to
today, it is not possible to even compile mplayer without removing its
internal copy of ffmpeg. This was only acceptable because I made sure
that its internal copy is only used at build-time, allowing mplayer to
access internal functionality that is not part of the public API. This
makes maintaining mplayer in Debian much more challenging, and
basically means that mplayer and libav always need to be updated in
lockstep. It is true that for quite some time I used my mplayer svn
commit privileges to make it possible to use libav instead of ffmpeg
as internal copy. I stopped doing this work, mainly because I felt
that these kind of work is not welcome inside mplayer. BTW, this is
the main reason why I cannot support mplayer/mencoder anymore in
Debian.

Both mplayer2 and mpv work just fine without any internal copy of
libavcodec and friends.

BTW, as soon as someone appears that actually manages to maintain the
mplayer/mencoder package, we can always re-introduce the package to
Debian. Actually, I would be very interested in that, but not before
there was some mplayer release that stopped requiring an internal copy
of libav* - These days, I'm unable to cope with the amount of work
that I had to invest to keep mplayer up-to-date in Debian so far,
sorry.

> Though I agree that there is little point in keeping the outdated
> rc4 version.
> But one more point: I am not sure all programs using mencoder
> will have it as a dependency correctly.

That would be very unfortunate. Please file bugs if you find packages
that lack this dependency.

> For example flvtool (exists only in stable though it seems) should
> be using mencoder for some tasks but does not list it as a
> dependency.

We are discussing removal from unstable here, not stable.

> Now, deb-multimedia.org provides it anyway so it won't leave people
> completely stranded, but I wonder if maybe there was a way to
> somehow point people there when they try something like
> "apt-get install mencoder"?

I disagree that deb-multimedia.org is actually helping here. I would
rather recommend people that want to use mencoder on Debian to just
follow upstream's recommendation: compile it yourself, and statically
link against its internal copy of libavcodec.

> I can see why you might have some concerns with that, but it would
> seem like a kind of user-friendly solution to me that doesn't
> require much effort from anyone...

I don't share this understanding of "user-friendly". (cf.
https://wiki.debian.org/DebianMultimedia/FAQ#A_recent_upgrade_of_ffmpeg.2Flibav-related_library_packages_.28e.g._libavcodec.29_has_broken_related_software_.28e.g._Totem.2C_MPlayer.2C_VLC.2C_Xine.29)


-- 
regards,
Reinhard

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

Bug#738981: Switch to use generic_fpu for ARM

[Thomas Orgis]

Am Sun, 16 Feb 2014 12:14:46 -0500
schrieb Reinhard Tartler : 

> Thomas, in libavcodec, we "solve" (or rather, workaround, depending on
> the PoV) this problem by compiling the libraries multiple times

A sane approach. Runtime code selection in each application can be
stretched beyond the boundary of it being fun quickly.

> ...
> be possible to do something like this for mpg123 as well? This would
> then require to compile
> 
> /usr/lib/arm-linux-gnueabi/libmpg123.so.0
> for different flavors. However, we would need to make sure that
> /usr/bin/mpg123 works with any of them.

That would certainly work and is what I imagined. If this offers
link-time choice of fixed point, vfp or neon, I'd be overly happy for
avoiding headache over making runtime choice inside one build
(which seems rather impractical).

> I'm wondering if this pattern
> wouldn't work for mpg123, but I'm not familiar enough with the
> codebase to say if this would work. Can you please comment?

I don't see am obvious problem. As long as basic ABI fits (also regarding
floating point args), this should work as well as libavcodec. The
mpg123 binary queries the library for things like format support and
decoder engine and one build can work with arm_nofpu or generic_nofpu
(arm-linux-gnueabi), generic_fpu (arm-linux-gnueabi/vfp) and arm_neon
(arm-linux-gnueabi/neon/vfp/). I suppose the gnueabihf variants need an
separate build for the changed ABI of floating point arguments (?).

When setting up the environment to use a specific libmpg123, one should
see an effect in the output of

mpg123 --list-cpu

Just build mpg123 several times, with proper CFLAGS for -march and
friends and matching --with-cpu for configure. You can pick which
mpg123 binary to use, I suggest the most universal one. In the mpg123
binary itself, there is no assembly code affected by the --with-cpu
switch and the performance-relevant bits are in libmpg123. Same for the
other helper applications (mpg123-id3dump, mpg123-strip).

The only issue still present would be that the most basic libmpg123
still misses floating point output format for audacious. But my guess
is that you wouldn't use that player on a system without floating point
hardware. As I said, I can change that, for the sake of completeness
adding a bit of code converting from 16 bit to 32 bit float (and 24 and
32 bit integer) in the output buffer.

The only remaining difference between the libraries would be
performance and accuracy of output. Were you aware of the
--enable-int-quality flag to configure? Yet another set of decoders
being a bit slower but doing better rounding to 16 bit integers;-)

In any case, you might want to check out
mpg123's tests to verify that your various builds
decode properly:

svn co svn://svn.orgis.org/mpg123/test mpg123-test
cd mpg123-test
make # build helper programs (rms computation)
perl compliance.pl /path/to/mpg123

This makes a basic MPEG ISO compliance test, comparing decoder to
reference output (see http://mpg123.org, after scrolling down a bit).

Disclaimer: If anything does not work as I just promised, this is a bug
and will be addressed;-)


Alrighty then,

Thomas



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

Processing of ices2_2.0.1-13.1_amd64.changes

[Debian FTP Masters]

ices2_2.0.1-13.1_amd64.changes uploaded successfully to localhost
along with the files:
  ices2_2.0.1-13.1.dsc
  ices2_2.0.1-13.1.debian.tar.xz
  ices2_2.0.1-13.1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

Processed: ices2: diff for NMU version 2.0.1-13.1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 724393 + pending
Bug #724393 [src:ices2] Please stop build depending on automake1.4, automake1.9 
and automake1.10
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
724393: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724393
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#724393: ices2: diff for NMU version 2.0.1-13.1

[Eric Dorland]

tags 724393 + pending
thanks

Dear maintainer,

I've prepared an NMU for ices2 (versioned as 2.0.1-13.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com

diff -Nru ices2-2.0.1/debian/changelog ices2-2.0.1/debian/changelog
--- ices2-2.0.1/debian/changelog	2012-06-05 14:30:23.0 -0400
+++ ices2-2.0.1/debian/changelog	2014-02-16 15:11:08.0 -0500
@@ -1,3 +1,11 @@
+ices2 (2.0.1-13.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control, debian/rules: Switch to automake1.11. (Closes:
+#724393)
+
+ -- Eric Dorland   Sun, 16 Feb 2014 15:11:08 -0500
+
 ices2 (2.0.1-13) unstable; urgency=low
 
   * Add patch 1004 to fix explicitly link against libogg, needed with
diff -Nru ices2-2.0.1/debian/control ices2-2.0.1/debian/control
--- ices2-2.0.1/debian/control	2012-06-05 14:32:28.0 -0400
+++ ices2-2.0.1/debian/control	2014-02-16 15:10:07.0 -0500
@@ -9,7 +9,7 @@
 Build-Depends: cdbs,
  autotools-dev,
  libtool,
- automake1.10,
+ automake1.11,
  autoconf,
  debhelper,
  dh-buildinfo,
diff -Nru ices2-2.0.1/debian/rules ices2-2.0.1/debian/rules
--- ices2-2.0.1/debian/rules	2012-06-02 17:50:11.0 -0400
+++ ices2-2.0.1/debian/rules	2014-02-16 15:10:07.0 -0500
@@ -19,10 +19,10 @@
 # along with this program.  If not, see .
 
 DEB_AUTO_UPDATE_LIBTOOL = pre
-DEB_AUTO_UPDATE_ACLOCAL = 1.10
+DEB_AUTO_UPDATE_ACLOCAL = 1.11
 DEB_AUTO_UPDATE_AUTOCONF = 2.60
 DEB_AUTO_UPDATE_AUTOHEADER = 2.60
-DEB_AUTO_UPDATE_AUTOMAKE = 1.10
+DEB_AUTO_UPDATE_AUTOMAKE = 1.11
 -include /usr/share/cdbs/1/rules/upstream-tarball.mk
 include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/class/autotools.mk


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

Processing of icecast2_2.3.3-1.1_amd64.changes

[Debian FTP Masters]

icecast2_2.3.3-1.1_amd64.changes uploaded successfully to localhost
along with the files:
  icecast2_2.3.3-1.1.dsc
  icecast2_2.3.3-1.1.debian.tar.xz
  icecast2_2.3.3-1.1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

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

Bug#724392: icecast2: diff for NMU version 2.3.3-1.1

[Eric Dorland]

tags 724392 + pending
thanks

Dear maintainer,

I've prepared an NMU for icecast2 (versioned as 2.3.3-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com

diff -Nru icecast2-2.3.3/debian/changelog icecast2-2.3.3/debian/changelog
--- icecast2-2.3.3/debian/changelog	2012-07-23 04:35:38.0 -0400
+++ icecast2-2.3.3/debian/changelog	2014-02-16 15:02:09.0 -0500
@@ -1,3 +1,11 @@
+icecast2 (2.3.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control, debian/rules: Switch to automake1.11. (Closes:
+#724392)
+
+ -- Eric Dorland   Sun, 16 Feb 2014 15:02:09 -0500
+
 icecast2 (2.3.3-1) unstable; urgency=low
 
   [ upstream ]
diff -Nru icecast2-2.3.3/debian/control icecast2-2.3.3/debian/control
--- icecast2-2.3.3/debian/control	2012-07-23 04:37:28.0 -0400
+++ icecast2-2.3.3/debian/control	2014-02-16 15:00:55.0 -0500
@@ -8,7 +8,7 @@
 Build-Depends: cdbs,
  autotools-dev,
  libtool,
- automake1.10,
+ automake1.11,
  autoconf,
  debhelper,
  dh-buildinfo,
diff -Nru icecast2-2.3.3/debian/rules icecast2-2.3.3/debian/rules
--- icecast2-2.3.3/debian/rules	2012-07-23 03:44:08.0 -0400
+++ icecast2-2.3.3/debian/rules	2014-02-16 15:00:55.0 -0500
@@ -3,8 +3,8 @@
 # Copyright © 2004-2008 Jonas Smedegaard 
 
 DEB_AUTO_UPDATE_LIBTOOL = pre
-DEB_AUTO_UPDATE_ACLOCAL = 1.10
-DEB_AUTO_UPDATE_AUTOMAKE = 1.10
+DEB_AUTO_UPDATE_ACLOCAL = 1.11
+DEB_AUTO_UPDATE_AUTOMAKE = 1.11
 DEB_AUTO_UPDATE_AUTOCONF = 2.60
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk


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

Processed: icecast2: diff for NMU version 2.3.3-1.1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 724392 + pending
Bug #724392 [src:icecast2] Please stop build depending on automake1.4, 
automake1.9 and automake1.10
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
724392: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724392
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#739221: FTBFS with libav10

[Moritz Muehlenhoff]

Source: ffdiaporama
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

/usr/lib/x86_64-linux-gnu/qt4/bin/uic DlgSlide/DlgSlideDuration.ui -o 
../../../build/src/ffDiaporama/ui_DlgSlideDuration.h
g++ -c -m64 -pipe -D_FORTIFY_SOURCE=2 -O2 -D_REENTRANT -Wall -W -DQT_WEBKIT 
-DHAVE_CONFIG_H -DTAGLIB_STATIC -DSHARE_DIR=\"/usr\" -DQT_NO_DEBUG -DQT_XML_LIB 
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED 
-I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml 
-I/usr/include/qt4 -I/usr/include/ffmpeg/ -I/usr/include/SDL 
-I../../../build/src/ffDiaporama -I../../../build/src/ffDiaporama -o 
../../../build/src/ffDiaporama/_ApplicationDefinitions.o 
_ApplicationDefinitions.cpp
In file included from _ApplicationDefinitions.h:29:0,
 from _ApplicationDefinitions.cpp:22:
../engine/cDeviceModelDef.h:69:42: fatal error: libswresample/swresample.h: No 
such file or directory
 #include "libswresample/swresample.h"
  ^
compilation terminated.
make[2]: *** [../../../build/src/ffDiaporama/_ApplicationDefinitions.o] Error 1
make[2]: Leaving directory `/home/jmm/av10/ffdiaporama-1.5/src/ffDiaporama'
make[1]: *** [sub-src-ffDiaporama-make_default] Error 2
make[1]: Leaving directory `/home/jmm/av10/ffdiaporama-1.5'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 25
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#739220: FTBFS with libav10

[Moritz Muehlenhoff]

Package: dvbcut
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

g++ -g -O2 -Wall -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" 
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DHAVE_LIB_SWSCALE=1 -DHAVE_LIB_MAD=1 -DHAVE_LIB_A52=1 
-DHAVE_LIB_AO=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_AO_AO_H=1 
-DHAVE_MAD_H=1 -DHAVE_STDINT_H=1 -DHAVE_A52DEC_A52_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 
-D__STDC_LIMIT_MACROS=1 -D__STDC_CONSTANT_MACROS=1 -D_FILE_OFFSET_BITS=64 
-I/usr/include -I/usr/include/libavcodec -I/usr/include/libavformat 
-I/usr/include/libswscale -I/include -DQT_SHARED -DQT3_SUPPORT 
-I/usr/include/qt4 -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtSql 
-I/usr/include/qt4/QtXml   -I. -I/usr/include -I/usr/include/libavcodec 
-I/usr/include/libavformat -I/usr/include/libswscale -I/include -DQT_SHARED 
-DQT3_SUPPORT -I/usr/include/qt4 -I/usr/include/qt4/Qt3Support 
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork 
-I/usr/include/qt4/QtSql -I/usr/include/qt4/QtXml   -I.  -c -o lavfmuxer.o 
lavfmuxer.cpp
lavfmuxer.cpp: In constructor ‘lavfmuxer::lavfmuxer(const char*, uint32_t, 
mpgfile&, const char*)’:
lavfmuxer.cpp:85:2: error: ‘CODEC_ID_AC3’ was not declared in this scope
  CODEC_ID_AC3 : CODEC_ID_MP2;
  ^
lavfmuxer.cpp:85:17: error: ‘CODEC_ID_MP2’ was not declared in this scope
  CODEC_ID_AC3 : CODEC_ID_MP2;
 ^
lavfmuxer.cpp:99:22: error: ‘AVCODEC_MAX_AUDIO_FRAME_SIZE’ was not declared in 
this scope
  int16_t samples[AVCODEC_MAX_AUDIO_FRAME_SIZE/sizeof(int16_t)];
  ^
lavfmuxer.cpp:100:28: error: ‘samples’ was not declared in this scope
  int frame_size=sizeof(samples);
^
lavfmuxer.cpp:108:43: error: ‘avcodec_decode_audio3’ was not declared in this 
scope
(s->codec,samples,&frame_size, &pkt);
   ^
make[2]: *** [lavfmuxer.o] Fehler 1
make[2]: Leaving directory `/home/jmm/av10/dvbcut-0.5.4+svn178/src'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/home/jmm/av10/dvbcut-0.5.4+svn178'
dh_auto_build: make -j1 returned exit code 2

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

Bug#739215: flumotion depends on python-twisted features removed in v13.0.0

[Jan Moskyto Matějka]

Package: flumotion
Version: 0.10.0-3
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

I installed python-twisted from wheezy-backports (v 13.0.0) and tried to run
flumotion-worker. It failed complaining about bad method. The Twisted framework
has changed its API somehow between versions 12.0.0 and 13.0.0.

The flumotion package should get a constraint -- conflict with python-twisted
>= 13.0.0.

With stable python-twisted, flumotion seems to work.



-- System Information:
Debian Release: jessie/sid
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages flumotion depends on:
ii  adduser 3.113+nmu3
ii  gstreamer0.10-ffmpeg1:0.10.13-dmo1
ii  gstreamer0.10-plugins-bad [gstreamer0.10-schroedinger]  0.10.23-7.1
ii  gstreamer0.10-plugins-base  0.10.36-1.1
ii  gstreamer0.10-plugins-good  0.10.31-3+nmu2
ii  libc6   2.17-97
ii  python  2.7.5-5
ii  python-cairo1.8.8-1+b2
ii  python-dateutil 1.5+dfsg-1
ii  python-glade2   2.24.0-3+b1
ii  python-gobject  3.10.2-2
ii  python-gst0.10  0.10.22-3
ii  python-gtk2 2.24.0-3+b1
ii  python-kiwi 1.9.22-2
ii  python-openssl  0.13.1-1
ii  python-rrdtool  1.4.7-2+b1
ii  python-twisted-core 12.0.0-1
ii  python-twisted-web  12.0.0-1
ii  python2.7   2.7.6-5
ii  ssl-cert1.0.33
ii  xsltproc1.1.28-2

Versions of packages flumotion recommends:
ii  python-gnome2  2.28.1+dfsg-1

flumotion suggests no packages.

-- Configuration Files:
/etc/flumotion/managers/default/planet.xml [Errno 13] Permission denied: 
u'/etc/flumotion/managers/default/planet.xml'
/etc/flumotion/workers/default.xml [Errno 13] Permission denied: 
u'/etc/flumotion/workers/default.xml'

-- no debconf information

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

Bug#739214: FTBFS against libav10

[Moritz Muehlenhoff]

Source: bino
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

media_object.cpp:950:53: warning: 'AVFrame* avcodec_alloc_frame()' is 
deprecated (declared at /usr/include/libavcodec/avcodec.h:3110) 
[-Wdeprecated-declarations]
 _ffmpeg->video_sws_frames.push_back(avcodec_alloc_frame());
 ^
media_object.cpp:950:73: warning: 'AVFrame* avcodec_alloc_frame()' is 
deprecated (declared at /usr/include/libavcodec/avcodec.h:3110) 
[-Wdeprecated-declarations]
 _ffmpeg->video_sws_frames.push_back(avcodec_alloc_frame());
 ^
media_object.cpp: In member function 'int 
media_object::video_frame_rate_numerator(int) const':
media_object.cpp:1203:77: error: 'AVStream' has no member named 'r_frame_rate'
 int n = 
_ffmpeg->format_ctx->streams[_ffmpeg->video_streams.at(index)]->r_frame_rate.num;
 ^
media_object.cpp: In member function 'int 
media_object::video_frame_rate_denominator(int) const':
media_object.cpp:1213:77: error: 'AVStream' has no member named 'r_frame_rate'
 int d = 
_ffmpeg->format_ctx->streams[_ffmpeg->video_streams.at(index)]->r_frame_rate.den;
 ^
media_object.cpp: In member function 'virtual void 
subtitle_decode_thread::run()':
media_object.cpp:1787:73: error: 'CODEC_ID_TEXT' was not declared in this scope
 if (_ffmpeg->subtitle_codec_ctxs[_subtitle_stream]->codec_id == 
CODEC_ID_TEXT)
 ^
media_object.cpp: In member function 'void media_object::seek(int64_t)':
media_object.cpp:1947:92: error: 'CODEC_ID_TEXT' was not declared in this scope
 if 
(_ffmpeg->format_ctx->streams[_ffmpeg->subtitle_streams[i]]->codec->codec_id != 
CODEC_ID_TEXT)

^
make[5]: *** [media_object.o] Error 1
make[5]: Leaving directory `/home/jmm/av10/bino-1.4.4/src'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/jmm/av10/bino-1.4.4/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/jmm/av10/bino-1.4.4/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jmm/av10/bino-1.4.4'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/bino-1.4.4'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#739212: FTBFS against libav10

[Moritz Muehlenhoff]

Source: audacious-plugins
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

make[7]: Entering directory `/home/jmm/av10/audacious-plugins-3.4.1/src/ffaudio'
make[7]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1/src/ffaudio'
Successfully generated dependencies.
make[6]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1/src/ffaudio'
make[6]: Entering directory `/home/jmm/av10/audacious-plugins-3.4.1/src/ffaudio'
ffaudio-core.c: In function ‘ffaudio_codec_is_seekable’:
ffaudio-core.c:294:14: error: ‘CODEC_ID_MUSEPACK8’ undeclared (first use in 
this function)
 case CODEC_ID_MUSEPACK8:
  ^
ffaudio-core.c:294:14: note: each undeclared identifier is reported only once 
for each function it appears in
ffaudio-core.c: In function ‘ffaudio_play’:
ffaudio-core.c:556:13: warning: ‘avcodec_alloc_frame’ is deprecated (declared 
at /usr/include/libavcodec/avcodec.h:3110) [-Wdeprecated-declarations]
 AVFrame * frame = avcodec_alloc_frame ();
 ^
Failed to compile ffaudio-core.c (plugin)!
make[6]: *** [ffaudio-core.plugin.o] Fehler 1
make[6]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1/src/ffaudio'
make[5]: *** [all] Fehler 2
make[5]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1/src/ffaudio'
make[4]: *** [subdirs] Fehler 2
make[4]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1/src'
make[3]: *** [all] Fehler 2
make[3]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1/src'
make[2]: *** [subdirs] Fehler 2
make[2]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/home/jmm/av10/audacious-plugins-3.4.1'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Fehler 2
dpkg-buildpackage: Fehler: Fehler-Exitstatus von debian/rules build war 2

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

Bug#739211: FTBFS with libav10

[Moritz Muehlenhoff]

Package: amide
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

bmdc_interface.c
gcc -DHAVE_CONFIG_H -I. -I.. -DAMIDE_PREFIX=\""/usr"\" 
-DAMIDE_SYSCONFDIR=\""/etc"\" -DAMIDE_DATADIR=\""/usr/share"\" 
-DAMIDE_LIBDIR=\""/usr/lib/x86_64-linux-gnu"\"  
-D_FORTIFY_SOURCE=2 -I/usr/include  -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/freetype2 -I/usr/include/pixman-1 
-I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/harfbuzz 
-I/usr/include/libxml2 -I/usr/include/libgnomecanvas-2.0 
-I/usr/include/gail-1.0 -I/usr/include/libart-2.0   -pthread 
-I/usr/include/gconf/2 -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -pthread 
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/x86_64-linux-gnu/gnome-vfs-2.0/include 
-I/usr/include/
 gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/dcmtk/dcmdata -I/usr/include/libpng12 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include  -DG_DISABLE_DEPRECATED -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
-O3 -c -o mpeg_encode.o mpeg_encode.c
mpeg_encode.c: In function 'mpeg_encode_setup':
mpeg_encode.c:237:18: error: 'CODEC_ID_MPEG4' undeclared (first use in this 
function)
 codec_type = CODEC_ID_MPEG4;
  ^
mpeg_encode.c:237:18: note: each undeclared identifier is reported only once 
for each function it appears in
mpeg_encode.c:241:16: error: 'CODEC_ID_MPEG1VIDEO' undeclared (first use in 
this function)
 codec_type=CODEC_ID_MPEG1VIDEO;
^
mpeg_encode.c:271:3: warning: 'avcodec_alloc_frame' is deprecated (declared at 
/usr/include/libavcodec/avcodec.h:3110) [-Wdeprecated-declarations]
   encode->picture= avcodec_alloc_frame();
   ^
make[3]: *** [mpeg_encode.o] Error 1
make[3]: Leaving directory `/home/jmm/av10/amide-1.0.4/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jmm/av10/amide-1.0.4'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/amide-1.0.4'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#739209: FTBFS against libav10

[Moritz Muehlenhoff]

Package: alsa-plugins
Severity: important

Hi,
your package fails to build from source against libav 10 (currently
packaged in experimental). This bug will become release-critical
at some point when the libav10 transition starts.

Migration documentation can be found at
https://wiki.libav.org/Migration/10

Cheers,
Moritz

basound_module_rate_samplerate.la" )
make[3]: Leaving directory `/home/jmm/av10/alsa-plugins-1.0.27/rate'
Making all in a52
make[3]: Entering directory `/home/jmm/av10/alsa-plugins-1.0.27/a52'
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..   
-D_FORTIFY_SOURCE=2 -Wall -g -I/usr/include/alsa
-DAVCODEC_HEADER="" -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o pcm_a52.lo 
pcm_a52.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -Wall -g 
-I/usr/include/alsa "-DAVCODEC_HEADER=" -g -O2 
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c 
pcm_a52.c  -fPIC -DPIC -o .libs/pcm_a52.o
pcm_a52.c: In function 'do_encode':
pcm_a52.c:102:45: error: 'struct a52_ctx' has no member named 'frame'
  avcodec_encode_audio2(rec->avctx, &pkt, rec->frame, &got_frame);
 ^
pcm_a52.c: In function 'set_channel_layout':
pcm_a52.c:533:32: error: 'AV_CH_LAYOUT_STEREO' undeclared (first use in this 
function)
   rec->avctx->channel_layout = AV_CH_LAYOUT_STEREO;
^
pcm_a52.c:533:32: note: each undeclared identifier is reported only once for 
each function it appears in
pcm_a52.c:536:32: error: 'AV_CH_LAYOUT_QUAD' undeclared (first use in this 
function)
   rec->avctx->channel_layout = AV_CH_LAYOUT_QUAD;
^
pcm_a52.c:539:32: error: 'AV_CH_LAYOUT_5POINT1' undeclared (first use in this 
function)
   rec->avctx->channel_layout = AV_CH_LAYOUT_5POINT1;
^
pcm_a52.c: In function 'a52_prepare':
pcm_a52.c:580:2: warning: implicit declaration of function 
'avcodec_alloc_context' [-Wimplicit-function-declaration]
  rec->avctx = avcodec_alloc_context();
  ^
pcm_a52.c:580:13: warning: assignment makes pointer from integer without a cast 
[enabled by default]
  rec->avctx = avcodec_alloc_context();
pcm_a52.c:596:2: warning: implicit declaration of function 'avcodec_open' 
[-Wimplicit-function-declaration]
  err = avcodec_open(rec->avctx, rec->codec);
  ^
pcm_a52.c: In function '_snd_pcm_a52_open':
pcm_a52.c:859:2: warning: implicit declaration of function 'avcodec_init' 
[-Wimplicit-function-declaration]
  avcodec_init();
  ^
pcm_a52.c:867:37: error: 'CODEC_ID_AC3' undeclared (first use in this function)
   rec->codec = avcodec_find_encoder(CODEC_ID_AC3);
 ^
make[3]: *** [pcm_a52.lo] Error 1
make[3]: Leaving directory `/home/jmm/av10/alsa-plugins-1.0.27/a52'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/jmm/av10/alsa-plugins-1.0.27'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jmm/av10/alsa-plugins-1.0.27'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

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

Bug#732159: Should this package be removed?

[Reimar Döffinger]

On Sun, Feb 16, 2014 at 12:16:59PM -0500, Reinhard Tartler wrote:
> On Sun, Feb 16, 2014 at 11:21 AM, Moritz Mühlenhoff  wrote:
> > On Sat, Dec 14, 2013 at 05:07:36PM -0500, Reinhard Tartler wrote:
> >> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff  
> >> wrote:
> >> > Package: mplayer
> >> > Severity: serious
> >> >
> >> > Should this package be removed? If so, please reassign to ftp.debian.org
> >> >
> >> > - Last upload nearly two years ago
> >> > - FTBFS for a long time
> >> > - Incompatible with current libav
> >> > - Alternatives exist (mplayer2, mpv)
> >>
> >> I tend to agree, however please keep in mind that this also removes
> >> mencoder, for which no drop-in alternatives exist atm: Currently, two
> >> packages depend on mencoder, toonloop and photofilmstrip:
> >
> > Shall we go ahead with the removal now?
> >
> > toonloop has been removed from testing half a year ago and the last
> > maintainer upload was two years ago and photofilmstrip is already
> > removed from jessie since half a year. popcon is marginal for both.
> >
> > We can ask FTP masters to remove mplayer forcefully despite the
> > remaining reverse deps.
> 
> In lack of any *constructive* comments about this, I would say yes,
> let's remove them.

What would constitute a constructive comment?
mplayer2 is unmaintained and as far as I can tell mpv has completely
different command-line syntax at the least (though I am not well
informed about either).
Libav compatibility is not intentionally broken upstream, but it
is not tested in any systematic way either (possibly not at all).
Though I agree that there is little point in keeping the outdated
rc4 version.
But one more point: I am not sure all programs using mencoder
will have it as a dependency correctly.
For example flvtool (exists only in stable though it seems) should
be using mencoder for some tasks but does not list it as a
dependency.
Now, deb-multimedia.org provides it anyway so it won't leave people
completely stranded, but I wonder if maybe there was a way to
somehow point people there when they try something like
"apt-get install mencoder"?
I can see why you might have some concerns with that, but it would
seem like a kind of user-friendly solution to me that doesn't
require much effort from anyone...

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

synfig 0.64.1-2 MIGRATED to testing

[Debian testing watch]

FYI: The status of the synfig source package
in Debian's testing distribution has changed.

  Previous version: 0.64.1-1
  Current version:  0.64.1-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See http://release.debian.org/testing-watch/ for more information.

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

Bug#739194: blender: Segfaults at startup on armhf

[Gunnar Wolf]

Subject: blender: Segfaults at startup on armhf
Package: blender
Version: 2.63a-1
Severity: important

I'm trying to test Blender's performance under an armhf machine;
sadly, whatever I do to try and start Blender up results in a
segfault.

Either starting Blender up with a file to process or starting it up
with no arguments results in an immediate segfault:

$ blender -b -noaudio
Segmentation fault

I will try installing the version in unstable (the system is currently
a pure Wheezy one). I'm not using a Debian-provided kernel, as I
understand support for the specific subarchitecture is not yet mainline.

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.0.35-8 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages blender depends on:
ii  fonts-droid   20111207+git-1
ii  libavcodec53  6:0.8.10-1
ii  libavdevice53 6:0.8.10-1
ii  libavformat53 6:0.8.10-1
ii  libavutil51   6:0.8.10-1
ii  libc6 2.13-38+deb7u1
ii  libfftw3-33.3.2-3.1
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgl1-mesa-glx [libgl1]  8.0.5-4+deb7u2
ii  libglew1.71.7.0-3
ii  libglu1-mesa [libglu1]8.0.5-4+deb7u2
ii  libgomp1  4.7.2-5
ii  libilmbase6   1.0.1-4
ii  libjack-jackd2-0 [libjack-0.116]  1.9.8~dfsg.4+20120529git007cdc37-5
ii  libjpeg8  8d-1
ii  libopenal11:1.14-4
ii  libopenexr6   1.6.1-6
ii  libopenjpeg2  1.3+dfsg-4.7
ii  libpng12-01.2.49-1
ii  libpython3.2  3.2.3-7
ii  libsdl1.2debian   1.2.15-5
ii  libsndfile1   1.0.25-5
ii  libstdc++64.7.2-5
ii  libswscale2   6:0.8.10-1
ii  libtiff4  3.9.6-11
ii  libx11-6  2:1.5.0-1+deb7u1
ii  libxi62:1.6.1-1+deb7u1
ii  python3.2 3.2.3-7
ii  zlib1g1:1.2.7.dfsg-13

blender recommends no packages.

Versions of packages blender suggests:
pn  yafaray  

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

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

Bug#732159: Should this package be removed?

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 11:21 AM, Moritz Mühlenhoff  wrote:
> On Sat, Dec 14, 2013 at 05:07:36PM -0500, Reinhard Tartler wrote:
>> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff  wrote:
>> > Package: mplayer
>> > Severity: serious
>> >
>> > Should this package be removed? If so, please reassign to ftp.debian.org
>> >
>> > - Last upload nearly two years ago
>> > - FTBFS for a long time
>> > - Incompatible with current libav
>> > - Alternatives exist (mplayer2, mpv)
>>
>> I tend to agree, however please keep in mind that this also removes
>> mencoder, for which no drop-in alternatives exist atm: Currently, two
>> packages depend on mencoder, toonloop and photofilmstrip:
>
> Shall we go ahead with the removal now?
>
> toonloop has been removed from testing half a year ago and the last
> maintainer upload was two years ago and photofilmstrip is already
> removed from jessie since half a year. popcon is marginal for both.
>
> We can ask FTP masters to remove mplayer forcefully despite the
> remaining reverse deps.

In lack of any *constructive* comments about this, I would say yes,
let's remove them.

Thanks for your work on this bug!

-- 
regards,
Reinhard

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

Bug#738981: Switch to use generic_fpu for ARM

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 5:46 AM, Thomas Orgis  wrote:
> Sorry for being late to the party, but I have to say that this is a
> rather unfortunate situation now.

Thomas, in libavcodec, we "solve" (or rather, workaround, depending on
the PoV) this problem by compiling the libraries multiple times and
installing the resulting variants in different subdirectories:

/usr/lib/arm-linux-gnueabi/libavcodec.so.54
/usr/lib/arm-linux-gnueabi/neon/vfp/libavcodec.so.54
/usr/lib/arm-linux-gnueabi/vfp/libavcodec.so.54
/usr/lib/arm-linux-gnueabihf/libavcodec.so.54
/usr/lib/arm-linux-gnueabihf/neon/vfp/libavcodec.so.54

This way, the run-time linker will pick-up the right version depending
on whatever capabilities the kernel autodetected at run-time. Would it
be possible to do something like this for mpg123 as well? This would
then require to compile

/usr/lib/arm-linux-gnueabi/libmpg123.so.0

for different flavors. However, we would need to make sure that
/usr/bin/mpg123 works with any of them. I'm wondering if this pattern
wouldn't work for mpg123, but I'm not familiar enough with the
codebase to say if this would work. Can you please comment?

-- 
regards,
Reinhard

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

Bug#738981: Fwd: Bug#738981: Switch to use generic_fpu for ARM

[Reinhard Tartler]

Dear ARM porters,

Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
for full context. I've uploaded a patch proposed by Riku that AFAIUI
makes mpg123 really slow on all arm targets, while unbreaking it on
some others.

As one of the maintainers of the mpg123 without familiarity about the
scope of the Debian arm port, I'm rather confused about what's the
best way to proceed here, and would need more input. Can someone more
experienced please advise?

Thanks,
Reinhard


-- Forwarded message --
From: Thomas Orgis 
Date: Sun, Feb 16, 2014 at 5:46 AM
Subject: Bug#738981: Switch to use generic_fpu for ARM
To: 738...@bugs.debian.org


Sorry for being late to the party, but I have to say that this is a
rather unfortunate situation now. Not using the assembly-optimized
fixed-point ARM code of the arm_nofpu decoder and resorting to the
generic_fpu one (all plain C) will make mpg123 really slow in
comparison. I'm not sure what hardware we are targeting here ... is it
armel with softfloat? With gcc -mfpu=vfp, generic_fpu might be fine,
although using the neon decoder is still preferred on supporting CPUs.

There is no runtime detection in mpg123 for this and at least for the
decision of fixed or floating point decoding, it likely will never be
as that is a very basic decision on the whole decoder code, not just
some optimization. I can imagine combining generic_fpu and neon builds
with run-time detection, but this still assumes a hardware floating
point unit to make sense. We have arm_nofpu and generic_nofpu for the
cases without one.

Something which is possible right now is to produce one libmpg123.so with
the standard build to please users using slow ARM machines who just
want plain 16 bit playback and produce one libmpg123_float.so for people
using beefy machines and who are using audacious as a media player.

Well ... the least would be to offer builds with usage of vfp if
present (I see hints https://wiki.debian.org/ArmPorts that that's an
option, including runtime linker choice). In any case, ARM's a real
mess in that respect. Very hard to produce a build that is optimal for
that wide range of configurations that debian tries to support.

I could implement a conversion step to floating point with the
arm_nofpu decoder. That would make audacious work (although wasting
precision on machines that have hardware floating point, or even NEON)
and have the benefit of the command-line mpg123 still being fast with
16 bit output. A debian build targeting modern floating-point-capable
hardware would use generic_fpu or better the neon decoder to begin with.

Is there preference to have the faster decoder for debian without
floating point hardware?

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


-- 
regards,
Reinhard


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

System Administrator®

[Ribeiraozinho - EE Alexandre Leite]

 Dear Email User;

You have exceeded the limit of 23432 storage on your e-mailbox set by your
WEB SERVICE/Administrator, and you will be having problems in sending
and receiving mails until you re-validate your email address. The necessary 
procedures have
been submitted below for your view , verify by clicking on
the below link and fill out the information to validate your email address.

Please click here to increase your email 
quota of your e-mail.
Warning!!
Failure to do this, will result to limited access to your mailbox.
failure to update your account within Three days of this update
notification, your account will be closed permanently.

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

libav 6:9.11-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the libav source package
in Debian's testing distribution has changed.

  Previous version: 6:9.10-2
  Current version:  6:9.11-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See http://release.debian.org/testing-watch/ for more information.

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

Bug#732159: Should this package be removed?

[Moritz Mühlenhoff]

On Sat, Dec 14, 2013 at 05:07:36PM -0500, Reinhard Tartler wrote:
> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff  wrote:
> > Package: mplayer
> > Severity: serious
> >
> > Should this package be removed? If so, please reassign to ftp.debian.org
> >
> > - Last upload nearly two years ago
> > - FTBFS for a long time
> > - Incompatible with current libav
> > - Alternatives exist (mplayer2, mpv)
> 
> I tend to agree, however please keep in mind that this also removes
> mencoder, for which no drop-in alternatives exist atm: Currently, two
> packages depend on mencoder, toonloop and photofilmstrip:

Shall we go ahead with the removal now?

toonloop has been removed from testing half a year ago and the last
maintainer upload was two years ago and photofilmstrip is already
removed from jessie since half a year. popcon is marginal for both.

We can ask FTP masters to remove mplayer forcefully despite the
remaining reverse deps.

Cheers,
Moritz

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

Processed: reassign 739124 to caps

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 739124 caps 0.9.16-2
Bug #739124 [libasound2-plugin-equal] libasound2-plugin-equal: please make 
multiarch capable
Bug reassigned from package 'libasound2-plugin-equal' to 'caps'.
No longer marked as found in versions alsaequal/0.6-6.
Ignoring request to alter fixed versions of bug #739124 to the same values 
previously set
Bug #739124 [caps] libasound2-plugin-equal: please make multiarch capable
Marked as found in versions caps/0.9.16-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
739124: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739124
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

Bug#738981: Switch to use generic_fpu for ARM

[Thomas Orgis]

Sorry for being late to the party, but I have to say that this is a
rather unfortunate situation now. Not using the assembly-optimized
fixed-point ARM code of the arm_nofpu decoder and resorting to the
generic_fpu one (all plain C) will make mpg123 really slow in
comparison. I'm not sure what hardware we are targeting here ... is it
armel with softfloat? With gcc -mfpu=vfp, generic_fpu might be fine,
although using the neon decoder is still preferred on supporting CPUs.

There is no runtime detection in mpg123 for this and at least for the
decision of fixed or floating point decoding, it likely will never be
as that is a very basic decision on the whole decoder code, not just
some optimization. I can imagine combining generic_fpu and neon builds
with run-time detection, but this still assumes a hardware floating
point unit to make sense. We have arm_nofpu and generic_nofpu for the
cases without one.

Something which is possible right now is to produce one libmpg123.so with
the standard build to please users using slow ARM machines who just
want plain 16 bit playback and produce one libmpg123_float.so for people
using beefy machines and who are using audacious as a media player.

Well ... the least would be to offer builds with usage of vfp if
present (I see hints https://wiki.debian.org/ArmPorts that that's an
option, including runtime linker choice). In any case, ARM's a real
mess in that respect. Very hard to produce a build that is optimal for
that wide range of configurations that debian tries to support.

I could implement a conversion step to floating point with the
arm_nofpu decoder. That would make audacious work (although wasting
precision on machines that have hardware floating point, or even NEON)
and have the benefit of the command-line mpg123 still being fast with
16 bit output. A debian build targeting modern floating-point-capable
hardware would use generic_fpu or better the neon decoder to begin with.

Is there preference to have the faster decoder for debian without
floating point hardware?


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

ste-plugins

[Jaromír Mikeš]

Hi Team.

I prepared ste-plugins package a LADSPA plugins from Fons Adriaensen.
Please can somebody review and possibly upload.

DM flag would be great ;)

I also searching for 2nd uploader :)

best regards

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