Bug#672352: marked as done (gmerlin doesn't start at all)
Your message dated Thu, 04 Sep 2014 09:34:54 +0200 with message-id 5408161e.2050...@debian.org and subject line Re: gmerlin: segfault on start (Debian: #616080) has caused the Debian Bug report #616080, regarding gmerlin doesn't start at all to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 616080: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616080 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: gmerlin Version: 0.4.3-2+b1 Severity: important modelearth:~# gmerlin ++ WARN: ioctl CDROMCLOSETRAY failed: Input/output error [cdaudio] Error: cdio_close_tray failed: driver I/O error ++ WARN: ioctl CDROMCLOSETRAY failed: Input/output error [cdaudio] Error: cdio_close_tray failed: driver I/O error [GL] Warning: GLX version too old: requested = 1.3 but got 1.2 Segmentation fault (core dumped) modelearth:~# -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-vserver-686 (SMP w/1 CPU core) 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 gmerlin depends on: ii gmerlin-data 0.4.3-2 a multiformat media player ii libasound2 1.0.23-2.1shared library for ALSA applicatio ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libcddb2 1.3.2-2 library to access CDDB data - runt ii libcdio-cdda0 0.81-4library to read and control digita ii libcdio-paranoia0 0.81-4library to read digital audio CDs ii libcdio10 0.81-4library to read and control CD-ROM ii libesd00.2.41-8 Enlightened Sound Daemon - Shared ii libgavl1 1.1.2-3 low level audio and video library ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgmerlin00.4.3-2+b1core library for gmerlin - runtime ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libjack-jackd2-0 [ 1.9.6~dfsg.1-2JACK Audio Connection Kit (librari ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libmusicbrainz4c2a 2.1.5-4 Second generation incarnation of t ii libpng12-0 1.2.44-1+squeeze4 PNG library - runtime ii libpulse0 0.9.21-3+squeeze1 PulseAudio client libraries ii libquicktime1 3:1.2.2-0.3squeeze1 library for reading and writing Qu ii libtiff4 3.9.4-5+squeeze4 Tag Image File Format (TIFF) libra ii libv4l-0 0.8.0-1 Collection of video4linux support ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxinerama1 2:1.1-3 X11 Xinerama extension library ii libxml22.7.8.dfsg-2+squeeze3 GNOME XML library ii libxv1 2:1.0.5-1 X11 Video extension library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gmerlin recommends: pn libgmerlin-avdec0 none (no description available) gmerlin suggests no packages. -- no debconf information ---End Message--- ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 since the problem relates to a version found only in oldstable, is irreproducible (at least with current versions) and no additional info has been received in the last 3 years, i'm closing this bug as outdated. thanks. fgasdmr IOhannes On 2014-07-19 16:52, IOhannes m zmölnig (Debian/GNU) wrote: hi, does the problem still persist with the latest gmerlin (1.2.0)? do you think we can close this bug-report? if the problem is still there, could you please provide a backtrace¹? fgmsadr IOhannes ¹ http://wiki.debian.org/HowToGetABacktrace -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUCBYbAAoJELZQGcR/ejb4IpUQAILtPd5NyH8RkgAJ4BIELhud qW1jhvjxBEhecQRRHh/M0sW5wpZJTcRfFDNU4uhmsF91h8T4D5ID5bnRQC+kxJ3g JvKJbjjaB6RtRhaIn5gsUyv39LtQ1wSqJMee8IPbKjKJ7XrnezUNitbETCIbphZU axRAZ5KPl9ucUFNF+09MGleMP0vkJ+WsycyyKN21p0luYlKa2ptUPBPjvpiH8QKW 9+1s3ejoxSJNysznE5vHmTfd56A4WMlAJ84sxazdR5hO8bKbKPK1zEZhairqSrmk Hih4L2kQ0r0z1FmVWFtGOITJKXe9XssbZesJHhkhZh+m5Md0KZ7fBqKDcDG4vg3h CUr55/7VYck8dDCG7K/YpWBa1ITkg6Ldh7+qLPkIg8pf19Ybyh5hy13GzilxFnm3
Re: patch for x32 for libpostproc
Hi Thorsten, 2014-09-03 10:15 GMT+02:00 Thorsten Glaser t...@mirbsd.de: Hi *, please see http://article.gmane.org/gmane.comp.video.ffmpeg.devel/182554 for a patch I forwarded upstream, which allows us to build libpostproc on Debian/x32. As I said there, we’ll need to run-time test the built package, but at least we got strigi ⇒ subversion ⇒ git building again (which was the higher goal at the moment). If there’s a standalone test for libpostproc, please point me to it, so I can test it. Not exactly a standalone test, but XBMC uses libpostproc. You can enable it while playing a video: http://forum.xbmc.org/showthread.php?tid=78642 Cheers, Balint ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
Hi Reinhard On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. you could try to test by buiding ffmpeg as a whole but disable asm everywhere except libpostproc that might allow easy testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago The Debian package tracks that repository, and ideally we could collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git So the promise given in https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html doesn't hold anymore? Can you be a bit more specific ? what promise by whom exactly do you speak of ? Any chance to make you reconsider reviving the standalone libpostproc.git? From what i remember there where some problems with that repository so actually maintaining it would probably imply first recreating it for example try to build a old revission: git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 (this is libpostproc/master~20 ATM) ./configure -bash: ./configure: No such file or directory this is a problem for anyone maintaining the code as for example git bisect would not be usable at all or if you do a git show commit a792a836e3d9ef6f1f311604b38095e587282ca7 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 ancestors So really, if someone wants to maintain or use libpostproc.git, first these things need to be fixed but i dont understand why you dont just take libpostproc from where its developed, tested and used ? but if it helps i guess we could copy the libpostproc from FFmpeg over the one in libpostproc.git (which is what reimar suggested) libpostproc.git was only intended to be a copy of FFmpeg with libs other than libpostproc removed anyway. Would this help you ? please use that for the debian package I fear that's not feasible at this point. Why ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#758543: mplayer bug ducktape fix
The bug is still existing in Jessie/unstable. The trick I did was removing and purging mplayer and installing it again. Ugly, but it works. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of libbluray_0.6.2-1_amd64.changes
libbluray_0.6.2-1_amd64.changes uploaded successfully to localhost along with the files: libbluray-dev_0.6.2-1_amd64.deb libbluray1_0.6.2-1_amd64.deb libbluray1-dbg_0.6.2-1_amd64.deb libbluray-bdj_0.6.2-1_all.deb libbluray-bin_0.6.2-1_amd64.deb libbluray-doc_0.6.2-1_all.deb libbluray_0.6.2-1.dsc libbluray_0.6.2.orig.tar.bz2 libbluray_0.6.2-1.debian.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
libbluray_0.6.2-1_amd64.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 04 Sep 2014 19:11:51 +0200 Source: libbluray Binary: libbluray-dev libbluray1 libbluray1-dbg libbluray-bdj libbluray-bin libbluray-doc Architecture: source amd64 all Version: 1:0.6.2-1 Distribution: unstable Urgency: medium Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintainers@lists.alioth.debian.org Changed-By: Sebastian Ramacher sramac...@debian.org Description: libbluray-bdj - Blu-ray Disc Java support library (BD-J library) libbluray-bin - Blu-ray disc playback support library (tools) libbluray-dev - Blu-ray disc playback support library (development files) libbluray-doc - Blu-ray disc playback support library (documentation) libbluray1 - Blu-ray disc playback support library (shared library) libbluray1-dbg - Blu-ray disc playback support library (debug symbols) Changes: libbluray (1:0.6.2-1) unstable; urgency=medium . * New upstream release. * debian/control: Add graphviz to Build-Depends-Indep for doxygen documentation. * debian/patches: Refreshed. Checksums-Sha1: b493418e85c3d586efcfccc5f33068b0e9f96789 2616 libbluray_0.6.2-1.dsc a1ab8c8c9310680fb1fe6a58f9fc5430613600fe 582227 libbluray_0.6.2.orig.tar.bz2 ff5bb3edd8c15bb91e1532f7a0f686543e4b8613 16284 libbluray_0.6.2-1.debian.tar.xz 89d5dd1549a6bf37a7dff626d652586b22a5eaaa 137774 libbluray-dev_0.6.2-1_amd64.deb d4c8c573cc3a184543fc83f50539917b339e18e8 116020 libbluray1_0.6.2-1_amd64.deb bff6250a0c162ec3c38a9f10647975db8d2953c7 307152 libbluray1-dbg_0.6.2-1_amd64.deb 16c275054e0ed413da5e4722f78470aaaecc204b 506068 libbluray-bdj_0.6.2-1_all.deb 93bddd3d19a317217ede76ca3d1cefe35d781b8f 18736 libbluray-bin_0.6.2-1_amd64.deb 681599d71d9e9d2efc4147b439447901a65d192b 343000 libbluray-doc_0.6.2-1_all.deb Checksums-Sha256: 7f5e87de9a3d9454c832226b08cb1c3ab86b9287660f98c662d17b5da0838f4b 2616 libbluray_0.6.2-1.dsc 8ca410c8a4a1e2e8344014a67e2c908182cff3e04ece4e3b9ef196cf6bca5cd0 582227 libbluray_0.6.2.orig.tar.bz2 d36d71d25e36c14a8e9463fbf23fb0d3532e9bc1dcac57ea4d9e1f222419c8ca 16284 libbluray_0.6.2-1.debian.tar.xz 267265bfea834b001660f926b14c72df0caff0dde594e505729e18053efab0ce 137774 libbluray-dev_0.6.2-1_amd64.deb c9da5b20d0e55bcfcb8c8ec8c39ddb99ff2ad0064b75c40a2d0a0a4da70cebeb 116020 libbluray1_0.6.2-1_amd64.deb 5d685806bec091039c27ffea259e05bf9a21ea7d186826430e57b87598a9c795 307152 libbluray1-dbg_0.6.2-1_amd64.deb 53eeb92816a385bc60e30d84b74e284e50d9d478bc348a96e85e7db6ba5fb010 506068 libbluray-bdj_0.6.2-1_all.deb 3678646d0c628b53b66b812ca5898474336dfd4ecdef8d334da865713880df77 18736 libbluray-bin_0.6.2-1_amd64.deb bb658f14fd34a34375ce80c73b723550dab48bfb5d45be8d4c2f65a02fb66ca5 343000 libbluray-doc_0.6.2-1_all.deb Files: d61a2eed67ba6331e7fc27695a6ef259 137774 libdevel optional libbluray-dev_0.6.2-1_amd64.deb c41e5ccadadbe1b4664ed82dfbd3ffaa 116020 libs optional libbluray1_0.6.2-1_amd64.deb 5ea78d0c1446ce692c124dfb31560374 307152 debug extra libbluray1-dbg_0.6.2-1_amd64.deb 8193dee798c63af5cbe093654abf37aa 506068 libs optional libbluray-bdj_0.6.2-1_all.deb 24c7c01d420958feb53e26ed9b8b5d0d 18736 utils optional libbluray-bin_0.6.2-1_amd64.deb 192f0ef8cb7e171c2e1963d6625a53bb 343000 doc optional libbluray-doc_0.6.2-1_all.deb f70d219ae81c3413d001d75873e81a78 2616 libs optional libbluray_0.6.2-1.dsc f4d2f2cab53f976cbb22cbae069057bd 582227 libs optional libbluray_0.6.2.orig.tar.bz2 4be7244be60f8b698edc4e8def9750fd 16284 libs optional libbluray_0.6.2-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUCJ4AAAoJEGny/FFupxmTsGMP/08djXLRrGVAIQdWzXmYaH5H R/IoWEzII5VdVQ9JvXG8YPHvw9Cf0Pv9wGK60aGy9A+SGjM3pvUJnnZWiiEpf5dY AUzTULR1h1AHHj1lOE0njtlDmNTz3EeuwkcI07yeR2IMnmE91Rg0rXBtjBLnahvz Ve8TJjn6JLIS3ktB4suh88aziYO1X6XkUPDQiIopRqqXgJAGKGL/Hn2A/bJm89uf II51+pB4GP6NQHnV98uKplM8BxZFCuQvX4sRGqCzBVTvvEh5cmxoJOFFBmS06QJm aOiJUPfn9uJrR9q7iaZgUyNl2N6zer2krIYKrIMhwx0578dSWq4XuhFkMiF5Lg3u +Un7uAO7yZu+nIWj7dfyrb0Wn8VNDEPRPgGXl/cXpFQXvHV65UhH7ej733X9eVm7 ismLzNltofVskygm4v+6dUIx0rsVqUbsOO2X6RBz/fhAVg0cSNzzfVgNQR3JZzmM cDFF72EJ8PO/vLwGiKXTa4bVg+dYoo/5/tWZLSYnhVTPYvj9Dzwehp+wH+QB0bkV qNRWmnDcPGldNYnBFd4QacgWs45XhJuEVt0ll17WxU5Oip/amPwKX9J9gAGMh67j u9EsSeEgzy5Dlji+ZtgpFNxqcCVgjIZsFM/Um30DBhBEILGAl54Mb7qsQ4c3wxYP jnX5qJxfMVvlR5qAkszc =xVME -END PGP SIGNATURE- Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: patch for x32 for libpostproc
Bálint Réczey dixit: Not exactly a standalone test, but XBMC uses libpostproc. You can Yeah, but unfortunately, that doesn’t help; xbmc is so far up in the A/V chain that it has never even be built. I’m going from low to high… bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: patch for x32 for libpostproc
On Thu, Sep 4, 2014 at 11:43 AM, Thorsten Glaser t...@mirbsd.de wrote: Bálint Réczey dixit: Not exactly a standalone test, but XBMC uses libpostproc. You can Yeah, but unfortunately, that doesn't help; xbmc is so far up in the A/V chain that it has never even be built. It looks like xbmc is finally on the Needs-Build list for the first time, so you could see if it builds. But judging from the buildd status, xbmc doesn't look very portable, so it wouldn't surprise me at all if it doesn't build on x32 either. -- Daniel Schepler ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#738760: libav: Add proper raspberry pi CPU detection
Hi, Please note that I'm not the bug submitter. Can you provide a patch, please? As of now, I can't. :/ I don't have the hardware to reproduce this or to verify the correctness of a patch. So I can only give a few hints about the background of this bug report. Anyone not planning to come up with a patch can probably skip it. :-) I don't know much about raspbian, and don't understand what you actually want to be changed here. I've used raspbian some time ago. The issue with some packages is that they enable ARM NEON instructions (and other illegal instructions?) during compilation, either generally for the armhf architecture, or based on what the build machine supports. The Raspberry Pi is armhf, but does not support NEON. Raspbian buildds *do* probably support NEON though. The Raspbian toolchain is configured to disable NEON. However, libav apparently still ends up with NEON instructions in the binary. Surprisingly, NEON is supposed to get enabled for libav only if the debian/confflag script detects that the toolchain supports NEON. Still, for the libav package in Raspbian, this line was changed: #RPI -- don't build neon flavour #FLAVORS += neon And I know Peter Green (plugwash, Raspbian maintainer) wants to stay as close to Debian as possible since he's a DD, so I assume there is a good reason for that change. Since that automatic detection had to be disabled, it probably fails to work correctly. I guess that means that gcc accepts NEON instructions in inline assembly if the build machine supports it, even when disabling NEON in the default compiler flags. Or there's another issue. I don't have any hardware available to test that. Also I'm not absolutely sure about the technical background, so take this with a grain of salt. If anyone knows how to detect whether or not NEON is enabled in the toolchain, this check should be used in the confflags file, around line 37, instead of check_asm vadd.i16… Plugwash once told me that cpp -dM /dev/null | grep -i ARM_ARCH_ should result in #define __ARM_ARCH_6__ 1 for Raspbian (even on buildds, IIRC) and in #define __ARM_ARCH_7A__ 1 for vanilla Debian armhf. Maybe this can be used as a workaround to check for the environment and disable NEON if it's ARM_ARCH_6. Since I don't have the hardware to reproduce this or verify correctness of a patch, I suppose someone can use these pointers to do the work. Or maybe the bug will rot in this place until the RPi (or Debian, or libav, whichever comes first) is obsolete. I wonder if it's worth the effort or if we should just hope that plugwash always comments out that single line fast enough. :-) (libav11 was not built for Raspbian yet, probably because of this.) Cheers Florian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer michae...@gmx.at wrote: Hi Reinhard On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. you could try to test by buiding ffmpeg as a whole but disable asm everywhere except libpostproc that might allow easy testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago The Debian package tracks that repository, and ideally we could collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git So the promise given in https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html doesn't hold anymore? Can you be a bit more specific ? what promise by whom exactly do you speak of ? The promise of having a maintained stand-alone libpostproc. Any chance to make you reconsider reviving the standalone libpostproc.git? From what i remember there where some problems with that repository so actually maintaining it would probably imply first recreating it for example try to build a old revission: git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 (this is libpostproc/master~20 ATM) ./configure -bash: ./configure: No such file or directory this is a problem for anyone maintaining the code as for example git bisect would not be usable at all or if you do a git show commit a792a836e3d9ef6f1f311604b38095e587282ca7 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 ancestors So really, if someone wants to maintain or use libpostproc.git, first these things need to be fixed but i dont understand why you dont just take libpostproc from where its developed, tested and used ? but if it helps i guess we could copy the libpostproc from FFmpeg over the one in libpostproc.git (which is what reimar suggested) libpostproc.git was only intended to be a copy of FFmpeg with libs other than libpostproc removed anyway. Would this help you ? At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 04, 2014 at 07:42:00PM -0400, Reinhard Tartler wrote: On Thu, Sep 4, 2014 at 7:27 AM, Michael Niedermayer michae...@gmx.at wrote: Hi Reinhard On Wed, Sep 03, 2014 at 11:33:48PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:34 PM, Michael Niedermayer michae...@gmx.at wrote: On Wed, Sep 03, 2014 at 08:22:43PM -0400, Reinhard Tartler wrote: On Wed, Sep 3, 2014 at 9:39 AM, Michael Niedermayer michae...@gmx.at wrote: On Tue, Sep 02, 2014 at 10:06:10PM +, Thorsten Glaser wrote: Hi, as discussed in IRC, I was trying to minimal-invasively port libpostproc (the Debian source package) to x32¹. I could not test it (for lack of a stand-alone test program) yet, but at least I got it to build. you could try to test by buiding ffmpeg as a whole but disable asm everywhere except libpostproc that might allow easy testing though fate or ffmpeg with libavfilter Is http://git.videolan.org/?p=libpostproc.git still maintained? AFAIK, no, it seems the last commit is 2 years ago The Debian package tracks that repository, and ideally we could collect the postproc patches there. libpostproc was and is maintained in git://source.ffmpeg.org/ffmpeg.git So the promise given in https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html doesn't hold anymore? Can you be a bit more specific ? what promise by whom exactly do you speak of ? The promise of having a maintained stand-alone libpostproc. Any chance to make you reconsider reviving the standalone libpostproc.git? From what i remember there where some problems with that repository so actually maintaining it would probably imply first recreating it for example try to build a old revission: git checkout a792a836e3d9ef6f1f311604b38095e587282ca7 (this is libpostproc/master~20 ATM) ./configure -bash: ./configure: No such file or directory this is a problem for anyone maintaining the code as for example git bisect would not be usable at all or if you do a git show commit a792a836e3d9ef6f1f311604b38095e587282ca7 Merge: 1d261c2 7f1c286 7391383 8f2dfd0 8cf4ef5 59d8d9c Its a commit with 6 ancestors, no commit in FFmpeg or Libav has 6 ancestors So really, if someone wants to maintain or use libpostproc.git, first these things need to be fixed but i dont understand why you dont just take libpostproc from where its developed, tested and used ? but if it helps i guess we could copy the libpostproc from FFmpeg over the one in libpostproc.git (which is what reimar suggested) libpostproc.git was only intended to be a copy of FFmpeg with libs other than libpostproc removed anyway. Would this help you ? At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. would it work if libpostproc could be build and installed standalone from ffmpeg git / ffmpeg release tarballs? i havent really investigated it but it seems with the 2 line patch below one can achive that with ./configure --enable-gpl --disable-all --enable-shared --enable-postproc make (it also would need changing #includes ... to ... to use system installed libavutil headers) this seems a easier path than maintaining libpostproc.git if it would work for debian, if not iam sure we will find another solution like updating libpostproc.git. diff --git a/Makefile b/Makefile index 57f6a91..63423bf 100644 --- a/Makefile +++ b/Makefile @@ -48,7 +48,7 @@ FFLIBS-$(CONFIG_POSTPROC) += postproc FFLIBS-$(CONFIG_SWRESAMPLE) += swresample FFLIBS-$(CONFIG_SWSCALE)+= swscale -FFLIBS := avutil +FFLIBS-$(CONFIG_AVUTIL) += avutil DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset) $(SRC_PATH)/doc/ffprobe.xsd EXAMPLES_FILES := $(wildcard $(SRC_PATH)/doc/examples/*.c) $(SRC_PATH)/doc/examples/Makefile $(SRC_PATH)/doc/examples/README diff --git a/configure b/configure index 7de07c3..7a3764f 100755 --- a/configure +++ b/configure @@ -2614,7 +2614,7 @@ avdevice_deps=avformat avcodec avutil avfilter_deps=avutil avformat_deps=avcodec avutil avresample_deps=avutil -postproc_deps=avutil gpl +postproc_deps=gpl swresample_deps=avutil swscale_deps=avutil [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] patch for x32 for libpostproc
On Thu, Sep 4, 2014 at 9:32 PM, Michael Niedermayer michae...@gmx.at wrote: At the end of the day, I need a source tarball that contains maintained sources of a stand-alone libpostproc. I don't care too much how it is created, as long as it doesn't result in code-duplication with existing sources in Debian. would it work if libpostproc could be build and installed standalone from ffmpeg git / ffmpeg release tarballs? That would be exactly the code-duplication I referred to in the text you've quoted. Best, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#758543: mplayer bug ducktape fix
On Thu, 04 Sep 2014 17:31:49 +0200 Steff st...@artikel-140.nl wrote: The bug is still existing in Jessie/unstable. jessie and unstable are different releases -- the updated package is not yet in jessie (testing) but it is in sid (unstable). The trick I did was removing and purging mplayer and installing it again. Ugly, but it works. Installing mplayer how? There is no mplayer package in either jessie or sid. (And packages from wheezy are not going to work in jessie or sid -- that's what this bug is about) For reference, this is what you will see when the fixed package is available (eliding lots of verbose output for clarity): # sed -i s/jessie/sid/ /etc/apt/sources.list # apt-get update # apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done [...] The following packages will be REMOVED: mplayer The following packages will be upgraded: [...] libdvdnav4 [...] 43 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Need to get 18.6 MB of archives. After this operation, 4985 kB disk space will be freed. Do you want to continue? [Y/n] To be explicit, the fix is to ensure that a non-working mplayer package does not remain installed on the system. mplayer is not in jessie or sid at all so there's no mplayer package to fix to use the updated library. There are plenty of alternatives to mplayer in the archive. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
