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
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
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 n
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 releas
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
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
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/testin
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
+
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 f
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
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
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
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
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.
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 s
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.ne
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
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 librar
jority 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 a
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
thei
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 ongo
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
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 rat
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
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
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
op
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
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
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.
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 poli
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
>>>
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 l
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 (RelT
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 webserv
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 ver
35 matches
Mail list logo
