Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Dimitri,
On 29.07.2014 03:12, Dimitri John Ledkov wrote:
I don't have an opinion about ffmpeg vs libav, apart from how hard the
soname transitions are, especially in ubuntu where we somehow ended up
with ex-multimedia packages around that either never were in debian,
or have been long removed from testing and/or unstable.
There are only 6 additional reverse-build-dependencies of src:libav in
utopic. Two build against lib*-ffmpeg-dev without further changes, one
needs a simple patch to use pkg-config, one needs a patch to adapt to
newer API (also needed for Libav 10), one is BD-uninstallable and one
fails for unrelated reasons, but its build-dependencies on libav*-dev
seem to be unnecessary anyway.
Per package list:
alsa-plugins-extra: OK
bombono-dvd: PATCH CodecID
dvdstyler: Unmet build dependencies: libwxsvg-dev (= 2:1.0.9)
gstreamer-vaapi: error: unsupported GStreamer API version 1.4
kffmpegthumbnailer: OK
libdlna: PATCH pkg-config
The patches are attached to this mail.
Thankfully, we
have worked to make sure libav is in universe only and thus is not a
security maintenance burden. Nonetheless, libav10 transition is still
not complete in utopic today.
Is bombono-dvd the last blocker?
I haven't checked, but now abi
compatible/incompatible the two stacks are? cause it would be a pain
if they are not drop in replacements, and it would also be a pain if
higher up packages link-in both ffmpeg libav and some clashing
symbols are present...
As Marco already wrote, FFmpeg is packaged to be ABI incompatible with
Libav, having different sonames and different symbol versions.
and people start requesting to have build
variants against both.
This could theoretically be done, but I don't think anyone wants to
maintain such a thing, especially because it would need two different
source packages, as the development packages of FFmpeg and Libav have to
conflict.
Has a rebuild of all deps been done? How many
build failures there are? (On both debian ubuntu, ideally) Is
hardening flags / toolchain enabled in both, or either of the two?
I did a rebuild of all the reverse-build-dependencies in sid and the
results can be found in my original mail.
For Ubuntu, see the beginning of this mail.
I'm not sure what you want to know about hardening.
The packages are otherwise unchanged, so use hardening flags if they
already do.
If that question was about FFmpeg/Libav, then yes, FFmpeg uses
--toolchain=hardened and Libav hardening flags.
Best regards,
Andreas
diff --git a/debian/patches/CodecID.patch b/debian/patches/CodecID.patch
new file mode 100644
index 000..e85d2da
--- /dev/null
+++ b/debian/patches/CodecID.patch
@@ -0,0 +1,51 @@
+Description: Rename CodecID to AVCodecID
+
+Author: Andreas Cadhalpun andreas.cadhal...@googlemail.com
+Last-Update: 2014-07-29
+
+--- bombono-dvd-1.2.2.orig/src/mgui/ffviewer.cpp
bombono-dvd-1.2.2/src/mgui/ffviewer.cpp
+@@ -62,7 +62,7 @@ C_LINKAGE_BEGIN
+
+ typedef struct AVCodecTag {
+ #if LIBAVFORMAT_VERSION_INT = AV_VERSION_INT(52,39,00)
+-enum CodecID id;
++enum AVCodecID id;
+ #else
+ int id;
+ #endif
+@@ -70,14 +70,14 @@ typedef struct AVCodecTag {
+ } AVCodecTag;
+
+ #if LIBAVFORMAT_VERSION_INT = AV_VERSION_INT(52,34,00)
+-static uint FFCodecID2Tag(CodecID codec_id)
++static uint FFCodecID2Tag(AVCodecID codec_id)
+ {
+ unsigned int ff_codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag ff_codec_bmp_tags[];
+ return ff_codec_get_tag(ff_codec_bmp_tags, codec_id);
+ }
+ #else
+-static uint FFCodecID2Tag(CodecID codec_id)
++static uint FFCodecID2Tag(AVCodecID codec_id)
+ {
+ unsigned int codec_get_tag(const AVCodecTag *tags, int id);
+ extern const AVCodecTag codec_bmp_tags[];
+@@ -388,7 +388,7 @@ static unsigned char GetChar(uint tag, i
+ return (tagbit_begin) 0xFF;
+ }
+
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ #ifdef _MSC_VER
+ std::string tag_str = boost::format(%1%) % codec_id % bf::stop;
+@@ -406,7 +406,7 @@ static std::string CodecID2Str(CodecID c
+
+ #else // CALC_FF_TAG
+
+-static std::string CodecID2Str(CodecID codec_id)
++static std::string CodecID2Str(AVCodecID codec_id)
+ {
+ return Int2Str(codec_id);
+ }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..03ff5cf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CodecID.patch
diff --git a/debian/control b/debian/control
index 4cd4492..a460e04 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Ubuntu MOTU Developers ubuntu-m...@lists.ubuntu.com
Uploaders: Alexis Saettler ale...@saettler.org
XSBC-Original-Maintainer: Alexis Saettler ale...@saettler.org
Homepage: http://libdlna.geexbox.org
-Build-Depends: debhelper (= 7.0.50), libavcodec-dev (= 4:0.6), libavformat-dev (= 4:0.7)
+Build-Depends: debhelper (= 7.0.50), libavcodec-dev (= 4:0.6), libavformat-dev (=
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, Jul 29, 2014 at 6:10 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: I don't have an opinion about ffmpeg vs libav, apart from how hard the soname transitions are, especially in ubuntu where we somehow ended up with ex-multimedia packages around that either never were in debian, or have been long removed from testing and/or unstable. There are only 6 additional reverse-build-dependencies of src:libav in utopic. Two build against lib*-ffmpeg-dev without further changes, one needs a simple patch to use pkg-config, one needs a patch to adapt to newer API (also needed for Libav 10), one is BD-uninstallable and one fails for unrelated reasons, but its build-dependencies on libav*-dev seem to be unnecessary anyway. Per package list: alsa-plugins-extra: OK bombono-dvd: PATCH CodecID dvdstyler: Unmet build dependencies: libwxsvg-dev (= 2:1.0.9) gstreamer-vaapi: error: unsupported GStreamer API version 1.4 kffmpegthumbnailer: OK libdlna: PATCH pkg-config In addition to this, I would like to note there is a lot of closed-source software which uses ffmpeg instead of libav. Not saying it doesn't exist but I don't know a single piece of closed-source software which has moved from ffmpeg to libav. I know, I know non DFSG-free software, we don't care. Well, I do. E. g. I'm having trouble with Qt right now because I'm using the commercial SDK which indirectly uses ffmpeg to provide some codecs on Linux. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 03:39:29 +0200, Andreas Cadhalpun wrote: Hi Reinhard, On 28.07.2014 02:05, Reinhard Tartler wrote: On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. I discussed this with Moritz in the ITP bug. Moritz ended this discussion [a], and as I wasn't convinced by his arguments, I continued my work. If in the end really only one copy is allowed in the next stable release, I think it should be FFmpeg. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Cheers, Julien signature.asc Description: Digital signature
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Ciao, On Mon, Jul 28, 2014 at 9:44 AM, Julien Cristau jcris...@debian.org wrote: The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. We're not going to ship both and hand that mess over to the security team. Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. It's too late for Jessie. Rather I'd suggest to start reconsidering such switch for Jessie+1. 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 28, Alessio Treglia ales...@debian.org wrote: Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. It's too late for Jessie. Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. Personally I feel that we have inflicted libav on our users for way more time than it was sensible to do. -- ciao, Marco signature.asc Description: Digital signature
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Julien, On 28.07.2014 10:44, Julien Cristau wrote: It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. The release team is likely to let the people involved in multimedia foo fight it out among themselves and pick a winner. I am not interested in a fight and would prefer it very much if this discussion remained purely technical. Having a fresh memory of the last fight that took place on debian-devel, I do not think that repeating a similar disaster is a good idea. We're not going to ship both and hand that mess over to the security team. Could you please explain what mess you are talking about? According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. Two of them (4:0.5.6-2 and 4:0.5.6-3) do not contain security related fixes, but rather fix build failures of the previous security upload, so they do not really count. That makes about 6 security fix uploads in about 3 years for squeeze, i.e. 1 upload per 6 month. If there were both forks in Jessie, this might double the number of uploads to 12 in 3 years, but probably some of them could also go through stable-updates instead of stable-security. Is that an unbearable burden? A lot of other software in Debian has already alternatives, like desktop environments, web browsers, text editors and even init systems. Why should this not be the case for a multimedia framework? There is also one particularly similar case, as in the packages are forks and require many security updates: MySQL and MariaDB are currently in Debian testing. Just for comparison, MySQL in squeeze had 3 uploads to stable-security and 3 to oldstable(-security) [2]. As I mentioned this particular example in my discussion with Moritz, he said that the security team will be working with the release team to sort this out for jessie[3]. Now, 5 months later, he seems to have changed his mind, as I am not aware of any such attempt, but instead Moritz seems to support both [4][5]. Thanks in advance for taking the time to answer these questions. Best regards, Andreas 1: http://metadata.ftp-master.debian.org/changelogs//main/f/ffmpeg/ffmpeg_0.5.10-1_changelog 2: http://metadata.ftp-master.debian.org/changelogs//main/m/mysql-5.1/mysql-5.1_5.1.73-1_changelog 3: https://bugs.debian.org/729203#435 4: https://bugs.debian.org/754940 5: https://bugs.debian.org/754941 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 12:12 PM, IOhannes m zmölnig (Debian/GNU) umlae...@debian.org wrote: Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Plus I would definitely appreciate to see some bug stats supporting such a theory. Cheers. (IOhannes et Multimedia guys, please let's keep debian-devel in the loop, I feel this is much more of general interest than a thing that needs to be addressed internally in pkg-multimedia) -- 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (resending, to keep debian-devel and the bug-report in the loop) personally i would welcome if both libav and ffmpeg could co-exist within Debian¹. as i see it, libav and ffmpeg have diverged, and as such i would like to have the choice which one to use. On 2014-07-28 11:55, Marco d'Itri wrote: On Jul 28, Alessio Treglia ales...@debian.org wrote: Personally I don't feel like dropping libav in favor of ffmpeg now at this stage. + 1 i don't think that dropping libav is appropriate at all. Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Personally I feel that we have inflicted libav on our users for way more time than it was sensible to do. i would appreciate it, if you (and anybody else) used a less flammable | touchy language. fgmadr IOhannes ¹ but then i'm not a member of the security team :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT1jRXAAoJELZQGcR/ejb45GYP/2a06m3B6PRGyjV6oGS1xwDg 0if/Lssn500F8yjrYFKnexKGZg6xncKVKJ+NJncX3pIWMKu/fOXKJusC5Z5eMdvg Ecruo7sXBojUnUxtaibGExkjdCWHv4wC/xwx/gQVUg3ijQGr5CQgZKXRPzf6dAG5 Sc4KS7w1SBtgLWaKvsOVhljSB39lye1cUk8vgkPkvSytJPiFMo1QSCDlbNz5JGbf 4c8viga5W9KCH5zMLzZTRQOkiPQpZMPsd/l220YX6ADwlBhnG/yRFBx7SBOnVDYb BIWb4MFrsCikzC5gJrJZdVAkB96AWOWR6J8N0s8LI2Y1ZwOIM4nJB1FNeQvFRaJI xe5p3dTI5DS7Kvc6i4LjKcO5m1EdZXeS1vV/OMDrLtgpfDC7pfhn3lImaYMPGCpA 60GNGo/PnbUMWGT3Z5JCeX/Q59X53d8DrW7gTcrQoSr6y0DN8AFEpcuDCYbd2ubt /A+0MeocRPNKGiNB7lEfvpSD3x3e4pGlSFB1AMgnwCGmpXzHeA51LzbDJGtfdWon x8L7OD5QD/LwRqQtAncRpf9jB56oJvktmznluSuCcJeY9ADSYH2YDPC1g3CCnuKG SOJpSClZrPjlc2511emDcnOaMJhkyjeQ8R+I67+I05r0jBdk2FDnFASsNVVcRV5o lzO+UTdVUs0nWsiDa+CX =PGZV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I understand perfectly that the soname and symbol versioning clash with libav is not ffmpeg's fault, but that's water (well, sewage) under the bridge. We have to deal with it. Here's an alternative proposal that should be less painful [to our users] in the long run: You need one of the two upstreams to do a *large* major soname bump (at least one order of magnitude higher than what they're currently using), so that both projects can keep evolving with little chance of soname clashes. Symbol versioning will take care of the rest, since both libs carry over their major soname into the symbol version. As it was done upstream, cross-distro/third-party compatibility problems are not increased. Debian will have to package this new bumped upstream release, and get rid of anything built against the old one. It will be easier for Debian if it is ffmpeg upstream that does the soname bump, otherwise we're talking about a huge number of binNMUs. But this is all academic if the security team is not prepared to deal with both libav and ffmpeg at the same time. That effectively forces a choice of either libav, or ffmpeg, and not both. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 13:24, Alessio Treglia wrote: On Mon, Jul 28, 2014 at 12:12 PM, IOhannes m zmölnig (Debian/GNU) umlae...@debian.org wrote: Except that, for a lot of the depending packages, there would be an immediate benefit in the number of bugs fixed. at least in theory. Plus I would definitely appreciate to see some bug stats supporting such a theory. My original mail mentioned some examples. Once FFmpeg is in the archive, each maintainer of a multimedia package could test build it against FFmpeg and see which, if any, of the bugs reported against said package vanish. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I don't think coordination with Ubuntu will be a problem. In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, please become a developer and start maintaining it in Debian. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#528 2: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263278 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 04:05:46PM +0200, Andreas Cadhalpun wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. Yes, i do! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28 July 2014 15:05, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. However: The change in Debian-specific symbol versioning and sonames being done to ffmpeg so that it is co-installable with libav *is* a problem. It has to be done in coordination with the Canonical guys, so that both Debian and Ubuntu do the same thing re. ffmpeg sonames and symbol versioning. Otherwise, the ffmpeg packages will be of very limited use (useless to run third-party binary-only games ;-p). I don't think coordination with Ubuntu will be a problem. In comment #7 in the corresponding bug at launchpad [2] Dimitri John Ledkov wrote that Ubuntu won't introduce FFmpeg on it's on, but instead: If you wish to see a supported ffmpeg stack in both Debian and Ubuntu, please become a developer and start maintaining it in Debian. I don't have an opinion about ffmpeg vs libav, apart from how hard the soname transitions are, especially in ubuntu where we somehow ended up with ex-multimedia packages around that either never were in debian, or have been long removed from testing and/or unstable. Thankfully, we have worked to make sure libav is in universe only and thus is not a security maintenance burden. Nonetheless, libav10 transition is still not complete in utopic today. I haven't checked, but now abi compatible/incompatible the two stacks are? cause it would be a pain if they are not drop in replacements, and it would also be a pain if higher up packages link-in both ffmpeg libav and some clashing symbols are present... and people start requesting to have build variants against both. Has a rebuild of all deps been done? How many build failures there are? (On both debian ubuntu, ideally) Is hardening flags / toolchain enabled in both, or either of the two? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. [1] https://lists.debian.org/debian-devel/2014/02/msg00668.html The FFmpeg version currently in NEW has been there for more than 2 months and is thus outdated. If you want to test the current packages, you can build them from the repository on Alioth [17] (e.g. using git-buildpackage). Furthermore, we'd like to move the FFmpeg packaging under the umbrella of the pkg-multimedia team, because this would facilitate future FFmpeg transitions. I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, and why do you believe you can do a better job with the ffmpeg package currently on NEW? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Jul 28, Reinhard Tartler siret...@gmail.com wrote: Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, and why do you believe you can do a better job with the ffmpeg package currently on NEW? Why should he work on libavcodec when he (along with many other people) wants ffmpeg instead? -- ciao, Marco signature.asc Description: Digital signature
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. Why, only because libav gets a more powerful and efficient competition? I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, and why do you believe you can do a better job with the ffmpeg package currently on NEW? As Marco said, why should he fix bugs in av which have been fixed since ages in ffmeg in many (most?) cases? I am all for having a good ffmpeg set of cmd line progs and libs in Debian. It is too long that this sad and useless split was made. Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Reinhard, On 28.07.2014 02:05, Reinhard Tartler wrote: On Sun, Jul 27, 2014 at 7:20 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: * Does it make sense for me to switch my package? The rule of thumb is, if your upstream uses FFmpeg for development you probably want to switch to using it, too. In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. I discussed this with Moritz in the ITP bug. Moritz ended this discussion [a], and as I wasn't convinced by his arguments, I continued my work. If in the end really only one copy is allowed in the next stable release, I think it should be FFmpeg. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the question above. It remains to be seen, what the release team prefers: frustrated users and developers or both forks in jessie. I think it would be best if ftp-master left the ffmpeg package in NEW until an answer to this problem has been found. I fail to see how this would help anyone, it only makes testing the package more difficult. Whether or not the package is acceptable for the next stable release is not to be decided by the ftp-masters, but rather by the release team. [1] https://lists.debian.org/debian-devel/2014/02/msg00668.html The FFmpeg version currently in NEW has been there for more than 2 months and is thus outdated. If you want to test the current packages, you can build them from the repository on Alioth [17] (e.g. using git-buildpackage). Furthermore, we'd like to move the FFmpeg packaging under the umbrella of the pkg-multimedia team, because this would facilitate future FFmpeg transitions. I am curious why this is your first email about this matter to pkg-multimedia, and why do you write this email only now? In the last discussion on debian-devel it was suggested to get the FFmpeg packages into experimental first [b], before further discussion, so I tried to achieve that. As the package has been in NEW for a rather long time and the freeze is getting closer, sending this mail now seemed appropriate. Moreover, I am curious why I haven't seen you working on libavcodec bugs in Debian before, It would be great if I could fix every bug in Debian, but unfortunately my time is limited. Therefore, when I encounter a problem that cannot immediately be fixed, I try to work around it. The workaround for practically all problems I had with the Libav packages in Debian could be solved by installing FFmpeg binaries from third parties. Therefore I finally decided to work on a more sustainable solution, i.e. a FFmpeg package in Debian. and why do you believe you can do a better job with the ffmpeg package currently on NEW? It is a lot more likely that I work on fixing a bug that affects me, if there is no easy workaround. Best regards, Andreas a: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#568 b: https://lists.debian.org/debian-devel/2014/02/msg00714.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
