[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#612341: libjpeg-turbo, getting it into wheezy



Hi,

(I had email problem ....resending ...)

On Wed, Jun 06, 2012 at 08:18:14AM +0200, Mike Gabriel wrote:
> Hi all,
> 
> it seems the discussion has come to an intermediary still point... I
> will pick up the thread then...
> 
> On So 03 Jun 2012 11:32:47 CEST Bill Allombert wrote:
> 
> >>Not getting what you mean exactly here. Can anything be done about
> >>it? Anything that we can do?
> >
> >I assume that Osamu refer to this line of the IJG license:
> >
> >(1) If any part of the source code for this software is
> >distributed, then this
> >README file must be included, with this copyright and no-warranty notice
> >unaltered; and any additions, deletions, or changes to the original files
> >must be clearly indicated in accompanying documentation.
> >
> >For example, when I released libjpeg 6b1, I added a file README.6b1
> >with the complete list of modified files (in attachment).
> >
> >(I am not especially fond of this requirement, but it is not really onerous).

Yes.  And also, some source codes are modified in the way which may look
like they were released by IJG while including libjpeg-turbo copyright
and names included.  For example: jpegtran.c

| /*
|  * jpegtran.c
|  *
|  * Copyright (C) 1995-2010, Thomas G. Lane, Guido Vollbeding.
|  * Copyright (C) 2010, D. R. Commander.
|  * This file is part of the Independent JPEG Group's software.
|  * For conditions of distribution and use, see the accompanying README file.
|  *
|  * This file contains a command-line user interface for JPEG transcoding.
|  * It is very similar to cjpeg.c, and partly to djpeg.c, but provides
|  * lossless transcoding between different JPEG file formats.  It also
|  * provides some lossless and sort-of-lossless transformations of JPEG data.
|  */

As I understand, D. R. Commander is not Independent JPEG Group.  This is a bit
ambiguous. (Since README is modified, this is not totally wrong but still
misleading.) I would add one line.

|  * This file ws part of the Independent JPEG Group's software.
|  * This file is adoped and modified for libjpeg-turbo.
|  * For conditions of distribution and use, see the accompanying README file.


> @Bill: Thanks for this extra info, this should be provided by
> libjpeg-turbo upstream and be re-modified by the Debian maintainers
> of libjpeg-turbo.

True to some extent.  Basically, when we package, we need to check all
licenses.  Especially for this type of software, its careful review is
strongly recommended for debian/copyright.  I think it is prudent send a
patch to upstream, if we can.

> Most important questions currently are:
> 
> 1. Is team maintenance wanted and ok (pkg-tigervnc team context).
> Fathi in the role of ITP holder, we need your statement here.

Please.  (Within few days since we are close to freeze.)
 
> 2. Is it ok to start working with:
> http://anonscm.debian.org/gitweb/?p=users/osamu/libjpeg-turbo.git;a=summary
> http://code.das-netzwerkteam.de/gitweb?p=debian/libjpeg-turbo.git;a=summary

I merged your changes.   Fathi, will you reset your collab-maint
archive.  So we can make better history and work together.

> 3. Who does what?

I can help routine simple works.  But one of you have to be the
maintainer. I can sponsor.

> 4. Communication channels (IRC, pkg-tigervnc-devel@l.a.d.o, Jabber?)

For now, good enough.  I do not do Jabber.
 
> 5. Who does review, sponsor, upload the work?

First, we still need to fix few things. Quick build and lintian found
some bugs and i fixed in my repo.  Please check.

I did not revert your change for debian/copyright.  But changing from
LGPL to GPL is not wise thing to do.  Did you consult previous
maintainer to get consent?  Also, I do not understand why debian/* was
marked as LGPL to start with while it contains patch to BSD upstream.
Cosidering situation, this may not cause much real problem but unusual.

I have not addressed following warnings.

W: libturbojpeg: shlib-without-versioned-soname usr/lib/x86_64-linux-gnu/libturbojpeg.so libturbojpeg.so
N: 
N:    The listed shared library in a public library directory has an SONAME
N:    that does not contain any versioning information, either after the .so
N:    or before it and set off by a hyphen. It cannot therefore be represented
N:    in the shlibs system, and if linked by binaries its interface cannot
N:    safely change. There is no backward-compatible way to migrate programs
N:    linked against it to a new ABI.
N:    
N:    Normally, this means the shared library is a private library for a
N:    particular application and is not meant for general use. Policy
N:    recommends that such libraries be installed in a subdirectory of
N:    /usr/lib rather than in a public shared library directory.
N:    
N:    To view the SONAME of a shared library, run readelf -d on the shared
N:    library and look for the tag of type SONAME.
N:    
N:    There are some special stub libraries or special-purpose shared objects
N:    for which an ABI version is not meaningful. If this is one of those
N:    cases, please add an override.
N:    
N:    Refer to Debian Policy Manual section 10.2 (Libraries) and Debian Policy
N:    Manual section 8.6 (Dependencies between the library and other packages
N:    - the shlibs system) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: shared-libs, Type: binary, udeb
N: 
I: libturbojpeg: no-symbols-control-file usr/lib/x86_64-linux-gnu/libturbojpeg.so
N: 
N:    Although the package includes a shared library, the package does not
N:    have a symbols control file.
N:    
N:    dpkg can use symbols files in order to generate more accurate library
N:    dependencies for applications, based on the symbols from the library
N:    that are actually used by the application.
N:    
N:    Refer to the dpkg-gensymbols(1) manual page and
N:    http://wiki.debian.org/UsingSymbolsFiles for details.
N:    
N:    Severity: wishlist, Certainty: certain
N:    
N:    Check: shared-libs, Type: binary, udeb
N: 
O: libjpeg-turbo8: package-name-doesnt-match-sonames libjpeg8
N: 
N:    The package name of a library package should usually reflect the soname
N:    of the included library. The package name can determined from the
N:    library file name with the following code snippet:
N:    
N:     $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//'
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: binaries, Type: binary, udeb
N: 
W: libjpeg-turbo8: shlibs-declares-dependency-on-other-package libjpeg8 (>= 8)
N: 
N:    This package declares in its shlibs control file either a dependency on
N:    some other package not listed in the Provides of this package or on a
N:    version of this package that the package version doesn't satisfy.
N:    
N:    Packages should normally only list in their shlibs control file the
N:    shared libraries included in that package, and therefore the
N:    dependencies listed there should normally be satisfied by either the
N:    package itself or one of its Provides.
N:    
N:    In unusual circumstances where it's necessary to declare more complex
N:    dependencies in the shlibs control file, please add a lintian override
N:    for this warning.
N:    
N:    Refer to Debian Policy Manual section 8.6 (Dependencies between the
N:    library and other packages - the shlibs system) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: shared-libs, Type: binary, udeb
N: 
O: libjpeg-turbo8: symbols-declares-dependency-on-other-package libjpeg8 #MINVER#
N: 
N:    This package declares in its symbols control file a dependency on some
N:    other package (and not one listed in the Provides of this package).
N:    
N:    Packages should normally only list in their symbols control file the
N:    shared libraries included in that package, and therefore the
N:    dependencies listed there should normally be satisfied by either the
N:    package itself or one of its Provides.
N:    
N:    In unusual circumstances where it's necessary to declare more complex
N:    dependencies in the symbols control file, please add a lintian override
N:    for this warning.
N:    
N:    Refer to Debian Policy Manual section 8.6 (Dependencies between the
N:    library and other packages - the shlibs system) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: shared-libs, Type: binary, udeb
N: 
I: libjpeg-turbo8: unused-override shlibs-declares-dependency-on-other-package libjpeg8 #MINVER#
N: 
N:    Lintian discovered an unused override entry in its database. Most likely
N:    it was used for a false-positive that has been fixed. However, some tags
N:    are only triggered in packages built on certain architectures. In this
N:    case, the override may need an architecture qualifier.
N:    
N:    If the override is unused, please remove it from the overrides file.
N:    
N:    Refer to Lintian User's Manual section 2.4.3 (Architecture specific
N:    overrides) for details.
N:    
N:    Severity: wishlist, Certainty: certain
N: 
W: libjpeg-turbo-test: binary-without-manpage usr/bin/tjunittest
N: 
N:    Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
N:    have a manual page
N:    
N:    Note that though the man program has the capability to check for several
N:    program names in the NAMES section, each of these programs should have
N:    its own manual page (a symbolic link to the appropriate manual page is
N:    sufficient) because other manual page viewers such as xman or tkman
N:    don't support this.
N:    
N:    If the name of the man page differs from the binary by case, man may be
N:    able to find it anyway; however, it is still best practice to make the
N:    case of the man page match the case of the binary.
N:    
N:    If the man pages are provided by another package on which this package
N:    depends, lintian may not be able to determine that man pages are
N:    available. In this case, after confirming that all binaries do have man
N:    pages after this package and its dependencies are installed, please add
N:    a lintian override.
N:    
N:    Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: manpages, Type: binary
N: 
W: libjpeg-turbo-progs: hardening-no-fortify-functions usr/bin/jpegexiforient
N: 
N:    This package provides an ELF binary that lacks the use of fortified libc
N:    functions. Either there are no potentially unfortified functions called
N:    by any routines, all unfortified calls have already been fully validated
N:    at compile-time, or the package was not built with the default Debian
N:    compiler flags defined by dpkg-buildflags. If built using
N:    dpkg-buildflags directly, be sure to import CPPFLAGS.
N:    
N:    NB: Due to false-positives, Lintian ignores some unprotected functions
N:    (e.g. memcpy).
N:    
N:    Refer to http://wiki.debian.org/Hardening and
N:    http://bugs.debian.org/673112 for details.
N:    
N:    Severity: normal, Certainty: possible
N:    
N:    Check: binaries, Type: binary, udeb
N: 
W: libjpeg-turbo-progs: hardening-no-relro usr/bin/jpegexiforient
N: 
N:    This package provides an ELF binary that lacks the "read-only
N:    relocation" link flag. This package was likely not built with the
N:    default Debian compiler flags defined by dpkg-buildflags. If built using
N:    dpkg-buildflags directly, be sure to import LDFLAGS.
N:    
N:    Refer to http://wiki.debian.org/Hardening for details.
N:    
N:    Severity: normal, Certainty: certain
N:    
N:    Check: binaries, Type: binary, udeb
N: 
I: libjpeg-turbo-progs: hyphen-used-as-minus-sign usr/share/man/man1/jpegexiforient.1.gz:54
N: 
N:    This manual page seems to contain a hyphen where a minus sign was
N:    intended. By default, "-" chars are interpreted as hyphens (U+2010) by
N:    groff, not as minus signs (U+002D). Since options to programs use minus
N:    signs (U+002D), this means for example in UTF-8 locales that you cannot
N:    cut and paste options, nor search for them easily. The Debian groff
N:    package currently forces "-" to be interpreted as a minus sign due to
N:    the number of manual pages with this problem, but this is a
N:    Debian-specific modification and hopefully eventually can be removed.
N:    
N:    "-" must be escaped ("\-") to be interpreted as minus. If you really
N:    intend a hyphen (normally you don't), write it as "\(hy" to emphasise
N:    that fact. See groff(7) and especially groff_char(7) for details, and
N:    also the thread starting with
N:    http://lists.debian.org/debian-devel/2003/debian-devel-200303/msg01481.h
N:    tml
N:    
N:    If you use some tool that converts your documentation to groff format,
N:    this tag may indicate a bug in the tool. Some tools convert dashes of
N:    any kind to hyphens. The safe way of converting dashes is to convert
N:    them to "\-".
N:    
N:    Because this error can occur very often, Lintian shows only the first 10
N:    occurrences for each man page and give the number of suppressed
N:    occurrences. If you want to see all warnings, run Lintian with the
N:    -d/--debug option.
N:    
N:    Refer to /usr/share/doc/groff-base/README.Debian and the groff_char(7)
N:    manual page for details.
N:    
N:    Severity: wishlist, Certainty: possible
N:    
N:    Check: manpages, Type: binary
N: 

Osamu



Reply to: