Bug#1021013: mplayer: CVE-2022-38600 CVE-2022-38856 CVE-2022-38861 CVE-2022-38862 CVE-2022-38864
Hi! > CVE-2022-38600[0]: > | Mplayer SVN-r38374-13.0.1 is vulnerable to Memory Leak via vf.c and > | vf_vo.c. > > https://trac.mplayerhq.hu/ticket/2390#comment:2 > https://git.ffmpeg.org/gitweb/mplayer.git/commit/59792bad144c11b21b27171a93a36e3fbd21eb5e > (r38380) > Followup: > https://git.ffmpeg.org/gitweb/mplayer.git/commit/48ca1226397974bb2bc53de878411f88a80fe1f8 > (r38392) I would advise consideration on whether this should be considered relevant for Debian security. This is a minor memory leak that happens for files that cannot be played properly (and the leak is linear with number of files played), and MPlayer is rarely used to play many broken videos (i.e. ones that will not show any video) in sequence. I.e. worst case this is a hard (as in, takes a long time and many files) to trigger DoS for a tiny, tiny percentage of users. > CVE-2022-38862[3]: > | Certain The MPlayer Project products are vulnerable to Buffer Overflow > | via function play() of libaf/af.c:639. This affects mplayer > | SVN-r38374-13.0.1 and mencoder SVN-r38374-13.0.1. > > https://trac.mplayerhq.hu/ticket/2400 > https://trac.mplayerhq.hu/ticket/2404 These have not been reproduced, even the reporter could not reproduce using valgrind, and I could reproduce with neither valgrind nor ASAN. It could simply be a bug in the specific ASAN version used by the reporter. Code review has not left me 100% confident whether there might be a real issue in this code or not. Even if it is a real issue it is possible it affects only MEncoder, not MPlayer. Best regards, Reimar
Bug#1005899: mplayer: should not release with bookworm
> On 28 Feb 2022, at 19:12, Ian Jackson wrote: > It seems to me that at #1004579 (ffmpeg 5.0) and #939032 (giflib) > would need to be addressed, These are definitely fixed in 1.5, and the fix for giflib should be not hard to cherry-pick for 1.4 if there is a need. > and #958865 (crash on theora) really ought > to be fixed too. I could never reproduce it, but it could be I never tested 1.4 Debian build. But chances are this is fixed by 1.5 at least. > If we had a maintainer who is able to deal with > those, and also deal with some of the outstanding bug gardening, then > we could conclude that mplayer ought to stay. I am completely unfamiliar with the Debian processes and doubt I have time to learn (and interacting with the bug tracker seems supremely painful and confusing to me). So I also don't know what exactly is needed. But if it's just about debugging/fixing bugs or finding patches to cherry-pick I am here, and as said the lists are also there, as is MPlayer's trac bug tracker (though not that actively monitored, so would need to ping me for a fast response). Best regards, Reimar
Bug#1005899: mplayer: should not release with bookworm
On Thu, Feb 17, 2022 at 08:45:59PM +0100, Sebastian Ramacher wrote: > On 2022-02-17 19:13:08 +0100, Reimar Döffinger wrote: > > > > > On 16 Feb 2022, at 23:25, Sebastian Ramacher wrote: > > > > > > Let's stop pretending that mplayer is maintained. > > > > What is your criteria for "maintained"? In Debian or upstream? Upstream > > issues are still addressed from time to time, there are still several > > people around that can address issues, in particular security issues. > > It's definitely not maintained in Debian. Looking at the recent history > of mplayer uploads, I did most of them without any bug triaging. So > that's not what I would consider mplaer being maintained. As to the bugs, I have looked through them from time to time and they all looked outdated, were not reproducible or definitely not relevant anymore (like G3 PowerPC). I didn't want to meddle with them beyond a quick check as I don't know much about the process. > If you want to pick up maintenance of mplayer in Debian, please feel > free do that. I asked one person with at least some knowledge about all that, but they seemed to think that Debian requirements are too high relative to the time they have available. > > > The upstream mailing > > > list infrastructure is gone > > > > I have absolutely no idea why you claim that. > > It's there and working. > > Yesterday evening lists.mplayerhq.hu failed to resolve. Otherwise I > would have forwarded the build failure with ffmpeg 5.0. In the end, this > will need to be fixed for bookworm. Compilation with FFmpeg 5.0 has been fixed since a while in our repo. Finally we've also built the release packages, though not done the final steps for releasing yet (download links etc). http://mplayerhq.hu/MPlayer/releases/MPlayer-1.5.tar.xz is the release that supports FFmpeg 5.0
Bug#1005899: mplayer: should not release with bookworm
> On 16 Feb 2022, at 23:25, Sebastian Ramacher wrote: > > Let's stop pretending that mplayer is maintained. What is your criteria for "maintained"? In Debian or upstream? Upstream issues are still addressed from time to time, there are still several people around that can address issues, in particular security issues. > The upstream mailing > list infrastructure is gone I have absolutely no idea why you claim that. It's there and working. > and development has been minimal over the > last couple of months and years. It's mostly in maintenance mode I guess. There might be Debian users who don't mind their software changing radically as long as it keeps doing what they've used it for the previous years... > So I think we should not include > mplayer in bookworm. mpv is a worthy replacement for mplayer. Possibly, though it's not a drop-in replacement (different command-line) and supposedly it aims more at modern computers, so might not be so great a replacement for legacy hardware. Best regards, Reimar Döffinger
Bug#788126: Patch
I see there is some progress upstream so it may be reasonable to just wait it out. But since I hacked it up for myself anyway (well, only the grep expression really, did not test the rules file). The following quick hack patch would remove the questionable headers and ensure only properly licensed ones will be included in future versions: --- rules.bak 2016-02-20 14:56:05.532323726 +0100 +++ rules 2016-02-20 14:55:44.165777997 +0100 @@ -116,6 +116,9 @@ find debian/tmp -name .cvsignore | xargs rm -f find debian -empty -type f | xargs rm -f + # remove headers not under boost license + rm $(grep -rL "\(Boost Software License\|LICENSE_1_0.txt\|automatically generated\)" debian/tmp/usr/include) + # package libboost-dbg # package libboost$(PKGVERSION)-dev
Bug#788126: libboost1.55-dev: Contains files with missing or questionable licenses
Package: libboost1.55-dev Version: 1.55.0+dfsg-3 Severity: serious Justification: Policy 2.3 Dear Maintainer, Several files in this package do not seem to be covered by any license described in the copyright file. Most serious: interprocess/sync/xsi/advanced_xsi_semaphore.hpp : No license mentioned at all python/detail/python22_fixed.h : Explicitly All rights reserved Probably fine but questionable and IMHO should be documented at least as they will fail in automated checks: algorithm/cxx14/mismatch.hpp : Refers to non-existing LICENSE10.txt, probably typo And some non-standard license headers in: rational.hpp math/common_factor_rt.hpp test/utils/runtime/cla/detail/argument_value_usage.hpp shared_container_iterator.hpp program_options/detail/utf8_codecvt_facet.hpp Aside: The latter files contain in some cases boostinspect:nolicense, indicating that someone at some point tried to avoid this license mess, however that activity seems to have died... Given the popularity of the library and the regularity of license slip-ups a more long-term solution than manual review/fixing would be nice to have. And apologies if Severity: serious was the incorrect choice. Thanks, Reimar Döffinger -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (700, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel, ppc64el Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libboost1.55-dev depends on: ii libstdc++-4.9-dev [libstdc++-dev] 4.9.2-18 ii libstdc++-5-dev [libstdc++-dev]5.1.1-9 libboost1.55-dev recommends no packages. Versions of packages libboost1.55-dev suggests: pn libboost-atomic1.55-dev none pn libboost-chrono1.55-dev none pn libboost-context1.55-dev none pn libboost-coroutine1.55-devnone pn libboost-date-time1.55-devnone pn libboost-exception1.55-devnone pn libboost-filesystem1.55-dev none pn libboost-graph-parallel1.55-dev none pn libboost-graph1.55-devnone pn libboost-iostreams1.55-devnone pn libboost-locale1.55-dev none pn libboost-log1.55-dev none pn libboost-math1.55-dev none pn libboost-mpi-python1.55-dev none pn libboost-mpi1.55-dev none pn libboost-program-options1.55-dev none pn libboost-python1.55-dev none pn libboost-random1.55-dev none pn libboost-regex1.55-devnone pn libboost-serialization1.55-devnone pn libboost-signals1.55-dev none pn libboost-system1.55-dev none pn libboost-test1.55-dev none pn libboost-thread1.55-dev none pn libboost-timer1.55-devnone pn libboost-wave1.55-dev none pn libboost1.55-doc none pn libboost1.55-tools-devnone pn libmpfrc++-devnone pn libntl-devnone -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732159: Should this package be removed?
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.doeffin...@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.doeffin...@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
Bug#732159: Should this package be removed?
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.doeffin...@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
Bug#732159: Should this package be removed?
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 j...@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 j...@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... -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732159: Should this package be removed?
On 14.12.2013, at 23:53, John Paul Adrian Glaubitz glaub...@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 j...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653887: libavformat53 breaks mplayer
On 1 Jan 2012, at 15:26, Reinhard Tartler siret...@tauware.de wrote: On So, Jan 01, 2012 at 15:08:03 (CET), Julien Cristau wrote: On Sun, Jan 1, 2012 at 08:25:00 +0100, Reinhard Tartler wrote: I really think this is a bug in mplayer. ff_codec_wav_tags is and always was an internal symbol, that is no longer exported since this commit: http://git.libav.org/?p=libav.git;a=commitdiff;h=8d74bf17c6d6280195854f4dadb19ef37d054566 This issue a long-standing wart in mplayer that should really be fixed there. Honestly, this is kind of a broken position IMO. The moment one of your reverse deps uses a symbol, it stops being internal, whatever your intentions were. Well, if you can show me that a number of other packages use ff_codec_wav_tags, I agree to patch the symbol versioning script to make it visible again. But TBH, I'd be surprised if you would find a single other package. Please note that this is fixed since several months (actually I think since very shortly after this became an issue) in MPlayer svn. So you could update, backport the patch (well, unfortunately several since the first few tries were broken) or make the versioning script change as a temporary workaround you would _not_ have to carry around forever. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536885: symbol lookup error: mplayer: undefined symbol: codec_wav_tags
On Tue, Jul 14, 2009 at 05:38:54PM +0200, Reinhard Tartler wrote: mplayer however contains a private copy of ffmpeg in its sources, and has therefore no problem including headers that are not installed. libavformat/riff.h is e.g. such a header. This is strictly speaking a violation of usage convention, but the mplayer developers don't care here. Just so that nobody gets the wrong impression: this is not so much not careing but that overall due to maintainability issues it still seems the better solution so far. I admit though that we focus more on our users that compile MPlayer themselves where this does not pose any issues. If this causes too serious issues for distributions we might try to re-evaluate, but obviously making us use harder to maintain code needs some convincing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Mon, Jun 16, 2008 at 04:21:50PM +0200, A Mennucc wrote: 2.2 the mplayer binary does not link with the ffmpeg-free libs. By reading and diffing, it would seem that the newer ffmpeg-free 0.svn20080206 source code seems compatible to the ffmpeg code shipped in mplayer... but unfortunately when I try to link, it fails. The error is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395252#226 To me it looks like either you are missing a -lavutil or have it at the wrong place. Note that compiling with and out-of-tree libavutil is and will not be supported by upstream at least for now since MPlayer depends on some of its internal functions that can not be exported cleanly (features that depend on a FFmpeg-compatible config.h). Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475973: mplayer: FTBFS: cabac.h:525: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'
On Mon, Apr 14, 2008 at 04:30:24PM +0200, Lucas Nussbaum wrote: On 14/04/08 at 11:58 +0200, Diego Biurrun wrote: On Mon, Apr 14, 2008 at 12:48:56PM +0200, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on i386. This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now the default on most architectures (even if it's not the case on i386 yet). Feel free to downgrade this bug to 'important' if your package is only built on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with gcc 4.2). Relevant part: cc -g -O2 -I./libavcodec -I./libavformat -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I. -I./libavutil -g -O2 -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/include/directfb -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -I/usr/include/freetype2 -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I../libswscale -I../libavcodec -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I.. -I../libavutil -g -O2 -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/include/directfb -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -I/usr/include/freetype2 -I/usr/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12-c -o h264.o h264.c h264.c: In function 'decode_cabac_residual': h264.c:5350: warning: passing argument 4 of 'decode_significance_8x8_x86' discards qualifiers from pointer target type cabac.h: In function 'get_cabac_noinline': cabac.h:525: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' cabac.h:525: error: 'asm' operand has impossible constraints make[2]: *** [h264.o] Error 1 That is a bug in gcc, not MPlayer. gcc should not run out of registers. This might be caused by the default value of CFLAGS now set by dpkg-buildpackage. Maybe this code doesn't build with -O2 ? No, certainly not. From the MPlayer developers side, only the build flags chosen by MPlayer's configure are acceptable and anything else is unsupported and very likely to fail. In particular, -fomit-frame-pointer is mandatory. While there is alternative code that works without, it is (for H.264 about 10%) slower and thus not really acceptable. Also, -O2 compared to the default of -O4 (equivalent to -O3) has very different inlining behaviour and might cause significant performance differences as well. Greetings, Reimar Döffinger
Bug#473056: mplayer: CVE-2008-0073 remote code execution via crafted rtsp stream
On Sat, Mar 29, 2008 at 02:10:27PM +0100, Nico Golde wrote: Hi A Mennucc, * A Mennucc [EMAIL PROTECTED] [2008-03-29 14:00]: Nico Golde ha scritto: Package: mplayer Severity: grave Tags: security patch This also affects mplayer since it also uses this code. A patch is available on: http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=12cb075fba8ea09813fc35e0c731d2a64265b637;style=raw I saw a comment of Reimar (that I am CC-ing); he wrote in the mplayer dev list, saying that mplayer is not affected as badly as xine; anyway Reimar wrote a short patch, that I will apply tomorrow Not sure what is meant with as badly but if you mean http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-March/056938.html the patch fixes the same problem in a different way like the diff from the xine-lib repository. I did not check myself I admit, I just assumed from explanations elsewhere that the xine version was missing some checks on stream_id as well. Sorry if I misunderstood (and thus misrepresented) the issue. Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: requires too much security maintainance work due to embedded ffmpeg copy - Lenny status
On Fri, Mar 28, 2008 at 02:41:19PM +, Neil McGovern wrote: Just a reminder that this is a RC issue, and needs resolving if mplayer is going to ship with lenny. Not that I am involved in this, but is it clear which are acceptable solutions? _If_ the FFmpeg version is compatible (easier to achieve by just not sticking to MPlayer releases but just updating it to SVN when FFmpeg is updated), just copying the libavformat/libavcodec/libswscale/libavutil directories over is one possibility - no idea if the build tools have an automated way for source-level code sharing though... Using the generated .a files should not be too much effort either, if there is a way to have some internal FFmpeg headers installed as well. Without those internal headers or when using .so files there would be a bit of trouble though, at the very least some features like -vf fspp would be lost... Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445731: mplayer stops working after kernel update to 2.6.21
Hello, On Sat, Oct 13, 2007 at 03:25:06PM -0400, Sean Zimmermann wrote: I found ALSA stopped working after the kernel upgrade. Any program that tried to work with alsa (like xmms, totem, or gnome sound) stalled. I recompiled the drivers and alsa now appears to be working. While it does not hang immediately it still looks like exactly the same problem to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445731: mplayer stops working after kernel update to 2.6.21
There is no difference at all in the outputs. I suspect this is not an MPlayer problem. Actually there is, in the later one audio gets stuck at 0.0 seconds. My guess is that ALSA broke... Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
