RFS: polyphone (soundfont editor)
Dear maintainers, It's been quite some time that I want to make Polyphone available in the Debian repositories. Polyphone is a soundfont editor like Swami and have these features: - support for sf2 files, version 2.01 and 2.04, - emphasis on ergonomics, - support for sfArk files (versions 2 and 1 also), - support for sfz files, - tools to automate instrument and preset settings (allow huge files to be easily handled), - available for Windows and Mac OS X. More information about this software can be found here: www.polyphone.fr I am the author of this software and the package should be ready: https://mentors.debian.net/package/polyphone Polyphone is an alternative to Swami, that is why I am also sending this email directly to Jaromir Mikes who is the maintainer of Swami. Best regards, Davy Triponney ___ 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] Reintroducing FFmpeg to Debian
Hi, Andreas Cadhalpun: Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It has been removed from sid, since it fails to build against Libav, but it builds fine against FFmpeg. (It uses some of the features only provided by FFmpeg.) Yet another reason why solely depending on libav is a bad idea. That leaves the question of the official opinion of the libav maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). Did none of them write anything in defense of libav, or have I simply missed it? IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. -- -- Matthias Urlichs ___ 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#756084: confirmed on an ARM server running Jessie
I observe the same behavior on a small ARM server running Jessie, where forked-daapd version is currently 21.0-1. Netstat shows the server listening on IPV4 but not IPV6. The configuration file does contain a line: ipv6 = yes in the general section. The firewall (here shorewall6) is set up to accept connections on port 3689 for IPV6 (but anyway since the server does not even listen on this port in IPV6, the firewall does nothing here). best regards, Luc ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
HOLA
buen día Por favor, ¿recibió el correo que envié a usted la última vez. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
APPLY FOR LOAN SÖKA LÅN
Contact us for quick and reliable loan with 3% interest rate if you are interested in loan contact us with the following email addres:apexfinancesl...@outlook.com ___ 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] Reintroducing FFmpeg to Debian
On Aug 08, Matthias Urlichs matth...@urlichs.de wrote: IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. Agreed. The interested parties should really raise this with the CTTE ASAP. -- ciao, Marco 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] Reintroducing FFmpeg to Debian
On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote: Hi, Andreas Cadhalpun: Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It has been removed from sid, since it fails to build against Libav, but it builds fine against FFmpeg. (It uses some of the features only provided by FFmpeg.) Yet another reason why solely depending on libav is a bad idea. That leaves the question of the official opinion of the libav maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). Did none of them write anything in defense of libav, or have I simply missed it? I intended to come up with a more timely full response, but I just didn't get to it so far. For now, please refer to http://lwn.net/Articles/607662/, http://codecs.multimedia.cx/?p=370 (rather old, but still true), and http://codecs.multimedia.cx/?p=674 (recent update on that matter) Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following discussion with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may provide them with extra features, but why on earth would anyone want 3 different implementations of a ProRes encoder (seriously, and FFmpeg seems to claim to provide security support for each of them), or support for fringe codecs such as Wing Command 3 (yes, you can decode the videos from that video game). There are a number of legitimate requested backports, such as for some of FFmpeg's additional filters in libavfilter, and similar. All of them are rather easy to backport, and this is done on a regular basis. However, with the due diligence and attention such a widely used and high-profile library requires. Which brings me to my next point: Release frequency. FFmpeg has an insane frequency of releases, and still seems to support (at least providing updates) to all of them, including 0.5 which is currently in oldstable (needless to say none of these patches made it to oldstable-security, why is still a mystery to me). The effect of that is that downstream projects have a hard time to choose what version of FFmpeg they want to support. This brings effectively back to the situation I was in when I took over maintenance of the package many years ago: Back then, Michael Niedermeyer strongly recommended all downstreams to avoid shared libraries and just link statically against libavcodec.a to avoid problems regarding incompatible library versions. I see exactly this problem arising again: Both mythtv and mplayer upstream (btw, xbmc as well) bundle some copy of ffmpeg in their sources and recommend everyone to just use the internal copy to avoid problems. Needless to say that this is not acceptable for use in Debian. Yes, I agree that this situation is a mess. A big mess. My fear is that switching to FFmpeg will bring us back to the mess we where 8 years ago, and I worked on for years. Libav is far from being perfect. That's true. I don't know why exactly FFmpeg seems to have more manpower, but it's not all black or white. For instance, there are a number of developers that actively contribute to both projects and are essential in keeping both projects in good health. Also I don't really buy the security argument. True, FFmpeg has more security updates, but backporting them to Libav turned out to be difficult because many if not most of them turn out to be either incomplete, invalid or require further clarification. Libav developers prefer to go the unpleasant road of fully understanding the issue, which takes extra time. For all these reasons, I do not see the necessity to do any drastic and dangerous steps right now. I now seriously wonder if the last 45 minutes in which I wrote this email wouldn't have been better spent with preparing the next upload for stable-security. YMMV. -- regards, Reinhard
Re: RFS: polyphone (soundfont editor)
2014-08-08 11:28 GMT+02:00 Davy Triponney davy.tripon...@gmail.com: Hello Davy, It's been quite some time that I want to make Polyphone available in the Debian repositories. Polyphone is a soundfont editor like Swami and have these features: - support for sf2 files, version 2.01 and 2.04, - emphasis on ergonomics, - support for sfArk files (versions 2 and 1 also), - support for sfz files, - tools to automate instrument and preset settings (allow huge files to be easily handled), - available for Windows and Mac OS X. More information about this software can be found here: www.polyphone.fr I am the author of this software and the package should be ready: https://mentors.debian.net/package/polyphone Polyphone is an alternative to Swami, that is why I am also sending this email directly to Jaromir Mikes who is the maintainer of Swami. Unfortunately I am not DD (Debian developer) just DM (Debian maintainer) thus I can't upload new packages. But anyway my advice is to join pkg-multimedia team package perfectly fit to it. It would much easier for me to help you with if you will be packaging in team's repo. I also believe that you will find easier DD uploader among team members. best regards mira ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: libde265_0.6-1_amd64.changes REJECTED
Hi Joachim, On Thu, 7 Aug 2014, Joachim Bauch wrote: just a quick follow-up on my last mail. As this is my first package I'm not sure if there is anything else I should do, or if I should just wait until someone finds some time to upload it. you need to prod your sponsor more often. Otherwise I am afraid you can only wait. Thorsten ___ 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#757463: vlc unblanks X screen when paused
Package: vlc Version: 2.1.5-1 Architecture: i386 To reproduce: 1. Play any video in vlc 2. Pause playback 3. (optional) iconify VLC 4. xset dpms force off 5. Wait about 30 seconds Expected: Screen stays off indefinitely Observed: Screen unblanks in less than a minute If VLC is not running, or is stopped, this doesn't happen. (I know that VLC causes this and other X applications I have tested do not, but it's possible it's am X server bug in response to some message that's not supposed to unblank the screen.) Given that xset dpms force off is essentially what the default laptop lid-close script does, the fact that the backlight comes back on is rather annoying. It achieves nothing but draining the battery and wearing out the backlight, This is an up-to-date Debian unstable i386 machine, using Intel 945 integrated graphics with the xserver-xorg-video-intel driver. This might be related to my earlier bug about vlc keeping busy during pause, but I'm not sure so I'm submitting them as two spearate issues. Thank you very much! ___ 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] Reintroducing FFmpeg to Debian
Quoting Reinhard Tartler (2014-08-08 14:29:59) For now, please refer to http://lwn.net/Articles/607662/, http://codecs.multimedia.cx/?p=370 (rather old, but still true), and http://codecs.multimedia.cx/?p=674 (recent update on that matter) Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. [snip] I now seriously wonder if the last 45 minutes in which I wrote this email wouldn't have been better spent with preparing the next upload for stable-security. YMMV. Thanks a lot for your input, Reinhard. Even if the loud ones in this thread may not, I doubt I am the only one finding value in your references and arguments. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: 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] Reintroducing FFmpeg to Debian
Hi, On Fri, Aug 8, 2014 at 12:13 PM, Matthias Urlichs matth...@urlichs.de wrote: That leaves the question of the official opinion of the libav maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). Did none of them write anything in defense of libav, or have I simply missed it? IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. This is an eminently bad idea. As I said before, it's too late for Jessie already. Many Jessie's multimedia framework and packages have been developed and QA'd with libav. We've spent a lot of time over the past months talking to upstreams, forwarding them our patches and make sure their programs and libraries work with libav. We've spent ***months*** in making the whole thing work, and dropping libav in favour of FFmpeg at this point, roughly few weeks from the freeze deadline, would be definitely insane. Cheers. -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A ___ 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: libde265_0.6-1_amd64.changes REJECTED
Hi Joachim
On 2014-08-07 09:49:27, Joachim Bauch wrote:
Dear team,
On 31.07.2014 12:02, Joachim Bauch wrote:
[...]
I understand. We created a new release that contains all your feedback.
@Alessio: could you (or any other uploader) please review my changes
and create/upload a new package of libde265?
I updated the git repository on alioth with these changes:
- Fixed debian/watch to download release tarball, not source tarball.
- Updated libde265 to latest upstream version 0.8
- Added libswscale-dev as build dependency so sherlock265 example
will be compiled.
- Reduced amount of exported symbols and updated .symbols file.
- Added comment about only the samples being GPL to debian/copyright.
[...]
just a quick follow-up on my last mail. As this is my first package I'm
not sure if there is anything else I should do, or if I should just wait
until someone finds some time to upload it.
Due to the lack of feedback I find it difficult to know if progress is
stalled because I'm missing some steps, or because everybody is busy
doing other stuff - which I totally understand ;-)
If Alessio (or someone else) doesn't beat me, here are some points that I'd
like to see fixed before I'd upload it:
* The build reports
dpkg-gencontrol: warning: Pre-Depends field of package libde265-dev: unknown
substitution variable ${misc:Pre-Depends}
dpkg-gencontrol: warning: Depends field of package libde265-dev: unknown
substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: Pre-Depends field of package libde265-dbg: unknown
substitution variable ${misc:Pre-Depends}
dpkg-gencontrol: warning: Depends field of package libde265-dbg: unknown
substitution variable ${shlibs:Depends}
That's right. libde265-dev and libde265-dbg don't have them. Please
remove them from Depends and Pre-Depends.
* Please use DEP-3 headers for the patch.
* If I'm not mistaken, the proper capitalization is H.265. Please fix
the Descriptions in d/control.
* Please use Priority: optional (except for the -dbg package, which
should stay Priority: extra).
* There is no need to pass --quilt to dh. You already use 3.0 (quilt).
* I'd put README.md into libde265-dev, i.e. rename debian/docs to
debian/libde265-dev.docs. It doesn't serve much purpose in the
library package.
* (This doesn't affect Debian since the files in extra are not used,
but you should get this addressed upstream: BSD-4-clause and the GPL
are incompatible (see for an example #744267). So anyone using these
files instead of another getopt implementation is unable to
distribute the binaries.)
Cheers
--
Sebastian Ramacher
signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: reported upstream
Processing commands for cont...@bugs.debian.org: forwarded 757185 http://bugzilla.libav.org/show_bug.cgi?id=728 Bug #757185 [libavformat55] libavformat55: missing support for 3D video tags in mkv decoder Set Bug forwarded-to-address to 'http://bugzilla.libav.org/show_bug.cgi?id=728'. thanks Stopping processing here. Please contact me if you need assistance. -- 757185: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757185 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 8 August 2014 13:29, Reinhard Tartler siret...@gmail.com wrote: On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote: Hi, Andreas Cadhalpun: Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It has been removed from sid, since it fails to build against Libav, but it builds fine against FFmpeg. (It uses some of the features only provided by FFmpeg.) Yet another reason why solely depending on libav is a bad idea. That leaves the question of the official opinion of the libav maintainers (pkg-multimedia-maintainers@lists.alioth.debian.org). Did none of them write anything in defense of libav, or have I simply missed it? I intended to come up with a more timely full response, but I just didn't get to it so far. For now, please refer to http://lwn.net/Articles/607662/, http://codecs.multimedia.cx/?p=370 (rather old, but still true), and http://codecs.multimedia.cx/?p=674 (recent update on that matter) Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following discussion with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. So in ubuntu, at the time we were doing libav9 transition we also still had mplayer and pleora of packages inheritance from deb-multimedia or some such repositories. I was very reluctant to remove mplayer and all the reverse-deps, as I felt it is valuable to ship mplayer. I believe it was based on unreleased experimental packaging in git and other bits [1] Later Colin Watson also provided minimal port to make it build on arm64. Unfortunately libav10 transition got entangled in too many ways and we didn't manager to port mplayer to libav10. This was attempted based on top of mplayer trunk snapshot / last stable tarball, patches from gentoo and own porting efforts from myself and sil2100/robru but albeit unsuccessfully. Under pressing wait of too many things stuck in proposed migration (britney migration) we did remove mplayer and reverse dependencies and pointed / filed bugs to port to mplayer2 or just libav-tools where appropriate. I did ponder about compiling mplayer with an embedded copy of libav9 statically linked, but ultimately decided that it's unnecessary evil and majority of use-cases are served by the current libav stack. Either of ffmpeg and libav is a big security maintenance burden, simply from nature of inherently handling complex and large streams of untrusted data. So in trusty, I did work to unsplit the packages such that libav moved from main to universe, and can be synced from debian unmodified to minimize net-total maintenance burden as now updates and packaging can be fully shared. I see moving to mplayer2 as a net positive benefit for Debian. MythTV alone, whilst important package, I don't see as special enough to grant use of an embedded copy or forcing an uncertain cost of switching back to ffmpeg. If we need to port that project, then in Debian/Ubuntu/UbuntuStudio there are enough interested people to get it done. [1] https://launchpad.net/ubuntu/+source/mplayer/2:1.1+dfsg1-0ubuntu1 Regards, Dimitri. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may provide them with extra features, but why on earth would anyone want 3 different implementations of a ProRes encoder (seriously, and FFmpeg seems to claim to provide security support for each of them), or support for fringe codecs such as Wing Command 3 (yes, you can decode the videos from that video game). There are a number of legitimate requested backports, such as for some of FFmpeg's additional filters in libavfilter, and similar. All of them are rather easy to backport, and this is done on a regular basis. However, with the due diligence and attention such a widely used and high-profile library requires. Which brings me to my next point: Release frequency. FFmpeg has an insane frequency of releases, and still seems to
Re: libde265_0.6-1_amd64.changes REJECTED
Hi Sebastian, thanks for the detailed feedback. On 08.08.2014 16:29, Sebastian Ramacher wrote: If Alessio (or someone else) doesn't beat me, here are some points that I'd like to see fixed before I'd upload it: [...] All reported issues have been changed in the repository on alioth. * (This doesn't affect Debian since the files in extra are not used, but you should get this addressed upstream: BSD-4-clause and the GPL are incompatible (see for an example #744267). So anyone using these files instead of another getopt implementation is unable to distribute the binaries.) I've reported this upstream to our developers, so we can resolve this in one of the next versions. Please let me know if there is anything you want to have changed, or are happy to upload it now ;-) Thanks again and best regards, Joachim ___ 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: libde265_0.6-1_amd64.changes REJECTED
On 2014-08-08 17:11:27, Joachim Bauch wrote: All reported issues have been changed in the repository on alioth. Great :) Please let me know if there is anything you want to have changed, or are happy to upload it now ;-) Please update the date in the changelog trailer to match today's date (run dch -r again) and then I'll build and upload. Cheers -- Sebastian Ramacher 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: libde265_0.6-1_amd64.changes REJECTED
On 08.08.2014 17:21, Sebastian Ramacher wrote: [...] Please update the date in the changelog trailer to match today's date (run dch -r again) and then I'll build and upload. Done. Best regards, Joachim ___ 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: libde265_0.6-1_amd64.changes REJECTED
On 2014-08-08 17:24:37, Joachim Bauch wrote: On 08.08.2014 17:21, Sebastian Ramacher wrote: [...] Please update the date in the changelog trailer to match today's date (run dch -r again) and then I'll build and upload. Done. Uploaded. -- Sebastian Ramacher 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: libde265_0.6-1_amd64.changes REJECTED
On 08.08.2014 17:35, Sebastian Ramacher wrote: Uploaded. Great, thanks! ___ 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 libde265_0.8-1_amd64.changes
libde265_0.8-1_amd64.changes uploaded successfully to localhost along with the files: libde265-0_0.8-1_amd64.deb libde265-dev_0.8-1_amd64.deb libde265-dbg_0.8-1_amd64.deb libde265-examples_0.8-1_amd64.deb libde265_0.8-1.dsc libde265_0.8.orig.tar.gz libde265_0.8-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
libde265_0.8-1_amd64.changes is NEW
binary:libde265-0 is NEW. binary:libde265-dbg is NEW. binary:libde265-dev is NEW. binary:libde265-examples is NEW. source:libde265 is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html ___ 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] Reintroducing FFmpeg to Debian
Hi Reinhard, On 08.08.2014 14:29, Reinhard Tartler wrote: On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote: I intended to come up with a more timely full response, but I just didn't get to it so far. Thanks for explaining your point of view here. For now, please refer to http://lwn.net/Articles/607662/, Have a look at: http://lwn.net/Articles/608040/ I was not there, when the FFmpeg/Libav split happened and I don't want to judge, whether it was a good thing or not. But it clearly caused a lot of bad blood between the developers involved, which in my opinion hurts the development of the multimedia framework in recent times. http://codecs.multimedia.cx/?p=370 (rather old, but still true), and If these features weren't used, they wouldn't have been developed. And many new features have been added to FFmpeg after that post. http://codecs.multimedia.cx/?p=674 (recent update on that matter) Let me quote from there: But that’s not what kills the fun, “security holes” do. With an advance of automatic fuzz tools it’s easy to generate millions of damaged files that crash your decoder and yet there are no tools for generating correct patches. Fixing those crashes is tedious, requires a lot of thinking (should I disable it? will it affect decoding correct files? etc.) and in other words not fun at all. That seems as if he doesn't want to continue Libav development, because fixing security issues is tedious work. It has basically nothing to do with whether FFmpeg is of good quality security wise or not, or a good or bad competitor against Libav. Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. One person thinking that the code is 'beautiful' is no convincing argument. The number of people expressing their interest in having FFmpeg back in Debian is a lot more convincing. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. Let me repeat what I wrote in my initial mail in this thread: Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it gives developers and users a choice between the two. Even if Libav were to be removed, a transition to FFmpeg could be rather smooth, as all the necessary patches already exist. But you're right that the time to test the resulting packages is getting rather short for the coming freeze. Still it can make sense for packages that are tested with FFmpeg upstream and have known issues with Libav. So if you and the other Libav maintainers were to support the idea of having both, the security and release teams could perhaps be convinced to allow that. This has been my goal from the beginning and I hoped that would be appreciated. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following discussion with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. That FFmpeg has more features is a rather technical argument. Note that also many other projects are developed mainly with FFmpeg, they just happen to not break completely when compiled against Libav. For example, mpv prefers FFmpeg for good reasons: Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg is preferred in general. This is simply because FFmpeg merges from Libav, and seems to have more features and fewer bugs than Libav. [1] These features are actually requested by users, see e.g. [2]. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may Just fine? Did you see the bugs I mentioned in my initial mail? And how does it come that XBMC needs the '--enable-libav-compat' configure option, which then uses code from lib/xbmc-libav-hacks, to build against Libav? provide them with extra features, but why on earth would anyone want 3 different implementations of a ProRes encoder (seriously, and FFmpeg seems to claim to provide security support for each of them), or support for fringe codecs such as Wing Command 3 (yes, you can decode the videos from that video game). One of those ProRes encoders comes from Libav and is
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Alessio Treglia: We've spent a lot of time over the past months talking to upstreams, forwarding them our patches and make sure their programs and libraries work with libav. We've spent ***months*** in making the whole thing work, and dropping libav in favour of FFmpeg at this point, roughly few weeks from the freeze deadline, would be definitely insane. Yes, that work might be wasted. But I don't think that it's a good idea to base the decision of whether or not X is better for Debian on the fact that somebody did a lot of work for Y instead. Yes, the freeze is not that far away. But frankly, how much effort would it be to switch now? As far as I can tell from this discussion, the answer is not a whole lot. The bulk of ffmpeg/libav's reverse dependencies is just a simple binNMU away, and as the libraries seem to be co-installable we don't even need a big transition. We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd hate to report some intractable codec bug which Upstream closes with an it works with FFmpeg comment -- what would you recommend me to do in that situation, next year -- install the ffmpeg libs from Experimental and rebuild the offender? -- -- Matthias Urlichs ___ 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#757526: vlc: memory leak with play rtmp-stream
Package: vlc Version: 2.0.3-5+deb7u1 Severity: normal Tags: upstream Dear Maintainer! I create stream on my raspberry with raspberian from usb-camera: gst-launch -v v4l2src \! image/jpeg,width=320,height=240,framerate=10/1 \! multipartmux \! tcpserversink host=10.11.6.231 port=5000 sync=false and start vlc and insert url rtmp://10.11.6.231:5000 VLC used very many memory: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 21544 sysadmin 20 0 18,2g 7,8g 6804 S 2,8 66,8 0:07.95 vlc Thaks! -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vlc depends on: ii dpkg 1.16.15 ii fonts-freefont-ttf20120503-1 ii libaa11.4p5-40 ii libavcodec53 6:0.8.13-1 ii libavutil51 6:0.8.13-1 ii libc6 2.13-38+deb7u3 ii libcaca0 0.99.beta18-1 ii libfreetype6 2.4.9-1.1 ii libfribidi0 0.19.2-3 ii libgcc1 1:4.7.2-5 ii libgl1-mesa-glx [libgl1] 8.0.5-4+deb7u2 ii libice6 2:1.0.8-2 ii libqtcore44:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libsdl-image1.2 1.2.12-2 ii libsdl1.2debian 1.2.15-5 ii libsm62:1.2.1-2 ii libstdc++64.7.2-5 ii libtar0 1.2.16-1+deb7u2 ii libva-x11-1 1.0.15-4 ii libva11.0.15-4 ii libvlccore5 2.0.3-5+deb7u1 ii libx11-6 2:1.5.0-1+deb7u1 ii libxcb-composite0 1.8.1-2+deb7u1 ii libxcb-keysyms1 0.3.9-1 ii libxcb-randr0 1.8.1-2+deb7u1 ii libxcb-render01.8.1-2+deb7u1 ii libxcb-shape0 1.8.1-2+deb7u1 ii libxcb-shm0 1.8.1-2+deb7u1 ii libxcb-xfixes01.8.1-2+deb7u1 ii libxcb-xv01.8.1-2+deb7u1 ii libxcb1 1.8.1-2+deb7u1 ii libxext6 2:1.3.1-2+deb7u1 ii libxinerama1 2:1.1.2-1+deb7u1 ii libxpm4 1:3.5.10-1 ii vlc-nox 2.0.3-5+deb7u1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages vlc recommends: ii vlc-plugin-notify 2.0.3-5+deb7u1 ii vlc-plugin-pulse 2.0.3-5+deb7u1 ii xdg-utils 1.1.0~rc1+git20111210-6 Versions of packages vlc suggests: pn videolan-doc none Versions of packages vlc-nox depends on: ii dpkg 1.16.15 ii liba52-0.7.4 0.7.4-16 ii libasound2 1.0.25-4 ii libass40.10.0-3 ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libavc1394-0 0.5.4-2 ii libavcodec53 6:0.8.13-1 ii libavformat53 6:0.8.13-1 ii libavutil516:0.8.13-1 ii libbluray1 1:0.2.2-1 ii libc6 2.13-38+deb7u3 ii libcddb2 1.3.2-3 ii libcdio13 0.83-4 ii libcrystalhd3 1:0.0~git20110715.fdd2f19-9 ii libdbus-1-31.6.8-1+deb7u3 ii libdc1394-22 2.2.0-2 ii libdca00.0.5-5 ii libdirac-decoder0 1.0.2-6 ii libdirac-encoder0 1.0.2-6 ii libdirectfb-1.2-9 1.2.10.0-5 ii libdvbpsi7 0.2.2-1 ii libdvdnav4 4.2.0+20120524-2 ii libdvdread44.2.0+20120521-2 ii libebml3 1.2.2-2 ii libfaad2 2.7-8 ii libflac8 1.2.1-6 ii libfontconfig1 2.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libfribidi00.19.2-3 ii libgcc11:4.7.2-5 ii libgcrypt111.5.0-5+deb7u1 ii libgnutls262.12.20-8+deb7u2 ii libgpg-error0 1.10-3.1 ii libiso9660-8 0.83-4 ii libkate1 0.4.1-1 ii liblircclient0 0.9.0~pre1-1 ii liblua5.1-05.1.5-4 ii libmad00.15.1b-7 ii libmatroska5 1.3.0-2 ii libmodplug11:0.8.8.4-3+deb7u1+git20130828 ii libmpcdec6 2:0.1~r459-4 ii libmpeg2-4 0.4.1-3 ii libmtp91.1.3-35-g0ece104-5 ii libncursesw5 5.9-10 ii libogg01.3.0-4 ii libpng12-0 1.2.49-1 ii libpostproc52 6:0.8.13-1 ii libproxy0 0.3.1-6 ii libraw1394-11 2.0.9-1 ii libresid-builder0c2a 2.1.1-14 ii libsamplerate0 0.1.8-5 ii libschroedinger-1.0-0 1.0.11-2 ii libshout3 2.2.2-8 ii libsidplay22.1.1-14 ii libsmbclient 2:3.6.6-6+deb7u4 ii libspeex1 1.2~rc1-7 ii libspeexdsp1 1.2~rc1-7 ii libstdc++6 4.7.2-5 ii libswscale26:0.8.13-1 ii libtag1c2a
Bug#757531: audacity: FTBFS with clang instead of gcc
Package: audacity Severity: minor Tags: patch User: pkg-llvm-t...@lists.alioth.debian.org Usertags: clang-ftbfs Hello, Using the rebuild infrastructure, your package fails to build with clang (instead of gcc). Detected this kind of error: http://clang.debian.net/status.php?version=3.4.2key=UNDEF_REF Full build log is available here: http://clang.debian.net/logs/2014-06-16/audacity_2.0.5-2_unstable_clang.log Thanks, Arthur -- System Information: Debian Release: jessie/sid (unstable) Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Compiler: Debian clang version 3.5.0-+rc1-2 (tags/RELEASE_35/rc1) (based on LLVM 3.5.0) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
