Charles Plessy writes:
> 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
On 07/31/2014 02:59 PM, Jeroen Dekkers wrote:
> At Wed, 30 Jul 2014 22:17:43 -0700,
> tony mancill wrote:
>> I contacted the upstream author (on the cc: - hi Frank), and his concern
>> with the passphraseless key trigger mechanism is precisely that you
>> don't have a passphrase. The key is unprot
On Thu, Jul 31, 2014 at 05:10:40PM -0500, Mike Molina wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: debian-devel@lists.debian.org
> Owner: Miguel Molina
>
> * Package name: kalendas
> Version : 1.0.0
> Upstream Author : Miguel Molina
> * URL : https://gi
On Aug 01, Russ Allbery wrote:
> I personally don't have enough information to know why libav was chosen
> instead of FFmpeg, and the discussion on debian-devel so far has mostly
> come from FFmpeg advocates. So there's probably another side to the story
> that hasn't been stated here yet.
Proba
On Thu, 31 Jul 2014, Steve Langasek wrote:
> upstream conflict, but this is just wrong. There is *nothing* unethical
> about reusing the library names and sonames when forking. In fact, the
Besides, when changing APIs and breaking interaction with other
programs that rely on the original API.
Y
On Fri, Aug 01, 2014 at 01:50:26AM +0200, Pau Garcia i Quiles wrote:
> I'm all for forks but if you do a fork, at least you do it with ethics:
> different library names, sonames, etc.
I have nothing resembling an informed opinion on the libav vs. ffmpeg
upstream conflict, but this is just wrong.
Excerpts from Jeroen Dekkers's message of 2014-07-31 14:59:48 -0700:
> At Wed, 30 Jul 2014 22:17:43 -0700,
> tony mancill wrote:
> > I contacted the upstream author (on the cc: - hi Frank), and his concern
> > with the passphraseless key trigger mechanism is precisely that you
> > don't have a pass
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 600 (new: 10)
Total number of packages offered up for adoption: 137 (new: 1)
Total number of packages reques
On Fri, Aug 1, 2014 at 1:29 AM, Russ Allbery wrote:
> I personally don't have enough information to know why libav was chosen
> instead of FFmpeg, and the discussion on debian-devel so far has mostly
> come from FFmpeg advocates. So there's probably another side to the story
> that hasn't been
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
Pau Garcia i Quiles writes:
> So had the proposal been "hey, let's replace libav with ffmpeg", would
> you vote "yes" ? Only one library to maintain and review, and it happens
> to have good upstream support And replacing libav with ffmpeg is easy
> and the ffmpeg maintainer is committed to help
On Fri, Aug 1, 2014 at 12:41 AM, Russ Allbery wrote:
> How is it better to have libav, which does a lot less security
> > bugfixing, in?
>
> It's not.
>
> However, what was proposed was having *both* of them, not dropping libav
> in favor of FFmpeg.
>
So had the proposal been "hey, let's replace
Pau Garcia i Quiles writes:
> On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette wrote:
>> No FFmpeg security update is “minor”.
>> Almost each ffmpeg security bug is a code execution one. Almost each
>> and every one of them is hard to backport.
>> Those 10 security updates might represent mor
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Miguel Molina
* Package name: kalendas
Version : 1.0.0
Upstream Author : Miguel Molina
* URL : https://github.com/mikemolina/kalendas
* License : GPL v3
Programming Lang: Per
Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta
* Package name: ruby-json-spec
Version : 1.1.2
Upstream Author : Steve Richert
* URL : https://github.com/collectiveidea/json_spec
* License : MIT/X
Programming Lang: Ruby
Description : Ruby libra
At Wed, 30 Jul 2014 22:17:43 -0700,
tony mancill wrote:
> I contacted the upstream author (on the cc: - hi Frank), and his concern
> with the passphraseless key trigger mechanism is precisely that you
> don't have a passphrase. The key is unprotected and subject to
> theft/unauthorized use. This
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.
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 hund
> This is caused by this, change between the afforementioned versions,
> which is also not mentioned in the package's changelog:
^
Exactly! I cannot stress this further enough, please always document
_every_ change you make to the packaging i
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. Introducing ffmpeg in jessie (with or without dropping
libav)
Package: wnpp
Severity: wishlist
Owner: Simon Paillard
* Package name: rohc
Version : 1.7.0
Upstream Author : Didier Barvaux
* URL : http://rohc-lib.org/
* License : LGPL-2.1+
Programming Lang: C
Description : RObust Header Compression (ROHC) library
On Thu, Jul 31, 2014 at 9:54 PM, Josselin Mouette wrote:
> No FFmpeg security update is “minor”.
>
> Almost each ffmpeg security bug is a code execution one. Almost each and
> every one of them is hard to backport.
>
> Those 10 security updates might represent more work than 100 *really*
> minor
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.
> As far as I know there are hundreds of security updates (for all
> packages together) in the lifetime of a stable release. Co
On Thu, Jul 31, 2014 at 07:04:42PM +0200, Alexander Alemayhu wrote:
> > The name is bad too.
> > But this is just an RFP, so...
> Why is the name bad?
Too generic.
--
WBR, wRAR
signature.asc
Description: Digital signature
On Wed, Jul 30, 2014 at 05:35:18PM +0600, Andrey Rahmatullin wrote:
> The name is bad too.
> But this is just an RFP, so...
>
Why is the name bad?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Arc
El 28/07/14 a las 21:10, Bastian Blank escribió:
> On Mon, Jul 28, 2014 at 08:59:26PM +0200, Philipp Kern wrote:
> > I guess you could offer lib32bz2 as a transitional package on the 32bit
> > arch, depending on libbz2 of its own arch and vice versa for lib64?
>
> Since when does apt consider a:am
* Jakub Wilk , 2014-07-30, 22:26:
WARNING: The following packages cannot be authenticated!
apt-transport-https
Install these packages without verification? [y/N]
E: Some packages could not be authenticated
[...]
But if the authentication troubles are really related to the
HTTP->HTTPS switch, th
On Thu, Jul 31, 2014 at 09:57:36 +0200, Ondřej Surý wrote:
> On Sat, Jul 5, 2014, at 08:19, Andreas Tille wrote:
> > Hi Christoph,
> >
> > On Fri, Jul 04, 2014 at 11:04:33PM +0200, Christoph Berg wrote:
> > >
> > > https://qa.debian.org/cgi-bin/vcswatch
> >
> > Cool! I wonder whether you could
On Sat, Jul 5, 2014, at 08:19, Andreas Tille wrote:
> Hi Christoph,
>
> On Fri, Jul 04, 2014 at 11:04:33PM +0200, Christoph Berg wrote:
> >
> > https://qa.debian.org/cgi-bin/vcswatch
>
> Cool! I wonder whether you could add a field where you can seek for
> package maintainer address (since if I
29 matches
Mail list logo
