Bug#612341: could anyone summarize the status on libjpeg-turbo WNPPs? [question for Tom]
Hi!
On Wed, Mar 20, 2013 at 9:59 AM, Yaroslav Halchenko <yoh@debian.org> 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!
>
> 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)
Correct. It only covers the files within the debian directory anyway.
Other changes that were outside are under the license of the upstream
project.
> 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.
Hm. News to me.
> 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?
I'm completely supportive of moving to BSD-3 for debian/*.
> - 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)
>
>
>> 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
Yeah that looks like an issue. Worth a look into the current code.
>> 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
Same.
> 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
>
>> W: libjpeg-turbo-test: binary-without-manpage usr/bin/jcstest
>> W: libjpeg-turbo-test: binary-without-manpage usr/bin/tjunittest
Hmm. These are both test binaries. I don't think it's a major loss
that there isn't a manpage for them.
> I would just override those with a notice that no upstream manpages are
> provided and these ones are of limited user use
>
> 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 that sounds reasonable to me.
>> 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>
>
>> 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 ;)
Thanks Yaroslav!
> --
> Yaroslav O. Halchenko
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Senior Research Associate, Psychological and Brain Sciences Dept.
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Tech Lead, Graphics Working Group | Linaro.org │ Open source software
for ARM SoCs
w) tom.gall att linaro.org
h) tom_gall att mac.com
Reply to: