> Best Regards
>
> Adam Farley
>
>
> Phil Race wrote on 30/05/2018 18:06:19:
>
> > From: Phil Race
> > To: Adam Farley8
> > Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard
> > , build-dev > d...@openjdk.java.net>, Magnus Ih
Farley
>
> P.S. I'm holding off on giving Guido the green light until after
> people say if they're happy with the error-enabled version of the fix.
>
> Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28:
>
> > From: Adam Farley8/UK/IBM
> > To: Phil Race
> >
: Phil Race
> To: Adam Farley8
> Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard
> , build-dev d...@openjdk.java.net>, Magnus Ihse Bursie
> , "Thomas Stüfe"
> Date: 30/05/2018 18:07
> Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix
>
Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard
> , build-dev d...@openjdk.java.net>, Magnus Ihse Bursie
> , "Thomas Stüfe"
> Date: 30/05/2018 18:07
> Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix
> compile warning in jchuff.c
>
> Thank
#x27;re happy with the error-enabled version of the fix.
Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28:
> From: Adam Farley8/UK/IBM
> To: Phil Race
> Cc: 2d-dev <2d-...@openjdk.java.net>, Andrew Leonard
> , build-dev d...@openjdk.java.net>, Magnus Ihse Bursie
>
ava.net>, Andrew Leonard
> , build-dev d...@openjdk.java.net>, Magnus Ihse Bursie
> , "Thomas Stüfe"
> Date: 14/05/2018 11:06
> Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix
> compile warning in jchuff.c
>
> Hi Phil,
>
> Would
Hi,
On 05/21/2018 10:14 AM, Thomas Stüfe wrote:
On Mon, May 21, 2018 at 11:07 AM, John Paul Adrian Glaubitz
wrote:
On 05/18/2018 07:09 PM, Thomas Stüfe wrote:
The amount of work you have to put into this far outbalances the
amount of work the OpenJDK maintainers would have to spend when (if
e
On Mon, May 21, 2018 at 11:07 AM, John Paul Adrian Glaubitz
wrote:
> On 05/18/2018 07:09 PM, Thomas Stüfe wrote:
>> The amount of work you have to put into this far outbalances the
>> amount of work the OpenJDK maintainers would have to spend when (if
>> ever) they were to merge down upstream libj
On 05/18/2018 07:09 PM, Thomas Stüfe wrote:
> The amount of work you have to put into this far outbalances the
> amount of work the OpenJDK maintainers would have to spend when (if
> ever) they were to merge down upstream libjpeg.
You might have more luck if you replaced libjpeg with libjpeg-turbo
Thanks for the compliment, but I plan to leave this open for a little
while longer.
I have already heard back from the 6x community, and they say they are no
longer associated with the IJG group (jpegclub.org) that creates 9x.
Unless we see the potential for an upstream merge from the sourcefor
I admire your perseverance :) but I think this is a fools errand.
The amount of work you have to put into this far outbalances the
amount of work the OpenJDK maintainers would have to spend when (if
ever) they were to merge down upstream libjpeg.
Note that we have a lot of experience with downstr
Hi,
I tried to use the IJG's contact page, but no joy. Seems broken; there a
spinning icon when you hit "send", but nothing happens.
http://jpegclub.org/reference/contact/
So I used a slightly older mailing list on sourceforge. The request to
update their code has been sent, and I hope it will
Hi,
OK .. if you can convince upstream this is worth doing, then we can
accept it
as we would not regress when updating. As I noted previously :
http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html
this is still an issue in the currently being developed 9c train.
-phil.
On 5/1
Hi Phil,
Would an acceptable compromise be to deliver the source code change
and send the code to the upstream community, allowing them to include
the fix if/when they are able?
I believe Magnus was advocating this idea as well. See below.
Best Regards
Adam Farley
> Same here. I would like to
Same here. I would like to have this fix in, but do not want to go
over Phils head.
I think Phil was the main objector, maybe he could reconsider?`
Thanks, Thomas
On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie
wrote:
> I don't object, but it's not build code so I don't have the final say.
I don't object, but it's not build code so I don't have the final say.
/Magnus
On 2018-04-25 17:43, Adam Farley8 wrote:
Hi All,
Does anyone have an objection to pushing this tiny change in?
It doesn't break anything, it fixes a build break on two supported
platforms, and it seems
like we ne
Hi All,
Does anyone have an objection to pushing this tiny change in?
It doesn't break anything, it fixes a build break on two supported
platforms, and it seems
like we never refresh the code from upstream.
- Adam
> I also advocate the source code fix, as Make isn't meant to use the sort
of
On 2018-04-16 12:58, Adam Farley8 wrote:
I also advocate the source code fix, as Make isn't meant to use the
sort of logic required
to properly analyse the toolchain version string.
e.g. An "eq" match on 4.8.5 doesn't protect the user who is using
4.8.6, and Make doesn't
seem to do substring
I also advocate the source code fix, as Make isn't meant to use the sort
of logic required
to properly analyse the toolchain version string.
e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6,
and Make doesn't
seem to do substring stuff unless you mess around with shells.
I also advocate the source code fix, as Make isn't meant to use the sort
of logic required
to properly analyse the toolchain version string.
e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6,
and Make doesn't
seem to do substring stuff unless you mess around with shells.
On 2018-03-27 18:44, Phil Race wrote:
As I said I prefer the make file change, since this is a change to an
upstream library.
Newtons fourth law: For every reviewer, there's an equal and opposite
reviewer. :)
Here I am, advocating a source code fix. As Thomas says, the compiler
complaint see
21 matches
Mail list logo
