from:"Andreas Cadhalpun"


Hi Jonas,

On 09.08.2014 13:51, Jonas Smedegaard wrote:

Quoting Andreas Cadhalpun (2014-08-09 13:34:04)

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.


In my experience you need not wait for ftpmaster approval to issue
subsequent releases: When approving, they will simply approve the
subsequent releases as well.

If you don't release updates, you may risk that when ftpmaster finds
time to inspect your package they find flaws (which you knew about and
had prepared fixes for but did not in fact formally provide) - and you
get the package rejected and need to wait for _next_ window that they
find time to inspect it anew.


Thanks for warning me, as that would indeed be unfortunate, so I'm going 
to ask my sponsor to make a new upload.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e6139b.1050...@googlemail.com

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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e6072c.7040...@googlemail.com

Bug#735884: Review of debian/copyright for ocp-indent


Hi Johannes,

On 09.08.2014 08:33, Johannes Schauer wrote:

I noticed something else: when you added tests/passing/traverse.mli as being
licensed under AGPL-3, is it not necessary to paste the full text of the AGPL-3
because the AGPL cannot be found in /usr/share/common-licenses? I added the
text of the AGPL-3 to debian/copyright to fulfill policy § 12.5.


Of course!
It would be nice if lintian could warn about this problem... :D [1]


You can find the full diff of the changes in:
http://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/ocp-indent.git/commit/?id=3316070c3164a14926abd9fcba46b88b8419640c


Thanks for fixing this so fast.


I uploaded the fixed package to mentors and would probably need somebody to
upload it for me:

http://mentors.debian.net/debian/pool/main/o/ocp-indent/ocp-indent_1.4.1-2.dsc


Unfortunately I can't help you here, because I'm no DD.


Thank you for your help!


You're welcome.

Best regards,
Andreas


1: https://bugs.debian.org/757545


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e5dbb0.6040...@googlemail.com

Bug#686447: Review of debian/copyright for zfs-linux


Hi,

On 09.08.2014 02:33, Darik Horn wrote:

On Fri, Aug 8, 2014 at 7:21 PM, Andreas Cadhalpun
 wrote:


OK, it's fine to have them separated, but in that case shouldn't the
copyright of the default stanza match what the COPYRIGHT file says, or maybe
just add Sun Microsystems, Inc. to the default stanza?


Yes.


OK.


As you are the author of the man page in question here, do you agree to
license the file man/man1/splat.1 under a DFSG-free license, e.g. GPL-2+?


Yes, of course, according to the mainline project license.


I suspected that, but it's a bit unclear when looking at the man page 
itself. Therefore I suggest to either add the standard GPL boilerplate 
to the man page or, if you prefer, just remove the scary "All rights 
reserved.", so that one doesn't have to wonder if the project license 
really applies to this file.



I haven't reviewed the debian/copyright of zfs-linux fully yet, but attached
patch fixes some issues I already noticed:


Thanks, syntax changes will happen on your advice.


You're welcome.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e5d860.8030...@googlemail.com

Bug#686447: Review of debian/copyright for zfs-linux


Hi Darik,

On 09.08.2014 00:09, Darik Horn wrote:

On Fri, Aug 8, 2014 at 6:05 AM, Turbo Fredriksson  wrote:


This have already been accepted (I saw a 0.6.3 update being accepted into the
archive a couple of days ago).


How were the licensing and namespace concerns resolved?  After two
years of waiting, it would be nice to know the decision criteria for
such important management issues.


I think he was talking about SPL [1], not zfs-linux here.

As far as I know nothing has been resolved with respect to zfs-linux, yet.


On Fri, Aug 8, 2014 at 7:58 AM, Andreas Cadhalpun
 wrote:


This problem can be circumvented easily, by not listing every file with
different copyright as separate stanza, but instead aggregation all
copyright holders for files licensed under CDDL-1.0 into the first, general
stanza (which also would make debian/copyright a lot easier to
review/maintain, e.g. avoids duplicated stanzas etc.).


When I did this code audit, in part to satisfy Debian import
requirements, the debian/copyright file was intentionally broken out
like this to avoid ambiguity and ensure copyright pedigree.

This is important because the downstream Debian sources are often
disjoint or unmergeable from the upstream git repository -- as you
just noticed -- and because there was an upstream conversion from svn
to git that mangled some of the commit history.


OK, it's fine to have them separated, but in that case shouldn't the 
copyright of the default stanza match what the COPYRIGHT file says, or 
maybe just add Sun Microsystems, Inc. to the default stanza?



I have CCed the copyright holders of these man pages, to inform them that they 
have to license them under a DFSG-free license, or they won't be allowed into 
Debian main.


Why are you making this request?  Surely this is the responsibility of
the package maintainers to do this work and maintain an upstream
rapport.


I'm just trying to help here. Of course, it would have been better if 
the package maintainers had noticed this, but as it seems that a 
potentially not DFSG-free file made it into the Debian archive, it's now 
an issue that affects any Debian user.


As you are the author of the man page in question here, do you agree to 
license the file man/man1/splat.1 under a DFSG-free license, e.g. GPL-2+?



We haven't seen Aron Xu or Carlos Alberto Lopez Perez at the upstream
issue tracker or support lists in more than a year.  Conversely, Turbo
Fredriksson is active and should therefore be added to the primary
list of people with Debian FTP upload privileges.


I didn't know that. They are currently listed as the only uploaders of 
SPL, but as that package is team-maintained by the Debian ZFS on Linux 
maintainers, which Turbo is part of, I don't see a problem.


I haven't reviewed the debian/copyright of zfs-linux fully yet, but 
attached patch fixes some issues I already noticed:

 * changing Disclaimer: to Comment: as the first one is only meant for
   explanations, why a packages has to be in non-free
 * removing some stanzas for files not present in the repository
 * removing duplicated stanzas
 * converting the Source: field of 'Files: debian/*' to a comment, as
   the Source: field is only allowed in the header
 * adding the missing licenses for some files
 * adding the choice-of-venue of the CDDL to debian/copyright

Best regards,
Andreas


1: https://tracker.debian.org/pkg/spl-linux
diff --git a/debian/copyright b/debian/copyright
index e45253b..f1c656c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,7 +2,7 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: Native ZFS for Linux
 Upstream-Contact: Brian Behlendorf 
 Source: https://github.com/zfsonlinux/zfs/
-Disclaimer:
+Comment:
  This work was produced at the Lawrence Livermore National Laboratory
  (LLNL) under Contract No. DE-AC52-07NA27344 (Contract 44) between
  the U.S. Department of Energy (DOE) and Lawrence Livermore National
@@ -60,11 +60,6 @@ Copyright: Oracle
  Delphix
 License: CDDL-1.0
 
-Files: cmd/zfs/zfs_main.h
-Copyright: Oracle
- Nexenta Systems, Inc.
-License: CDDL-1.0
-
 Files: cmd/zfs/zfs_util.?
 Copyright: Oracle
 License: CDDL-1.0
@@ -116,37 +111,23 @@ Files: cmd/zvol_id/*
 Copyright: Fajar A. Nugraha.
 License: CDDL-1.0
 
-Files: config/config.guess
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/config.sub
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/depcomp
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/ltmain.sh
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/missing
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
 Files: debian/*
 Copyright: Darik Horn 
-Source: https://github.com/dajhorn/pkg-spl/
 License: GPL-2+
+Comment:
+ On Debian systems, the full text of the GNU General Public License
+ version 2 can be found in the fi

Bug#735884: Review of debian/copyright for ocp-indent


Hi Johannes,

On 08.08.2014 20:08, Johannes Schauer wrote:

Quoting Andreas Cadhalpun (2014-08-08 01:42:33)

In order to help the ftp-masters processing the NEW queue[1], I have
reviewed the debian/copyright file of ocp-indent following the
guidelines at [2].
For this task I obtained the sources from
https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/ocp-indent.git.


thanks a lot for taking time for this!


I'm trying to help here, because I'm also waiting for a package in the 
NEW queue to be processed.
If you want to return the favor, you can have a look at the 
debian/copyright of FFmpeg in:

https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/tree/


Attached patch fixes the issues I noticed.
The most important ones were that the licenses for some files were missing.
It is also important to note, that this debian/copyright file does not
reflect the headers in the individual source files, because a license
clarification was obtained from upstream. As it is difficult to notice
this, when reading debian/copyright, I added a comment at the beginning
with a link to the upstream clarification.


The diff is a bit hard to read because you moved section around so I'll
summarize the changes:

You introduced a default copyright for "INRIA", "Jun Furuse" and "OCamlPro"
where I tried to name files individually to match the different copyrights. For
example the only files that are copyright "INRIA" seem to be
src/approx_tokens.ml, src/approx_lexer.mll and src/approx_common.mli so I don't
see how "INRIA" can be in the default block.


There had been no general 'Files: *' stanza and some files (like 
Makefile etc.) had not been mentioned explicitly. Therefore I created 
the default stanza with the license mentioned in the LICENSE file.
To shorten debian/copyright I merged all the files under this license 
into this stanza, which thus mentions all copyright holders.
But if you prefer to list some of them, e.g. those with copyright INRIA, 
separately, that is also fine.



Additionally, different files in src/* seem to have different copyright holders
(either just "OCamlPro" as for src/indentConfig.mli or "Jun Furuse" and
"OCamlPro" for the other files). Also, different files there have different
copyright dates. Some files are copyright "2012-2013 OCamlPro" and others are
copyright "2013 OCamlPro". Your default match makes them all "2011-2013
OCamlPro".


Merging all the copyright holders and dates into the default stanza 
doesn't mean that all the files are copyrighted by all the listed 
copyright holders with the same dates, but rather that at least one of 
them is copyrighted by at least one of these copyright holders with one 
of the dates.


The copyright format specification makes it clear that whether to merge 
or not is just a matter of taste:
"Since the license of the manual pages is the same as the other files in 
the package, the last paragraph above could instead be combined with the 
first paragraph, listing both copyright statements in one Copyright 
field. Whether to combine paragraphs with the same license is left to 
the discretion of the author of the debian/copyright file." [a]



As you can see in the link you referenced where upstream clarified the
copyright stanzas [1], upstream agreed on these individual distinctions of
copyright holders and years as they were found in the original debian/copyright
files.

You also found that I did not include the files m4/ocaml.m4,
tests/passing/traverse.mli and configure in my initial debian/copyright. Thanks
for finding them and fixing this! :)


You're welcome.
By the way, I just notice that 'BSD-3-clause' should have been 
'BSD-3-Clause' (with capital C) as recommended by the copyright format 
specification.



On the other hand, configure and m4/ocaml.m4 are not used (or not supposed to
be used and I yet have to fix this) during build time and thus I could just
repack the source tarball and list them under Files-Excluded in
debian/copyright.


As these have rather permissive licenses, it wouldn't hurt to leave them 
and just document there existence in debian/copyright.

But if you prefer, it's also fine to remove them via Files-Excluded.

Best regards,
Andreas

a: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e553a5.9060...@googlemail.com

Bug#683746: Review of debian/copyright for rspamd


Hi Mikhail,

On 08.08.2014 23:38, Mikhail Gusarov wrote:

Thank you for your help. rspamd has moved to github (bitbucket repo is
stale. Vsevolod: hint-hint). Please have a look at up-to-date
debian/copyright here:
https://github.com/vstakhov/rspamd/blob/master/debian/copyright. I'll
go through it and see what needs updating, but if you could eyeball it
too, I'd be grateful.


Yes, Vsevolod already told me that and I merged my changes, see [1].

Best regards,
Andreas

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683746#93


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e54561.4070...@googlemail.com

Bug#683746: Review of debian/copyright for rspamd


Hi,

On 08.08.2014 15:07, Vsevolod Stakhov wrote:

On 08/08/14 00:42, Andreas Cadhalpun wrote:
I'm sorry to say, but bitbucket repository is absolutely outdated and
I've now closed it completely. The current repository is now on github:

https://github.com/vstakhov/rspamd

The debian/copyright file has been rewritten completely since bitbucket
version.


Ah, I see. Fortunately the copyright situation didn't change much, so I 
merged my changes into the rewritten copyright file and reviewed the 
differences between the bitbucket and github repositories.


This resulted in attached patch, which fixes minor issues, e.g. moving 
the general stanza to the beginning, adding some missing copyright 
holders, mentioning the files licensed under LGPL-2.1+ or in the public 
domain, correcting copyright years, changing license names to more 
standard ones (BSD-2-clause -> BSD-2-Clause, Apache 2.0 -> Apache-2.0), 
and removing the MIT license, which is actually a duplicate of the Expat 
license.


Best regards,
Andreas

diff --git a/debian/copyright b/debian/copyright
index c7c185a..a3911e0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,24 +2,34 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: rspamd
 Source: https://github.com/vstakhov/rspamd
 
+Files: *
+Copyright: 2008-2014 Vsevolod Stakhov 
+License: BSD-2-Clause
+
 Files: contrib/lgpl/*
-Copyright: 1999, 2000  Scott Wimer,
+Copyright: 1999 - 2000 Tom Tromey
+   2000,  2005 Red Hat, Inc.
+   2007Emmanuele Bassi  
+License: LGPL-2+
+
+Files: contrib/lgpl/gregex.*
+Copyright: 1999 - 2000 Scott Wimer
2004Matthias Clasen ,
2005 - 2007 Marco Barisione 
-License: LGPL-2+
+License: LGPL-2.1+
 
 Files: contrib/hiredis/*
-Copyright: 2009 - 2011 Salvatore Sanfilippo 
+Copyright: 2006 - 2011 Salvatore Sanfilippo 
2010 - 2011 Pieter Noordhuis 
-License: BSD-3-clause-Redis
+License: BSD-3-Clause-Redis
 
 Files: compat/queue.h
 Copyright: 1991, 1993 The Regents of the University of California.
-License: BSD-3-clause-RotUoC
+License: BSD-3-Clause-RotUoC
 
 Files: contrib/uthash/*
 Copyright: 2003-2013 Troy D. Hanson http://troydhanson.github.com/uthash/
-License: BSD-1-clause
+License: BSD-1-Clause
 
 Files: src/json/*
 Copyright: 2009 Petri Lehtinen 
@@ -27,40 +37,46 @@ License: Expat
 
 Files: conf/lua/regexp/*
 Copyright: 2000-2012 The Apache Software Foundation
-License: Apache 2.0
-
-Files: src/json/*
-Copyright: 2009 Petri Lehtinen 
-License: Expat
+License: Apache-2.0
 
 Files: contrib/http-parser/*
 Copyright: 2002-2014 Igor Sysoev 
Joyent, Inc. and other Node contributors
-License: MIT
+License: Expat
 
 Files: contrib/libottery/*
 Copyright: Nick Mathewson
 License: CC0
 
+Files: contrib/libottery/chacha_crovetz.c
+   contrib/libottery/chacha_merged.c
+Copyright: Ted Krovetz 
+   D. J. Bernstein
+License: public-domain
+
 Files: contrib/xxhash/xxhash.*
 Copyright: 2012-2013, Yann Collet.
 License: BSD-2-Clause
 
-Files: src/diff.c
+Files: src/libutil/diff.c
 Copyright: 2004 Michael B. Allen 
2010-2014 Vsevolod Stakhov 
-License: MIT
-
-Files: *
-Copyright: 2008-2013 Vsevolod Stakhov 
-License: BSD-2-clause
+License: Expat
 
 Files: debian/*
 Copyright: 2011-2012 Vsevolod Stakhov 
  2014 Mikhail Gusarov 
-License: BSD-2-clause
+License: BSD-2-Clause
+
+Files: src/cdb/cdb*
+Copyright: Michael Tokarev 
+License: public-domain
+ The code is in public domain, that is, you may do anything you want with it.
+Comment:
+ The exact meaning of "Public domain" mentioned in the file headers was taken from:
+ http://www.corpit.ru/mjt/tinycdb.html
 
-License: BSD-1-clause
+License: BSD-1-Clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
@@ -80,7 +96,7 @@ License: BSD-1-clause
  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  SUCH DAMAGE.
 
-License: BSD-2-clause
+License: BSD-2-Clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:
  .
@@ -103,7 +119,7 @@ License: BSD-2-clause
  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  SUCH DAMAGE.
 
-License: BSD-3-clause-RotUoC
+License: BSD-3-Clause-RotUoC
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
@@ -131,7 +147,7 @@ License: BSD-3-clause-RotUoC
  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  SUCH DAMAGE.
 
-License: BSD-3-clause-Redis
+License: BSD-3-Clause-Redis
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:
  .
@@ -198,7 +214,26 @@ License: LGPL-2+
  License version 2 c

Bug#686447: Review of debian/copyright for zfs-linux


On 08.08.2014 12:05, Turbo Fredriksson wrote:

On Aug 8, 2014, at 1:29 AM, Andreas Cadhalpun wrote:


For this task I obtained the sources from 
https://github.com/zfsonlinux/pkg-spl, branch master/ubuntu/precise, which 
seems to contain the most recent changes.


That is the code for the SPL (Solaris Porting Layer) that ZFS/ZoL depends on.


Oh, I mixed that up.


This have already been accepted (I saw a 0.6.3 update being accepted into the
archive a couple of days ago).


Probably it wasn't noticed, but man/man1/splat.1 still doesn't have a 
license. (The other manpage is not present in the Debian archive.)



Could you try/look at https://github.com/zfsonlinux/pkg-zfs instead?


Yes. I just had a brief look there and noticed that most files are 
licensed under CDDL-1.0, because a lot of code comes from OpenSolaris.


But the first stanza in debian/copyright is:
Files: *
Copyright: Lawrence Livermore National Security, LLC.
License: CDDL-1.0

This contradicts the COPYRIGHT file, which states:
"The majority of the code in the ZFS on Linux port comes from 
OpenSolaris which has been released under the terms of the CDDL open 
source license.

[...]
Files which do not originate from OpenSolaris are noted in the file 
header and attributed properly."


So if a file doesn't contain a license header, it should be assumed to 
come from OpenSolaris, not Lawrence Livermore National Security.


This problem can be circumvented easily, by not listing every file with 
different copyright as separate stanza, but instead aggregation all 
copyright holders for files licensed under CDDL-1.0 into the first, 
general stanza (which also would make debian/copyright a lot easier to 
review/maintain, e.g. avoids duplicated stanzas etc.).
If you don't object to this idea, I'm going to send you a patch changing 
this (and fixing any other issues I might find).



I'm going to take a closer look at the patch and see if I can apply it manually,
but as it is now, all but the first hunk fails.


If it helps, my patch is based on:
commit 3a4902645c227439c1adbc689ae23e8760bacd14
Author: Darik Horn 
Date:   Thu Jun 12 20:50:09 2014 -0400

Update changelog for 0.6.3-1~precise release

commit a076ccc517e5c2e052542b4c5595a6029ac3223a

But from a brief look at the package uploaded to Debian I noticed that 
some files are not present in the commit I looked at, while some other 
files are missing in the uploaded package...


(BTW the first hunk, i.e. the change from Disclaimer: to Comment: is 
necessary, because the copyright format reserves Disclaimer: "for 
non-free or contrib packages to state that they are not part of Debian 
and to explain why (see Debian Policy section 12.5).")


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e4bb74.4030...@googlemail.com

Bug#729203: 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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53e4116b.80...@googlemail.com

Bug#735884: Review of debian/copyright for ocp-indent


user debian-le...@lists.debian.org
usertags 735884 one-copyright-review
thanks

Hi,

ocp-indent has been waiting in the NEW queue for more than 5 months, 
which is rather long.


In order to help the ftp-masters processing the NEW queue[1], I have 
reviewed the debian/copyright file of ocp-indent following the 
guidelines at [2].
For this task I obtained the sources from 
https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/ocp-indent.git.


Attached patch fixes the issues I noticed.
The most important ones were that the licenses for some files were missing.
It is also important to note, that this debian/copyright file does not 
reflect the headers in the individual source files, because a license 
clarification was obtained from upstream. As it is difficult to notice 
this, when reading debian/copyright, I added a comment at the beginning 
with a link to the upstream clarification.


If these issues are fixed, ocp-indent will hopefully be available in the 
Debian archive soon.


Best regards,
Andreas

1: https://ftp-master.debian.org/new.html
2: https://wiki.debian.org/CopyrightReview
diff --git a/debian/copyright b/debian/copyright
index 8645e74..6fc01ca 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,38 +1,72 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: ocp-indent
 Source: http://www.typerex.org/ocp-indent.html
+Comment: The license situation was clarified upstream:
+ https://github.com/OCamlPro/ocp-indent/issues/115
 
-Files: src/approx_tokens.ml src/approx_lexer.mll
+Files: *
+Copyright: 1996-2011 INRIA
+   2011 Jun Furuse
+   2011-2013 OCamlPro
+License: LGPL-3 with OCaml-linking exception
+
+Files: m4/ocaml.m4
+Copyright: 2000-2005, Georges Mariano
+   2000-2005, Jean-Christophe FilliÃ¢tre
+   2000-2005, Olivier Andrieu
+   2009, Richard W.M. Jones
+   2009, Stefano Zacchiroli
+License: BSD-3-clause
+Comment:
+ The license information was retrieved from:
+ http://forge.ocamlcore.org/docman/view.php/69/53/ocaml.m4.html#license
+
+Files: src/approx_lexer.mll
+   src/approx_tokens.ml
 Copyright: 2011-2013 OCamlPro
1996-2011 INRIA
-License: QPL-1 + linking exception
+License: QPL-1 with OCaml-linking exception
 
-Files: src/indentBlock.ml*
-   src/indentMain.ml
-   src/nstream.ml*
-   src/pos.ml*
-   src/util.ml
-Copyright: 2011 Jun Furuse
-   2012-2013 OCamlPro
-License: LGPL-3 + linking exception
+Files: debian/*
+Copyright: 2014 Johannes Schauer 
+License: GPL-3+
 
-Files: src/indentArgs.ml*
-   src/indentConfig.ml
-Copyright: 2011 Jun Furuse
-   2013 OCamlPro
-License: LGPL-3 + linking exception
+Files: tests/passing/traverse.mli
+Copyright: 2011 MLstate
+License: AGPL-3
 
-Files: src/indentConfig.mli
-Copyright: 2013 OCamlPro
-License: LGPL-3 + linking exception
+Files: configure
+Copyright: 1992-1996, 1998-2012 Free Software Foundation, Inc.
+   2013 OcamlPro SAS
+License: permissive
 
-Files: src/indentPrinter.ml*
-Copyright: 2012-2013 OCamlPro
-License: LGPL-3 + linking exception
+License: permissive
+ This configure script is free software; the Free Software Foundation
+ gives unlimited permission to copy, distribute and modify it.
 
-Files: debian/*
-Copyright: 2014 Johannes Schauer 
-License: GPL-3+
+License: BSD-3-clause
+ Redistribution and use in source and binary forms, with or without modification,
+ are permitted provided that the following conditions are met:
+ .
+ * Redistributions of source code must retain the above copyright notice, this
+ list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * The names of the contributors may not be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ''AS IS'' AND ANY
+ EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY
+ DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 License: GPL-3+
  This program is free software: you can redistribute it and/or modify
@@ -52,7 +86,20 @@ License: GPL-3+
  License version 3 can be found in the file
  `/usr/share/common-licenses/GPL-3'.
 
-License: L

Bug#683746: Review of debian/copyright for rspamd


user debian-le...@lists.debian.org
usertags 683746 one-copyright-review
thanks

Hi,

rspamd has been waiting in the NEW queue for more than 4 months, which 
is rather long.


In order to help the ftp-masters processing the NEW queue[1], I have 
reviewed the debian/copyright file of rspamd following the guidelines at 
[2].
For this task I obtained the sources from 
https://bitbucket.org/vstakhov/rspamd/src.


Attached patch fixes the issues I noticed.
The most important ones were that the licenses for some files were missing.
Also note that the copyright format always considers the last matching 
expressions for Files: as the correct one.
So one can special case particular files after 'Files: *', but any 
Files: stanza before 'Files: *' gets ignored.


If these issues are fixed, rspamd will hopefully be available in the 
Debian archive soon.


Best regards,
Andreas

1: https://ftp-master.debian.org/new.html
2: https://wiki.debian.org/CopyrightReview
diff -r e0a967fb0b4e debian/copyright
--- a/debian/copyright	Wed Jan 29 17:35:59 2014 +
+++ b/debian/copyright	Fri Aug 08 00:52:16 2014 +0200
@@ -2,10 +2,37 @@
 Upstream-Name: rspamd
 Source: https://bitbucket.org/vstakhov/rspamd
 
+Files: *
+Copyright: 2008-2014 Vsevolod Stakhov 
+   2012-2013 Yann Collet.
+   2013  Dmitriy V. Reshetnikov
+License: BSD-2-Clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+ .
+ Redistributions of source code must retain the above copyright notice, this
+ list of conditions and the following disclaimer.
+ .
+ Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ SUCH DAMAGE.
+
 Files: contrib/lgpl/*
-Copyright: 1999, 2000  Scott Wimer,
-   2004Matthias Clasen ,
-   2005 - 2007 Marco Barisione 
+Copyright: 1999 - 2000 Tom Tromey
+   2000,  2005 Red Hat, Inc.
+   2007Emmanuele Bassi  
 License: LGPL-2+
  This program is free software; you can redistribute it
  and/or modify it under the terms of the GNU Library General Public
@@ -18,7 +45,7 @@
  warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
  PURPOSE.  See the GNU Library General Public License for more
  details.
- .
+Comment:
  You should have received a copy of the GNU Library General Public
  License along with this package; if not, write to the Free
  Software Foundation, Inc., 51 Franklin St, Fifth Floor,
@@ -28,10 +55,33 @@
  License version 2 can be found in the file
  `/usr/share/common-licenses/LGPL-2'.
 
+Files: contrib/lgpl/gregex.*
+Copyright: 1999 - 2000 Scott Wimer
+   2004Matthias Clasen ,
+   2005 - 2007 Marco Barisione 
+License: LGPL-2.1+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+ .
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ Lesser General Public License for more details.
+Comment:
+ You should have received a copy of the GNU Lesser General Public
+ License along with this library; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ .
+ On Debian systems, the full text of the GNU Library General Public
+ License version 2 can be found in the file
+ `/usr/share/common-licenses/LGPL-2.1'.
+
 Files: contrib/hiredis/*
-Copyright: 2009 - 2011 Salvatore Sanfilippo 
+Copyright: 2006 - 2011 Salvatore Sanfilippo 
2010 - 2011 Pieter Noordhuis 
-License: BSD-3-CLAUSE
+License: BSD-3-Clause
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions are met:
  .
@@ -59,7 +109,7 @@
 
 Files: compat/queue.h
 Copyright: 1991, 1993 The Regents of the University of Calif

Bug#686447: Review of debian/copyright for zfs-linux


Control: user debian-le...@lists.debian.org
Control: usertags -1 one-copyright-review

Hi,

zfs-linux has been waiting in the NEW queue for more than 11 months, 
which is rather long.


In order to help the ftp-masters processing the NEW queue[1], I have 
reviewed the debian/copyright file of zfs-linux following the process at 
[2].
For this task I obtained the sources from 
https://github.com/zfsonlinux/pkg-spl, branch master/ubuntu/precise, 
which seems to contain the most recent changes.


Attached patch fixes most of the issues I noticed.
The most important problem is, that the man pages (man/man1/splat.1, 
man/man5/spl-module-parameters.5) do not have a proper license, but 
contain "All rights reserved.".

Therefore it seems as if they were not DFSG-free.
I have CCed the copyright holders of these man pages, to inform them 
that they have to license them under a DFSG-free license, or they won't 
be allowed into Debian main.


If these issues are fixed, zfs-linux will hopefully be available in the 
Debian archive soon.


Best regards,
Andreas

1: https://ftp-master.debian.org/new.html
2: https://wiki.debian.org/CopyrightReview
diff --git a/debian/copyright b/debian/copyright
index 5f1e428..44470c7 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,7 +2,7 @@ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: Solaris Porting Layer for Linux
 Upstream-Contact: Brian Behlendorf 
 Source: https://github.com/zfsonlinux/zfs/
-Disclaimer:
+Comment:
  This work was produced at the Lawrence Livermore National Laboratory
  (LLNL) under Contract No. DE-AC52-07NA27344 (Contract 44) between
  the U.S. Department of Energy (DOE) and Lawrence Livermore National
@@ -26,96 +26,65 @@ Disclaimer:
  not be used for advertising or product endorsement purposes.
  
 Files: *
-Copyright: Lawrence Livermore National Security, LLC.
- The Regents of the University of California
-License: GPL-2+
-
-Files: config/config.guess
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/config.sub
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/deb.am
-Copyright: Lawrence Livermore National Security, LLC.
-License: GPL-2+
-
-Files: config/depcomp
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/install-sh
-Copyright: 1994 X Consortium
-License:
- Permission is hereby granted, free of charge, to any person obtaining a copy
- of this software and associated documentation files (the "Software"), to
- deal in the Software without restriction, including without limitation the
- rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
- sell copies of the Software, and to permit persons to whom the Software is
- furnished to do so, subject to the following conditions:
- .
- The above copyright notice and this permission notice shall be included in
- all copies or substantial portions of the Software.
+Copyright:
+ 2001-2007, The Regents of the University of California
+ 2007-2013, Lawrence Livermore National Security, LLC.
+ 2008-2010, Sun Microsystems, Inc.
+License: GPL-2+
+ The SPL is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the
+ Free Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
  .
- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
- X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
- AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
- TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ The SPL is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ for more details.
+Comment:
+ On Debian systems, the full text of the GNU General Public License
+ version 2 can be found in the file `/usr/share/common-licenses/GPL-2'.
  .
- Except as contained in this notice, the name of the X Consortium shall not
- be used in advertising or otherwise to promote the sale, use or other deal-
- ings in this Software without prior written authorization from the X Consor-
- tium.
-
-Files: config/ltmain.sh
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/missing
-Copyright: Free Software Foundation, Inc.
-License: GPL-2+
-
-Files: config/tgz.am
-Copyright: Lawrence Livermore National Security, LLC.
-License: GPL-2+
+ You should have received a copy of the GNU General Public License along
+ with the SPL. If not, see .
 
 Files: debian/*
-Copyright: Darik Horn 
-Source: https://github.com/dajhorn/pkg-spl/
+Copyright: 2011-2014, Darik H

Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-07-29 Thread Andreas Cadhalpun


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 (>=

Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-07-28 Thread Andreas Cadhalpun


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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d658ba.5090...@googlemail.com

Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-07-28 Thread Andreas Cadhalpun


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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d64f90.1020...@googlemail.com

Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-07-28 Thread Andreas Cadhalpun

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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d62f9a.7040...@googlemail.com

Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian

2014-07-27 Thread Andreas Cadhalpun


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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53d5a9d1@googlemail.com

Bug#729203: Reintroducing FFmpeg to Debian

2014-07-27 Thread Andreas Cadhalpun


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

Bug#729203: Still Not Uploaded

2014-07-03 Thread Andreas Cadhalpun


Hi David,

On 03.07.2014 15:46, David L. Craig wrote:

Having discovered this bug report and subsequently absorbing
it, I cloned the repository, built the debs, and installed
them into my primary Sid box.  Now I need to track the repo.


Thanks for testing the repository!
I hope the packages work well for you.


I didn't see why this package has still not been uploaded.
Perhaps I need to reread the report.


Actually, ffmpeg has been uploaded 2 months ago and since then is 
waiting in the NEW queue [1].
Now it has to be accepted by the FTP Team, which apparently can take a 
lot of time for such a large package.



Nonetheless, all the objections to the state of ffmpeg in
Debian remain unaddressed.  This is, to me, egregious.
Even if ffmpeg is the only project to be so abused by Debian,
that by itself is sufficient to discredit the distribution
as a whole.  The value-add of all the members of the team
can be rendered useless for some installations by the
handling of even one important component.  Having begun with
release 1.0^H1 so long ago, I may have arrived at the point
of looking elsewhere for my primary GNU/Linux distro.


If you wait a little bit longer, you'll be able to install ffmpeg from 
the official Debian repository.


Best regards,
Andreas

1: https://ftp-master.debian.org/new/ffmpeg_7:2.2.1-1.html


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b57dec.8070...@googlemail.com

Bug#750817: ITP: x265 -- x265 HEVC Encoder

2014-06-10 Thread Andreas Cadhalpun


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-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53975ba4.5000...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-05-06 Thread Andreas Cadhalpun


Hi,

On 04.05.2014 22:16, Cyborg Ethly Alpha {My Research Desk} wrote:

On one system, I have FFmpeg 2.x is installed side by side with Libav ;
The package listing from Synaptic shows;
libavcodec-extra-52


This is from version 0.5...


libavcodec-extra-53


...and this from version 0.8.


libavcodec55-ffmpeg

all installed.


If you want to compare FFmpeg with Libav, it would be better to compare 
FFmpeg 2.2 with Libav 10 (currently in Debian/experimental), as they are 
approximately from the same time. Otherwise the comparison won't be fair.



and I found;
ffmpeg-set-alternatives

A helper package to create and remove the alternatives for the ffmpeg.

The Debian alternatives system (man update-alternatives):

It is possible for several programs fulfilling the same or similar functions
to be installed on a single system  at the  same  time. For example,
many systems have several text editors installed at once. This gives
choice to the
users of a system, allowing each to use a different editor, if desired,
but makes it difficult  for  a  program  to make a good choice for an editor
to invoke if the user has not specified a particular preference.
Debian's  alternatives  system aims to solve this problem.


As far as I can tell, ffmpeg-set-alternatives is meant for the binaries 
ffmpeg, ffplay etc., because older versions of Libav created them.
Newer versions of Libav use avconv, avplay etc., so this package is not 
needed anymore.



The FFmpeg install is direct from the FFmpeg.org sute.
I'm replacing the network router this week. The week after, I plan to do
some screencasts on the system with FFmpeg 2.2 .
After that I need add two systems to the test bench to practice creating
deb files, and test them.
Once the deb file(s) are successfully tested, they will be uploaded to
the ppa.


I see.


All my systems are Kubuntu 13.10 . I use [synaptic] and [apt] removing
muon, pulseaudio & disabling [desktop effects]


Is there a particular reason why you don't upgrade to Kubuntu 14.04?

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53690dc2.5030...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-05-04 Thread Andreas Cadhalpun


Hi Niv,

On 04.05.2014 13:03, Niv Sardi wrote:

I haven't gotten the time to look more into this, and am now in a 25hrs
bus with limited internet access.


I see.


My rationale is this:
- I don't want to ofend the libav maintainers nor want them to go on a
+300 api bump.


I don't want to offend them as well, but I don't see, why they should 
have to make any API bump.



- I don't want anything breaking in debian because users pick our lib on
a package that was meant to link to libav and somehow breaks.


To prevent this, FFmpeg is compiled with the --enable-raise-major 
option, so that the FFmpeg SONAME is increased by 100. So no package 
that does not depend on the FFmpeg libraries will use them. (Except 
maybe, if you still use that library in 100 years, which I don't think 
anyone will do.)



If we keep the names as they are, on next dist-upgrade everybody
depending on libavblah will pull it. If we want that, we should go tech
ctte and take over Libav, but that wasn't the consensus.


No, a dist-upgrade will not upgrade libavcodec54 to libavcodec155, it 
will only install libavcodec155, if any package depends on it and only 
remove libavcodec54, if no package depends on it anymore.
And there is no problem at all, if libavcodec54 and libavcodec155 are 
installed in parallel, because the SONAME is different.



I wanted to see if we had an easy way to alter the soname so this lib is
seen as an alternative to the other one and if we can keep packaging in
line with policy. In the defect of such possibility, I feel we should
rename to libavblah-ffmpegSoname.


I think the easy way you are looking for is --enable-raise-major and 
this is already used.
And changing the name of the library will not change much, as these 
libraries usually only get installed as dependencies, so the user will 
not see the name. As this package would still include libavcodec.so.155, 
it will have the same (theoretical) problems in 100 years, when the 
Libav libavcodec SONAME reaches 155.


So I have the feeling that here is kind of a misunderstanding about the 
effect of changing the package name.
To be perfectly clear: libavcodec155 from FFmepg and libavcodec54 from 
Libav are co-installable and work fine, if both are installed. You can 
try this, by installing the ffmpeg package and the needed libraries.

This will not break any existing installed program.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53663082.50...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-05-04 Thread Andreas Cadhalpun


Hi Niv,

I'm wondering, whether I should rename the libraries to *-ffmpegNNN.
Do you still think I should?

Have you found any other things that could be improved in the FFmpeg 
packaging?


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/536613f4.8040...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-04-28 Thread Andreas Cadhalpun


Hi,

On 28.04.2014 03:17, Cyborg Ethly Alpha {My Research Desk} wrote:

I've been watching the discussion. I'll be test benching the differences
with FFmpeg and Libav (on the same system) through-out the year.


That's interesting. How do you intend to benchmark this?
Do you want to test the command-line utilities, or compile all 
reverse-dependencies of src:libav against FFmpeg, or something else?



I will
be setting up the experimental (nightly) FFmpeg ppa in launch pad some
time tonight (it's 9pm EST here) or tomorrow. Then I'll add an
experimental (stable).


I couldn't find any packages in your PPA [1]. Should there be any, or 
didn't you add them yet?



If Debian, and all other derivatives, intend to
stay a Linux OS, then there should be a solution for FFmpeg & Libav to
co-exist. I've done this with Gnome and KDE - I have a hybridized
desktop. I don't expect Debian or Canonical to do this. I expect it to
be purely a community/individual effort. If a Linux OS is truly Linux,
then it must be highly customizable.


This is what I'm working for.

Best regards,
Andreas


1: https://launchpad.net/~cyborg-alpha-nh4/+archive/ffmpeg-exp-nightly


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535ec7a1.8060...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-04-27 Thread Andreas Cadhalpun


Hi Niv,

thanks for reviewing.

On 27.04.2014 21:24, Niv Sardi wrote:

I took a little bit of time to review your packages today,
you overhall did a really good job, and your efforts to bring FFMPEG
into debian are very apreciated

that said, here are a couple of things I think we need to fix before
upload, but mainly:
* the libav{codec,device,format,...} packages seem to be conflicting
with the libav ones.

right now we have libavcodec53 in debian, if we are going to make a
libavcodec155 then in 100 libav version we're going to have a hard
problem to deal with.


Libav makes a new release about once per year.
So even if every time the SONAME of libavcodec increases, they will get 
to 155 in about 100 years...
While I sincerely hope that Debian still exists in 100 years, I think 
this is a mostly theoretical problem, because I doubt that it will be a 
problem to reuse a package name that had been used 100 years earlier.



I thought you wanted to package like the -dev ackage into libavcodec-ffmpegxx


(The development packages are different, because Libav already uses the 
name libavcodec-dev.)



if we're going to aim into having both libav and ffmpeg, we should be
good citizen to each other.


As I don't think that's a problem, I prefer to follow policy [1]:
"Normally, the run-time shared library and its SONAME symlink should be 
placed in a package named librarynamesoversion, where soversion is the 
version number in the SONAME of the shared library."


But if you still think, it would be better to call them *-ffmpegNNN, I 
could live with that.


Best regards,
Andreas


1: 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime



--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535d6331.40...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-04-26 Thread Andreas Cadhalpun


Hi Niv,

On 26.04.2014 21:02, Niv Sardi wrote:

I'm happy to sponsor the upload, but am a bit confused about what
Package to look at.


Thanks for the offer to sponsor this.
The packaging is in the following repository:
http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary

You can get a Debian source package e.g. with:
git clone git://anonscm.debian.org/collab-maint/ffmpeg.git
cd ffmpeg
git-buildpackage -us -uc -S


I'm currently out of Office for a few days, but should be able to look
into it next weekend.


That's fine.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535c049c.80...@googlemail.com

Bug#729203: Rebuild of possible FFmpeg reverse build-dependenciesa

2014-04-26 Thread Andreas Cadhalpun


Hi,

I have rebuilt the 111 reverse build-dependencies of src:libav currently 
in sid against FFmpeg, by replacing the Libav '-dev' dependencies with 
the appropriate FFmpeg '-ffmpeg-dev' dependencies.
67 of these packages build right away, 13 have a fixed version in 
experimental and 19 can be fixed with more or less trivial patches, 
mainly replacing CodecID with AVCodecID and the like.

Together these are about 89% of the reverse build-dependencies.
From the remaining 12 packages, 8 are RC buggy and probably won't be in 
jessie and 4 depend indirectly (via libopencv-highgui-dev) on Libav 
'-dev' packages, which conflict with the FFmpeg '-ffmpeg-dev' packages. 
Probably libopencv-highgui-dev shouldn't have these dependencies and 
thus I filed bug #745934 about it.


All in all I think it is time to finally get FFmpeg uploaded to the archive.
Unfortunately I haven't heard from Jonathan Dowland in a while, so I'm 
going to ask for a sponsor on debian-mentors.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535be995.4000...@googlemail.com

Bug#729203: FFmpeg in Ubuntu

2014-04-24 Thread Andreas Cadhalpun


Hi,

On 23.04.2014 23:08, Cyborg Ethly Alpha {My Research Desk} wrote:

I'm in the middle of clearing up some network issues (on my network).


It seems you're not the only one with network issues, as Thorsten Glaser 
seems to be temporarily unavailable:

Delivery to the following recipient has been delayed:

 t...@mirbsd.de
[...]
The error that the other server returned was:
451 Temporary failure, please try again later.


I've complied ffmpeg on the Debian fork Ubuntu, and have an account on
launchpad. I'm aiming  to bring FFmpeg there.


That's great. Have you used the packaging from the collab-maint 
repository [1]? If so, do you have any suggestions on how to improve it?


I think it is ready for an upload to experimental, but unfortunately 
Jonathan Dowland seems to be busy, as he hasn't done so yet.


Once it is in unstable, it will automatically migrate to Ubuntu, won't it?

Best regards,
Andreas


1: http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5358f234.7090...@googlemail.com

Bug#729203: Bug#728772: closed by Debian FTP Masters (Bug#732159: Removed package(s) from unstable)

2014-04-23 Thread Andreas Cadhalpun


On 21.04.2014 12:42, Thorsten Glaser wrote:

Debian Bug Tracking System dixit:


This is an automatic notification regarding your Bug report
which was filed against the src:mplayer package:

#728772: mplayer: FTBFS: The architecture of your CPU (UNKNOWN) is not supported

It has been closed by Debian FTP Masters .

[…]

as the package mplayer has just been removed from the Debian archive

[…]



  * ***   ***  *  
   **  *  ****   **   * *
  **   *  * *   ***  **  **   ***  **   ***
**  ** * **  ** **  ** ***** ***
 *  *** * ** ****  ***
**   ** * ** **  ***   ** ***
**   ** * ** ** * **** ***  ********
**   ** * ** ***   ***  *    ****   ***
**   ** * ** ** ** ****  **** ***
**   ** * ** ** ** ****  **
 **  ** * ** ** ** ****  *****
  ** *  * *  ** ** ****  ****
   ***  ***  *   ** ** ****  **
 ** **  * **  **  
      ****   ***   ** 
*
   *
  *
 *


You cannot s̲e̲r̲i̲o̲u̲s̲l̲y̲ remove mplayer from the archive?
You must be kidding. MPlayer2 was born dead and VLC
just doesn’t work most of the time and has a horrible UI.

Honestly, please bring mplayer+ffmpeg back!


We are already working on this, see the FFmpeg ITP [1].
I think Alexander Strasser managed to build a recent mplayer with these 
FFmpeg packages.


You're welcome to join the team and help getting FFmpeg uploaded to the 
archive. There is already a collab-maint repository [2].


Best regards,
Andreas


1: https://bugs.debian.org/729203
2: http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/535772a6.1030...@googlemail.com

Bug#729203: Intent to package FFmpeg

2014-04-17 Thread Andreas Cadhalpun


Hi Norbert,

On 27.03.2014 14:49, Norbert Preining wrote:

I tried to build in a clean cowbuilder on amd64, but it dies right
at the beginning after configure:
...
Creating config.mak, config.h, and doc/config.texi...
make[1]: Leaving directory `/tmp/buildd/ffmpeg-2.2'
debian/rules override_dh_auto_build-arch
make[1]: Entering directory `/tmp/buildd/ffmpeg-2.2'
faketime "Mon, 24 Mar 2014 18:56:11 +0100" dh_auto_build -a -- 
tools/qt-faststart
sem_open: Function not implemented
make[1]: *** [override_dh_auto_build-arch] Error 1
...


I found the cause of this:
The pbuilder in stable does not mount /run/shm, but the pbuilder in 
testing does, see Bug#700591 [1].


Best regards,
Andreas


1: https://bugs.debian.org/700591


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53503c0a.8090...@googlemail.com

Bug#729203: Intent to package FFmpeg

2014-03-27 Thread Andreas Cadhalpun


Hi Norbert,

On 27.03.2014 14:49, Norbert Preining wrote:

On Thu, 27 Mar 2014, Andreas Cadhalpun wrote:

I updated my packaging to FFmpeg 2.2 and was finally able to push it
to the collab-maint repository [1].


I tried to build in a clean cowbuilder on amd64, but it dies right
at the beginning after configure:
...
Creating config.mak, config.h, and doc/config.texi...
make[1]: Leaving directory `/tmp/buildd/ffmpeg-2.2'
debian/rules override_dh_auto_build-arch
make[1]: Entering directory `/tmp/buildd/ffmpeg-2.2'
faketime "Mon, 24 Mar 2014 18:56:11 +0100" dh_auto_build -a -- 
tools/qt-faststart
sem_open: Function not implemented
make[1]: *** [override_dh_auto_build-arch] Error 1


Strange, as it builds fine with pbuilder.

I just tried a jessie/amd64 chroot with cowbuilder and it builds fine 
for me.

Does your cowbuilder mount /run/shm? Mine does:
I: mounting /run/shm filesystem

This might be the cause for 'sem_open: Function not implemented'.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5334372f.7080...@googlemail.com

Bug#729203: Intent to package FFmpeg

2014-03-27 Thread Andreas Cadhalpun


Hi Jonathan,

I updated my packaging to FFmpeg 2.2 and was finally able to push it to 
the collab-maint repository [1].


Please review and test this. When we are satisfied with it, you could 
upload it to experimental.


Best regards,
Andreas


1: http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary
   git clone git://anonscm.debian.org/collab-maint/ffmpeg.git


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533422d5.2080...@googlemail.com

Bug#729203: Intent to package FFmpeg

2014-03-23 Thread Andreas Cadhalpun


Hi,

On 22.03.2014 21:16, Cyborg Ethly Alpha {My Research Desk} wrote:

Thank you very much. I was thinking, that it might be a good idea to
have a second (back) repository, just in case. It would relieve pressure
on the primary repository and provide better up-time. While I currently
don't have a git server (and I would be willing to set one up). I do
have a launchpad account. [ https://launchpad.net/~cyborg-alpha-nh4 ] We
could provide source and binary packages from there - just as sunab ppa
(Olivier Banus) did for Kdenlive. I believe, I would set up an FFmpeg
project (under my ppa), and create a team (providing upload access). At
this point, we would not be building source - just providing a place to
serve it from.


Once I manage to push my packaging to the alioth repository you could 
simply clone that.



I have successfully build FFmpeg [ /ffmpeg version 2.2.git Copyright (c)
2000-2014 the FFmpeg developers//
//  built on Mar 13 2014 16:08:45 with gcc 4.8 (Ubuntu/Linaro
4.8.1-10ubuntu9) /] on Kubuntu 13.10 . However, there appears to be a
bug, that I'm trying to resolve.
[ ffmpeg -f alsa -ac 2 -i hw:2,0 -f x11grab -r 30 -s 1920x1080 -i :0.0
-acodec libmp3lame -ab 320k
/media/[username]/library-portable/video-studio/transfer-bin/BTSvlog03.avi ]
produces the error
[  [swscaler @ 0x9e81080] Warning: data is not aligned! This can lead to
a speedloss ]


I tried this with FFmpeg 2.1.4 and didn't get that warning, but the 
audio was out of sync. Without the '-r 30' option audio and video are in 
sync.

If this doesn't help you, try to ask upstream: ffmpeg-u...@ffmpeg.org

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532f13b1.8090...@googlemail.com

Bug#729203: Intent to package FFmpeg

2014-03-22 Thread Andreas Cadhalpun


Hi Daniel

On 21.03.2014 22:06, Cyborg Ethly Alpha {My Research Desk} wrote:

I'm interested in becoming a co-maintainer.


You are welcome to do so.
There is already a collab-maint git repository on alioth [1], but 
unfortunately some permissions are wrong, so I can't push my packaging 
to it. I hope one of the alioth maintainers will get around to fix this.


Best regards,
Andreas

1: http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/532d8039.8060...@googlemail.com

Bug#729203: Intent to package FFmpeg

2014-03-16 Thread Andreas Cadhalpun


Hi Jonathan,

unfortunately you haven't forwarded my and Alexander's request to join 
collab-maint to n...@debian.org. Thus we still don't have access to the 
repository you created.


Are you still interested in packaging FFmpeg for Debian?

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5325a8e3@googlemail.com

Bug#729203: Intent to package FFmpeg

Hi Jonathan,

thanks for your interest!

On 26.02.2014 21:17, Jonathan Dowland wrote:
> On Wed, Feb 26, 2014 at 01:39:23AM +, Clint Adams wrote:
>> Ideally someone should upload ffmpeg to unstable instead of
>> endlessly discussing it.  I don't see anyone preventing this
>> yet.
>
> Seconded. I felt that Moritz's last message (when it was the last
> message) was fine - let's get it into unstable, and /prove/ that
> security issues can be managed, by managing them. That will go a long
> way towards building trust in the ffmpeg-packaging-team (whoever that
> might be. Still to be resolved I guess) can handle it. It will also
> address the issue for a large chunk of Debian users, who use sid
> anyway.

Well, I think that Moritz is concerned about too many fixes going 
through stable-sec, which won't happen for a package in unstable.
But I guess, that if we show that it is well maintained in unstable, it 
doesn't hurt.

I intend to be in the packaging team and Alexander Strasser as well. 
Other co-maintainers are still welcome.

> And before someone actually uploads the thing - can we please get it
> into a git repo; clarify the team arrangements (collab-maint or set
> up a new one?); and can we reach an agreement on whether the first
> upload offers a binary ffmpeg package only (my preference), before we
> attempt to tackle the library co-installation (which might take a lot
> longer, require ftp master convincing etc.)

I would be fine with collab-maint and Alexander as well. If you create a 
repository, we could ask to be added and I could put my current 
packaging (imported via git-dsc-import) in there.

Of course, we can statically link the ffmpeg binaries (increases size by 
approximately factor 4), or move the libraries to /usr/lib/ffmpeg in a 
first phase.

On 26.02.2014 21:34, Jonathan Dowland wrote:

On Tue, Feb 25, 2014 at 05:43:25PM +0100, Andreas Cadhalpun wrote:

I intend to package and maintain FFmpeg for Debian. Co-maintainers
are welcome.

I am interested in co maintaining and can sponsor uploaders, as long
as the package is maintained in git and we aim to get an ffmpeg binary
into unstable before we try to tackle the library issues (i.e., as a
distinct, first phase, with an accepted upload).

It would be great to have you in the team.

Best regards,
Andreas

--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530e59cf.6020...@googlemail.com

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav


Hi Antoine,

On 26.02.2014 14:15, Antoine Beaupré wrote:

On 2014-02-26 04:56:02, Andreas Cadhalpun wrote:

At the moment I think Antoine is still reviewing my packaging before
sponsoring an upload.


This was a misunderstanding - I thought more work would be done on the
package first. :)


I think it would be good, if you could upload it to experimental now, 
because I would like to know, if FFmpeg builds on all architectures.
You could use the new upstream version 2.1.4 for this, simply by 
downloading the tarball [1] and changing the version in debian/changelog 
(trivial patch attached).



Is there a git repo or is there only the stuff you sent as an
attachment?


I have a local git repo created via git-import-dsc. It would probably be 
good to make this available somewhere.
But the debian.tar.xz and the upstream tarball should be enough to build 
the package with debuild.

If you need anything else, just ask.

By the way, Alexander Strasser from FFmpeg upstream has volunteered to 
co-maintain FFmpeg in Debian.


Best regards,
Andreas


1: https://ffmpeg.org/releases/ffmpeg-2.1.4.tar.gz
diff --cc debian/changelog
index e6697cc,000..4864cdd
@@@ -1,9 -1,0 +1,9 @@@
- ffmpeg (4:2.1.3-1) experimental; urgency=medium
++ffmpeg (4:2.1.4-1) experimental; urgency=medium
 +
 +  * Reintroduce FFmpeg to Debian. (Closes: #729203)
 +There are far to many changes since FFmpeg 0.5 to mention them here, see:
- https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=n2.1.3
++https://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=n2.1.4
 +Many security issues have been fixed as well, see:
 +https://ffmpeg.org/security.html
 +
-  -- Andreas Cadhalpun   Tue, 25 Feb 2014 11:03:38 +0100
++ -- Andreas Cadhalpun   Wed, 26 Feb 2014 15:30:25 +0100

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav


Hi Michael,

On 26.02.2014 02:44, Michael Gilbert wrote:

On Tue, Feb 25, 2014 at 8:39 PM, Michael Niedermayer wrote:

Id like to volunteer to help with any future security issues in
FFmpeg packages in debian.


The best place to start is testing and (more preferably) patches for
the present libav issues.  There are 18 of them:
https://security-tracker.debian.org/tracker/source-package/libav


Thanks for trying to make a constructive comment, but I'm not sure what 
you want Michael Niedermayer to do.

Quoting myself [0]:
"[...] I would be very interested in an explanation of the current state 
of the security tracker for libav [1], as *all* issues currently marked 
as open for libav are CVEs issued by FFmpeg about problems they fixed 
[2]. One, CVE-2011-3935, is even several years old *and* fixed for the 
FFmpeg in old-stable! I don't know whether to laugh or cry."


Maybe you thought it was a joke? It was not, just compare the CVE 
numbers on [1] and [2]. I don't know if these actually affect libav, but 
I guess they wouldn't be on the security tracker, if they didn't.
These CVEs are usually linked to the git commits that fix the problems, 
so there are already tested (in the sense that FFmpeg uses them) patches.


If you want Micheal Niedermayer to send these patches to libav upstream, 
I think you would have to convince them to remove some bans from their 
mailing lists. Good luck with that.


Best regards,
Andreas


0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#475
1: https://security-tracker.debian.org/tracker/source-package/libav
2: https://ffmpeg.org/security.html


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530dd576.6060...@googlemail.com

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav


Hi Clint,

On 26.02.2014 02:39, Clint Adams wrote:

On Tue, Feb 25, 2014 at 11:30:25PM +0100, Andreas Cadhalpun wrote:

Ideally the security team should now evaluate which of the two are
better from a security point of view and based on this decide, which
one they would prefer to see in jessie.
But if they don't, someone else will have to make this decision.


Ideally someone should upload ffmpeg to unstable instead of
endlessly discussing it.  I don't see anyone preventing this
yet.


Sorry, if I didn't make myself clear: Of course this discussion doesn't 
prevent an upload to unstable, but at some point this has to be 
discussed and I see no harm in starting such a discussion as early as 
possible.


At the moment I think Antoine is still reviewing my packaging before 
sponsoring an upload.


If you want to speed things up, you are very welcome to become a 
co-maintainer and upload as soon as you like.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530dba32.30...@googlemail.com

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav


On 25.02.2014 22:18, Yves-Alexis Perez wrote:

On Tue, Feb 25, 2014 at 06:23:20PM +0100, Andreas Cadhalpun wrote:

No, it means I don't have the time, nor nerve to discuss this. We're
after all busy to keep Debian secure and sick of maintainers who only
focus on their pet package and neglegt the overall maintainability
of the Debian archive.


While I always stated that I'm open to discussion, you just ended
the discussion after trying to block FFmpeg from entering Debian,
which I do not find very constructive.


My feeling is that this was discussed over and over and Moritz is
/slighly/ tired of repeating the same thing over and over. And me
replying to this mail doesn't mean I'm willing to engage in a large
thread on this, the security team position has been given.


My impression has been /slightly/ different: Moritz made dubious claims 
about FFmpeg:

"We've looked into many security issues
in ffmpeg which didn't affect libav, either because experimental
code wasn't merged yet or because code was rewritten in libav and not
affected. Also ffmpeg hasn't have long term branches which is a major
benefit of libav."

After I have questioned these, Moritz simply left the discussion. But 
maybe I didn't understand what Moritz wanted to say?



I want to see FFmpeg in Debian and I'm interested in any
constructive discussion about problems that might bring for others.
If you don't have time for such a discussion that is a pity.


Well, as it was already sated, the discussion needs to happen with libav
maintainers (and reverse dependencies indeed).


What do you think a discussion with them will gain?

Maybe it's not clear to everyone: Upstream FFmpeg and upstream libav are 
not exactly friendly towards each other. Furthermore some important 
developers of libav are among the Debian maintainers of libav.
Therefore I fear that any discussion with the libav maintainers about 
FFmpeg would likely end in a flamewar, which I tried to avoid.


Therefore I packaged FFmpeg in a way that doesn't conflict with libav, 
so that FFmpeg in Debian is neither a concern for the libav developers 
nor for anyone who wants to use libav, but that allows those, who need 
FFmpeg due to the additional features it provides, to use it.


But then the security team represented by Moritz stated that they would 
not support both FFmpeg and libav, so they are the only ones affected 
negatively by FFmpeg in stable. Thus I think it doesn't make much sense 
to discuss with anyone but the security team.


Ideally the security team should now evaluate which of the two are 
better from a security point of view and based on this decide, which one 
they would prefer to see in jessie.

But if they don't, someone else will have to make this decision.

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530d1981.1050...@googlemail.com

Bug#729203: Intent to package FFmpeg


On 25.02.2014 17:52, Antoine Beaupré wrote:

On 2014-02-25 11:43:25, Andreas Cadhalpun wrote:

Antoine, are you willing to sponsor this, maybe becoming a co-maintainer?


I am willing to sponsor an upload, but I don't have much time,
especially not to become a co-maintainer.


Thanks for sponsoring. If you detect any problems with the packaging or 
have any questions, just ask.



It also seems that I may not be perfectly qualified to handle all the
subtelties of this tricky package, so if someone else wants to step in,
that would be great.


The upstream developers are very helpful in solving any problem they can.


In the not too far future, the long term supported FFmpeg 2.2 will be
released, which I intend to get into jessie.


That would be awesome.


Yes. ;)

Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530cd223.9080...@googlemail.com

Bug#729203: Packaging for FFmpeg avoiding conflicts with libav


Hi Moritz,

On 25.02.2014 17:57, Moritz Mühlenhoff wrote:

On Sun, Feb 23, 2014 at 11:36:36PM +0100, Andreas Cadhalpun wrote:

Hi Moritz,

On 23.02.2014 22:56, Moritz Mühlenhoff wrote:

I don't have the time nor the interest to discuss this at length, so
EOD from my side.


since you started this discussion by effectively preventing FFmpeg
from being uploaded, I take it that you ending this discussion now
means FFmpeg can be uploaded and you prefer to "be working with the
release team to sort this out for jessie", after FFmpeg has reached
testing.


No, it means I don't have the time, nor nerve to discuss this. We're
after all busy to keep Debian secure and sick of maintainers who only
focus on their pet package and neglegt the overall maintainability
of the Debian archive.


While I always stated that I'm open to discussion, you just ended the 
discussion after trying to block FFmpeg from entering Debian, which I do 
not find very constructive.


Whether you believe it or not, my pet project is called Debian and I 
want to see the best possible software in it. You may have noticed that 
a lot of people are unhappy with the current situation of only having libav.


I tried to package FFmpeg in a way that has the smallest possible impact 
on the current Debian archive, i.e. as coinstallable with libav.



The security team made it abundantly clear that we will only support
either solution. If you go ahead with the ITP we'll file an RC bug
against ffmpeg to prevent it's transition to testing. You can then
sort out how/whether ffmpeg should _replace_ libav, but both are not
an option.


You can do however you like, but so can everyone else.

I want to see FFmpeg in Debian and I'm interested in any constructive 
discussion about problems that might bring for others. If you don't have 
time for such a discussion that is a pity.


Best regards,
Andreas


--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530cd188.30...@googlemail.com

Bug#729203: Intent to package FFmpeg