Debian Bug report logs - #732159
RM: mplayer - RoM - unmaintained, RC-buggy, alternatives exist

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Should this package be removed?

Date: Sat, 14 Dec 2013 22:28:58 +0100

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)

Cheers,
        Moritz

Message #10 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Alessio Treglia <alessio@debian.org>

To: Moritz Muehlenhoff <jmm@debian.org>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sat, 14 Dec 2013 21:43:00 +0000

On Sat, Dec 14, 2013 at 9:28 PM, Moritz Muehlenhoff <jmm@debian.org> wrote:
> 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 definitely agree.

BTW I'd like to get an opinion from any of the Uploaders first.

Cheers!

-- 
Alessio Treglia          | www.alessiotreglia.com
Debian Developer         | alessio@debian.org
Ubuntu Core Developer    | quadrispro@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

Message #15 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com>

To: Moritz Muehlenhoff <jmm@debian.org>, 732159@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sat, 14 Dec 2013 17:07:36 -0500

I've added debian-devel for further input, as I believe the
consequences are a bit wider than expected.

On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff <jmm@debian.org> 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:

Alexandre Quessy <alexandre@quessy.net>
   toonloop (U)

Debian Multimedia Maintainers
<pkg-multimedia-maintainers@lists.alioth.debian.org>
   toonloop

Gürkan Sengün <gurkan@phys.ethz.ch>
   photofilmstrip

Jens Göpfert <jens@sg-dev.de>
   photofilmstrip (U)

Jonas Smedegaard <dr@jones.dk>
   toonloop (U)

Philipp Huebner <debalance@debian.org>
   photofilmstrip (U)

If there is general consent that those packages are OK to remove as
well, then so be it.

Best regards,
Reinhard

Message #20 received at 732159@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Reinhard Tartler <siretart@gmail.com>, Moritz Muehlenhoff <jmm@debian.org>, 732159@bugs.debian.org

Cc: debian-devel@lists.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sat, 14 Dec 2013 23:53:05 +0100

[Message part 1 (text/plain, inline)]

On 12/14/2013 11:07 PM, Reinhard Tartler wrote:
> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff <jmm@debian.org> 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)

Well, to be honest, I think the problem is actually libav, not mplayer.
Most users prefer the original ffmpeg over libav from my own experience.

And there are new upstream releases of mplayer which are actually more
frequent and active than mplayer2:

- mplayer: current stable release 1.1.1, released May 6th, 2013
- mplayer2: current stable release 2.0, released: March 24th, 2011

Even the latest git commit for mplayer2 is older than the current
stable release of mplayer. The latter seems much more active to me.

So, what I'd rather like to see is that we get a proper ffmpeg
back in Debian again which would also allow to update mplayer
to the current upstream version. There is even an RFP for
that [1]. But I guess this is not going to happen.

I'm still a bit sad that the split among the ffmpeg people
happened.

Adrian

> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[signature.asc (application/pgp-signature, attachment)]

Message #25 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, "732159@bugs.debian.org" <732159@bugs.debian.org>

Cc: Reinhard Tartler <siretart@gmail.com>, Moritz Muehlenhoff <jmm@debian.org>, "732159@bugs.debian.org" <732159@bugs.debian.org>, "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 15 Dec 2013 11:04:21 +0100

On 14.12.2013, at 23:53, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> On 12/14/2013 11:07 PM, Reinhard Tartler wrote:
>> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff <jmm@debian.org> 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)
> 
> Well, to be honest, I think the problem is actually libav, not mplayer.
> Most users prefer the original ffmpeg over libav from my own experience.
> 
> And there are new upstream releases of mplayer which are actually more
> frequent and active than mplayer2:
> 
> - mplayer: current stable release 1.1.1, released May 6th, 2013
> - mplayer2: current stable release 2.0, released: March 24th, 2011
> 
> Even the latest git commit for mplayer2 is older than the current
> stable release of mplayer. The latter seems much more active to me.
> 
> So, what I'd rather like to see is that we get a proper ffmpeg
> back in Debian again which would also allow to update mplayer
> to the current upstream version. There is even an RFP for
> that [1]. But I guess this is not going to happen.
> 
> I'm still a bit sad that the split among the ffmpeg people
> happened.
> 
> Adrian
> 
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203

I thought someone was working on it already, but I am happy to help out both with getting a parallel install of FFmpeg working (via a rpath hack for example, supported in FFmpeg configure but probably needs fixes to MPlayer's configure to work) and to a limited degree also making MPlayer work with Libav.
However the latter would need a proper maintainer, and Libav misses quite a few features MPlayer needs, so it would be problematic and the result questionable IMHO.
I am assuming nobody in Debian wants to compile MPlayer statically/against an "internal" copy of FFmpeg.

Reimar

Message #30 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Pau Garcia i Quiles <pgquiles@elpauer.org>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Cc: Reinhard Tartler <siretart@gmail.com>, Moritz Muehlenhoff <jmm@debian.org>, 732159@bugs.debian.org, Debian Devel <debian-devel@lists.debian.org>

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 15 Dec 2013 11:43:27 +0100

[Message part 1 (text/plain, inline)]

On Sat, Dec 14, 2013 at 11:53 PM, John Paul Adrian Glaubitz <
glaubitz@physik.fu-berlin.de> wrote:


> Well, to be honest, I think the problem is actually libav, not mplayer.
> Most users prefer the original ffmpeg over libav from my own experience.
>

Agreed

Furthermore, I still do not understand why libav to take over the name
ffmpeg in the archive

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

[Message part 2 (text/html, inline)]

Message #35 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Bálint Réczey <balint@balintreczey.hu>

To: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, "732159@bugs.debian.org" <732159@bugs.debian.org>, Reinhard Tartler <siretart@gmail.com>, Moritz Muehlenhoff <jmm@debian.org>, "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 15 Dec 2013 15:26:02 +0100

2013/12/15 Reimar Döffinger <Reimar.Doeffinger@gmx.de>:
> On 14.12.2013, at 23:53, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>> On 12/14/2013 11:07 PM, Reinhard Tartler wrote:
>>> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff <jmm@debian.org> 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)
>>
>> Well, to be honest, I think the problem is actually libav, not mplayer.
>> Most users prefer the original ffmpeg over libav from my own experience.
>>
>> And there are new upstream releases of mplayer which are actually more
>> frequent and active than mplayer2:
>>
>> - mplayer: current stable release 1.1.1, released May 6th, 2013
>> - mplayer2: current stable release 2.0, released: March 24th, 2011
>>
>> Even the latest git commit for mplayer2 is older than the current
>> stable release of mplayer. The latter seems much more active to me.
>>
>> So, what I'd rather like to see is that we get a proper ffmpeg
>> back in Debian again which would also allow to update mplayer
>> to the current upstream version. There is even an RFP for
>> that [1]. But I guess this is not going to happen.
>>
>> I'm still a bit sad that the split among the ffmpeg people
>> happened.
>>
>> Adrian
>>
>>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203
>
> I thought someone was working on it already, but I am happy to help out both with getting a parallel install of FFmpeg working (via a rpath hack for example, supported in FFmpeg configure but probably needs fixes to MPlayer's configure to work) and to a limited degree also making MPlayer work with Libav.
How about introducing the ffmpeg shared libraries with libffmpeg
prefix instead of libav prefix?
This would rename the libraries, but since none of the forks shows
interest in using different library names and users already refer to
ffmpeg or libav versions it would cause just a little confusion.
This way the libraries could coexist on the same system and we could
avoid using the rpath hack.

Cheers,
Balint

PS: I'm interested in the topic because I'm working on reviving the
XBMC package but upstream prefers ffmpeg over libav.

Message #44 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: Debian Med Project List <debian-med@lists.debian.org>, 732159@bugs.debian.org

Cc: Jorge Soares <js21@sanger.ac.uk>

Subject: Re: Bug#732622: snp-sites: ITP First time debian snp-sites package

Date: Mon, 23 Dec 2013 09:22:35 +0100

Hi Jorge,

I was wondering why I was not seeing the ITP you was talking about.  I
guess you should try to read some relevant documentation since we
explicitly point to the way how you are doing ITPs in our policy:

   http://debian-med.alioth.debian.org/docs/policy.html#itp

It is very advisable to read this first to avoid mistakes like this ITP.
To fix it I see two options:

  1) You create a proper ITP via

         reportbug wnpp

     fill in the template but do not finally send the result but only
     save the document and afterwards answer to this existing bug report.

  2) You close this existing (broken) ITP and create a new one from
     scratch by `reportbug wnpp`

Thanks for your work anyway - it is no shame to do some beginner
mistakes and we as the Debian Med team is trying to minimise this
by explaining how to do things properly.

Kind regards

      Andreas.

On Sat, Dec 21, 2013 at 01:54:50PM +0200, Andrei POPESCU wrote:
> Control: reassign -1 wnpp
> 
> On Jo, 19 dec 13, 12:47:52, Jorge Soares wrote:
> > Package: snp-sites
> > Version: 1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > 	I would like to regiater my intent to package the software snp-sites
> > 
> > -- System Information:
> > Debian Release: 7.2
> >   APT prefers stable-updates
> >   APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> 
> -- 
> http://wiki.debian.org/FAQsFromDebianUser
> Offtopic discussions among Debian users and developers:
> http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
> http://nuvreauspam.ro/gpg-transition.txt



-- 
http://fam-tille.de

Message #49 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Xiangyu Liu <u122334@gmail.com>

To: 732159@bugs.debian.org

Subject: Re: Should this package be removed?

Date: Sun, 29 Dec 2013 13:04:21 +0800

[Message part 1 (text/plain, inline)]

Hi,

For some specific MKV files, mplayer2 has problem to sync A/V, but mplayer
works fine. I've filed a bug.
( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731937 )

If possible, please keep the mplayer in Debian. Gentoo has new upstream
versions of Mplayer (1.1.1, and 1.2_pre20130729) that can be built against
libav9.  Would you mind merging those patches to Mplayer in Debian ?
( https://packages.gentoo.org/package/media-video/mplayer )

Thanks,
Best Regards,
Xiangyu LIU

[Message part 2 (text/html, inline)]

Message #54 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Diego Biurrun <diego@biurrun.de>

To: Xiangyu Liu <u122334@gmail.com>, 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Mon, 06 Jan 2014 21:25:28 +0100

On 29.12.2013 06:04, Xiangyu Liu wrote:
> For some specific MKV files, mplayer2 has problem to sync A/V, but
> mplayer works fine. I've filed a bug.
> ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731937 )

MPlayer and MPlayer2 use different Matroska demuxers by default.  Try 
passing both "-demuxer lavf" and "-demuxer mkv" as options while playing 
the offending file(s).  I suspect that one or the other will make the 
problem go away.

Diego

Message #59 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Xiangyu Liu <u122334@gmail.com>

To: Diego Biurrun <diego@biurrun.de>, 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Wed, 8 Jan 2014 22:22:56 +0800

[Message part 1 (text/plain, inline)]

Hi ,

The option "-demuxer lavf" works !   Thanks a lot!
Please close the bug report #731937.


2014/1/8 Xiangyu Liu <u122334@gmail.com>

> Hi ,
>
> The option "-demuxer lavf" works !   Thanks a lot!
> Please close the bug report #731937.
>
> By the way, When I met problem in #731937,  I have read the manual of
> mplayer2, but I did not get any help about A/V sync except '-autosync'
> option. Is there any other documentation to display all of the switch
> option of mplayer2 and their *detailed functions* ?
>
>
>
>
> 2014/1/7 Diego Biurrun <diego@biurrun.de>
>
>> On 29.12.2013 06:04, Xiangyu Liu wrote:
>>
>>> For some specific MKV files, mplayer2 has problem to sync A/V, but
>>> mplayer works fine. I've filed a bug.
>>> ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731937 )
>>>
>>
>> MPlayer and MPlayer2 use different Matroska demuxers by default.  Try
>> passing both "-demuxer lavf" and "-demuxer mkv" as options while playing
>> the offending file(s).  I suspect that one or the other will make the
>> problem go away.
>>
>> Diego
>>
>
>

[Message part 2 (text/html, inline)]

Message #64 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Reinhard Tartler <siretart@gmail.com>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 16 Feb 2014 17:21:56 +0100

On Sat, Dec 14, 2013 at 05:07:36PM -0500, Reinhard Tartler wrote:
> On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff <jmm@debian.org> 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

Message #69 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 16 Feb 2014 12:16:59 -0500

On Sun, Feb 16, 2014 at 11:21 AM, Moritz Mühlenhoff <jmm@inutil.org> 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 <jmm@debian.org> 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

Message #74 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

To: Reinhard Tartler <siretart@gmail.com>, 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 16 Feb 2014 18:58:24 +0100

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 <jmm@inutil.org> 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 <jmm@debian.org> 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...

Message #79 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com>

To: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Sun, 16 Feb 2014 15:25:08 -0500

On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
<Reimar.Doeffinger@gmx.de> 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

Message #84 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

To: Reinhard Tartler <siretart@gmail.com>, 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Tue, 18 Feb 2014 00:52:08 +0100

On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote:
> On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
> <Reimar.Doeffinger@gmx.de> wrote:
> > 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".

Well, I expect that making it build wouldn't be that hard, but it
would be quite crippled and broken, and with the limited effort I
am willing to spend on getting patches into Libav I won't be getting
anywhere I would conclude from previous tries.

> > 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.

Well, it was motivation to suggest several ways to get FFmpeg into
Debian, since that is kind of the most realistic way to solve it,
also since otherwise it won't be the version of MPlayer that
is tested upstream.
However so far this seems to be considered completely out of the
question.
Which for me kind of leaves the question if the best MPlayer we
can offer under these circumstances is worth it.

> > 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).

This sounds to me like you see a difference between "Libav
compatibility" and "suitable in Debian"?
I'd be interested in that.

> 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.

Yes, no, maybe. I just looked into it. You have to provide matching
copies of libavformat/internal.h (can be eliminated reasonably well if
it's a concern) and libavutil/x86/asm.h (only issue here is that I don't
like duplicating it).
Nothing else is required.

> 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.

As far as I can tell none of that internal API usage remains,
unless you enable certain special features like those old
JPEG decoder cards (that actually don't compile anymore
even against internal FFmpeg).

> This
> makes maintaining mplayer in Debian much more challenging, and
> basically means that mplayer and libav always need to be updated in
> lockstep.

This has not been the case for some time.
Well, at least not due to internal API usage.
I believe there are a few "accessor" functions that MPlayer does not use when it
should, but that's kind of a bug.

> 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.

Well, "welcome" it is maybe from everyone's standpoint, but
even some of the developers who welcome it least have added ifdefs
to avoid breaking it even further.

> Actually, I would be very interested in that, but not before
> there was some mplayer release that stopped requiring an internal copy
> of libav*

I haven't tested the last release, and I don't know if only
requiring these two headers I mentioned is good enough,
but I would say it doesn't require an internal copy anymore.
I even fixed configure so that if you have only those two files
in ffmpeg/... it will default to compiling against a system FFmpeg.
Making a new release is something that would be good to do anyway.
_However_ none of this fixes the FFmpeg vs. Libav issues...

> > 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.

This is kind of messy on non-developer machines where it involves
installing compilers an lots of -dev packages, plus not knowing which
are needed (I suspect the debian packaging scripts inside the MPlayer
source are thoroughly broken at this point, though I have not tried).

> > 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)

This is too light on details to know what was going on.
I am sure that adding deb-multimedia in a way that will select
it by default can cause pain, however picking _only_ mencoder
and any of its dependencies not in Debian I think should
not be able to cause this kind of issue.
It _might_ even be possible to just download and manually install the
mencoder packages from there.
Just to be clear, this is just some wild thinking, not anything
I seriously propose at this point.

Regards,
Reimar Döffinger

Message #89 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com>

To: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Wed, 19 Feb 2014 08:24:01 -0500

TBH, I'm a bit confused about your reply.

On Mon, Feb 17, 2014 at 6:52 PM, Reimar Döffinger
<Reimar.Doeffinger@gmx.de> wrote:
> On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote:
>> On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
>> <Reimar.Doeffinger@gmx.de> wrote:
>> > 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".
>
> Well, I expect that making it build wouldn't be that hard, but it
> would be quite crippled and broken,
> and with the limited effort I
> am willing to spend on getting patches into Libav I won't be getting
> anywhere I would conclude from previous tries.

I take this as that you (as upstream) do not want mplayer to be
compiled against libav. That's a strong argument *for* removing it
from Debian, which ships this version of libav, *and* has working and
non-crippled alternatives to mplayer in the archive.

Besides, has development and support for mencoder been revived, or do
its developers still consider mencoder deprecated and/or obsolete?
AFAIR, people on the mencoder/mplayer mailing lists have recommended
to just use the command-line tool ffmpeg/avconv instead for a couple
of years now.

>> > 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.
>
> Well, it was motivation to suggest several ways to get FFmpeg into
> Debian, since that is kind of the most realistic way to solve it,
> also since otherwise it won't be the version of MPlayer that
> is tested upstream.
> However so far this seems to be considered completely out of the
> question.

Sorry, but taking mplayer as political argument to make pressure on
the FFmpeg vs. Libav conflict is not going to help anyone. Please have
this discussion elsewhere, e.g. in  #729203.

> Which for me kind of leaves the question if the best MPlayer we
> can offer under these circumstances is worth it.

I guess the conclusion of this discussion tends to "no", although we
disagree on the rationale. That's fair enough with me.

>> > 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).
>
> This sounds to me like you see a difference between "Libav
> compatibility" and "suitable in Debian"?
> I'd be interested in that.

Please contact me again in private about this. Let's keep this bug
focused on arguments pro and contra removal of mplayer/mencoder from
Debian.

>> 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.
>
> Yes, no, maybe. I just looked into it. You have to provide matching
> copies of libavformat/internal.h (can be eliminated reasonably well if
> it's a concern) and libavutil/x86/asm.h (only issue here is that I don't
> like duplicating it).
> Nothing else is required.

I missed that, did that change recently?

> I haven't tested the last release, and I don't know if only
> requiring these two headers I mentioned is good enough,
> but I would say it doesn't require an internal copy anymore.

Well, if it was really only two (internal!) headers that it takes, why
doesn't mplayer embed them just like mplayer2 and mpv, and just ditch
the svn:external equivalent for git mechanism? This needs to be
disabled when packaging it for use with a system-provided libavcodec
anyways. I guess the reason is that you still prefer to have it
compile against the very latest tip of ffmpeg, which again, is not the
typical configuration when integrating it into Debian. mplayer
competitors mplayer2/mpv do not seem to be this demanding.

Nevertheless, if what you say is true, then current mplayer should be
indeed rather easy to compile against any copy of libavcodec.

> I even fixed configure so that if you have only those two files
> in ffmpeg/... it will default to compiling against a system FFmpeg.
> Making a new release is something that would be good to do anyway.
> _However_ none of this fixes the FFmpeg vs. Libav issues...

Are they critical for Debian?

I personally don't think so, because I don't consider the missing
functionality that important. If it was, then it could be fixed if
there was enough good will. However, the political pressure and the
constant nagging from both developers and spectators result in a very
aggressive and negative atmosphere, and thus has diminished my
motivation to continue working on the package significantly. I mean,
even you as one of last very active mplayer developers use terms such
as "cripple" to induce political pressure towards FFmpeg.

>> > 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.
>
> This is kind of messy on non-developer machines where it involves
> installing compilers an lots of -dev packages, plus not knowing which
> are needed (I suspect the debian packaging scripts inside the MPlayer
> source are thoroughly broken at this point, though I have not tried).

So what? Juts give users a list of packages to install on a wiki page
and improve mplayer's configure script to detect missing packages and
provide better diagnostics, and everyone benefits (including potential
future packagers).

>> > 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)
>
> This is too light on details to know what was going on.

I don't think users need to know the political background behind all
of this. Since we adopted that policy and explanation, the number of
bug reports of applications that link against libavcodec with crashes
that stem from libraries that interfere here significantly decreased.

-- 
regards,
    Reinhard

Message #94 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

To: Reinhard Tartler <siretart@gmail.com>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Wed, 19 Feb 2014 19:58:28 +0100

On Wed, Feb 19, 2014 at 08:24:01AM -0500, Reinhard Tartler wrote:
> TBH, I'm a bit confused about your reply.

I probably lost track of the point I was trying to make.
I so far assumed that this issue was, bluntly put, about
almost exclusively
1) MPlayer does not work against Libav

But what you wrote sounded more like it's at least also
2) MPlayer has packaging issues

I've mentioned this a few times over the years, I'd be interested in
improving 2), and that is regardless of the status of this ticket.

> On Mon, Feb 17, 2014 at 6:52 PM, Reimar Döffinger
> <Reimar.Doeffinger@gmx.de> wrote:
> > On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote:
> >> On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
> >> <Reimar.Doeffinger@gmx.de> wrote:
> >> > 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".
> >
> > Well, I expect that making it build wouldn't be that hard, but it
> > would be quite crippled and broken,
> > and with the limited effort I
> > am willing to spend on getting patches into Libav I won't be getting
> > anywhere I would conclude from previous tries.
> 
> I take this as that you (as upstream) do not want mplayer to be
> compiled against libav.

No it means "I feel unable to maintain support for that".
And that is the same situation as right after the fork,
nobody has stepped up since then to take on this task.
(Yes, I am well aware that the mailing list climate was not
helpful in attracting someone to do it, and I am sorry for that).

> Besides, has development and support for mencoder been revived, or do
> its developers still consider mencoder deprecated and/or obsolete?

It's still on basic life support. So I don't think it should be considered
a major concern.
Still, ffmpeg/avconv in some cases still can't 100% replace it,
especially if it's not the very latest of those, so I am of course
still interested in not letting any users hang if there was some
magic easy way to achieve it.

> >> 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.
> >
> > Well, it was motivation to suggest several ways to get FFmpeg into
> > Debian, since that is kind of the most realistic way to solve it,
> > also since otherwise it won't be the version of MPlayer that
> > is tested upstream.
> > However so far this seems to be considered completely out of the
> > question.
> 
> Sorry, but taking mplayer as political argument to make pressure on
> the FFmpeg vs. Libav conflict is not going to help anyone. Please have
> this discussion elsewhere, e.g. in  #729203.

This was not mean political, this is about "solving" my point 1) above.
If we agree that we see no way to solve/avoid that I think there is
no point in dragging this out any further.

> >> 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.
> >
> > Yes, no, maybe. I just looked into it. You have to provide matching
> > copies of libavformat/internal.h (can be eliminated reasonably well if
> > it's a concern) and libavutil/x86/asm.h (only issue here is that I don't
> > like duplicating it).
> > Nothing else is required.
> 
> I missed that, did that change recently?

I don't think so. I think it must have been like this at least a year,
but no promises.
I do not know if Debian might have used options like --enable-zr (that
is the part that now no longer compiles), that one had hooks deep
into FFmpeg, but I think it lost what little relevance it had years ago.

> > I haven't tested the last release, and I don't know if only
> > requiring these two headers I mentioned is good enough,
> > but I would say it doesn't require an internal copy anymore.
> 
> Well, if it was really only two (internal!) headers that it takes, why
> doesn't mplayer embed them just like mplayer2 and mpv, and just ditch
> the svn:external equivalent for git mechanism? This needs to be
> disabled when packaging it for use with a system-provided libavcodec
> anyways.

If I make a copy of them I become responsible to maintain/update them.
Which I'd only want to do if it's really the best solution to a
significant problem.
Plus, creating a ffmpeg/ directory automatically disables the
automated FFmpeg download, so solving the one also fixes the other for
you.

> Nevertheless, if what you say is true, then current mplayer should be
> indeed rather easy to compile against any copy of libavcodec.

I expect there will be rough edges still, it's poorly tested.
It's a long progress, and at the risk of offending from my point of
view in part due to an unwillingness from the side of package
maintainers to complain loudly and clearly.

> > I even fixed configure so that if you have only those two files
> > in ffmpeg/... it will default to compiling against a system FFmpeg.
> > Making a new release is something that would be good to do anyway.
> > _However_ none of this fixes the FFmpeg vs. Libav issues...
> 
> Are they critical for Debian?
> 
> I personally don't think so, because I don't consider the missing
> functionality that important.

I don't know. I admit I am mostly thinking of VDPAU, though obviously
Ubuntu decided that saving 8.3 MB of disk space is more important than
it, so I might grossly overestimate its importance.
First of all, it would need to build at all however, and then someone
needs to ensure it continues to do so.
And someone should at least do some testing.
I hope you understand that at this point I consider it just too much.

> If it was, then it could be fixed if there was enough good will.

I so far assumed that even with good will the manpower wouldn't be
there.

> However, the political pressure and the
> constant nagging from both developers and spectators result in a very
> aggressive and negative atmosphere, and thus has diminished my
> motivation to continue working on the package significantly.

I know, and not only yours, and sorry.

> I mean,
> even you as one of last very active mplayer developers use terms such
> as "cripple" to induce political pressure towards FFmpeg.

There is probably more truth in it than I'd like to admit,
but I still believe I mostly meant it as a short-hand for
"there will be compatibility issues (or if you want, MPlayer code
horriblyness to not start a discussion on who is to blame) for
which I see no easy/quick solution that does not involve losing functionality".

> >> > 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)
> >
> > This is too light on details to know what was going on.
> 
> I don't think users need to know the political background behind all
> of this. Since we adopted that policy and explanation, the number of
> bug reports of applications that link against libavcodec with crashes
> that stem from libraries that interfere here significantly decreased.

But the details are kind of relevant here, since its MPlayer/mencoder
packages do not depend on libavcodec packages...
If you want me to stop arguing about this, just tell me so, but as
long as you bring counterarguments I'll argue if they don't convince me.

Message #99 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Reinhard Tartler <siretart@gmail.com>

Cc: 732159@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#732159: Should this package be removed?

Date: Mon, 17 Mar 2014 17:19:40 +0100

retitle 732159 RM: mplayer - RoM - unmaintained, RC-buggy, alternatives exist
reassign 732159 ftp.debian.org
thanks

On Sun, Feb 16, 2014 at 12:16:59PM -0500, Reinhard Tartler wrote:
> >> > 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!

Doing so.

FTP masters; there are two reverse depends on mencoder: toonloop
and photofilmstrip. Both are already dropped from testing for a long
time. I think we should go ahead and drop mplayer despite the rdeps, 
if the maintainers fix their packages they can re-enter jessie, otherwise
they'll also have to get removed at some point.

Cheers,
        Moritz

Message #112 received at 732159-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 732159-close@bugs.debian.org

Cc: mplayer@packages.debian.org, mplayer@packages.qa.debian.org

Subject: Bug#732159: Removed package(s) from unstable

Date: Mon, 21 Apr 2014 10:07:44 +0000

We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

  mencoder | 2:1.0~rc4.dfsg1+svn34540-1+b2 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
   mplayer | 2:1.0~rc4.dfsg1+svn34540-1 | source
   mplayer | 2:1.0~rc4.dfsg1+svn34540-1+b2 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
mplayer-dbg | 2:1.0~rc4.dfsg1+svn34540-1+b2 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc
mplayer-doc | 2:1.0~rc4.dfsg1+svn34540-1 | all
mplayer-gui | 2:1.0~rc4.dfsg1+svn34540-1+b2 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc

------------------- Reason -------------------
RoM; rc-buggy, unmaintained, alternatives exist
----------------------------------------------

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors until the next
dinstall run at the earliest.

Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.

We try to close bugs which have been reported against this package
automatically. But please check all old bugs, if they were closed
correctly or should have been re-assigned to another package.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 732159@bugs.debian.org.

The full log for this bug can be viewed at https://bugs.debian.org/732159

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Ansgar Burchardt (the ftpmaster behind the curtain)

Message #117 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Thorsten Glaser <tg@mirbsd.de>

To: 728772@bugs.debian.org, 732159@bugs.debian.org

Subject: Re: Bug#728772 closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (Bug#732159: Removed package(s) from unstable)

Date: Mon, 21 Apr 2014 10:42:58 +0000 (UTC)

Debian Bug Tracking System dixit:

>This is an automatic notification regarding your Bug report
>which was filed against the src:mplayer package:
>
>#728772: mplayer: FTBFS: The architecture of your CPU (UNKNOWN) is not supported
>
>It has been closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org>.
[…]
>as the package mplayer has just been removed from the Debian archive
[…]



     ***** *    **   ***      *                                  ****
  ******  *  *****    ***   **                       *         *********
 **   *  *     *****   ***  **                      **       ***  **   ***
*    *  **     * **      ** **                      **     ***    **     ***
    *  ***     *         ** **                    ********        **      ***
   **   **     *         ** **  ***      ****    ********         **     ***
   **   **     *         ** ** * ***    * ***  *    **            **    ***
   **   **     *         ** ***   ***  *   ****     **            **   ***
   **   **     *         ** **     ** **    **      **            ** ***
   **   **     *         ** **     ** **    **      **            ****
    **  **     *         ** **     ** **    **      **            ***
     ** *      *         *  **     ** **    **      **            **
      ***      ***      *   **     ** **    **      **
       ******** ********    **     **  ***** **      **          ****
         ****     ****       **    **   ***   **                 ****
                                   *
                                  *
                                 *
                                *


You cannot s̲e̲r̲i̲o̲u̲s̲l̲y̲ remove mplayer from the archive?
You must be kidding. MPlayer2 was born dead and VLC
just doesn’t work most of the time and has a horrible UI.

Honestly, please bring mplayer+ffmpeg back!

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Message #120 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Ansgar Burchardt <ansgar@debian.org>

To: Thorsten Glaser <tg@mirbsd.de>

Cc: 732159@bugs.debian.org

Subject: Re: Bug#732159: Bug#728772 closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (Bug#732159: Removed package(s) from unstable)

Date: Mon, 21 Apr 2014 13:05:29 +0200

Thorsten Glaser <tg@mirbsd.de> writes:
> Debian Bug Tracking System dixit:
>
>>This is an automatic notification regarding your Bug report
>>which was filed against the src:mplayer package:
>>
>>#728772: mplayer: FTBFS: The architecture of your CPU (UNKNOWN) is not supported
>>
>>It has been closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org>.
> […]
>>as the package mplayer has just been removed from the Debian archive
> […]
>
[...]
>
> You cannot s̲e̲r̲i̲o̲u̲s̲l̲y̲ remove mplayer from the archive?
> You must be kidding. MPlayer2 was born dead and VLC
> just doesn’t work most of the time and has a horrible UI.

Seems totally worth keeping:

mplayer (- to 2:1.0~rc4.dfsg1+svn34540-1)
    Maintainer: Debian multimedia packages maintainers
    829 days old (needed 5 days)
    Ignoring high urgency setting for NEW package
    mencoder/i386 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/i386 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/i386 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/i386 unsatisfiable Depends: libx264-123
    mplayer/i386 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/i386 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/i386 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/i386 unsatisfiable Depends: libsvga1
    mplayer/i386 unsatisfiable Depends: libx264-123
    mplayer-gui/i386 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/i386 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/i386 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/i386 unsatisfiable Depends: libsvga1
    mplayer-gui/i386 unsatisfiable Depends: libx264-123
    mencoder/amd64 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/amd64 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/amd64 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/amd64 unsatisfiable Depends: libx264-123
    mplayer/amd64 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/amd64 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/amd64 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/amd64 unsatisfiable Depends: libsvga1
    mplayer/amd64 unsatisfiable Depends: libx264-123
    mplayer-gui/amd64 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/amd64 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/amd64 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/amd64 unsatisfiable Depends: libsvga1
    mplayer-gui/amd64 unsatisfiable Depends: libx264-123
    mencoder/armel unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/armel unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/armel unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/armel unsatisfiable Depends: libx264-123
    mplayer/armel unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/armel unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/armel unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/armel unsatisfiable Depends: libx264-123
    mplayer-gui/armel unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/armel unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/armel unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/armel unsatisfiable Depends: libx264-123
    mencoder/armhf unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/armhf unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/armhf unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/armhf unsatisfiable Depends: libx264-123
    mplayer/armhf unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/armhf unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/armhf unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/armhf unsatisfiable Depends: libx264-123
    mplayer-gui/armhf unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/armhf unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/armhf unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/armhf unsatisfiable Depends: libx264-123
    mencoder/kfreebsd-amd64 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/kfreebsd-amd64 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/kfreebsd-amd64 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/kfreebsd-amd64 unsatisfiable Depends: libx264-123
    mplayer/kfreebsd-amd64 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/kfreebsd-amd64 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/kfreebsd-amd64 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/kfreebsd-amd64 unsatisfiable Depends: libx264-123
    mplayer-gui/kfreebsd-amd64 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/kfreebsd-amd64 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/kfreebsd-amd64 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/kfreebsd-amd64 unsatisfiable Depends: libx264-123
    mencoder/kfreebsd-i386 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/kfreebsd-i386 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/kfreebsd-i386 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/kfreebsd-i386 unsatisfiable Depends: libx264-123
    mplayer/kfreebsd-i386 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/kfreebsd-i386 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/kfreebsd-i386 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/kfreebsd-i386 unsatisfiable Depends: libx264-123
    mplayer-gui/kfreebsd-i386 unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/kfreebsd-i386 unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/kfreebsd-i386 unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/kfreebsd-i386 unsatisfiable Depends: libx264-123
    mencoder/mips unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/mips unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/mips unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/mips unsatisfiable Depends: libx264-123
    mplayer/mips unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/mips unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/mips unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/mips unsatisfiable Depends: libx264-123
    mplayer-gui/mips unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/mips unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/mips unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/mips unsatisfiable Depends: libx264-123
    mencoder/mipsel unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/mipsel unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/mipsel unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/mipsel unsatisfiable Depends: libx264-123
    mplayer/mipsel unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/mipsel unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/mipsel unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/mipsel unsatisfiable Depends: libx264-123
    mplayer-gui/mipsel unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/mipsel unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/mipsel unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/mipsel unsatisfiable Depends: libx264-123
    mencoder/powerpc unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/powerpc unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/powerpc unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/powerpc unsatisfiable Depends: libx264-123
    mplayer/powerpc unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/powerpc unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/powerpc unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/powerpc unsatisfiable Depends: libx264-123
    mplayer-gui/powerpc unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/powerpc unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/powerpc unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/powerpc unsatisfiable Depends: libx264-123
    mencoder/s390x unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/s390x unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/s390x unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/s390x unsatisfiable Depends: libx264-123
    mplayer/s390x unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/s390x unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/s390x unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/s390x unsatisfiable Depends: libx264-123
    mplayer-gui/s390x unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/s390x unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/s390x unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/s390x unsatisfiable Depends: libx264-123
    mencoder/sparc unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mencoder/sparc unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mencoder/sparc unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mencoder/sparc unsatisfiable Depends: libx264-123
    mplayer/sparc unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer/sparc unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer/sparc unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer/sparc unsatisfiable Depends: libx264-123
    mplayer-gui/sparc unsatisfiable Depends: libavcodec53 (>= 5:0.8-2~) | libavcodec-extra-53 (>= 5:0.8-2~)
    mplayer-gui/sparc unsatisfiable Depends: libavformat53 (>= 5:0.8-2~)
    mplayer-gui/sparc unsatisfiable Depends: libavutil51 (>= 5:0.8-2~)
    mplayer-gui/sparc unsatisfiable Depends: libx264-123
    mplayer (source, i386, amd64, armel, armhf, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc) has new bugs!
    Updating mplayer introduces new bugs: #708140, #711578, #726838, #740967
    Not considered

Ansgar

Message #125 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Reinhard Tartler <siretart@gmail.com>

To: Thorsten Glaser <tg@mirbsd.de>, 728772@bugs.debian.org

Cc: 732159@bugs.debian.org

Subject: Re: Bug#728772: closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (Bug#732159: Removed package(s) from unstable)

Date: Mon, 21 Apr 2014 08:20:17 -0400

On Mon, Apr 21, 2014 at 6:42 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> Debian Bug Tracking System dixit:
>
>>This is an automatic notification regarding your Bug report
>>which was filed against the src:mplayer package:
>>
>>#728772: mplayer: FTBFS: The architecture of your CPU (UNKNOWN) is not supported
>>
>>It has been closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org>.
> […]
>>as the package mplayer has just been removed from the Debian archive
> […]
>
>
>
>      ***** *    **   ***      *                                  ****
>   ******  *  *****    ***   **                       *         *********
>  **   *  *     *****   ***  **                      **       ***  **   ***
> *    *  **     * **      ** **                      **     ***    **     ***
>     *  ***     *         ** **                    ********        **      ***
>    **   **     *         ** **  ***      ****    ********         **     ***
>    **   **     *         ** ** * ***    * ***  *    **            **    ***
>    **   **     *         ** ***   ***  *   ****     **            **   ***
>    **   **     *         ** **     ** **    **      **            ** ***
>    **   **     *         ** **     ** **    **      **            ****
>     **  **     *         ** **     ** **    **      **            ***
>      ** *      *         *  **     ** **    **      **            **
>       ***      ***      *   **     ** **    **      **
>        ******** ********    **     **  ***** **      **          ****
>          ****     ****       **    **   ***   **                 ****
>                                    *
>                                   *
>                                  *
>                                 *
>
>
> You cannot s̲e̲r̲i̲o̲u̲s̲l̲y̲ remove mplayer from the archive?
> You must be kidding. MPlayer2 was born dead and VLC
> just doesn’t work most of the time and has a horrible UI.

I'm very, very sorry about this myself. The whole affair is pretty
ironic, considering the amount of energy I've personally invested to
get mplayer (and ffmpeg, FWIW into debian/main).

Unfortunately, even after repeated calls for help in #732159, nobody
volunteered to help out with the package.

In the mean time, may I suggest having a look at mpv?
-- 
regards,
    Reinhard

Message #130 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Dominik George <nik@naturalnet.de>

To: Thorsten Glaser <tg@mirbsd.de>

Cc: 728772@bugs.debian.org, 732159@bugs.debian.org

Subject: Re: Bug#728772 closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (Bug#732159: Removed package(s) from unstable)

Date: Mon, 21 Apr 2014 15:30:13 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

> You cannot s̲e̲r̲i̲o̲u̲s̲l̲y̲ remove mplayer from the archive?
> You must be kidding. MPlayer2 was born dead and VLC
> just doesn’t work most of the time and has a horrible UI.

this alone is a false claim and without any prove to be considered a blatant 
lie.

MPlayer2 works like a charm, so does VLC. VLC might even be the pioneer for 
compatibility and interoperability in open source media player software.

I can imaging that modern software might lack desired features under extremely 
non-standard operating environments. If you kill everything that is needed on 
a modern Linux desktop, then expect things to break, and please do not blame 
it on the software.

> Honestly, please bring mplayer+ffmpeg back!

Please come by at my desk and give me at least one proof of concept where 
mplayer works AND (mplayer2 doesn't OR vlc doesn't) AND the media at hand is 
not obviously broken.

- -nik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQJOBAEBCAA4BQJTVR1lMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZpVRAAuUAad2PdwHVkIJUgjlSs
mc7XR0HhsmR8fL70mKvj9xGngBwGNEJ9lmPJmlHVT0/5J3tTuQ7660r83IrZ2lwL
HPxen291dzoT9191yu7a3u5lJhLovgq2MA2mwbvQJj1WrcQ5CSA9kJvKI5oopiyk
C1NQTYqTebCU7mWToNsZg6dEG1NmqzP+uVTYApG+bFqt5QBO9/tg+v8xIXga13Oc
KCGab4vt9uGyC/zuTapPzgRjCF3Rbxi1NjFGhcqtGB0G8efr1I5WP3IlTXVtwmSG
r6aMqAVsIrt+mog5tGyl14+0CI3QtjA9f59iWR+SLXnEMkyVqpV5gGcCiDMNQAJo
ddQjPMcWBqGINBV3RMCDF/l+hWRWjklQwpNzIRzmGdpua/xXdeyZReTJEWj2sp2E
MtT/Xv3v9fZGlPcTgAPytJ+P7h5S5sqKBn/gB9Iul5KT+g2TLX+YuBaLZSApymNV
WzImmIdDRsfWxNilZZ03UxUC9D2JCw0thg5ywRf/MUbVmoRZ/kVd+n1cEj9FykcO
g7ohj3FdGeAnPFW/Wu+mDMXNMMstZyZK2xjPevN7hXPQjQQgya03TeVGqd2BnQvt
o+oTCmsRd0ZmHwCPeMb+D/q6PHFgdop2VUGgM3YXLfnClCplkEpVXoUIHkMsbG4E
lsSuLDmy/IDAuplwagS1yHE=
=MNRW
-----END PGP SIGNATURE-----

Message #135 received at 732159@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Thorsten Glaser <tg@mirbsd.de>

Cc: Alexander Strasser <eclipse7@gmx.net>, Jonathan Dowland <jmtd@debian.org>, 728772@bugs.debian.org, 732159@bugs.debian.org, 729203@bugs.debian.org

Subject: Re: Bug#728772: closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (Bug#732159: Removed package(s) from unstable)

Date: Wed, 23 Apr 2014 09:58:30 +0200

On 21.04.2014 12:42, Thorsten Glaser wrote:
> Debian Bug Tracking System dixit:
>
>> This is an automatic notification regarding your Bug report
>> which was filed against the src:mplayer package:
>>
>> #728772: mplayer: FTBFS: The architecture of your CPU (UNKNOWN) is not supported
>>
>> It has been closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org>.
> […]
>> as the package mplayer has just been removed from the Debian archive
> […]
>
>
>
>       ***** *    **   ***      *                                  ****
>    ******  *  *****    ***   **                       *         *********
>   **   *  *     *****   ***  **                      **       ***  **   ***
> *    *  **     * **      ** **                      **     ***    **     ***
>      *  ***     *         ** **                    ********        **      ***
>     **   **     *         ** **  ***      ****    ********         **     ***
>     **   **     *         ** ** * ***    * ***  *    **            **    ***
>     **   **     *         ** ***   ***  *   ****     **            **   ***
>     **   **     *         ** **     ** **    **      **            ** ***
>     **   **     *         ** **     ** **    **      **            ****
>      **  **     *         ** **     ** **    **      **            ***
>       ** *      *         *  **     ** **    **      **            **
>        ***      ***      *   **     ** **    **      **
>         ******** ********    **     **  ***** **      **          ****
>           ****     ****       **    **   ***   **                 ****
>                                     *
>                                    *
>                                   *
>                                  *
>
>
> You cannot s̲e̲r̲i̲o̲u̲s̲l̲y̲ remove mplayer from the archive?
> You must be kidding. MPlayer2 was born dead and VLC
> just doesn’t work most of the time and has a horrible UI.
>
> Honestly, please bring mplayer+ffmpeg back!

We are already working on this, see the FFmpeg ITP [1].
I think Alexander Strasser managed to build a recent mplayer with these 
FFmpeg packages.

You're welcome to join the team and help getting FFmpeg uploaded to the 
archive. There is already a collab-maint repository [2].

Best regards,
Andreas


1: https://bugs.debian.org/729203
2: http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary

Send a report that this bug log contains spam.