Bug#612341: could anyone summarize the status on libjpeg-turbo WNPPs? [question for Tom]

[Mike Gabriel]

Hi Yaroslav,

On Mi 20 Mär 2013 15:59:32 CET Yaroslav Halchenko wrote:

Hi Mike et al.,

On Sat, 16 Mar 2013, Mike Gabriel wrote:

>I wonder if anyone could give a concise summary stopping libjpeg-turbo
>from being uploaded?  there seemed to be lots of work, clarifications
>from upstream, downstream distributions including it,... and no
>clarity why we do not have it in Debian yet (could simply be a lack of
>time?).

>Thank you in advance!

I have experimented around with libjpeg-turbo.git on collab-maint recently.
I have updated upstream to 1.2.90.

Thanks for pushing it forward!

Thanks for reviewing!

Let me start with boring stuff:

- we should clarify debian/copyright content on debian/* materials
  copyright/license

  judging from git history, debian/* is not only "copyright" by our team
  but also by 2010, 2011 Linaro Limited;

  original license of Tom's (Linaro) work was LGPL-2.1 (probably for no
  specific reason)

  then Matthias Klose <d...@ubuntu.com>  also contributed (no changes in
  debian/copyright were done though)

  and then there was
+  * Drop outdated copyright notice for /debian folder and replace by
+    GPL-2+ copyright entry in /debian/copyright.

  which imho is incorrect -- we cannot subsume contributions of Tom and
Matthias   without their agreement ... moreover for Linaro's portion it might
even be not that easy -- so we should just maintain that copyright entry as
long as current work is based on their work ;)  But I am CCing them now
(may be they would like to join the team) --

  Tom -- do you remember a reason for choosing GPL for the debian/* works?

  BSD-3.  Would it be possible to change the license for your works, or am I
  missing the point here?

Ideally we should stay with a license compatible with upstream, in this case

My tendency is to use the upstream license for packaging as it makes applying patches and sending them to upstream far less bureaucratic (patches from /debian/patches then have the same license as upstream). However, I guess your are right about the license history of /debian/*. GPL, though, I find totally inappropriate for a non-GPL upstream source.

- debian/changelog


the history, only replace "unstable" with "UNRELEASED" or any other
distribution/release where that version was available (e.g precise)

as long as this work is based on someone else's work, I would prefer to keep

Ah. Ok. Good point.

By now the current version already looks quite promosing (I hope).
The dpkg-divert stuff, I have remove. The current policy is:

  o link native libjpeg-turbo code against libturbojpeg1
    -> a package like TigerVNC or VirtualGL should use libturbojpeg1
  o if the system admin chooses to replaced libjpeg8 by libjpeg8-turbo,
    he/she may do so. Only then libjpeg8 is replaced (including all
    consequences for all applications on the system)

Only open (lintian) issues:

mike@sid:~/build$ lintian -IE --pedantic --show-overrides --color
auto libjpeg-turbo_1.2.90-1_amd64.changes
X: libturbojpeg1: shlib-calls-exit
usr/lib/x86_64-linux-gnu/libturbojpeg.so.1.2.90

X: libjpeg8-turbo: shlib-calls-exit usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2

apparently inherent in libjpeg as well (and quite a few other tools) but they

might indeed be a "legit violation" -- needs some analysis

do not provide a lintian override with a description and it seems to me that it

Could you take over that task, as I am not that experienced with shared library coding (and fixing).

W: libjpeg-turbo-test: binary-without-manpage usr/bin/jcstest
W: libjpeg-turbo-test: binary-without-manpage usr/bin/tjunittest

I would just override those with a notice that no upstream manpages are
provided and these ones are of limited user use

Ok.

related:  I see empty override_dh_auto_test: -- shouldn't package better

to in my packages)?

exercise those tests at build time and fail if they fail (the practice I adhere

Yes, agreed. I missed that point. I will check that later.

W: libjpeg-turbo-progs: hardening-no-relro usr/bin/jpegexiforient

W: libjpeg-turbo-progs: hardening-no-fortify-functions usr/bin/jpegexiforient

now I spotted debian/extra -- needs an entry into debian/copyright, e.g.
Guido Vollbeding <gu...@jpegclub.org>

My todo.

N: yes, the package has a different name
O: libjpeg8-turbo: package-name-doesnt-match-sonames libjpeg8
N: yes, we specifically want linkers to depend on the standard libjpeg name

O: libjpeg8-turbo: shlibs-declares-dependency-on-other-package libjpeg8 (>= 8)

good ;)

:-)

Can you take a look and give feedback till here?

I will try to build the beastie now ;)

Good luck!

Mike


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

pgp3FkTACIZjE.pgp
Description: Digitale PGP-Unterschrift