date:20150518

Quoting Alessandro Ghedini (2015-05-18 14:33:18)
 On Mon, May 18, 2015 at 11:15:04AM +0200, Jonas Smedegaard wrote:
 There are multiple ways to handle packages unsuitable for long-term 
 maintenance:
 
   * Treat as experimental - e.g. mpv

 How is mpv unsuitable for long-term maintainance?

Oh, I simply assumed that was the case, but since we have an expert on 
the matter (yourself) let's ask:

Why are some mpv packages targeted experimental rather than unstable, if 
not because those specific releases are treated (by you) as unsuitable 
for long-term maintenance?


   * Have security team treat as too unreliable - e.g. iceweasel

 We do provide security support for iceweasel. Where did you get the 
 idea that we don't?

 We don't backport fixes but just provide the latest stable release.

Oh, you are right: Indeed iceweasel is not flagged as unsupported.

I got warnings about libmozjs* and wrongly assumed it was used by 
iceweasel itself as well.  Apparently Iceweasel gets off the hook by 
staticly linking libmoxjs (and xulrunner, but that has other more 
complex reasons, I believe).

A proper example is netsurf-gtk (the one causing my confusion).


 The situation with ffmpeg is completely different though, because 
 ffmpeg upstream actually documents which patches fix what security 
 issue: http://ffmpeg.org/security.html

 Something that libav upstream doesn't do.

I am describing ways to handle packages unsuitable for long-term support 
here - not throwing mud between FFmpeg and Libav.  You remarks above 
seem unrelated to this subtopic of mine.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

2015-05-18 Thread Bálint Réczey

Hi Reinhard,

2015-05-18 12:16 GMT+02:00 Reinhard Tartler siret...@gmail.com:
...

  These days, FFmpeg for
  sure asks for most (if not all) CVE numbers recently assigned, and
  claims
  to provide patches for them.

 FFmpeg not only claims to provide patches, but actually does provide them:
 most CVEs link to the corresponding patch.

 In many many cases, the descriptions of the patches and the issues are
 sub-standard, in many cases even misleading. In no case that I looked at,
 the issue was immediately reproducible, because all of the referenced
 samples are held back and it is not easy at all the get access to them. And
 even if you do contact people via email and eventually are provided the
 samples, reproducing the issue remains very challenging.

 I stopped looking actively at them when I repeatedly came to the conclusion
 that the issue can only be seen when seen when used in the test harnish that
 Google uses for testing libavcodec within chrome.
Thank you for for sharing this. This matches my perception as well and
if it is true Libav project should have stopped claiming being able to
provide security support for Libav long time ago. They can blame
others for not giving them full info about the issues, but that does
not close the CVE-s.
The situation made me remove libav from almost all systems I use.

Thanks,
Balint

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

On Sun, May 17, 2015 at 10:53:37PM +0200, Jonas Smedegaard wrote:
 Quoting Alessandro Ghedini (2015-05-17 21:58:15)
  The issues mentioned in the page were hardly wide ranging. One was 
  about the fact that libav doesn't implement some video filters, which 
  forces mpv to carry its own implementations (still true). Another 
  about about libav HTTP support (most likely fixed but I'm not sure). 
  The other were all about subtitles.
  
  It's also true that the list wasn't really esaustive before it was 
  deleted. For example one time I tried to convert a part of a movie 
  into a GIF with mpv, before realizing that libav's GIF encoder is 
  completely broken (I actually tried to backport it from ffmpeg, before 
  giving up and switching to ffmpeg myself), but this wasn't mentioned 
  in the wiki.
 
 Oh.  Do I understand you correctly that neither wiki page nor README.md 
 file is really relevant,

How would they not be relevant? They recommend users to use ffmpeg and list
examples of problems they may encounter if they decide to use mpv with libav
(problems that are regularly reported as mpv bugs).

But my point was that they don't list all the problems, so trying to argue
that the problems listed aren't really that relevant is useless because it
doesn't take much to find other ones.

  Ok, so exotic subtitle formats is a particular reason for mpv authors 
  to favor FFmpeg over libav.
 
  Where did you get the exotic part?
 
 Sorry that I didn't clarify.  I wanted to avoid the misconception (among 
 those reading along but not themselves using mpv) that _all_ mpv 
 subtitle handling was broken with Libav (it certainly is not), and 
 assumed from my own experience that those missing were less common than 
 the ones supported in both of the libraries.

Ok, that makes sense.

  I've run into libav's lack of external vobsub files support several 
  times already. I've also seen broken PGS subtitles decoding in the 
  wild, even though I'm not really an avid watcher of BluRays.
 
  Several people also expressly asked me to provide mpv packages built 
  against ffmpeg. I suppose they had their own reasons.
 
 ...and you do build against ffmpeg.  Targeted experimental.  No doubt 
 those wanting it would prefer it being easier accessible than that, but 
 if their reason was just to be sure to have the most bleeding edge 
 possible then they'd never use our too boring stable release anyway.

You keep saying bleeding edge, but is proper support for features that are
documented as being supported but are in practice buggy or unusable considered
bleeding edge? What about users of Debian stable that run into libav bugs?
Should they use experimental too?

 We don't know their reasons, so can only speculate and that speculation 
 can go in any direction, not only towards ffmpeg is the better choice 
 for Debian.

That goes both ways. You can't assume people want to use ffmpeg just because
it's bleeding-edge either (your earlier proposal to have packages built with
ffmpeg in experimental, or that ffmpeg shouldn't receive security support sort
of implies that).

  It might be true that there is no major issue that makes libav 
  unusable for everyone,
 
 I never said that.
 
 My main concern is long-term maintainability.

(The following is sort of off-topic in respect to the point you were making,
sorry about that, but I'd like to understand your POV).

What does long-term maintainability even mean for you? What are the factors
that make something long-term maintanable and something else not in your opinion
and why is libav better in that regard?

As far as Debian stable is concerned the only relevant metric is security
support, simply because pretty much any other change will just be rejected by
the release team (unless it's for some really serious bug). And it's already
clear that libav just doesn't provide enough security coverage, so how can you
justify leaving Debian stable users open to security vulnerabilities and bugs
by keeping libav in stable and not ffmpeg (or by providing security support
for libav and not ffmpeg)?

  but there are a lot of somewhat minor issues that make libav unusable 
  for many different use-cases (e.g. see Fabian's earlier email). Which 
  is kinda sad IMO, considering that the needs of our users is supposed 
  to be one of Debian's main priorities.
 
 supposed to be? - are you somehow implying that you know the needs of 
 our users

I'm implying that users have been asking for what they need (ffmpeg) for a long
time, and Debian isn't providing it. And no just having packages using ffmpeg
in experimental is IMO not a solution (it's a PITA for both the maintainers and
the users).

 and I do not (or do and don't give a shit)?

Well, do you? You already made clear several times that your main concern is
this concept of long-term maintanability that no one else is apparently
sharing. That by itself implies that you rate what users have asked multiple
times over the years less important.

Re: Request to Join Project Debian Multimedia Maintainers from Fabian Greffrath (fabian)

2015-05-18 Thread Bálint Réczey

2015-05-18 14:29 GMT+02:00 Felipe Sateler fsate...@debian.org:
 On 18 May 2015 at 05:55, IOhannes m zmölnig (Debian/GNU)
 umlae...@debian.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 2015-05-18 10:04, nore...@alioth.debian.org wrote:

 Joining with my fab...@debian.org account.


 congratulations fabian, for becoming a DD!

 \o/

 This was long overdue! Congratulations!!
Welcome to the team again! :-)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

On Mon, May 18, 2015 at 11:15:04AM +0200, Jonas Smedegaard wrote:
 There are multiple ways to handle packages unsuitable for long-term 
 maintenance:
 
   * Treat as experimental - e.g. mpv

How is mpv unsuitable for long-term maintainance?

   * Have security team treat as too unreliable - e.g. iceweasel

We do provide security support for iceweasel. Where did you get the idea that
we don't?

We don't backport fixes but just provide the latest stable release.

The situation with ffmpeg is completely different though, because ffmpeg
upstream actually documents which patches fix what security issue:
http://ffmpeg.org/security.html

Something that libav upstream doesn't do.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

On lun, mag 18, 2015 at 01:47:25 +0100, Alessio Treglia wrote:
 Ciao Alessandro,
 
 and thanks for sharing your thoughts, it's genuinely appreciated.
 
 On Mon, May 18, 2015 at 1:26 PM, Alessandro Ghedini gh...@debian.org wrote:
  And it's already clear that libav just doesn't provide enough security 
  coverage,
 
 Can you please elaborate? AFAICS the versions in oldstable (0.8.17)
 and stable (11.3) are actively maintained upstream.
 Honestly that looks quite enough of security support.

The security tracker lists three vulnerabilities that don't have patches in
libav.git (but are fixed in ffmpeg in sid):
https://security-tracker.debian.org/tracker/source-package/libav

ffmpeg also provides a helpful security page that associates CVE ids with git
commits for easy cherry-picking (libav doesn't do this):
http://ffmpeg.org/security.html

Plus see what Moritz (from the Security team) said about ffmpeg security
responses (Andreas already mentioned this, but I think it's relevant here as
well):

 I think ffmpeg is doing better in terms of handling security issues; when
 I contacted Michael Niedermeyer in private we has always quick to reply,
 while libav-security@ seems understaffed: Several queries in the past needed
 additional poking, some were left unaddressed until today. Also, the Google 
 fuzzer guys stated that more samples are unfixed in libav compared to ffmpeg.

https://lists.debian.org/debian-devel/2014/08/msg00060.html

  I'm implying that users have been asking for what they need (ffmpeg) for a 
  long
  time, and Debian isn't providing it.
 
 Well, that is an alleged opinion, not fact. Conversely libav backers
 couldn't say that we are giving the users all what they really really
 want and need.
 So please let's all just refrain from taking this as we're 100% to
 have joined the battle on the right side ;)

Fair enough. I was trying to understand Jonas' point of view but I may have
been carried away at times, sorry about that everyone.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

Quoting Dmitry Smirnov (2015-05-17 03:28:28)
I also found an interesting comparison where mpv upstream shares
their assessment of the problem:

https://web.archive.org/web/20150115005029/https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

Quoting Alessandro Ghedini (2015-05-18 14:26:41)
On Sun, May 17, 2015 at 10:53:37PM +0200, Jonas Smedegaard wrote:
Quoting Alessandro Ghedini (2015-05-17 21:58:15)
The issues mentioned in the page were hardly wide ranging.
[...]
It's also true that the list wasn't really esaustive before it was
deleted.

Oh. Do I understand you correctly that neither wiki page nor
README.md file is really relevant,

How would they not be relevant? They recommend users to use ffmpeg and
list examples of problems they may encounter if they decide to use mpv
with libav (problems that are regularly reported as mpv bugs).

Because a) it is not a comparison (as Dmitry introduced it) but a
non-exhaustive list now shrunk to a single concrete item (subtitle
coverage) that you find wrong to focus on and instead bring a different
example of your own, and because b) it is not an assesment of *our*
problem but a different problem that can be solved by running a script
that recompiles against uptodate FFmpeg statically linked against mpv.

I've run into libav's lack of external vobsub files support several
times already. I've also seen broken PGS subtitles decoding in the
wild, even though I'm not really an avid watcher of BluRays.

Several people also expressly asked me to provide mpv packages built
against ffmpeg. I suppose they had their own reasons.

...and you do build against ffmpeg. Targeted experimental. No doubt
those wanting it would prefer it being easier accessible than that,
but if their reason was just to be sure to have the most [REDACTED]
possible then they'd never use our too boring stable release anyway.

You keep saying [REDACTED], but

Sorry for my use of strong language. I distinguish between boring and
exciting, and concretely above translated that into a likely real-world
phrase. I can see how I picked a term with negative connotations.
Please try imagine the word cool in its stead.

is proper support for features that are documented as being supported
but are in practice buggy or unusable considered bleeding edge? What
about users of Debian stable that run into libav bugs? Should they use
experimental too?

I get the feeling that you think I prefer that mpv linked against FFmpeg
should stay in experimental. I don't: Please read my later response to
IOhannes where I try clarify how I see multiple options, only one of
them being the current practice of mpv. Or maybe I misunderstood - if
so then please try rephrase your questions.

We don't know their reasons, so can only speculate and that
speculation can go in any direction, not only towards ffmpeg is the
better choice for Debian.

That goes both ways.

Yes. As I wrote: can go in any direction.

You can't assume people want to use ffmpeg just because it's
bleeding-edge either (your earlier proposal to have packages built
with ffmpeg in experimental, or that ffmpeg shouldn't receive security
support sort of implies that).

My main reason for considering FFmeg less boring, more exciting, than
Libav is its larger codebase and larger featureset:

Quoting Jonas Smedegaard (2015-05-15 11:13:31)
Quoting Reinhard Tartler (2015-05-15 09:23:13)
Also, given that Libav supports significantly less codecs and formats
(and in some cases specific variants or features of codecs), many
security issues simply don't apply.

I find above important, not only for security but for long-term
maintenance in general.

I consider FFmpeg not boring enough for shipping with stable Debian,
compared to Libav.

Maybe _neither_ Libav nor FFmpeg are boring enough for stable Debian,
security team has send a clear message that they do not have enough
resources to handle security-related bugs for both, which can be
addressed by either picking one to have security support or pick none.

It might be true that there is no major issue that makes libav
unusable for everyone,

I never said that.

My main concern is long-term maintainability.

(The following is sort of off-topic in respect to the point you were
making, sorry about that, but I'd like to understand your POV).

What does long-term maintainability even mean for you? What are the
factors that make something long-term maintanable and something else
not in your opinion and why is libav better in that regard?

As far as Debian stable is concerned the only relevant metric is
security support, simply because pretty much any other change will
just be rejected by the release team (unless it's for some really
serious bug).

Stable updates are generally security updates. But iceweasel and
Postgres got major upgrades in several Wheezy point releases.

A concern for Release team is also complexity

Processed: tagging 785141

Processing commands for cont...@bugs.debian.org:

 tags 785141 + unreproducible
Bug #785141 [inkscape] inkscape crashes when opening any files if there are 
strange items in the recent files list
Added tag(s) unreproducible.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
785141: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785141
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#758986: marked as done (inkscape: Inkscape crashes printing to Postscript from the command line)

Your message dated Mon, 18 May 2015 18:21:15 +0200
with message-id 20150518162115.GA5886@localhost
and subject line Re: Fixed upstream in 0.91
has caused the Debian Bug report #758986,
regarding inkscape: Inkscape crashes printing to Postscript from the command 
line
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
758986: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758986
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: inkscape
Version: 0.48.3.1-1.3
Severity: normal

Dear Maintainer,
Inkscape crashes while printing to a PostScript-file from the 
command line. It's a matter of the language-setting. This causes 
the crash:

borchert@grafix:~$ echo $LANG
de_DE.UTF-8

And this is the crash:

borchert@grafix:~/design/grafik/A6_Karten/0ruecken$ make all
inkscape -z -f ruecken.svg -T -P ruecken.ps
Entity: line 13: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xBB 0x53 0x75 0x6E
filetypetooltipDas Bildformat »Sun Raster Image«/filetypetooltip
^

** (inkscape:5121): CRITICAL **: Inkscape::Extension::Extension* 
Inkscape::Extension::build_from_reprdoc(Inkscape::XML::Document*, 
Inkscape::Extension::Implementation::Implementation*): assertion `doc != NULL' 
failed

Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
** Message: Error: Inkscape ist auf einen internen Fehler gestoßen und wird nun 
geschlossen.

make: *** [ruecken.ps] Speicherzugriffsfehler

Here is a workaround: use LANG=C to start inkscape from the
commandline and ist will work.

borchert@grafix:~/design/grafik/A6_Karten/0ruecken$ make all
LANG=C inkscape -z -f ruecken.svg -T -P ruecken.ps
pstops -pa4 
'4:0L@0.95(21.25cm,0.25cm)+0L@0.95(10.75cm,0.25cm)+0L@0.95(21.25cm,15.2cm)+0L@0.95(10.75cm,15.2cm)'
 ruecken.ps a6aufa4.ps
[1] Wrote 1 pages, 230102 bytes
ps2pdf  -sPAPERSIZE=a4 a6aufa4.ps ruecken.pdf
ps2eps -f -s 14.8x10.5cm ruecken.ps
Input files: ruecken.ps
Processing: ruecken.ps
Calculating Bounding Box...using page size 14.8x10.5cm...ready. %%BoundingBox: 
231 40 408 277
Creating output file ruecken.eps ... ready.
zip ruecken.zip * -x ruecken.zip  a6aufa4.ps
updating: Makefile (deflated 51%)
updating: index.html (deflated 55%)
updating: ruecken.pdf (deflated 2%)
updating: ruecken.ps (deflated 69%)
updating: ruecken.svg (deflated 69%)
updating: ruecken.eps (deflated 69%)



-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages inkscape depends on:
ii  gconf-service   3.2.5-1+build1
ii  libaspell15 0.60.7~20110707-1
ii  libatk1.0-0 2.4.0-2
ii  libatkmm-1.6-1  2.22.6-1
ii  libc6   2.13-38+deb7u3
ii  libcairo2   1.12.2-3
ii  libcairomm-1.0-11.10.0-1
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgc1c21:7.1-9.1
ii  libgcc1 1:4.7.2-5
ii  libgconf-2-43.2.5-1+build1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libglibmm-2.4-1c2a  2.32.1-1
ii  libgnomevfs2-0  1:2.24.4-2
ii  libgomp14.7.2-5
ii  libgsl0ldbl 1.15+dfsg.2-2
ii  libgtk2.0-0 2.24.10-2
ii  libgtkmm-2.4-1c2a   1:2.24.2-1
ii  libgtkspell02.0.16-1
ii  liblcms11.19.dfsg-1.2
ii  libmagick++58:6.7.7.10-5+deb7u3
ii  libmagickcore5  8:6.7.7.10-5+deb7u3
ii  libpango1.0-0   1.30.0-1
ii  libpangomm-1.4-12.28.4-1
ii  libpng12-0  1.2.49-1
ii  libpoppler-glib80.18.4-6
ii  libpoppler190.18.4-6
ii  libpopt01.16-7
ii  libsigc++-2.0-0c2a  2.2.10-0.2
ii  libstdc++6  4.7.2-5
ii  libwpd-0.9-90.9.4-3
ii  libwpg-0.2-20.2.1-1
ii  libx11-62:1.5.0-1+deb7u1
ii  libxml2 2.8.0+dfsg1-7+wheezy1
ii  libxslt1.1  1.1.26-14.1
ii  zlib1g  1:1.2.7.dfsg-13

Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-1
ii  imagemagick  8:6.7.7.10-5+deb7u3
ii  libwmf-bin   0.2.8.4-10.3
ii  perlmagick   8:6.7.7.10-5+deb7u3
ii  pstoedit 3.60-2+b1

Versions of packages inkscape suggests:
ii  dia  0.97.2-8
ii  libgnomevfs2-extra   1:2.24.4-2
ii  libsvg-perl  2.52-1
ii  libxml-xql-perl

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

On Sat, May 16, 2015 at 03:43:37PM +0200, Alessandro Ghedini wrote:
 On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
  On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
   On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
Version: 6:11.3-1

On 2015-05-14 20:41:15, Arne Wichmann wrote:
 Package: libavcodec56
 Version: 6:11.3-2
 Severity: grave
 Tags: security
 Justification: user security hole
 
 Hi, as far as I can see this has not yet been reported or fixed:
 
 CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
 in
 FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
 allow
 remote attackers to cause a denial of service (use-after-free) or 
 possibly
 have unspecified other impact via crafted Vorbis I data [1]
 
 I marked this as grave as the impact is unclear and might include 
 arbitrary
 code execution. Feel free do downgrade if this can be ruled out.
 
 (Actually I would like to have a look at the test case to check a bit 
 more
 thoroughly, but AFAICS I would need to talk to google for this.)
 
 [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
   
 https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html

A similar commit to the one maintained in this mailing list post was 
applied to
11.3. So closing with that version.
   
   Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
   patch at
   all, and the commit message doesn't even mention the bug fix. How can you 
   be so
   sure that the bug is fixed?
  
  I might have read the commit wrong. Do you have a sample for this CVE?
 
 Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
 it, I'll keep you posted.

I got the reproducer from ffmpeg and it seems that libav in sid isn't affected
like Sebastian said. So yeah, this bug should stay closed. I don't know if the
patch linked above is what fixed the issue though.

Cheers


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

2015-05-18 Thread Bálint Réczey

2015-05-18 17:50 GMT+02:00 Jonas Smedegaard d...@jones.dk:
...
 and I don't really understand why you are asking for explanation.

 I thought is was obvious from above that I merely bounced a question
 asked by Alessandro back to himself.
I suggest stopping that.

Define how you quantify long-term maintenance instead.

Thanks,
Balint

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

Quoting Bálint Réczey (2015-05-18 16:59:34)
 2015-05-18 16:45 GMT+02:00 Jonas Smedegaard d...@jones.dk:
 Quoting Alessandro Ghedini (2015-05-18 14:33:18)
 On Mon, May 18, 2015 at 11:15:04AM +0200, Jonas Smedegaard wrote:
 There are multiple ways to handle packages unsuitable for long-term 
 maintenance:

   * Treat as experimental - e.g. mpv

 How is mpv unsuitable for long-term maintainance?

 Oh, I simply assumed that was the case, but since we have an expert 
 on the matter (yourself) let's ask:

 Why are some mpv packages targeted experimental rather than unstable, 
 if not because those specific releases are treated (by you) as 
 unsuitable for long-term maintenance?
 I uploaded xbmc versions built with ffmpeg to experimental because 
 ffmpeg was not allowed to enter testing but I wanted to provide an 
 xbmc version to our users which has better security support and fewer 
 bugs.
 I could not upload it to unstable since unstable could not have two 
 versions of the package built from the same source and creating a new 
 xbmc-ffmpeg source package would have consume a lot of additional 
 mirror space which I wanted to avoid.
 This solution seems to be trivial and established for trying different 
 build dependencies among developers

Thanks for providing an alternative example, and elaborating on it.


 and I don't really understand why you are asking for explanation.

I thought is was obvious from above that I merely bounced a question 
asked by Alessandro back to himself.

 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Processed: severity of 785141 is normal

Processing commands for cont...@bugs.debian.org:

 severity 785141 normal
Bug #785141 [inkscape] inkscape crashes when opening any files if there are 
strange items in the recent files list
Severity set to 'normal' from 'important'
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
785141: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785141
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#731973: marked as done (inkscape presumably built against pre-stable libraries)

Your message dated Mon, 18 May 2015 18:39:09 +0200
with message-id 20150518163909.GA7476@localhost
and subject line Re: inkscape presumably built against pre-stable libraries
has caused the Debian Bug report #731973,
regarding inkscape presumably built against pre-stable libraries
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
731973: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731973
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: inkscape
Version: 0.48.3.1-1.3
Severity: important

Currently, inkscape is linked against older libraries (pretty much looks like 
the squeeze versions? They were all included in a backup of mine from a squeeze 
/usr). When you try to invoke inkscape, you initially get this message:
inkscape: error while loading shared libraries: libwpg-0.1.so.1: cannot open 
shared object file: No such file or directory

I manually tried to fix things a bit, and running into messages like this later 
on:
inkscape: error while loading shared libraries: libMagick++.so.3: cannot open 
shared object file: No such file or directory
inkscape: error while loading shared libraries: libpoppler.so.5: cannot open 
shared object file: No such file or directory

...it seems to me, this package was built against older libraries.

Plus:
When creating symlinks with the older name and linked to the current debian 
versions, inkscape at least launches fine. (Don't know if it'll run stable, 
though.)


-- System Information:
Debian Release: 7.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages inkscape depends on:
ii  gconf-service   3.2.5-1+build1
ii  libaspell15 0.60.7~20110707-1
ii  libatk1.0-0 2.4.0-2
ii  libatkmm-1.6-1  2.22.6-1
ii  libc6   2.13-38
ii  libcairo2   1.12.2-3
ii  libcairomm-1.0-11.10.0-1
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgc1c21:7.1-9.1
ii  libgcc1 1:4.7.2-5
ii  libgconf-2-43.2.5-1+build1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libglibmm-2.4-1c2a  2.32.1-1
ii  libgnomevfs2-0  1:2.24.4-2
ii  libgomp14.7.2-5
ii  libgsl0ldbl 1.15+dfsg.2-2
ii  libgtk2.0-0 2.24.10-2
ii  libgtkmm-2.4-1c2a   1:2.24.2-1
ii  libgtkspell02.0.16-1
ii  liblcms11.19.dfsg-1.2
ii  libmagick++58:6.7.7.10-5+deb7u2
ii  libmagickcore5  8:6.7.7.10-5+deb7u2
ii  libpango1.0-0   1.30.0-1
ii  libpangomm-1.4-12.28.4-1
ii  libpng12-0  1.2.49-1
ii  libpoppler-glib80.18.4-6
ii  libpoppler190.18.4-6
ii  libpopt01.16-7
ii  libsigc++-2.0-0c2a  2.2.10-0.2
ii  libstdc++6  4.7.2-5
ii  libwpd-0.9-90.9.4-3
ii  libwpg-0.2-20.2.1-1
ii  libx11-62:1.5.0-1+deb7u1
ii  libxml2 2.8.0+dfsg1-7+nmu2
ii  libxslt1.1  1.1.26-14.1
ii  zlib1g  1:1.2.7.dfsg-13


-- Versions of packages inkscape recommends:
ii  aspell   0.60.7~20110707-1
ii  imagemagick  8:6.7.7.10-5+deb7u2
ii  libwmf-bin   0.2.8.4-10.3
ii  perlmagick   8:6.7.7.10-5+deb7u2
ii  pstoedit 3.60-2+b1

-- Versions of packages inkscape suggests:
pn  dia | dia-gnome  none
ii  libgnomevfs2-extra   1:2.24.4-2
pn  libsvg-perl  none
pn  libxml-xql-perl  none
ii  python   2.7.3-4+deb7u1
ii  python-lxml  2.3.2-1
ii  python-numpy 1:1.6.2-1.2
pn  python-uniconvertor  none
ii  ruby 1:1.9.3
ii  ruby1.8 [ruby]   1.8.7.358-7.1+deb7u1
pn  skencil  none



-- 

Harald Pfeiffer

IT specialist (SI)
[ gnu/linux | web | linguistics ]

pgp:0xB24842CE
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xB24842CE /*(safety
IS possible)*/
add:harald.pfeiffer-æ-lirion.net
web:http://www.lirion.net

mail sent on debian wheezy gnu/linux, with thunderbird




signature.asc
Description: OpenPGP digital signature
---End Message---
---BeginMessage---
Version: 0.48.5-3

Hi!

On 2013-12-11 at 19:47 (CET), Harald Pfeiffer wrote:
 Currently, inkscape is linked against older libraries (pretty much looks like 
 the squeeze versions? They were all included in a backup of mine from a 
 squeeze /usr). When you try to invoke inkscape, you initially get this 
 message:
 inkscape: error while loading shared libraries: libwpg-0.1.so.1:

Re: [SCM] multimedia-blends/master: Fix errors from log add first RFP starting with H

2015-05-18 Thread Felipe Sateler

On 18 May 2015 at 15:49,  ross-gu...@users.alioth.debian.org wrote:
 The following commit has been merged in the master branch:
 commit 0c491f273939fc71808989727f71351be3893661
 Author: Ross Gammon rossgam...@mail.dk
 Date:   Mon May 18 20:48:23 2015 +0200

 Fix errors from log  add first RFP starting with H


Ross, I was thinking maybe we should do an upload of the metapackages
with all your changes? They have accumulated quite a bit.

-- 

Saludos,
Felipe Sateler

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

2015-05-18 Thread Sebastian Ramacher

On 2015-05-18 20:01:47, Alessandro Ghedini wrote:
 On Sat, May 16, 2015 at 03:43:37PM +0200, Alessandro Ghedini wrote:
  On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
   On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
 Version: 6:11.3-1
 
 On 2015-05-14 20:41:15, Arne Wichmann wrote:
  Package: libavcodec56
  Version: 6:11.3-2
  Severity: grave
  Tags: security
  Justification: user security hole
  
  Hi, as far as I can see this has not yet been reported or fixed:
  
  CVE-2014-7937 : Multiple off-by-one errors in 
  libavcodec/vorbisdec.c in
  FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
  allow
  remote attackers to cause a denial of service (use-after-free) or 
  possibly
  have unspecified other impact via crafted Vorbis I data [1]
  
  I marked this as grave as the impact is unclear and might include 
  arbitrary
  code execution. Feel free do downgrade if this can be ruled out.
  
  (Actually I would like to have a look at the test case to check a 
  bit more
  thoroughly, but AFAICS I would need to talk to google for this.)
  
  [1] https://security-tracker.debian.org/tracker/CVE-2014-7937

  https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
 
 A similar commit to the one maintained in this mailing list post was 
 applied to
 11.3. So closing with that version.

Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
patch at
all, and the commit message doesn't even mention the bug fix. How can 
you be so
sure that the bug is fixed?
   
   I might have read the commit wrong. Do you have a sample for this CVE?
  
  Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
  it, I'll keep you posted.
 
 I got the reproducer from ffmpeg and it seems that libav in sid isn't affected
 like Sebastian said. So yeah, this bug should stay closed. I don't know if the
 patch linked above is what fixed the issue though.

Great!
-- 
Sebastian Ramacher


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

2015-05-18 Thread Andreas Cadhalpun

Hi Reinhard,

On 18.05.2015 12:16, Reinhard Tartler wrote:
 Please excuse my previous unfinished reply, it was sent in accident.

No problem, such things can happen.

 I'm not sure if this post really adds to this discussion, please
 consider it as clarifications to my previous post.

I find it much better than getting no reply, so thanks for following up.

 On May 15, 2015 4:56 PM, Andreas Cadhalpun
  I think security is not a decisive topic where either project cannot
  clearly claim of having a clearly better handle.

 I disagree: FFmpeg is clearly better at fixing security issues.
 To take a random example, an out of bounds read in the bink decoder was fixed
 in FFmpeg three years ago [1], while Libav git master is still vulnerable
 today.

 One can find more such examples, but I have better things to do with my time.
 
 I think this attitude demonstrates a clear problem.

The clear problem that I see is that Libav upstream seems not to care very much
about fixing such things. This also discourages bug reporters.

 Instead of properly describing the issue through the appropriate channels,
 posts like this draw a bad picture by providing anectodal references of issues
 that may or may not affect Libav.

Anyone looking at the patch and the surrounding code (like where similar error
messages Copy out of bounds appear) can see that this problem does affect 
Libav.

 The right thing to do would be file a bugreport that collects references and
 information what the problem is and how to verify the fix, but this is not
 how this fight is fought apparently.

You yourself admitted that the Libav bug tracking system is currently
dysfunctional [a].
So why bother reporting problems, if they won't get fixed anyway?
I already mentioned Libav bug 840 [10], that has a sample and a command line 
crashing
Libav, but no reply since 6 weeks, while the same issue was fixed in FFmpeg 
very fast
(trac ticket #4431 [9]).

 But the issue is even more serious: Despite having the cleaner code-base, 
 which
 compared to FFmpeg is much more accessible and easier to work with,

What do you mean with cleaner code-base?
I imagine it is a matter of taste.

 there are a significant number of very vocal developers that argue that 
 FFmpeg was
 better in every thinkable way.

That's because this is mostly true. At least I haven't seen much evidence
contradicting it.

 Despite several calls for help, people have shown very little response such 
 has
 pointing to specific patches and backporting/cherry picking missing 
 functionality.
 There have been a handful of instances where this worked out though!

That's not very surprising, because that'd be duplicating work...

 In many many cases, the descriptions of the patches and the issues are 
 sub-standard,
 in many cases even misleading. In no case that I looked at, the issue was 
 immediately
 reproducible, because all of the referenced samples are held back and it is 
 not easy
 at all the get access to them. And even if you do contact people via email and
 eventually are provided the samples, reproducing the issue remains very 
 challenging.

Understanding the bink issue I mentioned above is not that challenging. 
Reproducing it
is a bit more difficult, but I can send you a sample if you can't create one 
yourself.
(However, I think that one doesn't need to have a sample to fix this issue, 
because
the problem is quite obvious and thus it really should have been fixed three 
years
ago in Libav as well.)

 I stopped looking actively at them when I repeatedly came to the conclusion 
 that the
 issue can only be seen when seen when used in the test harnish that Google 
 uses for
 testing libavcodec within chrome.

That might be the case for some (I don't know), but clearly not for all.
So not even looking at the patches is quite a bad idea.

  they (of course) also share their samples with both Michael (FFmpeg) and
  Luca/Anton (Libav). Michael seems to have much more capacity and time, and
  thus is usually faster with pushing patches for such crashers.

 Yes, Michael does an awesome job at fixing those [2].
 
 He does an awesome job at producing patches that only a handful of people on 
 this
 planet are capable of assessing what's going on. I cannot tell if he is 
 obfuscating
 them on purpose, most likely this is rather the way he thinks and works on 
 the issues:
 The work of a genius that takes a genius to understand.

How is the patch for the bink issue difficult to understand?

 To me, this constitutes a serious bus-factor: Without Michael, (probably) 
 nobody is
 able to replace him.

Michael is the most active FFmpeg developer, but even without him FFmpeg would 
have
more manpower than Libav currently does (not counting that Libav changes get 
merged
into FFmpeg).
So even without Michael FFmpeg would probably do better than Libav does today.

 On the other hand, in such a scenario we wouldn't have the forks competing 
 with
 each other either.

How can you know?

 Interestingly

Bug#785650: mpv will not launch

2015-05-18 Thread Norman Ramsey

Package: mpv
Version: 0.6.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

I wanted to play a video.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

At a shell prompt, I typed /usr/bin/mpv followed by a filename.

   * What was the outcome of this action?

I got this error message in red text:

mpv was compiled and linked against a mixture of Libav and FFmpeg versions. 
This won't work and will most likely crash at some point. Exiting.

   * What outcome did you expect instead?

I expected the video to start playing.

I get the same failure no matter what video I try to play.

-- System Information:
Debian Release: 8.0
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mpv depends on:
ii  libasound2  1.0.28-1
ii  libass5 0.10.2-3
ii  libavcodec5610:2.5.4-dmo1
ii  libavdevice55   6:11.3-1
ii  libavfilter56:11.3-1
ii  libavformat56   10:2.5.4-dmo1
ii  libavresample2  10:2.5.4-dmo1
ii  libavutil54 10:2.5.4-dmo1
ii  libbluray1  2:0.7.0-dmo1
ii  libbs2b03.1.0+dfsg-2.1
ii  libc6   2.19-18
ii  libcdio-cdda1   0.83-4.2
ii  libcdio-paranoia1   0.83-4.2
ii  libcdio13   0.83-4.2
ii  libdvdnav4  5.0.1-1
ii  libdvdread4 5.0.0-1
ii  libegl1-mesa [libegl1-x11]  10.3.2-1
ii  libenca01.16-1
ii  libgl1-mesa-glx [libgl1]10.3.2-1
ii  libguess1   1.2-1
ii  libjack-jackd2-0 [libjack-0.116]1.9.10+20140719git3eb0ae6a~dfsg-2
ii  libjpeg62-turbo 1:1.3.1-12
ii  liblcms2-2  2.6-3+b3
ii  liblircclient0  0.9.0~pre1-1.2
ii  liblua5.2-0 5.2.3-1.1
ii  libmpg123-0 1.20.1-2
ii  libpulse0   5.0-13
ii  libquvi70.4.1-3
ii  libsdl2-2.0-0   2.0.2+dfsg1-6
ii  libswscale3 10:2.5.4-dmo1
ii  libuuid12.25.2-6
ii  libva-glx1  1.4.1-1
ii  libva-x11-1 1.4.1-1
ii  libva1  1.4.1-1
ii  libvdpau1   0.8-3
ii  libwayland-client0  1.6.0-2
ii  libwayland-cursor0  1.6.0-2
ii  libwayland-egl1-mesa [libwayland-egl1]  10.3.2-1
ii  libx11-62:1.6.2-3
ii  libxext62:1.3.3-1
ii  libxinerama12:1.1.3-1+b1
ii  libxkbcommon0   0.4.3-2
ii  libxrandr2  2:1.4.2-1+b1
ii  libxss1 1:1.2.2-1
ii  libxv1  2:1.0.10-1+b1
ii  zlib1g  1:1.2.8.dfsg-2+b1

mpv recommends no packages.

mpv suggests no packages.

-- no debconf information

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

ffms2_2.21-1_amd64.changes is NEW

2015-05-18 Thread Debian FTP Masters

binary:libffms2-4 is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will recieve an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Processing of ffms2_2.21-1_amd64.changes

2015-05-18 Thread Debian FTP Masters

ffms2_2.21-1_amd64.changes uploaded successfully to localhost
along with the files:
  ffms2_2.21-1.dsc
  ffms2_2.21.orig.tar.gz
  ffms2_2.21-1.debian.tar.xz
  ffmsindex_2.21-1_amd64.deb
  libffms2-4_2.21-1_amd64.deb
  libffms2-dev_2.21-1_amd64.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] multimedia-blends/master: Fix errors from log add first RFP starting with H

2015-05-18 Thread Ross Gammon

On 05/18/2015 08:52 PM, Felipe Sateler wrote:
 On 18 May 2015 at 15:49,  ross-gu...@users.alioth.debian.org wrote:
 The following commit has been merged in the master branch:
 commit 0c491f273939fc71808989727f71351be3893661
 Author: Ross Gammon rossgam...@mail.dk
 Date:   Mon May 18 20:48:23 2015 +0200

 Fix errors from log  add first RFP starting with H
 
 
 Ross, I was thinking maybe we should do an upload of the metapackages
 with all your changes? They have accumulated quite a bit.
 

Yes - At the moment I am going through all the RFPs. But these are not
needed for the metapackages, only for the website.

I will read up on the process.



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: [SCM] multimedia-blends/master: Fix errors from log add first RFP starting with H

2015-05-18 Thread Ross Gammon

On 05/18/2015 09:38 PM, Ross Gammon wrote:
 On 05/18/2015 08:52 PM, Felipe Sateler wrote:
 On 18 May 2015 at 15:49,  ross-gu...@users.alioth.debian.org wrote:
 The following commit has been merged in the master branch:
 commit 0c491f273939fc71808989727f71351be3893661
 Author: Ross Gammon rossgam...@mail.dk
 Date:   Mon May 18 20:48:23 2015 +0200

 Fix errors from log  add first RFP starting with H


 Ross, I was thinking maybe we should do an upload of the metapackages
 with all your changes? They have accumulated quite a bit.

 
 Yes - At the moment I am going through all the RFPs. But these are not
 needed for the metapackages, only for the website.
 
 I will read up on the process.

Okay - I have got the metapackages ready. Doing a make dist, unpacking
the tarball and building from there seems to work (which were the
instructions on the blends wiki).

I haven't tested installing any of them.

Have a look and let me know how to go on from here. I can build and
upload to mentors for sponsoring, or you can take direct from git.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

2015-05-18 Thread Reinhard Tartler

On May 15, 2015 4:56 PM, Andreas Cadhalpun 
andreas.cadhal...@googlemail.com wrote:

 Hi Reinhard,

 thanks for explaining your point of view here.

 On 15.05.2015 09:23, Reinhard Tartler wrote:
  Thanks for this insightful post, Dmitry,
 
  On Mon, May 11, 2015 at 5:44 AM, Dmitry Smirnov only...@debian.org
mailto:only...@debian.org wrote:
  On Sat, 9 May 2015 16:00:49 Andreas Cadhalpun wrote:
  What would you count as very compelling reasons if more features,
less bugs
   and better security support are not sufficient?
 
  More features is not necessary means less maintenance burden;
  Less bugs is not always means better software (it is a matter of how
upstream
  manages bugs);
  Quality of security support is something that remains to be seen.
 
  I think security is not a decisive topic where either project cannot
  clearly claim of having a clearly better handle.

 I disagree: FFmpeg is clearly better at fixing security issues.
 To take a random example, an out of bounds read in the bink decoder was
fixed
 in FFmpeg three years ago [1], while Libav git master is still vulnerable
 today.

 One can find more such examples, but I have better things to do with my
time.

I think this sea0¨˜j67

  These days, FFmpeg for
  sure asks for most (if not all) CVE numbers recently assigned, and
claims
  to provide patches for them.

 FFmpeg not only claims to provide patches, but actually does provide them:
 most CVEs link to the corresponding patch.

  What is less visible is what happens behind the scenes:
 
  Most of these issues originate from Google Guys that work on security
and
  conduct fuzzing tests on libavcodec/libavformat. Their main target is of
  course their own libavcodec/libavformat fork that they ship in Chrome,
but

 As far as I'm aware they use a git snapshot of FFmpeg that they update
 from time to time. They only change the build process to produce one
single
 libffmpegsumo library instead of libavcodec/libavformat/libavutil.

  they (of course) also share their samples with both Michael (FFmpeg) and
  Luca/Anton (Libav). Michael seems to have much more capacity and time,
and
  thus is usually faster with pushing patches for such crashers.

 Yes, Michael does an awesome job at fixing those [2].

  Libav takes
  the time to investigate, reproduce and understand those patches.

 That's a commendable idea, but if the result is that these patches
 don't get applied in a reasonable time frame, it's rather bad.

  Unfortunately, in the majority of cases, this is not trivial at all,
often
  because of terse (or even wrong) commit messages, or the fact that there
  are better places to fix a particular issue in the code.

 In that case it would probably help to ask the author of the patch.
 Did the Libav developers do that?

  Better usually
  means that more than a single instance of the issue is fixed.

 Can you give examples for this?

  Also, given that Libav supports significantly less codecs and formats
(and
  in some cases specific variants or features of codecs), many security
  issues simply don't apply.

 While it's true that some security issues only affect code not present in
 Libav, the majority of issues affect both projects (until they are fixed
in
 FFmpeg).
 Much of the additional code in FFmpeg poses nearly no security problem.
 For example, even if there was a potentially security relevant bug in one
 of the more than 100 additional filters in FFmpeg, it would be very hard
to
 exploit, since the filters generally have to be invoked manually.
 Only decoders/demuxers can be easily triggered automatically,
 e.g. by visiting a web site or opening a folder with images, for which
 thumbnails are created.
 Additionally it would be much easier to disable some rarely used features
 in Debian's FFmpeg than to enable desired features in Debian's Libav,
 when they are not present upstream.

  Libav could for sure do a much better job here by releasing faster. In
the
  past, I looked at doing new point releases about every 2-3 months, but
for
  family reasons, I wasn't able to keep that pace. Release frequency is
  clearly something that needs improvement. As far as for the release
  content, I am not aware of critical fixes being missed, so quality wise
I
  think we are good.

 You are wrong about the quality. Have a look at the bink example I gave
above.

  I have a feeling that Debian already became life support for libav.
  Ever since Debian chosen libav, ffmpeg remained alive and apparently
doing
  well without our help. I'm not too sure if libav would be able to stay
alive
  without Debian.
 
  That's an interesting take on the matter. I don't think it is accurate;
for
  instance OpenEmbedded or Gentoo also ship Libav (in favor of FFmpeg), so
  DebianUbuntu are clearly not alone.

 Interestingly Gentoo recently switched to FFmpeg by default [3] after
conducting
 a survey [4]. About 300 people participated in that survey and the outcome
 was rather clear:
 62%[ 189 ]I prefer

Re: Request to Join Project Debian Multimedia Maintainers from Fabian Greffrath (fabian)

2015-05-18 Thread Debian/GNU

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2015-05-18 10:04, nore...@alioth.debian.org wrote:
 
 Joining with my fab...@debian.org account.
 

congratulations fabian, for becoming a DD!


fgmsdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVWakBAAoJELZQGcR/ejb4AMUP/iCILZIZdffX2fxfIUIIjayr
21YPJUGl3KIBrqvbbTdAdIi+lGDUpb7sWgsQuWwIaSKLEyuxsx/WKg0WI7Rhvzif
38XOBwfN+Izjb+DCO4a/CnzKP5GuqhNYCHC6iUHagXYG5k4SoEwbpcewzyNWBDwK
SGHlkRKUO7RBKB0ZqKZw0yK3qcvOlwnbnVXCbB16oAi84pzI2Lj+Lu06CYBopPY/
/bgr4U4pVlScTdUAJfBm2uj9qrPvK5OimByGBjFeQCso+dXtFF6K9f8HjnLqUA23
SL3C0APc3DCMx+deEYGyBz2jI1KUcYWyFPAzr3YteWPQFZLXmdl71cxYckNM9Pcn
Mdmw1VR2l+pJT4edV2jivBbim0m/8SF52cyslUmN0pf0J5tOEifd+1/jKCwTxJZO
xQ8mAaXhdOyp19pweUVE+bSIB4g0CPYJM7iHN3RXbItlDmJSDS1OkF1ght+nP37h
SY90vkRij/5W12JYkxOe14jyK5kpdAL1A045br9tkDs2uSzRS9M7e3/WhFZQQTaG
zuXODNAvvMin1L1q08c/VnMP3Ka1wUPHG/MbGwBTZi4wJEtNt4Lxjx+n9WQ8OEgq
ARofz/CHfAyhUQRjs+BKTcrvtIqXZUiGE57MJ9yoGKJ9kRqWvJypaBFxtVe+wSOB
yJ8Fu06zERwrh1JFdJrz
=VMzI
-END PGP SIGNATURE-

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

Quoting IOhannes m zmölnig (Debian/GNU) (2015-05-18 09:36:51)
 On 2015-05-17 22:53, Jonas Smedegaard wrote:
 I use bleeding edge tools for some of my own work.  And I use FFmpeg 
 for some of that.  But I will continue to use bleeding edge tools for 
 that work - which renders it irrelevant for judging what is relevant 
 for long term maintenance in Debian.

 my personal situation is:
 - - i use Debian
 - - i (need to) use bleeding edge tools

 this obviously makes my a user of testing/sid (trying to avoid 
 experimental as i historically had some problems with that - and if 
 only is about stalling while fetching tons of Packages updates for the 
 one or two packages i actually use).

 so i can use bleeding edge tools whenever they enter sid, which means 
 that they probably will enter stable at some future time (any package 
 entering sid should reach stable somewhen; some don't, but that's not 
 how it *should* be).
 but if a package is unfit for stable due to un-existing long term 
 maintenance, it will never show up in sid :-(
 
 your suggestion with using experimental suggest a way to fix that 
 problem. however, i'm not sure whether the number of users going on 
 through the hazzle of enabling experimental would make up for the 
 additional maintenance burden.

Uhm, I examplified by mpv's use of experimental, but my proposal is more 
generally to distinguish between boring and exciting, and treat only the 
former as suitable for long-term maintenance.

There are multiple ways to handle packages unsuitable for long-term 
maintenance:

  * Treat as experimental - e.g. mpv
  * Flag as buggy - e.g. bitcoin
  * Have security team treat as too unreliable - e.g. iceweasel

Each way has its problems, either being cumbersome to reach without 
raising the risk of also accidentally pulling in other unrelated 
stowed-away-for-other-reasons package, or being too easy to install 
without warning about its own problematic nature (i.e. if not having 
package debian-security-support installed).

(It is far less risky nowadays to include experimental suite in APT, due 
to adjusted default scores for that suite.  But risk is still there.)

What I propose is to not wait for security team approval, but at first 
use methods of treating FFmpeg-linked packages as too exciting for 
stable which are possibe without security team coordination.


 - Jonas

-- 
 * Jonas Smedegaard - idealist  Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: Select provider of libav* libraries

2015-05-18 Thread Reinhard Tartler

Please excuse my previous unfinished reply, it was sent in accident.
I'm not sure if this post really adds to this discussion, please consider
it as clarifications to my previous post.

On May 15, 2015 4:56 PM, Andreas Cadhalpun
  I think security is not a decisive topic where either project cannot
  clearly claim of having a clearly better handle.

 I disagree: FFmpeg is clearly better at fixing security issues.
 To take a random example, an out of bounds read in the bink decoder was
fixed
 in FFmpeg three years ago [1], while Libav git master is still vulnerable
 today.

 One can find more such examples, but I have better things to do with my
time.

I think this attitude demonstrates a clear problem. Instead of properly
describing the issue through the appropriate channels, posts like this draw
a bad picture by providing anectodal references of issues that may or may
not affect Libav. The right thing to do would be file a bugreport that
collects references and information what the problem is and how to verify
the fix, but this is not how this fight is fought apparently.

But the issue is even more serious: Despite having the cleaner code-base,
which compared to FFmpeg is much more accessible and easier to work with,
there are a significant number of very vocal developers that argue that
FFmpeg was better in every thinkable way. Despite several calls for help,
people have shown very little response such has pointing to specific
patches and backporting/cherry picking missing functionality. There have
been a handful of instances where this worked out though!


  These days, FFmpeg for
  sure asks for most (if not all) CVE numbers recently assigned, and
claims
  to provide patches for them.

 FFmpeg not only claims to provide patches, but actually does provide them:
 most CVEs link to the corresponding patch.

In many many cases, the descriptions of the patches and the issues are
sub-standard, in many cases even misleading. In no case that I looked at,
the issue was immediately reproducible, because all of the referenced
samples are held back and it is not easy at all the get access to them. And
even if you do contact people via email and eventually are provided the
samples, reproducing the issue remains very challenging.

I stopped looking actively at them when I repeatedly came to the conclusion
that the issue can only be seen when seen when used in the test harnish
that Google uses for testing libavcodec within chrome.


  they (of course) also share their samples with both Michael (FFmpeg) and
  Luca/Anton (Libav). Michael seems to have much more capacity and time,
and
  thus is usually faster with pushing patches for such crashers.

 Yes, Michael does an awesome job at fixing those [2].

He does an awesome job at producing patches that only a handful of people
on this planet are capable of assessing what's going on. I cannot tell if
he is obfuscating them on purpose, most likely this is rather the way he
thinks and works on the issues: The work of a genius that takes a genius to
understand.

To me, this constitutes a serious bus-factor: Without Michael, (probably)
nobody is able to replace him. On the other hand, in such a scenario we
wouldn't have the forks competing with each other either.

 Interestingly Gentoo recently switched to FFmpeg by default [3] after
conducting
 a survey [4]. About 300 people participated in that survey and the outcome
 was rather clear:

It saddens me to see people organizing votes where people participate that
have no idea what they are voting about. How many of the 300 people that
participated have tried to cherry pick a fix to libavcodec, or can even
tell what the difference between libavcodec and libswscale is?

[...]
  I think the debate on the development methodology is the biggest
  disagreement between the two projects: FFmpeg insists on keeping its
  development velocity and allowing developers to get work done,
  compromising on maintainability and common understanding of the code
base
  in favor of more features.

 I don't think getting work done is bad, because if work (like bug fixes)
 doesn't get done, it is worse for maintainability.

  Libav on the other hand rather focuses on clean
  implementation and let's say better designed APIs.

 Let's say Libav focuses more on cosmetics like consistent indentation,
 use of spaces around brackets, a linear commit history and such.

Please refrain from polemics such as these insults. Not everyone on this
mailing list is as involved and familiar with both projects to clearly
identify such statements as what they are.

  This requires more work,
  which in effect significantly lowers the development velocity. For a
system
  integration job on the scale of Debian, less velocity seems more
appealing
  to me.

 Less velocity in fixing (security) issues seems everything but appealing.


It is true that manpower is a scarce resource, in particular for
volunteer-driven free software projects. In Debian, we are very aware of

Processed: your mail