Bug#882176: libgsm1-dev: installs internal, non-public header files
Package: libgsm1-dev Version: 1.0.13-4+b2 Severity: important Tags: patch Hello! The -dev Debian package for libgsm installs all of the header files contained in the libgsm upstream sources instead of only installing the gsm.h public header file. I'm including a patch to fix this. It's untested because I don't have package building infrastructure easily available on this machine. Furthermore Debian renames a libgsm internal header, config.h, to gsm_config.h in 03_config.patch of the quilt patch series. This is probably a workaround for issues introduced by wrongly installing that header. I'm attaching another patch to drop 03_config.h. best regards, Diego Only in debian.orig/patches: 03_config.patch diff -ur debian.orig/rules debian.fixed/rules --- debian.orig/rules 2012-04-12 18:10:27.0 +0200 +++ debian.fixed/rules 2017-11-19 21:22:16.586583755 +0100 @@ -34,9 +34,8 @@ dh_testroot dh_installdirs mkdir -p debian/tmp/usr/lib debian/tmp/usr/bin debian/libgsm1-dev/usr/lib/$(DEB_HOST_MULTIARCH) debian/libgsm1/usr/lib/$(DEB_HOST_MULTIARCH) - $(MAKE) $(CROSS) INSTALL_ROOT=debian/tmp/usr GSM_INSTALL_INC=debian/libgsm1-dev/usr/include/gsm GSM_INSTALL_MAN=debian/libgsm1-dev/usr/share/man/man3 TOAST_INSTALL_MAN=debian/libgsm-tools/usr/share/man/man1 install - ln -s gsm/gsm.h debian/libgsm1-dev/usr/include/gsm.h - cp inc/*.h debian/libgsm1-dev/usr/include/gsm + $(MAKE) $(CROSS) INSTALL_ROOT=debian/tmp/usr GSM_INSTALL_INC=debian/libgsm1-dev/usr/include GSM_INSTALL_MAN=debian/libgsm1-dev/usr/share/man/man3 TOAST_INSTALL_MAN=debian/libgsm-tools/usr/share/man/man1 install + ln -s ../gsm.h debian/libgsm1-dev/usr/include/gsm/gsm.h mv lib/*so debian/libgsm1-dev/usr/lib/$(DEB_HOST_MULTIARCH) mv lib/*a debian/libgsm1-dev/usr/lib/$(DEB_HOST_MULTIARCH) mv lib/*so.* debian/libgsm1/usr/lib/$(DEB_HOST_MULTIARCH) diff -ur debian.orig/patches/04_includes.patch debian.fixed/patches/04_includes.patch --- debian.orig/patches/04_includes.patch 2012-04-12 17:22:53.0 +0200 +++ debian.fixed/patches/04_includes.patch 2017-11-19 22:26:39.379002210 +0100 @@ -37,7 +37,7 @@ --- a/src/code.c +++ b/src/code.c @@ -9,8 +9,8 @@ - #include "gsm_config.h" + #include "config.h" -#ifdefHAS_STDLIB_H diff -ur debian.orig/patches/series debian.fixed/patches/series --- debian.orig/patches/series 2012-04-12 17:22:53.0 +0200 +++ debian.fixed/patches/series 2017-11-19 21:40:20.233591925 +0100 @@ -1,6 +1,5 @@ 01_makefile.patch 02_cplusplus.patch -03_config.patch 04_includes.patch 05_compiler_warnings.patch 06_fix_manpages.patch
Bug#710064: libcdio: upstream version still not packaged
Source: libcdio Followup-For: Bug #710064 Hello, a new version of this package was uploaded to experimental 3 years ago, but it never propagated to unstable. Several new upstream versions have been released since, but there was no further activity on the Debian package. Has this package been orphaned? best regards, Diego
Bug#732159: Should this package be removed?
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717072: AMV-support is missing
close 717072 stop On 2013-07-16 15:45, Juhapekka Tolvanen wrote: Package: ffmpeg Version: 6:0.8.7-1 Severity: important https://en.wikipedia.org/wiki/AMV_video_format The AMV code has been sent upstream to the main FFmpeg project[5] and the mainline version of FFmpeg now decodes and encodes AMV. Maybe you should check the date on that one, it will give you something about 2007. Oh, really?: juhtolv@juhtolv | ti 16 heinä 2013 16:43:04 | 10019 | pts/23 /home/juhtolv % ffmpeg -formats 21 | grep -i amv [1]3874 done ffmpeg -formats 21 | 3875 exit 1 grep $GREP_OPTIONS -i amv AMV is not a format, it's a codec: $ avconv -codecs 2 /dev/null | grep '[^_]amv[^_]' D.VIL. amv AMV Video The distinction between format (or container) and codec is often not made by those not working closely with multimedia, but it's important nonetheless. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717072: AMV-support is missing
On 2013-07-16 16:27, Fabian Greffrath wrote: Am Dienstag, den 16.07.2013, 16:45 +0300 schrieb Juhapekka Tolvanen: The AMV code has been sent upstream to the main FFmpeg project[5] and the mainline version of FFmpeg now decodes and encodes AMV. Oh, really?: In fact, ffmpeg seems to have it while libav doesn't. I have no idea where you got that idea. AMV support was added in September 2007, years before the split. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654974: mplayer: FTBFS on hurd-i386
On Sat, Jan 07, 2012 at 03:37:19PM +0100, Samuel Thibault wrote: mplayer currently FTBFS on hurd-i386 due to missing cdparanoia dependency, and unconditional PATH_MAX usage. The attached patch fixes both. PATH_MAX is POSIX, so you should fix Hurd instead, see: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515713: mplayer: binary_codecs.sh install seems to fail when my ISP hijacks DNS errors
On Sun, Oct 03, 2010 at 07:12:26PM +0200, A Mennucc wrote: I attach a new version of the script, with 3 changes, 1) use 'dpkg --print-architecture' , the option --print-installation-architecture is deprecated 2) do not create a fake 'bestsites' if neither 'fping' or 'netselect' are installed 3) check that the download of 'wget' is not been redirected by some nice provider DNS If you sent a patch to upstream, this might even get applied... Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595452: mplayer: Fails to play recent Matroska (MKV) files: Track 1 has been compressed with an unknown/unsupported compression algorithm (3)
On Sun, Sep 05, 2010 at 11:30:20AM +0200, Reinhard Tartler wrote: On Sun, Sep 05, 2010 at 11:16:28 (CEST), Reimar Döffinger wrote: On Sat, Sep 04, 2010 at 10:44:38PM +0200, Reinhard Tartler wrote: BTW, I can reproduce this error with rc4 by forcing the native mkv muxer with the opten '-demuxer mkv'. This means that this bug is not fixed in rc4 at all, but just masked by using lavf by default! Note that there is a patch pending for it in the MPlayer dev list (and a few more as well). Unfortunately the patch submitter disappeared and I would have preferred to let him apply himself. For what specifically? fixing the native mkv muxer or switching the default? There are some pending patches for the native mkv demuxer. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506244: mplayer: Can't keep up with 64kbit/s Vorbis on 400MHz CPU
On Fri, Aug 06, 2010 at 10:16:49AM -0400, Reinhard Tartler wrote: In case this works, Diego, Reimar, do you think it's worth to ship a different codecs.conf on arm-ish (arm, armel and armhf) platforms that prefer tremor over ffvorbis? Or can this preference perhaps be influenced by a configure switch? I have thought about this before, but I have no good idea how to solve this. A different codecs.conf will work, but it's ugly. Maybe we could add a fixedpoint flag to codecs.conf entries and prefer these codecs on systems without FPU? Reimar? Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506244: mplayer: Can't keep up with 64kbit/s Vorbis on 400MHz CPU
On Fri, Aug 06, 2010 at 05:56:25PM +0200, Reimar Döffinger wrote: On Fri, Aug 06, 2010 at 05:07:14PM +0200, Diego Biurrun wrote: On Fri, Aug 06, 2010 at 10:16:49AM -0400, Reinhard Tartler wrote: In case this works, Diego, Reimar, do you think it's worth to ship a different codecs.conf on arm-ish (arm, armel and armhf) platforms that prefer tremor over ffvorbis? Or can this preference perhaps be influenced by a configure switch? I have thought about this before, but I have no good idea how to solve this. A different codecs.conf will work, but it's ugly. Maybe we could add a fixedpoint flag to codecs.conf entries and prefer these codecs on systems without FPU? Reimar? I think the approach that was discussed for FFmpeg was to only compile the faster variant. I has quite a few issues, but in principle only compiling in tremor support would select it. It would also work the other way round (and probably better), make tremor the default but only compile it in on FPU-less systems. In the case of MPlayer there may be some issues with that, e.g. the native ogg demuxer behaviour might change. Of course the best solution would have been if tremor hadn't been developed as a completely different library but instead was just a different configuration of libvorbis... I disagree slightly here since the issue does not only apply to Vorbis/Tremor. For MP3 we have a similar situation: We default to mp3lib, but ffmp3 is fixedpoint and thus faster on systems without FPU. So a slightly more general framework on our side might be adequate. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
On Fri, Apr 23, 2010 at 05:31:29PM +0200, Petr Salinger wrote: --- trunk/libvo/vo_directfb2.cThu Apr 22 16:02:20 2010(r31057) +++ trunk/libvo/vo_directfb2.cFri Apr 23 12:04:56 2010(r31058) @@ -35,9 +35,9 @@ #ifdef __linux__ -#include sys/kd.h -#else #include linux/kd.h +#else +#include sys/kd.h #endif You could really use sys/kd.h everywhere: http://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/sys/kd.h;hb=HEAD In fact, it seems we can live without that header entirely. I just removed the #include. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
On Fri, Apr 23, 2010 at 12:57:33PM +0200, Petr Salinger wrote: That was helpful, fixed upstream. I once again reiterate my suggestion to pass problems to upstream first before attempting to work around them locally in the packaging infrastructure of a single distribution. The expected workflow is a different one. Let the package does not build on a particular architecture. Iff it is detected by porter (me), porter tries to find the cause or provide workaround/fix/hints. They go to Debian BTS, package maintainer evaluates them and integrates into package and forward upstream. In some cases the package maintainer is upstream author or have commit rights into upstream repository, some upstream authors look after bug entries in some distribution. Please take a look at [1], click on bottom on Toggle all extra information. There is at about 16000 source packages in Debian. It cannot be managed to comunicate with every of thousands upstreams directly. Moreover the entry in BTS signals for other porters, that the problem is known and its state. I can understand your position if you are only a porter and not a direct maintainer of a package. However, I have seen package maintainers in different distros duplicate each other's work and add hacks to their packages that I could have fixed quicker and cleaner if somebody had shared their problems with me. I'm just letting you know the upstream position. We want to hear about issues and we want the patches. Everybody's life gets easier if work gets upstreamed. Just look how quick we managed to get GNU/kfreebsd building, it was a matter of hours after we received the reports. And now that it's upstream nobody will have extra work maintaining patches again... Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
On Wed, Apr 21, 2010 at 04:50:59PM +0200, Petr Salinger wrote: the current version fails to build on kfreebsd-amd64. it suffices to disable vidix support in debian/rules Bad solution, this will only work for Debian. You should fix configure instead of adding workarounds to the local packaging infrastructure. What are the error messages? The full build log is linked from usual place https://buildd.debian.org/status/package.php?p=mplayer https://buildd.debian.org/fetch.cgi?pkg=mplayerver=1.0%7Erc3%2Bsvn20090405-1arch=kfreebsd-amd64stamp=1271726776file=log vidix/pci.o: In function `pci_config_read': /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:719: undefined reference to `pci_config_read_long' vidix/pci.o: In function `pci_scan': /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:536: undefined reference to `pci_config_type' /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:556: undefined reference to `pci_get_vendor' /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:568: undefined reference to `pci_config_read_long' /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:570: undefined reference to `pci_config_read_long' /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:572: undefined reference to `pci_config_read_long' /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:574: undefined reference to `pci_config_read_long' /build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:576: undefined reference to `pci_config_read_long' vidix/pci.o:/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:578: more undefined references to `pci_config_read_long' follow That was helpful, fixed upstream. I once again reiterate my suggestion to pass problems to upstream first before attempting to work around them locally in the packaging infrastructure of a single distribution. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
On Wed, Apr 21, 2010 at 02:10:31PM +0200, Petr Salinger wrote: the current version fails to build on kfreebsd-amd64. it suffices to disable vidix support in debian/rules to get working mplayer. ifeq ($(DEB_HOST_ARCH),kfreebsd-amd64) with_real_and_xanim = true DEB_BUILD_CONFIGURE += --enable-runtime-cpudetection --disable-vidix endif Bad solution, this will only work for Debian. You should fix configure instead of adding workarounds to the local packaging infrastructure. What are the error messages? Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578622: mplayer: FTBFS on kfreebsd-amd64
On Wed, Apr 21, 2010 at 04:22:16PM +0200, Petr Salinger wrote: please also change configure as shown bellow. Otherwise the memalign() is without prototype, which on 64 bit platform leads to segfaults for some videos. Fixed upstream. Why don't you submit your patches directly to MPlayer instead of hiding them in some distro package? Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576590: mplayer - Please remove unusable video outputs
On Mon, Apr 05, 2010 at 11:15:33PM +0200, Bastian Blank wrote: Package: mplayer Version: 1.0~rc3+svn20090405-1+b1 Severity: normal Please remove unusable video outputs from the shipped mplayer binaries: | xmgaMatrox G200/G4x0/G550 overlay in X11 window (using /dev/mga_vid) | mga Matrox G200/G4x0/G550 overlay (/dev/mga_vid) | tdfxfb 3Dfx Banshee/Voodoo3/Voodoo5 | 3dfx3dfx (/dev/3dfx) All of them are replaced by Xv in the meantime. Nonsense. Maybe it would be also okay to remove the following: | fbdev Framebuffer Device | fbdev2 Framebuffer Device | dfbmga DirectFB / Matrox G200/G400/G450/G550 They can be replaced by directfb. Ditto. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569727: ffmpeg: Please update
On Sun, Feb 14, 2010 at 03:34:26PM +0200, Adrian Bunk wrote: On Sun, Feb 14, 2010 at 09:16:26AM +0100, Reinhard Tartler wrote: ... and lacks e.g. the AMR support that is now possible with libraries already in Debian. that's already possible with ffmpeg 0.5 that we ship with squeeze. The problem with that is the license: linking against opencore will render the resulting libavcodec library as GPLv3. Until now, noone has made an analysis on the impact of that change. Why? opencore is licenced under the Apache License Version 2.0 .. which is only compatible with (L)GPL v3, not v2 .. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214134316.gd20...@pool.informatik.rwth-aachen.de
Bug#567725: mplayer: gets SIGILL on Pentium II when playing an MPEG video with -vo caca
On Sun, Jan 31, 2010 at 04:47:13PM +0100, Reinhard Tartler wrote: On So, Jan 31, 2010 at 12:18:29 (CET), Reimar Döffinger wrote: On Sun, Jan 31, 2010 at 09:32:05AM +0100, Reinhard Tartler wrote: libswscale uses MMX2: -- The GDB backtrace #0 0xb620657d in yuv420_rgb24_MMX2 (c=0x8601ec0, src=0xbfffcb70, srcStride=0xbfffcb40, srcSliceY=0, srcSliceH=16, dst=0x862c944, dstStride=0xbfffcb50) at /build/buildd-ffmpeg_0.5+svn20090706-5-i386-gCmK4F/ffmpeg-0.5+svn20090706/libswscale/yuv2rgb_template.c:292 This is the same bug as https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/386397 As easy workaround, you can move /usr/lib/i686/cmov/libswscale.so.0 out of the way. Not sure how to fix this properly. By doing what the first comment in that bug report says? Compile FFmpeg with --enable-runtime-cpudetection upon closer inspection, this is not possible in ffmpeg 0.5 yet. Unless someone wants to work on backporting this change from current trunk, I fear this will remain unfixed until ffmpeg 0.6. This sounds like a candidate for backporting, i.e. it is likely a change that I would approve. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544681: mplayer: please add libmad support
On Wed, Sep 02, 2009 at 02:25:21PM +0400, Nikita V. Youshchenko wrote: Debian mplayer package is built without libmad support. Libmad is a fixed-point audio mpeg decoder.1 Without libmad support, mplayer can't be used on slow armel devices that lack hardware FPU, such as the Freerunner. False. FFmpeg contains a fixed-point MP3 decoder that is much faster than libmad and already available to MPlayer without adding an unnecessary libmad dependency. Package from debian-multimedia.org is built with libmad support, and it works in Freerunner much better. Since libmad is available in debian main, please enable libmad support in the official debian mplayer package. The real problem is that the Ubuntu MPlayer package (and possibly others) contains the following bad config file entry .. # Specify default audio codec (see -ac help for a list). ac=mad, .. which results in libmad getting preferred over other MP3 decoders, upsetting the default we are using (for a good reason) at upstream. That's why you falsely believe that you should be using libmad when ffmp3 is much better. For the freerunner you should simply prefer ffmp3 over mp3lib. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544681: mplayer: please add libmad support
On Wed, Sep 02, 2009 at 04:21:41PM +0400, Nikita V. Youshchenko wrote: For the freerunner you should simply prefer ffmp3 over mp3lib. That really works. Excellent, I'm glad the hint helped. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544681: mplayer: please add libmad support
On Wed, Sep 02, 2009 at 02:43:31PM +0200, Fabian Greffrath wrote: Diego Biurrun schrieb: FFmpeg contains a fixed-point MP3 decoder that is much faster than libmad and already available to MPlayer without adding an unnecessary libmad dependency. Anyway, we should offer the choice to use libmad and therefore I added libmad0-dev to the Build-Depends. Sorry, but this is nonsense. There is an insane amount of dependencies that you can add for no practical gain. That's why you falsely believe that you should be using libmad when ffmp3 is much better. For the freerunner you should simply prefer ffmp3 over mp3lib. Sorry, but I don't think so. Until now the mplayer package in neither Debian nor Ubuntu has been built against libmad. It was built against libmad in the past until I convinced Reinhard Tartler to drop the useless dependency. Now you have put it back. Way to go... Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540424: [Mlt-devel] SIGV with a DIF (DV) movie file (PAL)
On Wed, Aug 12, 2009 at 09:47:30PM +0200, Reinhard Tartler wrote: I have no plans to stop tracking the 0.5 release branch, so yes, we'd need a patch for the 0.5 release. In fact, the 0.5 release branch *is* updated with updates, and there is even a 0.5.1 release in the pipe. Note that I do not plan to add feature or bugfix patches to the 0.5 branch. I only want security fixes and licensing issues, plus some portability patches that do not affect other platforms. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540729: ffmpeg: Possible regression - fails to decode AAC
On Mon, Aug 10, 2009 at 10:27:10AM +0200, Fabian Greffrath wrote: Reinhard Tartler schrieb: Well, checking this would be helpful. I've extracted the relevant patch, you can find it attached. [...] I've succeeded to reproduce the problem, I'm currently testbuilding ffmpeg to see if the patch indeed fixes playback of that file. [...] yes, that patch allows me to listen to your voice testing 123 testing. I'll include that patch in the next upload. Hu? Doesn't ffmpeg use faad2 anymore to play back AAC files and use their own code now? We have an internal AAC decoder now that is about 3x faster than FAAD. The only shortcoming is thatt it still lacks SBR support. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-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 04:01:16PM +0100, Christophe Mutricy wrote: 2009/7/14 Reinhard Tartler siret...@tauware.de: r19254 | diego | 2009-06-23 01:09:34 +0200 (Di, 23. Jun 2009) | 3 lines Add ff_ prefixes to exported symbols in libavformat/riff.h. [...] - mplayer is (yet another time) using internals of libavformat and therefore very dependent on the exact version of ffmpeg against which it was compiled against. Now i'm confused. For me exported = external. so it's a break of the API so requires a soname bump. riff.h is not an installed header. So if I trust the svn log, it's FFMpeg fault for not bumping soname and mot mplayer fault. FFmpeg, not FFMpeg, please notice the correct spelling. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530436: ffmpeg-debian: FTBFS on Hurd
On Mon, May 25, 2009 at 03:26:50AM -0400, Andres Mejia wrote: On Monday 25 May 2009 01:34:15 Diego Biurrun wrote: On Sun, May 24, 2009 at 08:53:08PM -0400, Andres Mejia wrote: On Sunday 24 May 2009 17:08:17 Marc Dequènes (Duck) wrote: The configure script does not support the GNU system. The attached very small patch adds the required modification to fix this problem. Please consider applying it in your next upload and help push this change upstream. Thanks. It's been applied in the git repo for the next upload and forwarded upstream. Better strategy: Forward upstream first, then merge back whatever changes upstream really implements. Oh yeah, got to fix that now. I'll forward these changes upstream first then from now on. Thanks. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530436: ffmpeg-debian: FTBFS on Hurd
On Mon, May 25, 2009 at 03:26:50AM -0400, Andres Mejia wrote: On Monday 25 May 2009 01:34:15 Diego Biurrun wrote: On Sun, May 24, 2009 at 08:53:08PM -0400, Andres Mejia wrote: On Sunday 24 May 2009 17:08:17 Marc Dequènes (Duck) wrote: The configure script does not support the GNU system. The attached very small patch adds the required modification to fix this problem. Please consider applying it in your next upload and help push this change upstream. Thanks. It's been applied in the git repo for the next upload and forwarded upstream. Better strategy: Forward upstream first, then merge back whatever changes upstream really implements. Oh yeah, got to fix that now. I'll forward these changes upstream first then from now on. Note that I changed your patch twice already. While yours is correct even if not optimal, committing it prematurely still caused you duplicated work. Had it been buggy, there might have been trouble... With an upstream as active and responsive as FFmpeg I think there is never a reason to commit a patch before it is accepted upstream. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530436: ffmpeg-debian: FTBFS on Hurd
On Sun, May 24, 2009 at 08:53:08PM -0400, Andres Mejia wrote: On Sunday 24 May 2009 17:08:17 Marc Dequènes (Duck) wrote: The configure script does not support the GNU system. The attached very small patch adds the required modification to fix this problem. Please consider applying it in your next upload and help push this change upstream. Thanks. It's been applied in the git repo for the next upload and forwarded upstream. Better strategy: Forward upstream first, then merge back whatever changes upstream really implements. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370599: OpenCORE AMR library
On Thu, May 14, 2009 at 10:54:43PM -0400, Andres Mejia wrote: Martin Storsjö developed a wrapper around the AMR codecs from the OpenCORE framework, and supplied patches to the FFmpeg project so they can be used as a replacement for the libraries you developed. Those patches have been accepted into the FFmpeg source. The announcement is at [1]. 1. http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-April/068167.html The patches have *not* been accepted. I don't know what gave you the idea. What I applied was a small fix for the libamr check in configure. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370599: OpenCORE AMR library
On Fri, May 15, 2009 at 02:32:24PM -0400, Andres Mejia wrote: On Friday 15 May 2009 05:03:17 Diego Biurrun wrote: On Thu, May 14, 2009 at 10:54:43PM -0400, Andres Mejia wrote: Martin Storsjö developed a wrapper around the AMR codecs from the OpenCORE framework, and supplied patches to the FFmpeg project so they can be used as a replacement for the libraries you developed. Those patches have been accepted into the FFmpeg source. The announcement is at [1]. 1. http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-April/068167.html The patches have *not* been accepted. I don't know what gave you the idea. What I applied was a small fix for the libamr check in configure. Oh I see. Sorry. What was the problem with those patches? Just curious. I just checked again and implemented the patch slightly differently. I haven't yet had time to test the replacement library itself though. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370599: [Bug 93849] Re: Can't hear audio from 3GP video files: AMR audio support missing in ffmpeg
On Tue, May 12, 2009 at 04:04:38PM -0400, Andres Mejia wrote: On Tuesday 12 May 2009 06:29:39 Reinhard Tartler wrote: Nicolò Chieffo nicolo.chie...@gmail.com writes: Read here: http://blogs.gnome.org/uraeus/2009/05/11/help-for-transmageddon/ It seems that there's a free (apache licenced) amr decoder and encoder in the android GIT repository. let's hope it will get integrated into ffmpeg! I like this implementation better. I'll look into this instead. My favorite is the native FFmpeg implementation that was developed during Google Summer of Code 2006. Unfortunately it was never finished. With a bit of luck it will be finished during this year's SoC. Help is very much welcome. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#370599: [Bug 93849] Re: Can't hear audio from 3GP video files: AMR audio support missing in ffmpeg
On Tue, May 12, 2009 at 04:27:02PM -0400, Andres Mejia wrote: On Tuesday 12 May 2009 16:12:50 Diego Biurrun wrote: On Tue, May 12, 2009 at 04:04:38PM -0400, Andres Mejia wrote: On Tuesday 12 May 2009 06:29:39 Reinhard Tartler wrote: Nicolò Chieffo nicolo.chie...@gmail.com writes: Read here: http://blogs.gnome.org/uraeus/2009/05/11/help-for-transmageddon/ It seems that there's a free (apache licenced) amr decoder and encoder in the android GIT repository. let's hope it will get integrated into ffmpeg! I like this implementation better. I'll look into this instead. My favorite is the native FFmpeg implementation that was developed during Google Summer of Code 2006. Unfortunately it was never finished. With a bit of luck it will be finished during this year's SoC. Help is very much welcome. Yet another interesting implementation is retrocode. https://sourceforge.net/projects/retrocode/ This one is GPL3+. No, this is not an implementation of AMR, it uses the nonfree libamr. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526735: mplayer: 'dumpstream' should be switchable (on/off) while a stream is being played
On Sun, May 03, 2009 at 12:42:54PM +0200, a...@users.sourceforge.net wrote: My starting point was: Why can't mplayer recognize a URL as a playlist if that is the case? Then I started analysing the URLs given for different streams and built the first part of the script. mplayer -playlist Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#440216: Bug#508524: Bug#440216: Two issues here, bug needs splitting
On Tue, Apr 21, 2009 at 12:17:52PM +0200, Reinhard Tartler wrote: I'm doing a bit of bug clean up here. Bug #508524 claims that there was an mpeg4 encoder in etch. That's impossible, ffmpeg never had an mpeg4 encoder. What is true is that libavcodec can use libx264 for mpeg4 encoding. This encoder is called 'libx264', not 'mpeg4'. We can enable Sure FFmpeg has an MPEG-4 (ASP) encoder. x264 encodes H.264 (MPEG-4 AVC). Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
On Thu, Mar 26, 2009 at 07:36:24AM +0100, Reinhard Tartler wrote: maybe --enable-debug in combination with our debian patch that replaces libavfoo/libavfoo.a with /usr/lib/libfoo.so? May I suggest dropping this monstrously ugly patch and instead replacing it by the use of the proper configure flags to disable static FFmpeg libraries? Diego signature.asc Description: Digital signature
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
On Thu, Mar 26, 2009 at 11:23:18AM +0100, Reinhard Tartler wrote: Diego Biurrun di...@biurrun.de writes: On Thu, Mar 26, 2009 at 07:36:24AM +0100, Reinhard Tartler wrote: maybe --enable-debug in combination with our debian patch that replaces libavfoo/libavfoo.a with /usr/lib/libfoo.so? May I suggest dropping this monstrously ugly patch and instead replacing it by the use of the proper configure flags to disable static FFmpeg libraries? Yes, that is what I have in mind. I wonder if that is enough to fix the build on mips or if we need to remove the --enable-debug in addition (and only on mips). Drop the patch and find out. Getting rid of it is a good thing in any case. Diego signature.asc Description: Digital signature
Bug#520113: mplayer: FTBFS: non-dynamic relocations refer to dynamic symbol free@@GLIBC_2.0
On Wed, Mar 25, 2009 at 09:32:45AM +0100, Sune Vuorela wrote: I tried building it with the ifeq(mipsel)... -fPIC -DPIC hack applied on -2 Fails the same way. build log attached. The options you guys pass to configure look suspicious: --prefix=/usr --confdir=/etc/mplayer --datadir=/usr/share/mplayer --codecsdir=/usr/lib/codecs The first makes the other three redundant. --enable-debug Why do you use this flag? It could be the cause for this build failure. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520459: mplayer: tries to overwrite file owned by manpages-zh
On Fri, Mar 20, 2009 at 08:40:54AM +0100, Fabian Greffrath wrote: manpages-zh contains an outdated mplayer manpage dating back to 2003. It it besides the only manpages.* package that ships its own mplayer manpage: http://packages.debian.org/search?searchon=contentskeywords=mplayer.1mode=filenamesuite=unstablearch=any We should prefer the upstream mplayer manpage, the one from manpages-zh must go (IMHO). I can only say that upstream agrees completely. The thought of random packages carrying outdated MPlayer man pages is scary. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#410962: mplayer crashes on every play file
On Wed, Mar 11, 2009 at 09:10:08AM +0100, Reinhard Tartler wrote: Diego Biurrun di...@biurrun.de writes: Didn't you already have an alternative libavcodec version in place somewhere? Yes, but is that of any help for G3 users? If mplayer itself is compiled using -maltivec, then mplayer would crash even before it hits any code of ffmpeg. If mplayer itself does not use any altivec instructions and restricts altivec usage to libavcodec, then I'd say the bug can be closed. I think AltiVec instructions can appear anywhere if you compile with -maltivec, so I think the bug cannot be deferred to FFmpeg. The alternatives you suggested are not very pretty, but I don't see a good alternative. I think the symlink approach is preferrable. Unless of course you created two different packages, one with AltiVec support and one without. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#410962: mplayer crashes on every play file
On Sun, Mar 08, 2009 at 06:11:24PM +0100, Reinhard Tartler wrote: Diego Biurrun di...@biurrun.de writes: Hello Reimar, indeed its a PPC G3 Ibook without altivec. And indeed this is the cause for the crash. Fixing this is going to be tricky. As a personal workaround, compile your own MPlayer without AltiVec support. I envision two approached to fix this problem: a. compile mplayer twice on powerpc and install as /usr/bin/mplayer.altivec and /usr/bin/mplayer.non-altivec. Then a shell wrapper that detects altivec e.g. in /proc/cpuinfo or something is calling the real binary b. compile mplayer twice on powerpc and install as /usr/bin/mplayer.altivec and /usr/bin/mplayer.non-altivec. The mplayer package's postinst will then symlink /usr/bin/mplayer to the right binary. Is one of the two an acceptable solution? If yes, which one is better? Didn't you already have an alternative libavcodec version in place somewhere? Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407010: lol-mplayer.mpg
On Tue, Jan 13, 2009 at 03:55:27PM +0100, A Mennucc wrote: I don't see this distinction between upstream and mantainer so rigid, it would be rather a distinction between people who know the code very well and people who know the code half well but try to contribute nonetheless. I for example fall in this second category regarding freevo, I have submitted many patches and snippets of code, most are now part of upstream. Maybe we can start talking about your MPlayer package again then. We as upstream have multiple issues we want to talk about and see rectified... On Thu, Dec 25, 2008 at 02:18:42PM +0100, Diego Biurrun wrote: The openssl fiasco was just a very visible and catastrophic example. But let's not forget that most of the time the upstream code is flawed by itself, with not help from the mantainer: http://www.ocert.org/advisories/ocert-2008-016.html Well, if people who know the code very well make these fatal mistakes, it's all the more reason for people who know the code half well but try to contribute nonetheless to be doubly careful, don't you think? Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407010: lol-mplayer.mpg
On Thu, Dec 25, 2008 at 10:32:45PM +0100, Nico Golde wrote: * Diego Biurrun di...@biurrun.de [2008-12-25 22:19]: On Wed, Dec 24, 2008 at 11:12:34PM +0100, Nico Golde wrote: * Diego Biurrun di...@biurrun.de [2008-12-24 22:50]: On Tue, Dec 23, 2008 at 09:56:15PM +0100, A Mennucc wrote: [...] Your patch is incorrect and insufficient. You should submit your patches upstream to FFmpeg instead of posting it to a distro bug tracker. It was reviewed no more than 15 minutes (on a December 24) after I sent it to the ffmpeg-devel mailing list. Please do not add not fully understood patches to your distro packages. You do read the referenced bugs before starting to throw with mud do you? I guess not otherwise you would have read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509616#5: Attached is a patch to fix this, I am not sure if that is the correct way to fix this as I have no insight on the code functionality itself but at least it prevents mplayer from crashing. So you might want to check back with upstream. And here is your upstream, confirming what you already suspected: Your patch papers over the problem without fixing the root cause. So if you knew this all along, why act offended now? Because I have better things to do than reading arrogant upstream replies who fail to read the references but instead act like people would blindly apply patches? Sorry, but I have personally reviewed looked at about a dozen FFmpeg and MPlayer packages[1] and blindly apply patches was often enough an accurate description of my findings. Debian is no exception. Before Reinhard Tartler took over as FFmpeg packager about a dozen patches were being applied to FFmpeg by Debian. Thankfully Reinhard works much more closely with upstream (and me in particular) than his predecessors. I reviewed that dozen of patches. The end result was that 50% could be discarded, two or so were applied and another two or so I implemented better within FFmpeg. The next time Reinhard updates FFmpeg only one local patch will remain (IIRC). So you will have to forgive me if I step in when I see a patch being proposed for the FFmpeg package in Debian. It would not have been the first time that incomplete workarounds got applied. We all know the troubles this caused with openssl. What a miserable comparison. I beg to differ. It is not a distributions job to patch programs. There are hardly any exceptions to this rule. The openssl fiasco was just a very visible and catastrophic example. The root problem, however, is the same: Distributions patching programs without upstream coordination and review. I see no need to discuss this with you as you seem to miss the necessary background, please consult your favorite search engine. You know http://marc.info/?l=openssl-devm=114652287210110w=2 do you? I know. And the root cause of the problem was distros applying patches without fully understanding them. I do not see this issue resolved. This is not at all specific to Debian. Sooner or later something like this was bound to happen. It's just sheer bad luck that it hit Debian. It could have been any other Linux (or BSD) distro. The only way forward is closer cooperation with upstream. However, if you are going to get offended every time someone utters the term openssl your life as packager will be difficult. It's going to be cited for years as a bad example of where things can end... merry xmas same to you, let's start on fixing the bug. Working on it. I already proposed your patch and entered the issue into our project bug tracker so that it is not forgotten. I will let Reinhard know if/when a proper solution appears that he can backport. Diego [1] Note that I do not make a difference between Linux distributions and BSD flavors. From the upstream perspective they are just another packager. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407010: lol-mplayer.mpg
On Wed, Dec 24, 2008 at 11:12:34PM +0100, Nico Golde wrote: * Diego Biurrun di...@biurrun.de [2008-12-24 22:50]: On Tue, Dec 23, 2008 at 09:56:15PM +0100, A Mennucc wrote: On Tue, Dec 23, 2008 at 09:21:44PM +0100, Nico Golde wrote: I tracked the ogm file issue down to ffmpeg, it's not an mplayer issue. I reported this as: #509616.. Your patch is incorrect and insufficient. You should submit your patches upstream to FFmpeg instead of posting it to a distro bug tracker. It was reviewed no more than 15 minutes (on a December 24) after I sent it to the ffmpeg-devel mailing list. Please do not add not fully understood patches to your distro packages. You do read the referenced bugs before starting to throw with mud do you? I guess not otherwise you would have read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509616#5: Attached is a patch to fix this, I am not sure if that is the correct way to fix this as I have no insight on the code functionality itself but at least it prevents mplayer from crashing. So you might want to check back with upstream. And here is your upstream, confirming what you already suspected: Your patch papers over the problem without fixing the root cause. So if you knew this all along, why act offended now? This is upstream appearing on your distribution channels and helping you out directly. We all know the troubles this caused with openssl. What a miserable comparison. I beg to differ. It is not a distributions job to patch programs. There are hardly any exceptions to this rule. The openssl fiasco was just a very visible and catastrophic example. The root problem, however, is the same: Distributions patching programs without upstream coordination and review. Unfortunately this mindset is entrenched in distro people's minds and changing your habits will be difficult. If the openssl fiasco leads to change in this area, it will end up having had a positive effect in the long run. merry xmas Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407010: lol-mplayer.mpg
On Tue, Dec 23, 2008 at 09:56:15PM +0100, A Mennucc wrote: On Tue, Dec 23, 2008 at 09:21:44PM +0100, Nico Golde wrote: I tracked the ogm file issue down to ffmpeg, it's not an mplayer issue. I reported this as: #509616.. Your patch is incorrect and insufficient. You should submit your patches upstream to FFmpeg instead of posting it to a distro bug tracker. It was reviewed no more than 15 minutes (on a December 24) after I sent it to the ffmpeg-devel mailing list. Please do not add not fully understood patches to your distro packages. We all know the troubles this caused with openssl. you may propose your patch into http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1212 No, because that bug report is about the MPEG demuxer, not the ogm issue. Diego -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505985: LIRC input can get `delayed' by one
On Tue, Nov 18, 2008 at 02:54:52AM +1300, Dennis Vshivkov wrote: When LIRC codes begin with modifiers, the LIRC input stream can get `delayed by one'. The attached patch fixes the bug for me. If you wish to see this applied you should submit it upstream. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506724: Pressing capital 'Q' makes mplayer crash
tags 506724 fixed-upstream thanks On Sun, Nov 23, 2008 at 08:18:49PM +0100, Jérémy Dufour wrote: When I press capital 'Q' (rather than 'q' to quit), it makes MPlayer crash with the following message: MPlayer interrupted by signal 11 in module: key_events - MPlayer crashed by bad usage of CPU/FPU/RAM. [...] This has been fixed in MPlayer commit r27840 about a month ago. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506244: mplayer: Can't keep up with 64kbit/s Vorbis on 400MHz CPU
On Wed, Nov 19, 2008 at 01:52:41PM -0500, Stefan Monnier wrote: mplayer struggles to keep up with a 64kbit/s Vorbis stream on my OpenMoko Freerunner, apparently because it uses the floating-point version of the Vorbis decoder rather than using the integer version (aka Tremor, aka libvorbisidec.so). Just instruct MPlayer to use Tremor for decoding: mplayer -afm libvorbis mplayer -ac vorbis and/or put something lik ac=vorbis, afm=libvorbis, in your configuration file. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488226: mplayer: Please don't embedded libdvdread/libdvdnav
On Wed, Sep 24, 2008 at 12:03:00PM +0200, Wolfgang Scheicher wrote: On Saturday 05 July 2008 14:25:06 Diego Biurrun wrote: libdvdnav has never been embedded in MPlayer. I assume the actual problem (at least it's the problem i did just run into), is that mplayer as it's built currently doesn't use libdvdread and therefor cannot play some broken dvds ... Of course MPlayer uses libdvdread. I have at least one dvd which i could only play after rebuilding mplayer with --disable-dvdread-internal. Seems Industry is loosing the ability to create a valid file system. So i say: please build mplayer with that option. Why would you want to disable DVD support? Because that is what that option will do... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497787: mplayer: needs libstdc++.so.5 to play RealVideo
On Thu, Sep 04, 2008 at 07:16:13PM +0200, A Mennucc wrote: AFAIK this happens only if you use external binary codecs that are linked against that old lib. Can you confirm ? Correct: silver:~ $ ldd /usr/local/lib/codecs/drvc.so linux-gate.so.1 = (0xe000) libstdc++.so.5 = /usr/lib/libstdc++.so.5 (0xb7dfb000) libc.so.6 = /lib/tls/libc.so.6 (0xb7cc9000) libm.so.6 = /lib/tls/libm.so.6 (0xb7ca4000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb7c99000) /lib/ld-linux.so.2 (0x8000) Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497787: mplayer: needs libstdc++.so.5 to play RealVideo
On Thu, Sep 04, 2008 at 09:11:01PM +0200, B. Zhang wrote: Diego Biurrun wrote: On Thu, Sep 04, 2008 at 07:16:13PM +0200, A Mennucc wrote: AFAIK this happens only if you use external binary codecs that are linked against that old lib. Can you confirm ? Yes. There is already a warning in /usr/share/mplayer/scripts/binary_codecs.sh for powerpc users to install libstdc++5, maybe you should add x86 (and other). Sounds like a good idea. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348896: libc6-dev: implicit declaration of function swab
Package: libc6-dev Version: 2.7-12 Followup-For: Bug #348896 I do not get the compilation failure of the original reporter and have no trouble using the unistd.h header with a #define __USE_XOPEN just before it. However, I also need the #ifdef, which should not be required. Is this bug going to be addressed? best regards Diego -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.23 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libc6-dev depends on: ii libc6 2.7-12 GNU C Library: Shared libraries ii linux-libc-dev2.6.25-6 Linux Kernel Headers for developme Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.3.1-2 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-15 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-6The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.3-7The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-23 The GNU C compiler ii gcc-4.2 [c-compiler] 4.2.4-3The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.1-5The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489411: mplayer 1.0~rc2-14 is slow
On Tue, Jul 08, 2008 at 12:25:31PM +0200, Michal Suchanek wrote: On 07/07/2008, A Mennucc [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 10:41:46AM +0200, Michal Suchanek wrote: On 06/07/2008, A Mennucc [EMAIL PROTECTED] wrote: also, it is compiled using --enable-debug, so it has -O2 instead of -O4 The set of flags for compiling ffmpeg is quite messy currently; in one single line of gcc in http://buildd.debian.org/fetch.cgi?pkg=ffmpeg-free;ver=0.svn20080206-8;arch=alpha;stamp=1212572490 I count 4 -g, two -O2 and two -O3 (does this make it -O2.5 ? :-) Yes, this would be more likely the problem. The ffmpeg code is used much more during playback than the mplayer code. Still the movie in question is h264 and this library should remain the same in all cases. Not more likely, this is the problem. Currently MMX and other processor-specific optimizations are disabled in Debian's FFmpeg. This makes things slow to a crawl... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489411: mplayer 1.0~rc2-14 is slow
On Tue, Jul 08, 2008 at 12:29:13PM +0200, Michal Suchanek wrote: On 07/07/2008, Diego Biurrun [EMAIL PROTECTED] wrote: On Mon, Jul 07, 2008 at 02:48:55PM +0200, A Mennucc wrote: On Mon, Jul 07, 2008 at 10:41:46AM +0200, Michal Suchanek wrote: On 06/07/2008, A Mennucc [EMAIL PROTECTED] wrote: also, it is compiled using --enable-debug, so it has -O2 instead of -O4 The reason I did that was that I was expecting some mess when I finally would have prepared a version of MPlayer linked to external FFMpeg, so a -dbg package would have helped; (and indeed a lot of mess happened) MPlayer 1.0~rc2-15 is compiled with -g -O2 instead of -O4 -ffast-math . I could reverse this flag now; but note that this flag affects the code of MPlayer itself, not the code in the FFmpeg external libraries (that are out of my reach), and AFAIK that code is much more relevant to speed. I would suggest that you build with the same flags that we use upstream. What are these? Whatever the configure script sets; -O4 and no -g IIRC. I wonder how do the dpkg-buildpackage default flags interact with the mplayer build. MPlayer's configure reacts to the CFLAGS environment variable. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489411: mplayer 1.0~rc2-14 is slow
On Mon, Jul 07, 2008 at 02:48:55PM +0200, A Mennucc wrote: On Mon, Jul 07, 2008 at 10:41:46AM +0200, Michal Suchanek wrote: On 06/07/2008, A Mennucc [EMAIL PROTECTED] wrote: also, it is compiled using --enable-debug, so it has -O2 instead of -O4 The reason I did that was that I was expecting some mess when I finally would have prepared a version of MPlayer linked to external FFMpeg, so a -dbg package would have helped; (and indeed a lot of mess happened) MPlayer 1.0~rc2-15 is compiled with -g -O2 instead of -O4 -ffast-math . I could reverse this flag now; but note that this flag affects the code of MPlayer itself, not the code in the FFmpeg external libraries (that are out of my reach), and AFAIK that code is much more relevant to speed. I would suggest that you build with the same flags that we use upstream. The set of flags for compiling ffmpeg is quite messy currently; in one single line of gcc in http://buildd.debian.org/fetch.cgi?pkg=ffmpeg-free;ver=0.svn20080206-8;arch=alpha;stamp=1212572490 I count 4 -g, two -O2 and two -O3 (does this make it -O2.5 ? :-) The FFmpeg package is in bad shape currently, it is being built without processor-specific optimizations on x86. Thus it is unusably slow. I and others have been talking with Reinhard Tartler, who currently maintains FFmpeg. A new package should appear soon. Let's see what happens then. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489411: mplayer 1.0~rc2-14 is slow
On Sat, Jul 05, 2008 at 04:07:59PM +0200, Michal Suchanek wrote: I had a problem with playback so I tried to upgrade to newer mplayer. However, the only thing that I can tell for sure after the upgrade is that there is a large preformance gap between 1.0~rc2-8+lenny1 and 1.0~rc2-14. The same H.264+AAC file would play at 60%-70% cpu with the older release and 90%-100%+ (unusable) with the newer release on the same system. This is because the Debian package now links dynamically against the FFmpeg version in Debian instead of linking statically against its own private copy. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407010: mplayer: multiple segmentation faults
On Thu, Jan 25, 2007 at 02:30:42PM +0100, Diego Biurrun wrote: Some status information about those crashes .. On Mon, Jan 15, 2007 at 05:04:55PM +0100, Sam Hocevar (Debian packages) wrote: MPlayer crashes at various places with the following files: http://sam.zoy.org/zzuf/lol-mplayer.mp3 (SIGSEGV) Crash in mp3lib. http://sam.zoy.org/zzuf/lol-mplayer.ogg (SIGSEGV) Crash in libvorbis. http://sam.zoy.org/zzuf/lol-mplayer.aac (SIGSEGV) Crash in libfaad. http://sam.zoy.org/zzuf/lol-mplayer.avi (SIGSEGV) Unreproducible with HEAD. http://sam.zoy.org/zzuf/lol-mplayer.mpg (SIGSEGV) http://sam.zoy.org/zzuf/lol-mplayer.m2v (SIGSEGV) http://sam.zoy.org/zzuf/lol-mplayer.flac (SIGSEGV) http://sam.zoy.org/zzuf/lol-mplayer.ogm (SIGSEGV) http://sam.zoy.org/zzuf/lol-mplayer.wmv (SIGSEGV) All fixed. I cannot reproduce any of the crashes anymore with the latest Debian package on PowerPC. I think this report should be closed. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407010: mplayer: multiple segmentation faults
On Sun, Jul 06, 2008 at 12:49:05PM +0200, Nico Golde wrote: * Diego Biurrun [EMAIL PROTECTED] [2008-07-06 12:40]: On Thu, Jan 25, 2007 at 02:30:42PM +0100, Diego Biurrun wrote: [...] All fixed. I cannot reproduce any of the crashes anymore with the latest Debian package on PowerPC. I think this report should be closed. Since you seem to have a copy of these files, can you put them online somewhere as they are no longer available on the original website? Umm, I got them from the original website... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407010: mplayer: multiple segmentation faults
On Sun, Jul 06, 2008 at 02:11:13PM +0200, Nico Golde wrote: Hi Diego, * Diego Biurrun [EMAIL PROTECTED] [2008-07-06 13:51]: On Sun, Jul 06, 2008 at 12:49:05PM +0200, Nico Golde wrote: * Diego Biurrun [EMAIL PROTECTED] [2008-07-06 12:40]: On Thu, Jan 25, 2007 at 02:30:42PM +0100, Diego Biurrun wrote: [...] All fixed. I cannot reproduce any of the crashes anymore with the latest Debian package on PowerPC. I think this report should be closed. Since you seem to have a copy of these files, can you put them online somewhere as they are no longer available on the original website? Umm, I got them from the original website... HEAD /zzuf/lol-mplayer.mp3 HTTP/1.1 Host: sam.zoy.org HTTP/1.1 301 Moved Permanently Date: Sun, 06 Jul 2008 12:11:09 GMT Server: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c mod_perl/1.29 DAV/1.0.3 Location: http://libcaca.zoy.org/wiki/zzuf Content-Type: text/html; charset=iso-8859-1 So if you reproduced it with this, you tried to reproduce it on an html page :) ROTFL :) Anyway, I found the files locally, lol-mplayer.ogm and lol-mplayer.aac and lol-mplayer.mpg still crash with Subversion HEAD. The Debian package currently crashes with anything ;-p I put the files online at http://www1.mplayerhq.hu/~diego/zzuf/ Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488226: mplayer: Please don't embedded libdvdread/libdvdnav
On Fri, Jun 27, 2008 at 10:03:46AM +0200, Daniel Baumann wrote: please don't use embedded libdvdread or libdvdnav but link against them. For libdvdnav, we already have the new upstream from mplayer project in Debian, so that won't give regressions; for libdvdread, it would be nice to have the original libdvdread patched up with mplayer patches (if any). libdvdnav has never been embedded in MPlayer. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489419: mplayer: crashes on playing a standalone aac file
severity important merge 489419 487830 thanks This is the same problem we are experiencing all over... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489419: mplayer: crashes on playing a standalone aac file
severity 489419 important merge 489419 487830 thanks Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481401: mplayer:[PowerPC] MPlayer crashed by an 'Illegal Instruction'
severity 481401 important merge 481401 410962 thanks On Tue, Jul 01, 2008 at 06:10:40PM +0200, Diego Biurrun wrote: severity 481401 important merge 481401 410962 thanks I always forget to CC control@, so here it is once more with feeling.. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487830: crashes on all flv files
severity important thanks I can confirm the crashes on a PowerPC machine. I highly suspect the move to link against the FFmpeg libraries that are part of FFmpeg. This was highly dubious in the first place. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487830: crashes on all flv files
On Fri, Jul 04, 2008 at 04:00:54PM +0200, Diego Biurrun wrote: severity important thanks I can confirm the crashes on a PowerPC machine. I highly suspect the move to link against the FFmpeg libraries that are part of FFmpeg. This was highly dubious in the first place. Forgot to say: This only happens with the Debian package version, all my local builds work fine. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481401: mplayer:[PowerPC] MPlayer crashed by an 'Illegal Instruction'
severity 481401 important merge 481401 410962 thanks On Thu, May 15, 2008 at 09:54:33PM +0200, mancausoft wrote: When start a video it crash. Message: MPlayer interrupted by signal 4 in module: decode_video - MPlayer crashed by an 'Illegal Instruction'. It may be a bug in our new runtime CPU-detection code... Please read DOCS/HTML/en/bugreports.html. - MPlayer crashed by bad usage of CPU/FPU/RAM. Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and won't help unless you provide this information when reporting a possible bug. -- HW Information: $ cat /proc/cpuinfo cpu : 740/750 machine : Power Macintosh motherboard : AAPL,PowerMac G3 MacRISC This is a duplicate bug report, your machine lacks AltiVec instructions. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Thu, Jun 19, 2008 at 09:50:24AM +0200, Fabian Greffrath wrote: (1) Ffmpeg should finally decide about a stable API, or at least one that is stable for more than two weeks. It is commonly believed myth that FFmpeg does not have a stable API, but a myth nonetheless. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
On Thu, Jun 19, 2008 at 01:35:49PM +0200, Fabian Greffrath wrote: Reinhard Tartler schrieb: FFMpeg and Mplayer developers have a rather large overlap. BTW, how large is the overlap of ffmpeg developers with vlc or xine? Practically zero. Diego signature.asc Description: Digital signature
Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny
Note that I am upstream for both MPlayer and FFmpeg. On Thu, Jun 19, 2008 at 01:35:49PM +0200, Fabian Greffrath wrote: Reinhard Tartler schrieb: I know that it is tricky, but I still think that for the problem we are facing, this is an acceptable solution. YMMV of course. Fine, but how about all the other packages that depend on ffmpeg, like gstreamer, vlc and xine. They do also ship embedded copies of ffmpeg source code. I fear these packages could suffer from the decision to gear our ffmpeg library packages to mplayer releases. All packages already suffer from being tied to a specific FFmpeg release. Building against another FFmpeg version is a rather big change from the upstream releases. From the last remarks I have heared from upstream is that they want to wait this year's GOC and integrate the results from that. After that a release could indeed happen, depending on the available manpower, of course. Short: there is not enough interest in maintaining stable releases. This means additional efford for: - tracking bugs - fixing bugs - write release notes etc. Come on, thousands of even smaller software projects face these problems regularly and nevertheless get releases going. The problem is that many people request releases, but nobody is willing to step up to help with releases. Obviously none of the current FFmpeg developers has a problem with the way things are handled right now and there are always more interesting things than fixing other people's issues... FFMpeg and Mplayer developers have a rather large overlap. I cannot imagine that you can convince them to restrict themselves to the public ffmpeg api, but good luck with that! Then they shouldn't distinguish between these two projects While there is a large overlap, the projects are most definitely not the same. Also, I think it is always a bad idea to tell other projects what they should or should not do. If I voiced my opinion about what the Debian project should do with the same amount of conviction, I'm sure you guys would take me out back and beat me up ;-) Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483499: mplayer icon on gnome menu does not appear on sid
On Thu, May 29, 2008 at 12:05:51AM -0300, Fernando Mitio Yamada wrote: Icon on the Applications/Sound Video menu on gnome does not appear. Found the problem at: /usr/share/applications/mplayer.desktop The line containing: Icon=mplayer is incorrect. Changing to: Icon=mplayer.xpm Solves the problem This was changed to be the way it is now after the discussion in bug #472833. The way it is now complies with the specification, so the bug must be somewhere in GNOME. Diego -- 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:38:47PM +0200, Lucas Nussbaum wrote: Don't blame gcc 4.3. It built that code fine last week. Blame dpkg (see my other mail) If gcc fails to allocate registers, it is a bug in gcc. Report it to them. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475934: FATAL: Could not initialize video filters (-vf) or video output (-vo)
On Mon, Apr 14, 2008 at 11:04:10AM +0200, A Mennucc wrote: On Mon, Apr 14, 2008 at 02:08:46AM +0100, Sam Morris wrote: Package: mplayer Version: 1.0~rc2-10 Severity: grave Justification: renders package unusable Since upgrading to version 1.0~rc2-10, mplayer has not been able to play back any video files: in 1.0~rc2-10 , to try to bypass a bug in gmplayer, I set the default to 'vo=xvmc,xv,x11' in /etc/mplayer/mplayer.conf Setting a default vo is a bad idea. The problem is the GUI, so what you need to provide is a default vo for the GUI. Diego -- 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 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. Diego
Bug#472833: Please rename mplayer.xpm to mplayer in desktop file
On Thu, Apr 03, 2008 at 10:25:33PM +0200, giggzounet wrote: Diego Biurrun a écrit : On Wed, Mar 26, 2008 at 07:19:25PM +0100, giggz wrote: Just a little thing : In the mplayer.desktop the icon name is mplayer.xpm. Is it possible to rename it just mplayer (as it is common) ? What makes you think that this is common? Many other desktop files on my unstable system do this. Is there some sort of specification that demands this? 22:24 [EMAIL PROTECTED] /usr/share/applications % desktop-file-validate mplayer.desktop mplayer.desktop: warning: key Encoding in group Desktop Entry is deprecated mplayer.desktop: warning: value mplayer.xpm for key Icon in group Desktop Entry is an icon name with an extension, but there should be no extension as described in the Icon Theme Specification if the value is not an absolute path OK, change applied to upstream desktop file. Andrea can apply the change as well or wait for the next release. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472833: Please rename mplayer.xpm to mplayer in desktop file
.. while we're at it .. On Mon, Apr 07, 2008 at 09:43:45AM +0200, Diego Biurrun wrote: On Thu, Apr 03, 2008 at 10:25:33PM +0200, giggzounet wrote: 22:24 [EMAIL PROTECTED] /usr/share/applications % desktop-file-validate mplayer.desktop mplayer.desktop: warning: key Encoding in group Desktop Entry is deprecated Do you know what one is supposed to use instead of Encoding? Are the files simply mandated to be UTF-8 and has the encoding entry thus become obsolete? Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472833: Please rename mplayer.xpm to mplayer in desktop file
On Wed, Mar 26, 2008 at 07:19:25PM +0100, giggz wrote: Just a little thing : In the mplayer.desktop the icon name is mplayer.xpm. Is it possible to rename it just mplayer (as it is common) ? What makes you think that this is common? Many other desktop files on my unstable system do this. Is there some sort of specification that demands this? Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396954: Can mencoder be provided for at least some output formats?
On Mon, Mar 03, 2008 at 10:18:59PM +0100, Francesco Poli wrote: On Mon, 3 Mar 2008 10:49:53 +0100 Diego Biurrun wrote: On Sat, Mar 01, 2008 at 01:15:00PM +0100, Francesco Poli wrote: [...] AFAICT, the usual Debian practice to deal with software patents is not worrying about them unless they are actively enforced. This is not a description of Debian's practice when dealing with software patents. It's what is usually said on debian-legal about the topic... Obviously, there's no warranty that each and every package in Debian follows consistently this practice. But it should, AFAIK. There is no such thing as consistency and I have not seen this practice in writing anywhere. I'd be glad to see pointers to such a place. For example patents on browsers are actively enforced, but Debian turns a blind eye. In the sense that many people do *know* about those actively enforced patents and, still, pretend there is no problem? Yes. Think about the company Eolas, which managed to extort millions from Microsoft with a patent on browser plugins. For some mysterious reason encoding software is treated different from everything else. Mmmh, I was under the impression that audio/video MPEG encoding was one of the main fields encumbered by actively enforced software patents. You instead claim that there are other fields with similar issues, while the Debian Project seems to only care about MPEG patents... Yes. Note that distributors are never bothered about MPEG patents.. Have you ever discussed this on debian-devel/debian-legal? Do you think it would be worth it? Do you think anybody would change opinions? Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396954: Can mencoder be provided for at least some output formats?
On Sat, Mar 01, 2008 at 01:15:00PM +0100, Francesco Poli wrote: On Sat, 1 Mar 2008 12:29:44 +0100 Diego Biurrun wrote: On Sat, Mar 01, 2008 at 12:21:57AM +0100, Francesco Poli wrote: [...] Do you happen to know about any other third parties holding patents on Theora and *actively enforcing* them by compelling people to pay royalties or by forbidding people to exercise their freedoms on Theora? No, but I did not look at the 10s of software patents that exist around the world. Nobody with deep pockets uses Theora, so there is no incentive for patent holders to go after them. You should not actively search for infringed software patents. I have better ways to spend my time. AFAICT, the usual Debian practice to deal with software patents is not worrying about them unless they are actively enforced. This is not a description of Debian's practice when dealing with software patents. For example patents on browsers are actively enforced, but Debian turns a blind eye. For some mysterious reason encoding software is treated different from everything else. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396954: Can mencoder be provided for at least some output formats?
On Sat, Mar 01, 2008 at 12:21:57AM +0100, Francesco Poli wrote: On Sat, 1 Mar 2008 00:05:18 +0100 Diego Biurrun wrote: [...] Read the paragraph closely. They only say that *they* won't come knocking at your door. No word about third parties. I thought third parties were On2. Do you happen to know about any other third parties holding patents on Theora and *actively enforcing* them by compelling people to pay royalties or by forbidding people to exercise their freedoms on Theora? No, but I did not look at the 10s of software patents that exist around the world. Nobody with deep pockets uses Theora, so there is no incentive for patent holders to go after them. P.S.: I really hope projects like http://endsoftpatents.org/ manage to get a patent reform soon... :-( We all do... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396954: Can mencoder be provided for at least some output formats?
On Fri, Feb 29, 2008 at 11:00:47PM +0100, Francesco Poli wrote: On Wed, 27 Feb 2008 22:22:35 +0100 Diego Biurrun wrote: [...] Who told you that Theora was not patent-encumbered? Have you ever seen anything to substantiate that claim? Because I haven't ... Well, Xiph claims it is unencumbered by patents, in the sense that there are no patent-royalties that must be paid in order to use/sell/implement the compression format. Quoting from http://www.theora.org/benefits/ : | Theora comes without licensing fees. Neither commercial nor private use | will make you owe money to us. The Theora specification is in the | public domain, its reference implementation is open source and subject | to a license which permits inclusion in proprietary commercial | products. On2, which owns patents that apply to the technical | foundations of Theora, granted an unrevocable free license regarding | those patents. I thought this was true. Do you have any reason to believe that Xiph is lying? Read the paragraph closely. They only say that *they* won't come knocking at your door. No word about third parties. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396954: Can mencoder be provided for at least some output formats?
On Wed, Feb 27, 2008 at 02:22:02PM +0100, A Mennucc wrote: I have had this same idea for long time, and I would love to do that. Please don't, a crippled MEncoder will not help anybody. Note that MPEG-4 encoding is already available through FFmpeg, but hey, it was hard enough to get MPlayer into Debian. On Wed, Feb 20, 2008 at 11:10:13PM +0100, Francesco Poli wrote: I think mencoder could be useful to recode a video from a mplayer-readable format to Ogg/Theora (or to other patent-unencumbered formats). recently the SNOW video codec reached a good status, it may be another option http://en.wikipedia.org/wiki/Snow_(codec) though I did not try it personally, and moreover I cannot tell if it is patent-unencumbered Who told you that Theora was not patent-encumbered? Have you ever seen anything to substantiate that claim? Because I haven't ... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461795: mplayer: segfaults when playing second DV file
On Sun, Jan 20, 2008 at 03:50:25PM -0500, Frédéric Brière wrote: When playing more than one DV file in succession, mplayer will typically segfault after switching to the second file. I'm attaching a 2-second blank DV file (nothing.dv) that exhibits this behavior. $ mplayer -vo xv nothing.dv nothing.dv [...] MPlayer interrupted by signal 11 in module: decode_video Just one line of output is completely useless, the uncut output of mplayer -v is necessary. I cannot reproduce the crash with a current Subversion build of MPlayer. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444841: iceweasel: about dialog displays wrong version info
close 444841 thanks On Sun, Nov 11, 2007 at 01:55:42PM -0500, Eric Dorland wrote: * Diego Biurrun ([EMAIL PROTECTED]) wrote: Package: iceweasel Version: 2.0.0.6-0etch1 Severity: minor If I go to about: or Help -- About Mozilla Firefox[1] the version number is given as 2.0.0.3, but the package claims to be 2.0.0.6. What gives? While this is obviously a minor issue the problem is that newer minor releases are usually security updates AFAIU. So this might create the impression that iceweasel is vulnerable even though it is not. Hmmm, are you sure you're actually running Iceweasel? Ahem, no I was in fact not running Iceweasel. I'm sitting in a dark corner with a brown paperbag over my head while I type this. Sorry for the noise... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449041: mplayer: wrong driver setting: vo_driver= xmga by NVidia and ATI Cards
On Fri, Nov 02, 2007 at 04:38:14PM +0100, Siegfrid Brandstätter wrote: Maintainer: Christian Marillat I think you are reporting the bug in the wrong place. Christian's packages are not the same as the official Debian ones. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448791: mplayer: FTBFS on GNU/kFreeBSD
On Thu, Nov 01, 2007 at 09:05:53PM +0100, Petr Salinger wrote:
--- mplayer-1.0~rc2.orig/configure
+++ mplayer-1.0~rc2/configure
@@ -6728,6 +6728,7 @@
dev/ic/bt8xx.h ; do
cat $TMPC EOF
#include sys/types.h
+#include sys/ioctl.h
#include $file
int main(void) {
ioctl(0, TVTUNER_GETFREQ, 0);
Can you please give the compiler output/error message you get without
that? Probably best just copy the whole corresponding section from
configure.log.
Something like error: expected identifier or '(' before '/' token.
It is due to
#define TVTUNER_GETFREQ_IOR('x', 36, unsigned int) /* get
frequency */
but _IOR is not properly defined. This is fixed by including
sys/ioctl.h.
Applied.
Diego
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448105: mplayer: Illegal Instruction in init_audio_codec
On Fri, Oct 26, 2007 at 10:55:01AM +0200, Mario Frasca wrote: On 2007-1026 10:32:55, Reimar Döffinger wrote: AltiVec runtime detection never worked reliably (compiler dependant) and the way it was detected in libavcodec was an unacceptable hack. Since the PowerPC architecture does not offer a sane way to distinguish between with and without Altivec we now treat them as different architectures, meaning you need a different build for each. let me understand better... when you say : * never worked, it was, we now treat: does it mean in rc2 as compared to rc1? * you need a different build: in the sense that I am using a mplayer which was not compiled for my system? in this case, how do I specify that I have a PowerPC without AltiVec? must I compile mplayer myself or can I still use a debian distributed binary? You need a PowerPC binary without AltiVec support. Debian does not currently distribute such a thing. Diego -- 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. Diego -- 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
On Mon, Oct 08, 2007 at 09:20:26AM +0200, A Mennucc wrote: please send us the output of 'mplayer -v -v -v file...' (with both kernels if possible) I don't think megabytes of log files are really helpful. I never found more than a single -v useful. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444841: iceweasel: about dialog displays wrong version info
Package: iceweasel Version: 2.0.0.6-0etch1 Severity: minor If I go to about: or Help -- About Mozilla Firefox[1] the version number is given as 2.0.0.3, but the package claims to be 2.0.0.6. What gives? While this is obviously a minor issue the problem is that newer minor releases are usually security updates AFAIU. So this might create the impression that iceweasel is vulnerable even though it is not. best regards Diego Biurrun [1] Why doesn't it say Iceweasel? -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-5-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages iceweasel depends on: ii debianutils2.17 Miscellaneous utilities specific t ii fontconfig 2.4.2-1.2 generic font configuration library ii libatk1.0-01.12.4-3 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-5+etch1 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-21GCC support library ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgtk2.0-02.8.20-7 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-18 MySpell spellchecking library ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxp6 1:1.0.0.xsf1-1X Printing Extension (Xprint) clie ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii psmisc 22.3-1Utilities that use the proc filesy ii zlib1g 1:1.2.3-13compression library - runtime iceweasel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322760: UTF-8 input support available in Fedora groff
Package: groff Version: 1.18.1.1-12 Followup-For: Bug #322760 Has any progress been made on UTF-8 input support for Debian's groff? The last comment is two years old and the discussion about the Japanese patch does not seem to be progressing. Note that the groff package in Fedora does appear to handle UTF-8 input without problems. It has a couple of patches applied that you may wish to check out: http://cvs.fedora.redhat.com/viewcvs/rpms/groff/FC-6/?root=core best regards Diego -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.22 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages groff depends on: ii groff-base 1.18.1.1-12 GNU troff text-formatting system ( ii libc6 2.6-2GNU C Library: Shared libraries ii libgcc1 1:4.2-20070707-1 GCC support library ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.2-20070707-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxaw7 1:1.0.3-3X11 Athena Widget library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxmu6 1:1.0.3-1X11 miscellaneous utility library ii libxpm4 1:3.5.6-3X11 pixmap library ii libxt6 1:1.0.5-3X11 toolkit intrinsics library Versions of packages groff recommends: ii gs 8.56.dfsg.1-1.1 Transitional package ii gs-gpl [gs] 8.56.dfsg.1-1.1 The GPL Ghostscript PostScript int ii imagemagick 7:6.2.4.5.dfsg1-1+b1 Image manipulation programs ii libpaper1 1.1.21 Library for handling paper charact ii netpbm 2:10.0-11Graphics conversion tools ii psutils 1.17-24 A collection of PostScript documen -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#196762: groff: UTF-8 input support available in Fedora
Package: groff Version: 1.18.1.1-12 Followup-For: Bug #196762 I'd like to note here that the groff version in Fedora appears to handle Chinese man pages in UTF-8 encoding just fine. Maybe some of the patches can be adopted to improve the Debian version: http://cvs.fedora.redhat.com/viewcvs/rpms/groff/FC-6/?root=core best regards Diego -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.22 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages groff depends on: ii groff-base 1.18.1.1-12 GNU troff text-formatting system ( ii libc6 2.6-2GNU C Library: Shared libraries ii libgcc1 1:4.2-20070707-1 GCC support library ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.2-20070707-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxaw7 1:1.0.3-3X11 Athena Widget library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxmu6 1:1.0.3-1X11 miscellaneous utility library ii libxpm4 1:3.5.6-3X11 pixmap library ii libxt6 1:1.0.5-3X11 toolkit intrinsics library Versions of packages groff recommends: ii gs 8.56.dfsg.1-1.1 Transitional package ii gs-gpl [gs] 8.56.dfsg.1-1.1 The GPL Ghostscript PostScript int ii imagemagick 7:6.2.4.5.dfsg1-1+b1 Image manipulation programs ii libpaper1 1.1.21 Library for handling paper charact ii netpbm 2:10.0-11Graphics conversion tools ii psutils 1.17-24 A collection of PostScript documen -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430211: no dvdnav:// support
On Sat, Jun 23, 2007 at 01:47:51PM +0200, Louis-David Mitterrand wrote: mplayer dvdnav:// or mplayer dvdnav://1 gives the following errors: Playing dvdnav://. [file] No filename Failed to open dvdnav://. or: Playing dvdnav://1. File not found: '1' Failed to open dvdnav://1. However mplayer dvd://1 works fine. This is because MPlayer does not support DVD menus. What is the thing you consider a bug here? Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430211: no dvdnav:// support
On Sat, Jun 23, 2007 at 06:22:33PM +0200, Louis-David Mitterrand wrote: On Sat, Jun 23, 2007 at 05:27:01PM +0200, Diego Biurrun wrote: On Sat, Jun 23, 2007 at 01:47:51PM +0200, Louis-David Mitterrand wrote: mplayer dvdnav:// or mplayer dvdnav://1 gives the following errors: Playing dvdnav://. [file] No filename Failed to open dvdnav://. or: Playing dvdnav://1. File not found: '1' Failed to open dvdnav://1. However mplayer dvd://1 works fine. This is because MPlayer does not support DVD menus. What is the thing you consider a bug here? I just rebuilt your source and now dvdnav support is present. Did you install libdvdnav-dev? I repeat: What are you considering a bug? Why are you reporting something that is happening with your recompiled MPlayer here in the BTS? Note that MPlayer *really* does not support DVD menus, much less the version in Etch. Do not be fooled by the fact that things happen when you have libdvdnav-dev lying around during compilation, DVD menu support is not one of those things ... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430211: no dvdnav:// support
On Sat, Jun 23, 2007 at 10:10:01PM +0200, Louis-David Mitterrand wrote: On Sat, Jun 23, 2007 at 07:35:01PM +0200, Diego Biurrun wrote: On Sat, Jun 23, 2007 at 06:22:33PM +0200, Louis-David Mitterrand wrote: On Sat, Jun 23, 2007 at 05:27:01PM +0200, Diego Biurrun wrote: On Sat, Jun 23, 2007 at 01:47:51PM +0200, Louis-David Mitterrand wrote: mplayer dvdnav:// or mplayer dvdnav://1 gives the following errors: Playing dvdnav://. [file] No filename Failed to open dvdnav://. or: Playing dvdnav://1. File not found: '1' Failed to open dvdnav://1. However mplayer dvd://1 works fine. This is because MPlayer does not support DVD menus. What is the thing you consider a bug here? I just rebuilt your source and now dvdnav support is present. Did you install libdvdnav-dev? I repeat: What are you considering a bug? Call it a missing feature if you will. mplayer *does* support dvd menus (it's even *hinted* at in the manpage, read it) if you have libdvdnav installed. I wrote the man page and I happen to be a long-time MPlayer developer. I know what I'm talking about here. MPlayer has never in the past or present supported DVD menus. But for that to happen the very wise package maintainer must *first* (you seem to like these asterisks) not forget to *install* libdvdnav-dev. Otherwise what happens, pretty please pray tell? MPlayer uses libdvdread to access DVDs, which is the supported and tested way to do this. Using libdvdnav for this is experimental at best. Then us poor Sony dvd users can't watch our movies because that company implements a copy protection scheme that *only* dvdnav:// can workaround. So now it would be much appreciated if you added libdvdnav-dev to the build deps. Install libdvdnav-dev, MPlayer's configure will pick it up automatically. This is not, however, suitable for the general-purpose package, at least not yet. If you are feeling adventurous you can try Subversion and fiddle with MPlayer's fork of libdvdnav. YMMV. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428857: fai: multiple English corrections
Package: fai Severity: minor Tags: patch Here is a patch for some minor English mistakes I noticed throughout FAI. Diego -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Index: conf/sources.list === --- conf/sources.list (revision 4347) +++ conf/sources.list (working copy) @@ -1,5 +1,5 @@ # These lines should work for many sites -# A more comprehensive example can be found in /usr/share/doc/fai/examples/etc +# A more comprehensive example is at /usr/share/doc/fai-doc/examples/etc deb http://ftp.debian.org/debian etch main contrib non-free #deb http://ftp.debian.org/debian etch-proposed-updates main contrib non-free Index: man/fai-chboot.8 === --- man/fai-chboot.8(revision 4347) +++ man/fai-chboot.8(working copy) @@ -63,7 +63,7 @@ verbose,sshd,createvt .TP .B \-h -Show simle help and version. +Show simple help and version. .TP .B \-i Set parameters for booting the FAI install kernel. Same as -k ip=dhcp vmlinuz-install /dev/nfs. This does not set FAI_ACTION. @@ -71,7 +71,7 @@ .B \-I Same as -i but also sets FAI_ACTION=install. So a fully automatic installation will be performed. ATTENTION! This will erase most of the -data on the install clients local disks. +data on the local disks of the install clients. .TP .BI \-k parameters Set kernel append parameters. Index: man/install_packages.8 === --- man/install_packages.8 (revision 4347) +++ man/install_packages.8 (working copy) @@ -45,7 +45,7 @@ remove, or purge packages or tasks. install_packages is called from the custom fai_rcS script and should not be -called directly. It's function is to parse the package_config files based on +called directly. Its function is to parse the package_config files based on the class definitions of the client. For example, if the client belonged to the SMTPSERVER class, install_packages would parse ../package_config/SMTPSERVER for instructions on what packages to install, hold, remove, or purge. Index: examples/simple/class/FAIBASE.var === --- examples/simple/class/FAIBASE.var (revision 4347) +++ examples/simple/class/FAIBASE.var (working copy) @@ -1,6 +1,6 @@ # default values for installation. You can override them in your *.var files -# allow installation of pacakges from unsigned repositories +# allow installation of packages from unsigned repositories FAI_ALLOW_UNSIGNED=1 CONSOLEFONT= @@ -14,7 +14,7 @@ # pw is fai ROOTPW='$1$kBnWcO.E$djxB128U7dMkrltJHPf6d1' -# moduleslist contains modules that will be loaded by the new system, +# MODULESLIST contains modules that will be loaded by the new system, # not during installation these modules will be written to /etc/modules # If you need a module during installation, add it to $kernelmodules # in 20-hwdetect.source. But discover should do most of this job Index: examples/simple/class/10-base-classes === --- examples/simple/class/10-base-classes (revision 4347) +++ examples/simple/class/10-base-classes (working copy) @@ -1,6 +1,6 @@ #! /bin/bash -# echo architecture and OS name in upper case. Do NOT remove these two lines +# Echo architecture and OS name in uppercase. Do NOT remove these two lines. uname -s | tr '[:lower:]' '[:upper:]' [ -x `which dpkg` ] dpkg --print-installation-architecture | tr a-z A-Z Index: examples/simple/class/20-hwdetect.source === --- examples/simple/class/20-hwdetect.source(revision 4347) +++ examples/simple/class/20-hwdetect.source(working copy) @@ -2,7 +2,7 @@ # (c) Thomas Lange, 2002-2005, [EMAIL PROTECTED] -# NOTE: Files named *.source will be evaluated, but their output ignored and instead +# NOTE: Files named *.source will be evaluated, but their output ignored. Instead # the contents of $newclasses will be added to the list of defined classes. echo 0 /proc/sys/kernel/printk @@ -14,7 +14,7 @@ for i in $mod; do modprobe $i 1/dev/null 21 done -# Booting from CD does not enable dma always +# Booting from CD does not always enable DMA. for d in $( echo /proc/ide/hd[a-z] 2/dev/null); do [ -d $d ] echo using_dma:1 $d/settings done @@ -36,7 +36,7 @@ # let discover do most of the job [ -x /sbin/discover-modprobe ] /sbin/discover-modprobe -# now we can mount the usb file system +# now we can mount the USB filesystem mount -t usbfs usbfs /proc/bus/usb modprobe -a sd_mod sr_mod @@ -44,7 +44,7 @@ echo 6 /proc/sys/kernel/printk # try to detect
Bug#428858: fai: wrong path mentioned in documentation
Package: fai Severity: normal Tags: patch Here is a patch for a wrong pathname mentioned in the documentation. Diego -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Index: doc/fai-guide.sgml === --- doc/fai-guide.sgml (revision 4347) +++ doc/fai-guide.sgml (working copy) @@ -1374,9 +1374,9 @@ p The installation script uses many subroutines, which are defined in -file/usr/share/fai/subroutines/file, and an operating system specific -file footnotefile/usr/share/fai/subroutines-linux/file for Linux, -file/usr/share/fai/subroutines-sunos/file for Solaris./footnote. +file/usr/lib/fai/subroutines/file, and an operating system specific +file footnotefile/usr/lib/fai/subroutines-linux/file for Linux, +file/usr/lib/fai/subroutines-sunos/file for Solaris./footnote. All important tasks of the installation are called via the subroutine tttask/tt appended by the name of the task as an option (e.g. tttask
Bug#428859: fai: use /media for floppy mountpoint
Package: fai
Severity: normal
Tags: patch
Here is a patch for fixing the mountpoint created for floppy disks in
the simple examples. It should be /media/floppy, not /floppy.
Diego
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.21
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Index: examples/simple/scripts/FAIBASE/20-removable_media
===
--- examples/simple/scripts/FAIBASE/20-removable_media (revision 4347)
+++ examples/simple/scripts/FAIBASE/20-removable_media (working copy)
@@ -3,7 +3,7 @@
# (c) Thomas Lange, 2006, [EMAIL PROTECTED]
# create entries for removable media in fstab and directories in /media
-ainsl $target/etc/fstab /dev/fd0 /floppy auto users,noauto 0 0
+ainsl $target/etc/fstab /dev/fd0 /media/floppy auto users,noauto 0 0
cdromlist() {
[ -f /proc/sys/dev/cdrom/info ] || return
Bug#428860: fai: wrong path used for mounting local mirror
Package: fai
Severity: normal
Tags: patch
When mounting a local mirror FAI adds an extra slash to the path, which
made the mount fail for me. Here is a patch that fixes the issue.
Diego
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.21
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Index: lib/subroutines-linux
===
--- lib/subroutines-linux (revision 4347)
+++ lib/subroutines-linux (working copy)
@@ -151,9 +151,9 @@
# mount debian mirror directory
[ $FAI_DEBMIRROR ] || return # nothing to do
-mkdir -p $FAI_ROOT/$MNTPOINT
-if mount $romountopt $FAI_DEBMIRROR $FAI_ROOT/$MNTPOINT; then
- [ $debug ] echo Mirror mounted from $FAI_DEBMIRROR to
$FAI_ROOT/$MNTPOINT
+mkdir -p ${FAI_ROOT}${MNTPOINT}
+if mount $romountopt $FAI_DEBMIRROR ${FAI_ROOT}${MNTPOINT}; then
+ [ $debug ] echo Mirror mounted from $FAI_DEBMIRROR to
${FAI_ROOT}${MNTPOINT}
else
sendmon TASKERROR mirror $?
die Can't mount $FAI_DEBMIRROR
Bug#422982: example
On Wed, May 09, 2007 at 02:28:53PM +0530, Joshua N Pritikin wrote: http://samples.mplayerhq.hu/Matroska/theora.mkv Playing theora.mkv. [mkv] Unknown/unsupported CodecID (V_THEORA) or missing/bad CodecPrivate data (track 1). [mkv] Track ID 1: video (V_THEORA), -vid 0 [mkv] No video track found/wanted. Matroska file format detected. No stream found. A fix just hit HEAD. Andrea, you can close this bug report as soon as you package RC2. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422982: mplayer: theora is OK except when wrapped in mkv
On Wed, May 09, 2007 at 02:17:45PM +0530, [EMAIL PROTECTED] wrote: theora video (from ffmpeg2theora) play fine. However, if you try to wrap theora video with matroska (mkvtoolnix) then it isn't recognized. The same mkv file plays fine using totem-gstreamer 2.16. Useless bug report. We need (part of) a sample file to confirm this and the output of mplayer -v when playing the file. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422025: manual page for genisoimage references nonexisting genisoimagerc manual page
Package: genisoimage Version: 9:1.1.2-1 Severity: normal Hello, genisoimage(1) mentions genisoimagerc(5), but a manual page for genisoimagerc is nowhere to be found. regards Diego -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages genisoimage depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libmagic1 4.17-5etch1 File type determination library us ii zlib1g 1:1.2.3-13 compression library - runtime genisoimage recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421363: mplayer debconf question about RTC is confusing
On Sat, Apr 28, 2007 at 11:03:18AM +0100, [EMAIL PROTECTED] wrote: One of the debconf questions mplayer asks on install is: On older kernels MPlayer can use the RTC (Real Time Clock) to provide better timing in reproduction, with less CPU cost; to this end, though, the device /dev/rtc must be accessible to group audio, and the default max-user-freq must be raised to 1024. Any needed change must be done by root. If you wish, MPlayer will automatically do this at boot, so that any user can enjoy this feature. Note that there may be security issues with this (although none are known now). This is confusing; specifically, the reference to 'older kernels' is too vague. Does it mean that if you have a newer kernel: * making the change is a bad idea * making the change is harmless but pointless, and mplayer will have as good a performance as it would have done on older kernels with RTC access * making the change is harmless but pointless, and mplayer will have the same poorer no-RTC-access performance Finally and most obviously, it should say what it means by 'older' -- 2.4? 2.2? 2.6.5 ? Without this information it's impossible to answer the question sensibly. Looking at upstream's website the answer would appear to be 'with newer kernels making the change is somewhere between pointless and a bad idea' -- but I couldn't find any indication of which kernel version counts as 'new' or indeed why the change. This kind of supports what I have been saying all along: This debconf question is not a good idea in the first place. RTC timing is obsolete. Whoever needs it should enable it manually. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
