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

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

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 <doko@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?
Ideally we should stay with a license compatible with upstream, in this case 
  BSD-3.  Would it be possible to change the license for your works, or am I
  missing the point here?
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
as long as this work is based on someone else's work, I would prefer to keep 
the history, only replace "unstable" with "UNRELEASED" or any other
distribution/release where that version was available (e.g precise)


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
do not provide a lintian override with a description and it seems to me that it 
might indeed be a "legit violation" -- needs some analysis
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
exercise those tests at build time and fail if they fail (the practice I adhere 
to in my packages)?


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 <guido@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.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

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

Attachment: pgpNtKFSdrnxZ.pgp
Description: Digitale PGP-Unterschrift

Reply to: