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 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 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
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
27 matches
Mail list logo
