Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Charles Plessy writes (Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian): Le Thu, Jul 31, 2014 at 04:29:53PM -0700, Russ Allbery a écrit : Based purely on security evaluations by others that I was able to find on the web, FFmpeg appears to be better at the moment than libav on the security front (although libav appears to be trying to catch up). Hello everybody At that point, and given the impressive number of users who expressed interest for having FFmpeg in Debian (see http://bugs.debian.org/729203), I think that it would be fair to ask the libav maintainers to provide arguments on whether to distribute both libraries or make a choice, even if it is against their own interest since they may see their packages removed at the end. Otherwise we are in that kind of frequent Debianesque situation where the winning strategy is to stay silent as long as possible. CCing libav@packages.d.o. Ian. ___ 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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun wrote: Given the amount of software in Debian and thus the amount of security fixes necessary for a stable release, I think that the additional stable-security uploads for FFmpeg in the order of 10 per release will be hardly noticeable. They are surely noticeable to the security team: the release process of a security update is more than just a throw and forget. Tracking every single vulnerability for each copy of the code consumes time. Every single update also consumes team's time, and that of many organisations external to Debian. What is particularly hard for me to understand is why e.g. MySQL and MariaDB can be in testing at the same time without much resistance from the security team, but FFmpeg and Libav can apparently not. There is resistance - we only want one, not two, not three (percona). IMH (and personal) O, if you want to see ffmpeg in Jessie or later, you should replace libav - i.e. no silly one binary + libraries that won't work for anything else. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net ___ 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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-07-29 03:20, Marco d'Itri wrote: 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... This is why the new ffmpeg will use different symbols. Again, read the first message. according to the first message, this is *not* true. the packages will have different libraries-names / sonames, but this does not mean that they don't have clashing symbols. if both library foo (/usr/lib/libfoo.so.3.21) and library bar (/usr/lib/i386-linux-gnu/libbar.so.4.1) export the symbol knarzifax, then how do you make sure that an application that is linked against both libraries for different functionality always chooses the korrect knarzifax? this becomes a real world issue, as soon as plugins are involved (which i find a common practice to access multimedia frameworks). application flurp has a both flurp-plugin-libav and flurp-plugin-ffmpeg installed. whichever plugin is loaded first, will pull in a library that shadows the symbol knarzifax for the *other* plugin. fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJT10jZAAoJELZQGcR/ejb4o1AP/3aoHeFNZ3xcOLl/I0Y9g5Fp GsejeqWuE59CTtoo/1jp5byhueA5Uw9LpmFOmfKttKvqG3sEXhIkXBOA9wATXYS1 uDsblHzuhKhKagmkQ42N1Ql0h+d7vkZA8/duaAtcSb+8HOU/peMRUMQx/MQyxF4X z8hrmSHMpd9S2QTFJxjIfFa0kCQ9gtBv+p/2BSCRpLkxQBDyCoZeHwTmNQnpac4S xYT5Qzo2YW7U5JKXjllHoKcvdBJ1+gYJYfByBcn7ZmHVSv2Ittu9pl7kgH+S1KPk kdK9mopt3B0riCnIR+m3467TJ4U/F/UQ5VuZwENZ5GqivyiqvHHyyWnf3T2aa+rC hZM+k7mF06kQzOWcRi9F9Mqa/Tt0myZKYZVqpJY/y4U6LUYeSAcNmr6b0vzUkxh1 9YG3RwXMLNQZz565Dw7NoqO/7BKgoviSwSnd6OpHruGIYfScPQGkh0q9eU8v4q0U wazXWQ9ks1hHmp4Ea5QJuT+S/BQv3I5QEW0QYXn6flUkDeyj+T27djBisugive7g yGWEr4sVGczzwXjo1T5vgYxNGzvxPeBWGUzJqsRtxqVZKYYyMLYdzNA0TUP1B3vK rQQJXi7oXDTt/ta7yp09Pbp3ZHqxkJbjpLibgYoY9g9dIsEab25jahIK5xRBytz1 6BtDVvwo6srTgQEqOjzw =vaCN -END PGP 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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more but the code has evolved too much for it to be feasible to backport the patches. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net ___ 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: 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 (=
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Raphael, On 29.07.2014 09:47, Raphael Geissert wrote: Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more You're right, my calculation is slightly flawed. but the code has evolved too much for it to be feasible to backport the patches. That is likely true for some, but not for others. The real reason that there have not been more security updates for ffmpeg in squeeze is that since 0.5.6 this is actually Libav and Libav upstream stopped providing backports to 0.5 after 0.5.10 in February 2013 [1]. FFmpeg upstream released 0.5.14 in July 2014 [2] with some more fixes [3]. So had both been in squeeze, there would have been four more, i.e. 16 security updates. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. What do you mean here? If the affected code is not there, then that's nice, because a backport is not needed. Best regards, Andreas 1: https://www.libav.org/releases/ 2: https://www.ffmpeg.org/releases/ 3: https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=refs/heads/release/0.5 ___ 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: 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) ___ 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: Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote: On 29.07.2014 09:47, Raphael Geissert wrote: Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more You're right, my calculation is slightly flawed. That was my point, so please don't use it as an argument. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. What do you mean here? If the affected code is not there, then that's nice, because a backport is not needed. Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check is missing - while the rest of the code is there. Which is kinda... worse. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net ___ 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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 29.07.2014 21:59, Raphael Geissert wrote: On Tuesday 29 July 2014 18:43:17 Andreas Cadhalpun wrote: On 29.07.2014 09:47, Raphael Geissert wrote: Andreas Cadhalpun wrote: According to the changelog[1], there have been 8 security updates for ffmpeg in squeeze. There would have been more You're right, my calculation is slightly flawed. That was my point, so please don't use it as an argument. Maybe I didn't make my point clear enough, for which the actual number of the security uploads is not important, only the order of magnitude. Given the amount of software in Debian and thus the amount of security fixes necessary for a stable release, I think that the additional stable-security uploads for FFmpeg in the order of 10 per release will be hardly noticeable. While I understand and agree with the general idea of reducing code duplication, I have a really hard time trying to understand why the security team has such a strong opposition to the idea of having both FFmpeg and Libav in Debian stable. One argument against code duplication is the risk that security issues get fixed in one, but not in the other. But in this particular case FFmpeg upstream merges all security fixes from Libav, so an FFmpeg package in a stable release won't have that problem. What is particularly hard for me to understand is why e.g. MySQL and MariaDB can be in testing at the same time without much resistance from the security team, but FFmpeg and Libav can apparently not. Not to mention that some bugs that are being fixed are, for example, for incomplete checks - checks that don't exist in the 0.5 branch. What do you mean here? If the affected code is not there, then that's nice, because a backport is not needed. Let me rephrase it: the fix is for an incomplete check, but in 0.5 the check is missing - while the rest of the code is there. Which is kinda... worse. Now I see, what you mean. Indeed that's worse, but if one notices something like that, then the whole check can be backported instead of the change in the check. Though it probably would have been better to backport already the incomplete check, when it was introduced in the development branch. Best regards, Andreas ___ 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: 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 ___ 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: 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 ___ 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: 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 ___ 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: 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 ___ 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: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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/ iQIcBAEBCAAGBQJT1jAxAAoJELZQGcR/ejb4DtoP/2jEpmxHblY7XX+mGoVT5I+c /Kr/VMwXv8glsbJhrEzgyJS0xaj6PONV0CL+pfoM7BzojK3LJQLza0aPs5u1ipLo +KqMOiK4WMNDk3YSnzZtYcGkM+vKN/bUZ3BF9b5HnBgCs/MI/hxInq52i6Ly6ESv TF6vfS/oUKyM1/PJAf5fiaZ5tegFBBc2QPYnK4ehSuDoT0IOhzxGmft7L5XTQJgU l3dwgYc7aKaDkiFthcXQjFiTuDynOEZtNfSt6CYouulNycNlue3ptMr+DA2exNzY RtpG/GY+lZnklEuHa+0Y/sfM2CBEJwJqSmvPmUXrg4vikDkjGBq0PhAc7D5OO8a0 0Z69wgyrGGCESdZAcTzbWTfKNi02X2kMDkrbDHiq9d605zh6XTYQqBPspVYkY3bW mne+wfu5UN/TK21nIDzV88NQEV9FJ4pQyJpU64Yj8hT2mXNetLps6eMAJJobNby6 xz4Mw3QkNkamy3/vZD+SlYyv1a/K23mY4rkE2JXX0RD6xdMa5RxUuvkWfvJbI1S/ MNAo5eag+RVVHNo1n/p9JliSFYUJFhrkrQy/giyPeBDoNP/yNrmYoxBxmGuMWSu8 Mr/NjfSF9tJ47E1dDmJ+i6YKmyDm0uwqX+oaWo7sS1Ag78RrkVjlP/FOtds9gfQN rwBXUWvmKD3zsCpTcfG0 =kSsp -END PGP 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: 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 ___ 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: 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 ___ 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: 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 ___ 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: 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. ___ 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: 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 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
