Re: [opensource-dev] 64 bit viewers build instructions

[Nat Goodspeed]

On Mon, Jan 16, 2017 at 6:47 AM, Nicky Perian  wrote:

> https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
>
> Please take this in and then provide for the updated archives in the viewer. 
> I also received a report that the missing texture issue is in macOS when 
> using openjpeg-1.5.1.

There are admittedly painful aspects to the two-step autobuild
mechanism: (1) rebuild the 3p package and (2) update every consumer.

However, one of the benefits of that approach is that we can adjust
the version of a given 3p package consumed by (e.g.) the viewer
without actually having to revert the 3p repository source. We can
just change back the package URL specified in the viewer's
autobuild.xml.

> Or, if the problem with 1.5.1 is easily corrected

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
texture files that are correctly handled by 1.5.0?

I think Cinder has a point: if we can move forward with 1.5.1, we should.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Cinder Roxley]

We’ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can put 
together some patches to get it working.
 
 
-- 
Cinder Roxley
Sent with Airmail
 

On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (n...@lindenlab.com 
 ) wrote:

 
Nat Goodspeed  erian  wrote:

> https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
>
> Please take this in and then provide for the updated archives in the viewer. 
> I also received a report that the missing texture issue is in macOS when 
> using openjpeg-1.5.1.

There are admittedly painful aspects to the two-step autobuild
mechanism: (1) rebuild the 3p package and (2) update every consumer.

However, one of the benefits of that approach is that we can adjust
the version of a given 3p package consumed by (e.g.) the viewer
without actually having to revert the 3p repository source. We can
just change back the package URL specified in the viewer's
autobuild.xml.

> Or, if the problem with 1.5.1 is easily corrected

Please forgive me if this should already be on my plate, but I don't
recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load

texture files that are correctly handled by 1.5.0?

I think Cinder has a point: if we can move forward with 1.5.1, we should.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Nicky Perian]

>>Please forgive me if this should already be on my plate, but I don't
>>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
>>texture files that are correctly handled by 1.5.0?

Yes.
openjpeg-1.5.1 has so many textures marked as over-sized and unavailable
that the viewer is unusable. This came about with viewer64 as the default
viewer is still on openjpeg-1.4.0.  I had seen the same texture missing
message once while using Project Alex Ivy viewer and filed a jira on that
instance at  https://jira.secondlife.com/browse/BUG-41228 . I am making a
wild guess, but I think there is a possible CDN delivery issue that
openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU.

I had not known of openjpeg-1.5.0 every being supplied in a viewer or I
would have certainly looked for it.




On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley 
wrote:

> We’ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can
> put together some patches to get it working.
>
> --
> Cinder Roxley
> Sent with Airmail
>
> On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (n...@lindenlab.com)
> wrote:
>
> Nat Goodspeed  erian  wrote:
>
> > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
> >
> > Please take this in and then provide for the updated archives in the
> viewer. I also received a report that the missing texture issue is in macOS
> when using openjpeg-1.5.1.
>
> There are admittedly painful aspects to the two-step autobuild
> mechanism: (1) rebuild the 3p package and (2) update every consumer.
>
> However, one of the benefits of that approach is that we can adjust
> the version of a given 3p package consumed by (e.g.) the viewer
> without actually having to revert the 3p repository source. We can
> just change back the package URL specified in the viewer's
> autobuild.xml.
>
> > Or, if the problem with 1.5.1 is easily corrected
>
> Please forgive me if this should already be on my plate, but I don't
> recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
> texture files that are correctly handled by 1.5.0?
>
> I think Cinder has a point: if we can move forward with 1.5.1, we should.
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 64 bit viewers build instructions

[Niran]

I had openjpeg 1.5 long ago for some time, the 32bit version wasn't all
that better... it was... unreliable.

2017-01-17 18:09 GMT+01:00 Nicky Perian :

> >>Please forgive me if this should already be on my plate, but I don't
> >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
> >>texture files that are correctly handled by 1.5.0?
>
> Yes.
> openjpeg-1.5.1 has so many textures marked as over-sized and unavailable
> that the viewer is unusable. This came about with viewer64 as the default
> viewer is still on openjpeg-1.4.0.  I had seen the same texture missing
> message once while using Project Alex Ivy viewer and filed a jira on that
> instance at  https://jira.secondlife.com/browse/BUG-41228 . I am making a
> wild guess, but I think there is a possible CDN delivery issue that
> openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU.
>
> I had not known of openjpeg-1.5.0 every being supplied in a viewer or I
> would have certainly looked for it.
>
>
>
>
> On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley 
> wrote:
>
>> We’ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can
>> put together some patches to get it working.
>>
>> --
>> Cinder Roxley
>> Sent with Airmail
>>
>> On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (n...@lindenlab.com)
>> wrote:
>>
>> Nat Goodspeed  erian  wrote:
>>
>> > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2
>> >
>> > Please take this in and then provide for the updated archives in the
>> viewer. I also received a report that the missing texture issue is in macOS
>> when using openjpeg-1.5.1.
>>
>> There are admittedly painful aspects to the two-step autobuild
>> mechanism: (1) rebuild the 3p package and (2) update every consumer.
>>
>> However, one of the benefits of that approach is that we can adjust
>> the version of a given 3p package consumed by (e.g.) the viewer
>> without actually having to revert the 3p repository source. We can
>> just change back the package URL specified in the viewer's
>> autobuild.xml.
>>
>> > Or, if the problem with 1.5.1 is easily corrected
>>
>> Please forgive me if this should already be on my plate, but I don't
>> recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load
>> texture files that are correctly handled by 1.5.0?
>>
>> I think Cinder has a point: if we can move forward with 1.5.1, we should.
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges