On Thu, May 2, 2013 at 2:58 PM, Andrey Rahmatullin wrote:
> On Wed, May 01, 2013 at 07:18:31PM -0400, Paul Tagliamonte wrote:
> > Why has this taken so long?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034#62
> And no one raised this to tech-ctte.
And this has been done now: #717076
On Sat, May 04, 2013 at 06:11:48AM +0200, Matthias Klose wrote:
> Am 24.04.2013 11:23, schrieb Ondřej Surý:
>
> do you have some insight how openjpeg enters this game? apparently some
> packages
> already use openjpeg explicitly to support some jpeg2000 features.
Irrelevant to this discussion, a
Am 24.04.2013 11:23, schrieb Ondřej Surý:
do you have some insight how openjpeg enters this game? apparently some packages
already use openjpeg explicitly to support some jpeg2000 features. There was
some discussion on that in Ubuntu, see https://launchpad.net/bugs/711061.
Matthias
--
To UNS
On Thu, May 2, 2013 at 12:16 AM, Bill Allombert
wrote:
> so we are better off with Guido as upstream maintainer.
So you are saying you won't budge even a little and any discussion
with you to consider that change of the default libjpeg-dev is futile?
Am I getting that right?
Ondrej
--
Ondřej Su
On Wed, May 01, 2013 at 07:18:31PM -0400, Paul Tagliamonte wrote:
> Why has this taken so long?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034#62
And no one raised this to tech-ctte.
> I mean, every other major distro is using -turbo. It can't be that bad.
They are not Debian.
--
WBR, w
Bill Allombert wrote:
> On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote:
> > P.S.: You still haven't answered my questions in the previous email. I
> > don't think they are unreasonable.
>
> Let start with the beginning:
>
> I became the maintainer of libjpeg62 in November 2001, the p
On Thu, May 02, 2013 at 12:16:46AM +0200, Bill Allombert wrote:
>
> On the other hand, it is also obvious that the libjpeg-turbo upstream does
> not
> have a full understanding of the libjpeg code, so we are better off with Guido
> as upstream maintainer.
It's no reason to hold the whole distro
On Sat, Apr 27, 2013 at 08:55:28AM +0200, Ondřej Surý wrote:
> On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert
> wrote:
> >
> > I think there are some misunderstanding about what offer libjpeg8:
> >
> > 1) by default, libjpeg8 creates JFIF files which are compatible with
> > libjpeg62.
> >
> > 2
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert
wrote:
> On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote:
>> On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert
>> wrote:
>> >
>> > As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more
>> > feature.
>> >
>>
>> From a user'
On Fri, Apr 26, 2013 at 11:50 PM, Bill Allombert <
bill.allomb...@math.u-bordeaux1.fr> wrote:
> So I do not think it is fair to restrict JPEG support in Debian to 1998
> image
> processing technology.
>
>
According to this mail by the Fedora KDE maintainer, ISO rejected the
latest changes introdu
+++ Bill Allombert [2013-04-26 23:50 +0200]:
>
> So I do not think it is fair to restrict JPEG support in Debian to 1998 image
> processing technology.
Neither does anyone else, which is why they want to be able to use the
SIMD features in their CPUs for (much) faster JPEG processing.
So far a
On Wed, Apr 24, 2013 at 10:10:42PM +0800, Aron Xu wrote:
> On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert
> wrote:
> >
> > As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more
> > feature.
> >
>
> From a user's prospective, I don't think adding bunches of not widely
> used f
On Fri, Apr 26, 2013 at 02:27:47PM +0200, Adam Borowski wrote:
> > > It boils down to "jpeg6-2 is the only important thing. Forget about
> > > jpeg8 and jpeg9, which bring incompatible changes".
> > There are other features in newer libjpeg that packages do need, even
> > when not using exotic JPEG
On Fri, Apr 26, 2013 at 12:29:27PM +0100, Simon McVittie wrote:
> On 25/04/13 20:39, Pau Garcia i Quiles wrote:
> > It boils down to "jpeg6-2 is the only important thing. Forget about
> > jpeg8 and jpeg9, which bring incompatible changes".
>
> There are other features in newer libjpeg that package
On Fri, 2013-04-26 at 12:29 +0100, Simon McVittie wrote:
> On 25/04/13 20:39, Pau Garcia i Quiles wrote:
> > It boils down to "jpeg6-2 is the only important thing. Forget about
> > jpeg8 and jpeg9, which bring incompatible changes".
>
> There are other features in newer libjpeg that packages do ne
On 25/04/13 20:39, Pau Garcia i Quiles wrote:
> It boils down to "jpeg6-2 is the only important thing. Forget about
> jpeg8 and jpeg9, which bring incompatible changes".
There are other features in newer libjpeg that packages do need, even
when not using exotic JPEG-like formats. For instance, ioq
Hi all,
On Do 25 Apr 2013 22:29:53 CEST Michael Biebl wrote:
Am 25.04.2013 20:49, schrieb Mike Gabriel:
Can this be a proposal? Package libjpeg and libjpeg-turbo using an
alternatives setup and thus, making both libs installable in parallel.
Packagers can then build-depend on one or the other
I think this might be a good move, since the libjpeg-turbo maintainer
still wants to keep compatibility with libjpeg7/8, and he doesn't want
to implement incompatible changes, which might be introduced when
coding Jpeg2000 or JpegXR.
And if there's and consensus in the community that libjpeg-turbo
On Apr 25, Michael Biebl wrote:
> Please no. If libjpeg-turbo is the saner implementation, which reading
> through the messages posted so far it seems like, let's switch to it fully.
Agreed.
--
ciao,
Marco
signature.asc
Description: Digital signature
Am 25.04.2013 20:49, schrieb Mike Gabriel:
> Can this be a proposal? Package libjpeg and libjpeg-turbo using an
> alternatives setup and thus, making both libs installable in parallel.
> Packagers can then build-depend on one or the other libjpeg
> implementations.
Please no. If libjpeg-turbo is t
Hello,
The KDE maintainer in Fedora started an interesting discussion some time
ago in Digikam's mailing list. There was input from the very IJG:
http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html
It boils down to "jpeg6-2 is the only important thing. Forget about jpeg8
and jpe
On Thu, 2013-04-25 at 20:49 +0200, Mike Gabriel wrote:
> Hi all,
>
> On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:
>
> > On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
> > wrote:
> >> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> >>> Hi Bill and Debian Developers,
> >>>
>
Hi all,
On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:
On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
wrote:
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
Hi Bill and Debian Developers,
My proposal is:
A. Add libjpeg-turbo to Debian archive (that's easy)
B. Add required
On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> li
[Mathieu Malaterre]
> I do not believe in debian life-span, a package manager ever switch
> an implementation of a package. So libjpeg9 and libjpeg-turbo will
> have to co-live.
It happens. Look at the source for 'libc6'. It used to be glibc,
these days it is a fork called eglibc. Likewise the
Riku Voipio wrote:
>On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
>
>> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
>
>This would be a relevant if some application actually used the
>"full libjpeg8 ABI" . In fact, 100% of debian works fine with
>libjpeg-tu
On 2013-04-25, Mathieu Malaterre wrote:
> Chicken & egg issue, until everyone follow debian and uses libjpeg9,
> there may be surprise.
Everyone seems to head towards libjpeg-turbo.
>> I find the reason that IJG libjpeg8 fork is so triggerhappy to
>> repeatedly break the API and ABI (and image f
On Thu, Apr 25, 2013 at 6:17 AM, Riku Voipio wrote:
> On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
>> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more
>> feature.
>
> Only the applications that actually want to experiment with libjpeg8/9 ABI
> should be
On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more
> feature.
Only the applications that actually want to experiment with libjpeg8/9 ABI
should be using it -
The 100% of current applications that work just l
On Wed, Apr 24, 2013 at 03:11:53PM -0700, Russ Allbery wrote:
> >> We have a plenty of libraries (and other packages) who do conflict
> >> between themselves, so we know the drill.
> >>
> >> Also Debian no longer ships libjpeg62, so there's not conflict there
> >> at least for baseline implementati
Vincent Bernat writes:
> ❦ 24 avril 2013 13:08 CEST, Ondřej Surý :
>> We have a plenty of libraries (and other packages) who do conflict
>> between themselves, so we know the drill.
>>
>> Also Debian no longer ships libjpeg62, so there's not conflict there
>> at least for baseline implementatio
❦ 24 avril 2013 13:08 CEST, Ondřej Surý :
> We have a plenty of libraries (and other packages) who do conflict
> between themselves, so we know the drill.
>
> Also Debian no longer ships libjpeg62, so there's not conflict there
> at least for baseline implementation (libjpeg62 API/ABI). Remember
On Wed, Apr 24, 2013 at 11:12:33PM +0800, Thomas Goirand wrote:
> Just being curious... Is the -turbo called this was because it's faster?
> How much faster is it then?
Hi, Thomas,
The very first hit on the duckduckgo.com search engine for search
expression "libjpeg-turbo" (not including the quot
On 04/24/2013 05:23 PM, Ondřej Surý wrote:
> Hi Bill and Debian Developers,
>
> while doing work on GD Library 2.1.0 it was discovered there's
> encoding incompatibility introduced by libjpeg8/9 [1]. While doing
> further research I have found that Fedora has switched to
> libjpeg-turbo[2] (for rea
On Wed, Apr 24, 2013 at 05:01:50PM +0300, Riku Voipio wrote:
> Libjpeg-turbo website [3] has all the signs of an healthy open source
> project - A SVN repo with many commiters, bug tracker, a mailing list
> with open discussion etc.
libjpeg-turbo is also used by webkit, blink, and gecko.
Mike
-
On Wed, Apr 24, 2013 at 01:48:48PM +0200, Mike Gabriel wrote:
> >C. Decide which package should provide default libjpeg-dev library
> Last statement from Bill: libjpeg by IJG
The current IJG has nothing to do with the IJG that originally created JPEG.
The last activity of original IJG was in 19
On Wed, Apr 24, 2013 at 9:19 PM, Bill Allombert
wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> li
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> Hi Bill and Debian Developers,
>
> My proposal is:
> A. Add libjpeg-turbo to Debian archive (that's easy)
> B. Add required provides/alternatives for libjpeg62-dev and
> libjpeg8-dev (where API/ABI match)
> C. Decide which package shou
Hi Ondřej,
I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW [1].
On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:
Debian has already open ITP[3] #602034 for libjpeg-turbo, which
support libjpeg62 API/ABI and also some important bits of libjpeg8. As
libjpeg is one of th
On Wed, 24 Apr 2013 15:30:46 +0600, Andrey Rahmatullin wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> > A. Add libjpeg-turbo to Debian archive (that's easy)
> Not really (especially if you want it to ship libjpeg.so.* too).
We have a plenty of libraries (and other packages
On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> A. Add libjpeg-turbo to Debian archive (that's easy)
Not really (especially if you want it to ship libjpeg.so.* too).
--
WBR, wRAR
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
Hi Bill and Debian Developers,
while doing work on GD Library 2.1.0 it was discovered there's
encoding incompatibility introduced by libjpeg8/9 [1]. While doing
further research I have found that Fedora has switched to
libjpeg-turbo[2] (for reasoning please read the referred email).
Ubuntu (and St
42 matches
Mail list logo
