Reintroducing FFmpeg to Debian
Hi all,
some of you may have noticed a weird ffmpeg package in the NEW queue[1].
Let me explain:
In 2011 Libav[2] was forked from FFmpeg[3]. It was a time of great
uncertainty, the fork happened with much drama that didn't help making a
technical cut, and at that peculiar time Debian switched to Libav.
Since then the two projects evolved differently, and we have now a
clearer view.
Some short answers to questions you might have now:
* Why is FFmpeg needed in Debian?
- It has features our users are asking for (mostly support for more
codecs, formats and filters)[4-6].
- Some applications break when built against Libav on Debian,
because they are developed using FFmpeg[7-10].
- There are issues[11-12] in Libav's command line tools, that can't
be reproduced with FFmpeg's tools.
- It has a big and active user and developer community. Those of
them who want to use Debian currently need to install FFmpeg from
third parties or compile their own version from source.
* Do you intend to replace Libav by FFmpeg in Debian?
No, there is no need to replace anything as long as it is maintained.
Currently the main goal is to give multimedia maintainers a choice
between the two sets of libraries to link against, and our users the
choice to use the 'ffmpeg' utility. That is possible, because the
packages are co-installable. (Only the *-dev packages conflict.)
* But I thought they were forks, why don't you just create conflicting
packages?
- Because it can't really work! If we do that, packages built with
FFmpeg won't be installable next to packages built with Libav
unless we have full binary compatibility.
- Binary compatibility can only be achieved with some tradeoffs:
a) Not all soversions of the libraries match, so we would have
to patch that away.
b) FFmpeg would have to be compiled with the configure option
--enable-incompatible-libav-abi, resulting in less tested
code paths.
c) FFmpeg and Libav would need to be updated at the same time.
d) The biggest problem is that this would allow applications only
to use the minimal set of the ABI supported by both.
* I do not believe you, explain that voodoo to me: How is it that it
won't break all of Debian and make kittens cry?
(aka: How is FFmpeg packaged for Debian?)
- We built the packages in a way that avoids filename conflicts.
The sonames of the FFmpeg libraries are suffixed with '-ffmpeg',
e.g. libavcodec-ffmpeg.so.55 instead of libavcodec.so.55.
This also means that only if a package uses pkg-config to detect
the correct linker flags, you can simply install e.g. the
libavcodec-ffmpeg-dev package and it will work transparently.
(About half the packages build with no further change, see
stats below.)
- From a user point of view, the tools have different names anyway,
e.g. ffmpeg and avconv, except for qt-faststart, which is
therefore packaged in a separate binary package that diverts
the Libav version to qt-faststart.libav.
Yes, you can have /usr/bin/ffmpeg and /usr/bin/avconv at the same
time without conflicts.
- The development packages have to conflict, because they provide
header files (and pkg-config files) with identical names in
identical locations.
- To avoid potential problems when a program is linked against
FFmpeg libraries and other libraries, which in turn are linked
against Libav, the symbol versions are changed to e.g.
LIBAVCODEC_FFMPEG_55 instead of LIBAVCODEC_55.
* Ok, let's say I'm a multimedia maintainer and want to try out
building my package against your ffmpeg, what should I do?
- If your package uses pkg-config, which is commonly the case, all
you have to do is to replace all lib{av,swscale,postproc}*-dev
build-dependencies by lib{av,swscale,postproc}*-ffmpeg-dev.
You can keep the Libav build-dependencies as alternatives.
- In the (odd) case your upstream doesn't use pkg-config
(52 packages), it's probably a good idea to start using it, so
that the program can be easily built with both.
The patches are usually quite simple as you can see in this
example:
--- squeezelite-1.6.orig/Makefile
+++ squeezelite-1.6/Makefile
@@ -26,7 +26,7 @@ LINK_ALSA= -lasound
LINK_PORTAUDIO = -lportaudio
LINKALL = -lFLAC -lmad -lvorbisfile -lfaad -lmpg123
-LINKALL_FF = -lavcodec -lavformat -lavutil
+LINKALL_FF = $(shell pkg-config --libs libavcodec libavformat
libavutil)
LINKALL_RESAMPLE = -lsoxr
DEPS = squeezelite.h slimproto.h
Patches for packages using Autoconf or Cmake are similarly
straight-forward.
- Sometimes other minor adjustments are needed. (13 packages)
- There are only 2 packages (opencv and ffms2) that would trigger a
needed transition, but that woul
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 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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d5a9d1@googlemail.com
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d62f9a.7040...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Holger, On 28.07.2014 13:22, Holger Levsen wrote: On Montag, 28. Juli 2014, Niv Sardi wrote: As described in Andreas thorough mail, there are only 2 packages that can't use both (and iirc they currently FTBFS as upstream uses FFmpeg) and 5 packages that could need a transition, so the release team can just pop an RC bug on ffmpeg until all is sorted out to ensure it doesn't get into testing. note that also the ffmpeg maintainers could file this RC bug, which would also show their willingness to cooperate, prevent potential mess and which can be easily fixed anytime. We could file such a RC bug if that is deemed the best way forward, but at the moment it's a rather irrelevant point, because the package targeted at experimental is still waiting in the NEW queue. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d64a77.7090...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 28.07.2014 12:20, Thorsten Glaser wrote: Andreas Cadhalpun wrote: * Do you intend to replace Libav by FFmpeg in Debian? No, there is no need to replace anything as long as it is maintained. Currently the main goal is to give multimedia maintainers a choice between the two sets of libraries to link against, and our users the choice to use the 'ffmpeg' utility. That is possible, because the packages are co-installable. (Only the *-dev packages conflict.) Hm, I wonder if this will work, see the JPEG discussion. Well, it would work, if the security and release teams would agree with it. But I'd *love* to see ffmpeg replace libav and to get my mplayer back, which is currently on hold. 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.) Best regards, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d64e31.9060...@googlemail.com
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)" 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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d64f90.1020...@googlemail.com
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d658ba.5090...@googlemail.com
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
+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 (tag>>bit_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
Uploaders: Alexis Saettler
XSBC-Original-Maintainer: Alexis Saettler
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d7cf25.3040...@googlemail.com
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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d80eda.8040...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Russ, On 29.07.2014 23:30, Russ Allbery wrote: Andreas Cadhalpun writes: 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. Er, 8 security updates over the course of a stable release is already very high. Wouldn't adding another 10 make that the least secure source package in Debian? I believe that's worse than web browsers, which have a very large attack surface and huge numbers of active and well-funded attackers. And this is just for a multimedia library. I must have failed to make my point again. :( As far as I know there are hundreds of security updates (for all packages together) in the lifetime of a stable release. Compared to that 10 is not large. And, as I already mentioned, I think that some of the FFmpeg updates are minor enough to go through stable-updates. It doesn't make a software less secure, if (even minor) security fixes get backported even to old release branches, rather the contrary. Webbrowsers tend to have a lot more security issues and e.g. for Firefox 15 security releases are planned in two years[2]. More importantly, Mozilla supports one release only for one year. That is much worse than the case of FFmpeg. As e.g. the chromium browser uses FFmpeg[3] it is also under the scrutiny of the very same attackers and security researchers as webbrowsers. I suppose it depends on how many of those could be grouped into one update, and each Iceweasel update usually has multiple fixed CVEs, so maybe this isn't an entirely fair comparison. But still, those are jaw-dropping numbers. For the numbers of CVEs fixed in each FFmpeg release, please have a look at their security webpage[4]. Note how many of them get backported to old releases and if one isn't, that's probably because the old release didn't contain the vulnerable code. 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. Because the sorts of numbers that you're talking about indicate that this code is a complete security disaster. Seen from a different point of view they show that the security support of FFmpeg is very good. 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. MySQL is already a security update problem due to Oracle's very unhelpful attitude towards security patches. And we're still talking about rather fewer security vulnerabilities than this, I believe. So this gives me the impression that MySQL has a worse security support than FFmpeg, which doesn't really help to understand why the security team seems to be fine with having both forks of that in Debian testing. Best regards, Andreas 1: https://security-tracker.debian.org/tracker/source-package/libav 2: https://www.mozilla.org/en-US/firefox/organizations/faq/ 3: https://src.chromium.org/svn/trunk/deps/third_party/ffmpeg/README.chromium 4: https://ffmpeg.org/security.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d82293.7010...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 30.07.2014 00:54, Russ Allbery wrote: Andreas Cadhalpun writes: I must have failed to make my point again. :( As far as I know there are hundreds of security updates (for all packages together) in the lifetime of a stable release. Compared to that 10 is not large. And, as I already mentioned, I think that some of the FFmpeg updates are minor enough to go through stable-updates. It doesn't make a software less secure, if (even minor) security fixes get backported even to old release branches, rather the contrary. Well... backporting security fixes more of a bare minimum -- that's just something that has to happen if we're going to support the software at all, with a handful of exceptions where the software is, for one reason or another, important enough that we're willing to release with it even though security patches aren't backported properly and then terminate support in the middle of our normal stable process. So it's good that FFmpeg upstream does that backporting. But software should also not pose a significant security load in the first place. That quantity of security vulnerabilities tells me that something is deeply wrong with FFmpeg as an upstream source base. That's a sign of code with a bad smell. In my opinion the large amount of security fixes is due to the fact that FFmpeg is a large codebase and that most of the code has to deal with untrusted data, a.k.a. multimedia files. Now, that doesn't necessarily mean that it doesn't belong in Debian. Sometimes we have to hold our nose and live with that, and it sounds like libav isn't necessarily a lot better. On the contrary I think that Libav is worse, as it doesn't even apply all patches for security vulnerabilities fixed in FFmpeg that also affect Libav. Just have a look at the security tracker of Libav[1]. But those are really painful statistics that, to me at least, indicate the world is crying out for a replacement code base that accomplishes the same goals but was written with a higher level of quality in mind. Obviously easier said than done, of course. The time needed to do that would likely be spent a lot better with trying to find and fix the remaining vulnerabilities in FFmpeg, because any rewrite of such a large code base inevitably introduces it's own security bugs. Is upstream aware that this is a really bad track record and trying to do something proactive to increase the quality of the code, like comprehensive auditing, or proactive rewrites to use more secure coding practices such as some of the work that the LibreSSL team has been doing? On 30.07.2014 01:01, Russ Allbery wrote: > Ah, I should have Googled my own question. > > http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html > > Well, that's... better than nothing. It's certainly part of an > overall strategy, although that number of issues still indicates to > me that there are style and architecture issues here that could > benefit from more proactive design work. I could be wrong, having > not looked at the code personally -- maybe the problem space is just > really hard. But that seems like quite a lot of errors. You could also have asked FFmpeg upstream. (I've CCed Michael Niedermayer now.) I'm sympathetic to the concerns of the security team and the release team about supporting two code bases with this much security activity in a stable release. Maybe it's still the right thing to do, but that's a lot of work for them. Of course I'm also sympathetic with the concerns of the security and release teams. But given that the alternatives are either to drop Libav, which the Libav maintainers would probably be unhappy about, or not having FFmpeg in the next stable release, which a lot of other people would be unhappy about, having both in stable seems like the least bad solution. Best regards, Andreas 1: https://security-tracker.debian.org/tracker/source-package/libav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53d83869.90...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Josselin, On 31.07.2014 21:54, Josselin Mouette wrote: Le mercredi 30 juillet 2014 à 00:39 +0200, Andreas Cadhalpun a écrit : I must have failed to make my point again. :( No, you are the one who misunderstands the point. Thanks for sharing your opinion. As far as I know there are hundreds of security updates (for all packages together) in the lifetime of a stable release. Compared to that 10 is not large. And, as I already mentioned, I think that some of the FFmpeg updates are minor enough to go through stable-updates. No FFmpeg security update is “minor”. While it's hard to proof your statement, I agree that most of the FFmpeg security fixes should not be considered minor. Still not every FFmpeg update (note that the word 'security' is absent here) fixes a severe security issue. Some contain only regression fixes. For example in the 2.2 release series, only 2.2.4 fixed a CVE, the other four updates did not, so could have gone through stable-updates. Almost each ffmpeg security bug is a code execution one. Almost each and every one of them is hard to backport. When making such a statement it is very helpful to explain how you came to this conclusion. For example, the last security fix (CVE-2014-4609) could be trivially backported even to the 0.5 branch. (I did so myself.) Those 10 security updates might represent more work than 100 *really* minor security updates. Even if it required a lot of work to backport the security fixes, that work would be done by FFmpeg upstream anyway. The security team would at most have to review the changes. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53daae09.3000...@googlemail.com
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Didier, On 31.07.2014 22:36, Didier 'OdyX' Raboud wrote: Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit : How is it better to have libav, which does a lot less security bugfixing, in? Our security team has to prepare the libav updates over the lifetime of wheezy anyway. As far as I know, both the updates for Libav and FFmpeg are prepared by their respective upstreams, then integrated into the Debian packages by the respective maintainers and only then comes work for the security team in reviewing the patches and writing a DSA. Introducing ffmpeg in jessie (with or without dropping libav) means (at least) duplicating that work. Since all the updates for Libav are merged by FFmpeg, it's not really duplicated work. At least in theory only the additional fixes of FFmpeg would have to be reviewed additionally. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53dab016.2020...@googlemail.com
Re: Reintroducing FFmpeg to Debian
user debian-le...@lists.debian.org usertags 729203 copyright-review-requested thanks Hi Charles, On 06.08.2014 13:55, Charles Plessy wrote: A few years ago, I made a proposal for peer-reviewing copyright files in the NEW queue. https://wiki.debian.org/CopyrightReview The goal is not to substitute for the inspection by the FTP Master team, but to correct defects before their review, therefore saving their time. This looks like a good idea, but unfortunately it seems not to be an often used process. I have done a few dozens of these reviews and share Thorsten's impression in general (althouth in my opinion 80 % is quite an upper-range estimate…). I have no accurate numbers, but I just reviewed three packages [1-3] and found problems in all of them. It's a rather small sample size, but still... I encourage everybody who uploads to the NEW queue to review some packages in exchange. To help people reviewing your package, please make sure that a copy is accessible (source packages in the NEW queue are not accessible outside the FTP Master team). Now, could anyone review the debian/copyright file of ffmpeg? The sources are available in this repository: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git Best regards, Andreas 1: https://bugs.debian.org/686447 2: https://bugs.debian.org/735884 3: https://bugs.debian.org/683746 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e4116b.80...@googlemail.com
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 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 provided in FFmp
Re: Bug#729203: Reintroducing FFmpeg to Debian
Hi Charles, On 09.08.2014 11:45, Charles Plessy wrote: I searched for license information missing from your debian/copyright and could find only one case, libavutil/x86/x86inc.asm, which is under the ISC license. The debian/copyright file of your package looks comprehensive to me. Many thanks for the copyright review. (I know it is a lot of work.) I added the missing information you found (and also uppercased some license names to match the copyright format specification) [1]. It's probably not necessary to make a new upload to the NEW queue for this change. In the repository is a new upstream version anyway and it will be uploaded, once the current version gets accepted. Best regards, Andreas 1: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=d5f7788c60951684851ac8ef7fbb468bd385cdeb -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e6072c.7040...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Kieran, On 09.08.2014 19:26, Kieran Kunhya wrote: The reality is that in the current state of affairs static linking is the *only* way you are guaranteed to have the features you expect and avoid ABI mismatches. It's very complicated when your users complain about bugs in an underlying library that is either too old on a system or the wrong flavour of the fork. Then your users have to rebuild a massive dependency chain to fix that bug or hope for the best in the future. I can understand that statically linking is easier from an upstream point of view, but it has important disadvantages for a distribution such as Debian and thus should be avoided if possible. It is also the responsibility of a distribution to make sure that there are no ABI mismatches or similar problems. We also use a fork specifically to work around very wasteful calculations in libswscale during 10-bit chroma conversion that involve multiplying a pixel by a 2^n value with 32-bit precision and then shifting that value down by n back to 16-bit precision (achieving nothing). The fix breaks other codepaths that we don't use but the performance gain is big enough to warrant a fork. Can you provide a commit/diff/link for reference? The way you describe it makes it appear as if these calculations are needed sometimes, but not always. If so, there should be away to teach libswscale to only do these calculations if they are necessary. FWIW I think debian should also enable libavresample. This code has been proven to be more robust internally and was designed by a larger group instead of libswresample which was basically one person (and literally appeared in git out of nowhere). FWIW I already enabled libavresample in the Debian FFmpeg package for compatibility reasons [1]. Still I would be interested in any proof of libavresample being 'more robust internally'. Best regards, Andreas 1: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=e6d32135ec5ada648465aba8d4daad58b86ff8d0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e66785.4020...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
: The silence from the Libav camp seems to not to be taken as consent. Quite the contrary is true. Do you want to say here, that there are many people preferring Libav, who haven't participated in this discussion? This might or might not be true, but I would welcome anyone, who makes a technical argument. How to proceed from here? TBH, I'm not sure. Ideally, both projects would find some common ground and "just merge" (however that would technically look like). Indeed, that would be the ideal solution, ... However, this very debate within Debian shows that this is unlikely to happen anytime soon: There is way to much disagreement on very fundamental questions that require agreement within a free software project, and the hostile and aggressive tone the majority of participants in this debate exhibit does not help with making progress on that front either. ... but I'm also under the impression that there is still too much bad blood between both upstreams for this to happen. On 10.08.2014 16:18, Reinhard Tartler wrote: > On Fri, Aug 8, 2014 at 2:06 PM, Andreas Cadhalpun > wrote: >> It would be nice, if you could also spent some time thinking about >> the possibility of having both FFmpeg and Libav in Debian. > > Please believe me that I did spend a lot of time thinking about this. > I firmly do not think that this is a reasonable approach. Please see > my other email on debian-devel as explanation. To me it seems your other mail (above) doesn't mention the possibility of having both, only: "FFmpeg would stop tracking Libav as soon as it replaces Libav in Debian" But if you are opposed to having both and also opposed to letting FFmpeg replace Libav, it seems that it will be impossible to get a consensus here. Therefore the technical committee will have to decide between: a) having both FFmpeg and Libav in Debian b) only having FFmpeg in Debian c) only having Libav in Debian As I haven't seen any convincing technical argument for only having Libav, I doubt the technical committee's decision will be c). Best regards, Andreas 1: I'm getting tired of this phrase... 2: https://bugs.debian.org/757280 3: https://bugs.debian.org/747868 4: https://bugs.debian.org/739312 5: https://bugs.debian.org/755810 6: https://bugs.debian.org/748861 7: https://bugs.debian.org/751344 8: https://bugs.debian.org/745819 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e7ddfc.4090...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On 16.08.2014 17:49, Pau Garcia i Quiles wrote: On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George mailto:geo...@nsup.org>> wrote: The only option is to make sure the users do not suffer from the fork, by making sure they can easily use the version that is most suited for their need without being sucked into the developers' disagreements. Can we get back on topic? Yes. I have now sent the pkg-config patches to the BTS [1]. With or without libav in Debian, there are solid technical reasons to have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although they parted ways in a civilized way: different library names), and we certainly have a ton of librarys which provide very similar features. This is also my point of view. Since before the fork, the libav developers have been sabotaging ffmpeg as much as possible, in every "combat field": library names, library versions, taking distributions hostage (ffmpeg package that installs libav!?), etc. This is not the way to fork anything. This is a fact. It would be nice, if everyone, including you, would refrain from posting such flamebaits on debian-devel. Please try to follow Debian's code of conduct [2]. I don't care whether Michael Nidermayer was a dictator or not. I don't care whether the code-review rules in libav are better or worse. I don't care what the Linux kernel does. The only thing I care about is Debian is shipping a less-capable (i. e. less multimedia formats supported) distribution due to this conflict. This has to stop. ffmpeg is not yet in Debian due to the filename clashing, which will most certainly cause binary problems. This is wrong, because the FFmpeg Debian packaging avoids filename conflicts. If libav and ffmpeg maintainers cannot reach an agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. This is already done in the FFmpeg Debian packages. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past. This is not necessary, because the Libav binaries already have different names, avconv, avplay and so on. And before someone mentions it: I don't think it's too late. It's getting too late because nobody with the right to act is doing anything. In the end, our users are the ones being harmed and we are left wondering why they are increasingly moving to other distributions or Mac OS X. Indeed it's getting late, because the FFmpeg package has been waiting in the NEW queue for more than 3 months. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com 2: https://www.debian.org/code_of_conduct -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53efdfea.8000...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Russ, On 16.08.2014 18:33, Russ Allbery wrote: All the renaming and cordial co-existence in the world won't change this. The things that would change this is for one or both projects to develop a better security track record and a history of higher-quality code releases that require less ongoing work in stable, Let's just have a look at FFmpeg's security track record. The easiest way I found to do this quantitatively, is to count the CVEs on FFmpegs security page [1] per year. 2011: 39 2012: 55 2013: 66 This indeed looks bad and even getting worse. But don't forget that e.g. in 2012 the systematic fuzzing by Jurczyk and Coldwind began. By now, more than half of 2014 is over and so far only 5 CVEs [3] have been fixed in FFmpeg this year. I must admit that I'm no security expert, but I think this shows that FFmpeg's security has improved a lot. or for the people who care deeply about this to somehow find a way to relieve the impact on those teams in some way acceptable to those teams. Michael Niedermayer already volunteered to help with all security related problems of FFmpeg in Debian. So what should he do to relieve the impact on the security and release teams? Short of that, there's clearly a need for software of this type in Debian, and at the same time it's clearly a ton of work. The teams involved have indicated that they're willing (if not necessarily happy) to deal with one version of the source base, but not two. This still confuses me, because apparently nobody has a problem with having three binary compatible MySQL variants in Debian: MySQL, MariaDB and PerconaDB [4] Best regards, Andreas 1: https://ffmpeg.org/security.html 2: http://j00ru.vexillium.org/?p=2211 3: The security page shows 6 CVEs, but CVE-2014-4609 and CVE-2014-4610 are the same, once reported for Libav and once for FFmpeg. 4: https://lists.debian.org/debian-devel/2014/08/msg00016.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f094d6.4070...@googlemail.com
Re: libfreerdp changed soname without transition - rebuilds necessary
Hi, On 18.08.2014 07:20, Dominik George wrote: the libfreerdp1 package changed its soname without a transition and without introducing a new package. That broke binary compatibility of at least remmina and libguac-client-rdp0 [0]. The bug report about this is: https://bugs.debian.org/757926 Best regards, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f1e557.80...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Thomas, On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with potentially the same security issues that we'd have to fix twice rather than once. Why is it a security problem to have FFmpeg and Libav, but apparently no problem to have MySQL, MariaDB and PerconaDB? This seems quite arbitrary to me, especially since there have been already 36 CVEs in 2014 for MySQL [1], of which 26 apparently are also relevant for MariaDB [2] and PerconaDB [3], but only 7 for FFmpeg [4] and 8 for Libav [5] in the same time. Best regards, Andreas 1: https://security-tracker.debian.org/tracker/source-package/mysql-5.5 2: https://security-tracker.debian.org/tracker/source-package/mariadb-5.5 3: https://security-tracker.debian.org/tracker/source-package/percona-xtradb-cluster-5.5 4: https://security-tracker.debian.org/tracker/source-package/ffmpeg 5: https://security-tracker.debian.org/tracker/source-package/libav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f1e5f9.4030...@googlemail.com
Re: Reintroducing FFmpeg to Debian
Hi Moritz, On 18.08.2014 14:05, Moritz Mühlenhoff wrote: Andreas Cadhalpun schrieb: On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with potentially the same security issues that we'd have to fix twice rather than once. Why is it a security problem to have FFmpeg and Libav, but apparently no problem to have MySQL, MariaDB and PerconaDB? Raphael Geissert already wrote that mysql/mariadb/percona will be addressed as well; we haven't come around to since since we need to deal with a lot of stuf and being dragged into endless discussions on -devel is certainly not helpful. I don't remember Raphael Geissert writing anything about security concerns with having MySQL, MariaDB and PerconaDB, only that you wrote half a year ago, that the security team will "be working with the release team to sort this out for jessie" [1]. As I haven't seen any further discussion about this and the recent mail about MySQL, MariaDB and PerconaDB on debian-devel [2] indicated that the plan was to have all of them as alternatives, I assumed this was resolved. There wouldn't be any discussion about the security of FFmpeg and Libav as well, if you hadn't started it [3]. Why is FFmpeg treated differently than MariaDB/PerconaDB? Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#435 2: https://lists.debian.org/debian-devel/2014/08/msg00016.html 3: https://lists.debian.org/debian-devel/2014/02/msg00668.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f1fc78.7030...@googlemail.com
Re: Reintroducing FFmpeg to Debian
Hi, On 17.08.2014 00:49, Andreas Cadhalpun wrote: I have now sent the pkg-config patches to the BTS [1]. I have found a simpler way to make it possible to link packages not using pkg-config against FFmpeg in Debian: The lib*-ffmpeg-dev packages now install symbolic links from the standard lib*.so library names to the suffixed ones. This makes it possible to use the normal linker flags, e.g. '-lavcodec', to link against the FFmpeg libraries with '-ffmpeg' suffix. Therefore I have closed the bugs with the pkg-config patches [1]. Thus, once FFmpeg is through NEW, most packages can just switch the build-dependencies to be build against FFmpeg. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f87004.6000...@googlemail.com
Re: Multiple suspend issues
Hi Patrik, On 25.02.2014 13:50, Patrik Dufresne wrote: I've installed "jessie" on my laptop during the week-end. I do have many issues related to suspend. 1. Fn + F7 doesn't suspend the laptop. (was working in Debian wheezy) 2. Closing the Lid doesn't suspend either. I remember there was an option in "Tweak Tools" to suspend the laptop... Can't find it anymore. Was is removed or move somewhere else ? 3. Finnaly, the only was I manage to suspend the laptop is using the menu in the top-right corner. I'm use it multiple time and each time, the laptop seams to wakeup for unknown reason. Meaning, after hours I notice the laptop is no longer in suspend mode. I'm not a "expert", so I will needs your tips to provide you the right information. I think you are one more suffering from Bug #726763. This should be fixed by either installing systemd-shim or by installing systemd-sysv and thus switching to the new default init system called systemd. I hope I could help you. Best regards, Andreas 1: https://bugs.debian.org/726763 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/530c9c7c.2050...@googlemail.com
Re: Bug#750817: ITP: x265 -- x265 HEVC Encoder
Hi, On 10.06.2014 02:06, Reinhard Tartler wrote: I took a first look at the package, and it builds a shared library by default (good). Unfortunately, it doesn't provide a proper SONAME: $ objdump -p libx265.so | grep SONAME SONAME libx265.so It does have a proper SONAME, when I'm building it (with default options): $ objdump -p libx265.so | grep SONAME SONAME libx265.so.22 How does your x265/build/linux/x265_config.h look like? It should contain: #ifndef X265_CONFIG_H #define X265_CONFIG_H /* Defines generated at build time */ /* Incremented each time public API is changed, X265_BUILD is used as * the shared library SONAME on platforms which support it. It also * prevents linking against a different version of the static lib */ #define X265_BUILD 22 #endif The only strange thing is that the generated libx265.so.22 is a symlink to libx265.so.1.1, but I guess this doesn't really matter, as long as libx265.so.22 is there. This makes me wonder if it's worth building it as shared library in debian as this point, or if we wouldn't be better of with a static library only. I wonder what is upstream's take on this? I would appreciate it if a shared library would be build, so that other programs (like FFmpeg) can use it. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53975ba4.5000...@googlemail.com
Re: apt-get source linux behaves weird
Hi Daniel, On 14.08.2015 08:10, Daniel Reichelt wrote: > when I do 'apt-get source linux' with jessie+sid enabled in sources.list, > there's no way to select jessie's ksrc version by target release. Neither > of these work: > > - apt-get source linux > - apt-get -t jessie source linux > - apt-get source linux/jessie > > > Everytime the result is: > ---8<--- > $ apt-get source linux/jessie > Reading package lists... Done > Building dependency tree > Reading state information... Done > Selected version '4.1.3-1' (jessie) for linux Note how this line is clearly wrong, as jessie doesn't have linux 4.1.3-1. [...] > Am I missing something or is this a bug in apt? > Any hints are greatly appreciated. This looks very much like apt bug #746412 [1], which I reported in April last year (and which was mistakenly closed today). Best regards, Andreas 1: https://bugs.debian.org/746412
Re: apt-get source linux behaves weird
Control: tag -1 patch
On 15.08.2015 02:13, Russ Allbery wrote:
> I believe the explanation is that selecting the distribution doesn't work
> the way that you think it does. It just changes the prioritization used
> for selecting packages to install, which is then ignored by the source
> command. (I could have the details wrong; this is vague memory from
> previous discussions.)
Actually the explanation is that it's a bug (or two) in apt.
The code responsible for this behavior is [1]:
while ((Parse = SrcRecs.Find(Src.c_str(), MatchSrcOnly)) != 0)
{
const string Ver = Parse->Version();
// See if we need to look for a specific release tag
if (RelTag != "" && UserRequestedVerTag == "")
{
const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
if (Rel == RelTag) /// <-- Here it compares the '-t' argument with
the release, e.g. stable/unstable.
{
Last = Parse;
Offset = Parse->Offset();
Version = Ver; /// <-- Here it can have the correct version. :-)
}
}
// Ignore all versions which doesn't fit
if (VerTag.empty() == false &&
Cache->VS().CmpVersion(VerTag, Ver) != 0) // exact match
continue;
// Newer version or an exact match? Save the hit
if (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 0) {
Last = Parse;
Offset = Parse->Offset();
Version = Ver; /// <-- But here it overwrites the found version
with any newer one. :-(
}
// was the version check above an exact match?
// If so, we don't need to look further
if (VerTag.empty() == false && (VerTag == Ver))
break;
}
To fix this problem, one can add a 'break;' at the point, where apt got
the correct version.
Then 'apt-get -t unstable source ' works as expected,
but 'apt-get -t sid source ' still doesn't work, because
apt doesn't compare with the distribution codename, e.g. jessie/sid.
That's not hard to fix either.
> It would be great if this could be fixed at some point, since it's really
> surprising UI behavior.
Attached patch fixes both problems, so hopefully the next apt release gets
this right.
Best regards,
Andreas
1:
https://anonscm.debian.org/cgit/apt/apt.git/tree/cmdline/apt-get.cc?id=990af3c952676eaa51ccd614ab2d4234693da397#n383
--- a/cmdline/apt-get.cc
+++ b/cmdline/apt-get.cc
@@ -161,7 +161,7 @@ static std::string MetaIndexFileNameOnDisk(metaIndex *metaindex)
// -
/* */
static std::string GetReleaseForSourceRecord(pkgSourceList *SrcList,
- pkgSrcRecords::Parser *Parse)
+ pkgSrcRecords::Parser *Parse, std::string &Dist)
{
// try to find release
const pkgIndexFile& CurrentIndexFile = Parse->Index();
@@ -184,6 +184,7 @@ static std::string GetReleaseForSourceRecord(pkgSourceList *SrcList,
{
indexRecords records;
records.Load(path);
+ Dist = records.GetDist();
return records.GetSuite();
}
}
@@ -387,13 +388,15 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,pkgRecords &Recs,
// See if we need to look for a specific release tag
if (RelTag != "" && UserRequestedVerTag == "")
{
-const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
+string Dist;
+const string Rel = GetReleaseForSourceRecord(SrcList, Parse, Dist);
-if (Rel == RelTag)
+if (Rel == RelTag || Dist == RelTag)
{
Last = Parse;
Offset = Parse->Offset();
Version = Ver;
+ break;
}
}
Re: "PIE by default" transition is underway -- wiki needs updating
Hi, On 25.10.2016 13:55, Guillem Jover wrote: > I don't think the reasoning there is sound (as I've mentioned > elsewhere), and the policy bug should be closed. > > Switching from no-PIE to PIE by default preserves our current behavior > WRT static libraries vs shared libraries. The current policy says: "As to the static libraries, the common case is not to have relocatable code" As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler enables PIE by default, which means it produces relocatable code. This should definitely be updated to reflect reality. > For many static libraries, > making them embeddable into other shared libraries is really not > desirable. And those should be using the shared libraries instead. If that's the reason why it shouldn't be done, policy should mention it. The current policy does not list this as reason not to use -fPIC, merely: "since there is no benefit" > I still think the current policy is fine, and if someone wants to build > a static library with PIC it should be brought up here. The current ffmpeg packages builds shared and static libraries, the latter because they are used in the test suite. Both are built from the same object files compiled with -fPIC. Do you really think those static libraries should not be included in the binary lib*-dev packages just because they are not incompatible with including in other shared libraries? Best regards, Andreas
Re: Bug#837478: "PIE by default" transition is underway -- wiki needs updating
Hi, On 26.10.2016 05:26, Guillem Jover wrote: > On Wed, 2016-10-26 at 00:37:18 +0200, Andreas Cadhalpun wrote: >> On 25.10.2016 13:55, Guillem Jover wrote: >>> For many static libraries, >>> making them embeddable into other shared libraries is really not >>> desirable. And those should be using the shared libraries instead. >> >> If that's the reason why it shouldn't be done, policy should mention it. >> The current policy does not list this as reason not to use -fPIC, merely: >> "since there is no benefit" > > I don't think it's "the reason", but personally I think it's one > important reason. If there are more, they could be mentioned in policy, too. > Embedding static libraries into shared libraries can be very > problematic if the shared libraries do not take precautions, such as > explicit symbol visibility or symbol versioning, etc. Which most > shared libraries do not do. And even then it's still prone to symbol > conflicts, etc, even inside the shared library being linked itself in > case of namespace issues, if the static library is sloppy. A (possibly shortened) version of this paragraph would be a good addition to the policy. :) > So I think this should be in general discouraged. > >>> I still think the current policy is fine, and if someone wants to build >>> a static library with PIC it should be brought up here. >> >> The current ffmpeg packages builds shared and static libraries, the >> latter because they are used in the test suite. Both are built from >> the same object files compiled with -fPIC. >> Do you really think those static libraries should not be included >> in the binary lib*-dev packages just because they are not incompatible >> with including in other shared libraries? > > Well, I guess depends on how "clean" they are, what's the intended > usage, etc. But given that in this case the usage is inside the same > project, that seems pretty safe! There might be some confusion here. The ffmpeg package uses these static libraries only for build-time testing, so doesn't need to have them included in the binary packages. I don't know if anyone is using these shipped static libraries. > I'd personally probably not ship them, > and would instead provide non-PIC ones there. Or at most ship them in > addition as _pic.a libraries, to require explicit invocation. I'd rather not built everything twice, so I think I'll just drop the static libraries in the next upload and only worry about this again, when/if someone files a bug about missing the static libraries. Best regards, Andreas
Re: "PIE by default" transition is underway -- wiki needs updating
Hi, On 26.10.2016 05:37, Adam Borowski wrote: > What's your reason for building something as big and with as extensive > dependencies statically? Some parts of the test suite use private functions not exposed in the shared libraries, so they need the static libraries. > Let's delegate static libraries to special needs only, as limited as possible. Yeah, I'll just not include the static libraries in the lib*-dev packages anymore. Best regards, Andreas
Re: apt-get source linux behaves weird
Control: tag -1 patch
Hi David,
On 15.08.2015 13:40, David Kalnischkies wrote:
> Control: tag -1 - patch
>
>> @@ -387,13 +388,15 @@ static pkgSrcRecords::Parser *FindSrc(const char
>> *Name,pkgRecords &Recs,
>> // See if we need to look for a specific release tag
>> if (RelTag != "" && UserRequestedVerTag == "")
>> {
>> -const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
>> +string Dist;
>> +const string Rel = GetReleaseForSourceRecord(SrcList, Parse,
>> Dist);
>>
>> -if (Rel == RelTag)
>> +if (Rel == RelTag || Dist == RelTag)
>> {
>
> In the experimental git branch this changed completely as Release files
> have risen from the underground to be proper first class citizens (while
> Sources are still second class at best) where this was fixed by
> "accident" already in a seemingly "unrelated" commit (5ad0096a4) by me.
Since that has finally reached sid, I had another look at this bug.
>> Last = Parse;
>> Offset = Parse->Offset();
>> Version = Ver;
>> + break;
>> }
>> }
>>
>
> That 'fixes' this problem while reopening #731853 among others. Running
> the autopkgtest tests would have shown it. You can do this without
> building and installing apt packages via ./test/integration/run-tests,
> which will use the apt buildtree it is in. You need to install a bunch
> of additional test-dependencies through.
Thanks for pointing to the autopkgtests. However, some tests fail with:
"You have to build aptwerbserver or install a webserver"
But there is no aptwe*r*bserver...
One has to do:
$ cd test/interactive-helper
$ make aptwebserver
> Adding a testcase here (they are simple shell scripts with an insane
> amount of shell functions building a testing 'framework' to setup
> packages, repositories and webservers among others) wouldn't hurt the
> acceptance of a patch either.
How sane can a framework be if it has to generate packages that are "used
only by testcases and surf [...]", even though there are no waves? ;)
The relevant testcases are in test/integration/test-apt-get-source.
There is a test for #731853 that is supposed to "ensure that apt will
pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
However, this works by pure chance, as simply reversing the order
of the two insertsource lines makes the test fail.
So #731853 isn't really fixed, yet.
Actually, that's related to the problem I reported, as the underlying
issue for both is the same:
In the FindSrc function apt chooses a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or the version of the package is higher than the last best hit.
Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
in this order.
Looking for the version in stable, apt first selects 1.0, because the
release matches the target release, but then subsequently selects 2.0,
because the version is higher.
Looking for the version in unstable, apt first selects 2.0, because the
release matches the target release, but then subsequently selects 1.5,
because the release also matches the target release.
The correct way would be to choose a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or there is no target release
and the version is higher than the last best hit.
Attached is a patch fixing this and another one adding above two
testcases.
Best regards,
Andreas
--- a/apt-private/private-source.cc
+++ b/apt-private/private-source.cc
@@ -288,6 +288,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
while ((Parse = SrcRecs.Find(Src.c_str(), MatchSrcOnly)) != 0)
{
const std::string Ver = Parse->Version();
+ bool CorrectRelTag = false;
// See if we need to look for a specific release tag
if (RelTag != "" && UserRequestedVerTag == "")
@@ -297,13 +298,10 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
{
if ((Rls->Archive != 0 && RelTag == Rls.Archive()) ||
(Rls->Codename != 0 && RelTag == Rls.Codename()))
- {
- Last = Parse;
- Offset = Parse->Offset();
- Version = Ver;
- }
+CorrectRelTag = true;
}
- }
+ } else
+CorrectRelTag = true;
// Ignore all versions which doesn't fit
if (VerTag.empty() == false &&
@@ -311,7 +309,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
continue;
// Newer version or an exact match? Save the hit
- if (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 0) {
+ if (CorrectRelTag && (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 0)) {
Last = Parse;
Offset = Parse->Offset();
Version = Ver;
--- a/test/integration/test-apt-get-source
+++ b/test/integration/test-apt-get-source
@@ -27,6 +27
Re: apt-get source linux behaves weird
On 29.11.2015 14:41, David Kalnischkies wrote: > On Sun, Nov 29, 2015 at 03:17:47AM +0100, Andreas Cadhalpun wrote: >> One has to do: >> $ cd test/interactive-helper >> $ make aptwebserver > > A simple 'make' in the top-level directory builds this webserver Indeed, but somehow 'debian/rules build-arch' doesn't. >> How sane can a framework be if it has to generate packages that are "used >> only by testcases and surf [...]", even though there are no waves? ;) > > You have never seen apt fail bigtime then. > That generates lots of waves… ;) I'm glad I haven't. ;) > And as a testrun doesn't show regressions… applied & pushed to git. Thanks. > Should be part of the next upload, which might or might not be soon > depending on how many RCs people find now to block our transition after > they had months in experimental to do it. ;) Apparently somebody found something... > Thanks for working on this! Thank you for apt 1.1, I like it. :-) Best regards, Andreas
Re: apt-get source linux behaves weird
On 29.11.2015 19:25, Josh Triplett wrote:
> Andreas Cadhalpun wrote:
>> The correct way would be to choose a new 'best hit', if either
>> * there is a target release and it matches the release of the package,
>> * or there is no target release
>> and the version is higher than the last best hit.
>
> Not quite; that would fail if you have "1.1 (stable)" and "1.0 (stable)"
> in that order. You want to choose the package under consideration as
> the new 'best hit' if it matches the target release (or no target
> release exists) *and* if it has a higher version than the last best hit.
That's what I (thought I) described.
> Looking at the code, it looks like you may have implemented that, rather
> than what you describe above. However, your comments don't match that,
> and your test case doesn't test for that:
>
>> @@ -311,7 +309,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
>> continue;
>>
>> // Newer version or an exact match? Save the hit
>
> This comment needs updating for the new algorithm. Something like:
> "Newer version (in the target release if any)? Save it."
Maybe.
>> -if (Last == 0 || Cache->VS().CmpVersion(Version,Ver) <
>> 0) {
>> +if (CorrectRelTag && (Last == 0 ||
>> Cache->VS().CmpVersion(Version,Ver) < 0)) {
>> Last = Parse;
>> Offset = Parse->Offset();
>> Version = Ver;
>
>> --- a/test/integration/test-apt-get-source
>> +++ b/test/integration/test-apt-get-source
>> @@ -27,6 +27,14 @@ insertsource 'stable' 'foo' 'all' '1.0'
>> insertsource 'wheezy' 'foo' 'all' '0.0.1'
>> insertsource 'wheezy' 'foo' 'all' '0.1'
>>
>> +# the order of these versions is choosen to ensure that
>
> s/choosen/chosen/
Indeed.
>> +# * apt will pick the one in the correct release, despite a higher version
>> coming later and
>> +# * apt will pick the highest version in a release, despite a lower version
>> coming later.
>> +# (bts #746412)
>> +insertsource 'stable' 'baz' 'all' '1.0'
>> +insertsource 'unstable' 'baz' 'all' '2.0'
>> +insertsource 'unstable' 'baz' 'all' '1.5'
>
> This test case doesn't ensure that apt picks the highest version in
> stable, rather than the last-mentioned version in stable.> For more
> robustness, I'd suggest:
>
> insertsource 'stable' 'baz' 'all' '0.1'
> insertsource 'stable' 'baz' 'all' '1.0'
> insertsource 'stable' 'baz' 'all' '0.5'
> insertsource 'unstable' 'baz' 'all' '1.4'
> insertsource 'unstable' 'baz' 'all' '2.0'
> insertsource 'unstable' 'baz' 'all' '1.5'
That'd be a bit redundant, but shouldn't hurt.
Best regards,
Andreas
