Closed Bug 57004 Opened 24 years ago Closed 24 years ago

put new JRE into trunk and branch builds

Categories

(SeaMonkey :: Build Config, defect, P2)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: granrosebugs, Assigned: granrosebugs)

References

Details

(Whiteboard: [rtm need info] need linux installer hackery) 

I have a new JRE drop from Sun to put in the branch and trunk.  This does not
fix the Japanese text in Java bug, but I'm told it fixes 7 java plugin specific
bugs.

no review really possible, leaf has give me the a= as build config owner.

PDT: can I get an rtm++ to check it in?
Status: NEW → ASSIGNED
Keywords: rtm
Whiteboard: [rtm+] JRE in hand, need rtm++
Could it be that this missed the PDT queries because the status whiteboard
contains rtm++ ? If this is the case, I'd suggest to replace "need rtm++" with
something like "need PDT approval". Sorry for my spam...
Gtu Idee Andreas, I've changed it.

Jonathan, due to 57046, and the i18n bug, we'll have to give you yet another 
drop.  However, please put this one on the shelf for now.
Whiteboard: [rtm+] JRE in hand, need rtm++ → [rtm+] JRE in hand, need DPT approval
no spam, you're right.  I thought the queries only looked at what was in the []
but I was mistaken.

Ed: how long do you think for the next drop?  We'd need it by next week at the
latest.
Whiteboard: [rtm+] JRE in hand, need DPT approval → [rtm+] JRE in hand, need PDT approval
We need international approval on any JRE drops we take at this point.
Please contact ftang and get his review (approval).
International has had too many regressions to take drops without checking them 
first.

Frank: Please nominate to rtm-plus when you are satisfied that this is an 
improvement.

Marking rtm need info
Whiteboard: [rtm+] JRE in hand, need PDT approval → [rtm need info] JRE in hand, need PDT approval
This drop will explicity *not* get I18n approval because of the japanese display
bug that is still known. I'd opt for waiting until we have that fix before
checking into the shelf, as each checkin of the jre is going to double the
amount of space in the cvsserver taken up by the jre.exe,v file.

Ed, is there an eta on the japanese display bug fix?
Adding myself to the cc: list.

I agree with Leaf's comments. In addtion, I don't see anything in this report
that illuminates us to where the "win" is here (i.e. How do we benefit from
taking this new drop? What works better or been fixed?).

PDT - I would hold on the ++ for right now.

Ftang and I will be meeting with George this afternoon to discuss.
Yesterday, we were surprised to discover that on 10/12 there
was an interface change in the browser (57046) which causes
a segfault in the Java Plug-in on all Unix platforms.  (I thought
the interface was frozen?)

I just met briefly with George Drapeau, who will probably communicate
the Java 'plan du jour' to the PDT.  We rebuilt the Java Plug-in
last night and plan to test and re-deliver COB Wed, 10/25.  Here
are the only changes planned for this final drop...

   1) Plugin-side adjustment to the interface change (57046) on Unix
   2) Fix for newly-discovered Netscape 4.x plugin regression on Win32
   3) font.properties updates for 1.0 font compatibility in asian+ locales
   4) Updated message bundles

This will be our final Java FCS drop.  If the interface changes again,
there will be no time to respin Java.  Please don't kill Java!  We can
provide an early drop to interested parties to check out prior to the
planned release on 10/25.

updated status whiteboard.

lchiang - is 10/25 going to be soon enough to be able to get this in and still
certify the bits?
Severity: normal → critical
Priority: P3 → P2
Whiteboard: [rtm need info] JRE in hand, need PDT approval → [rtm need info] waiting for new JRE, ETA 10/25
PDT says rtm++ to land the JRE drop that George Drapeau will deliver tomorrow,
Thursday, 10/19.
Whiteboard: [rtm need info] waiting for new JRE, ETA 10/25 → [rtm++] waiting for new JRE, ETA 10/25
just talked with the Sun guys as well, am expecting an email or CD with the new
bits tomorrow, to show up in the builds tomorrow night.
Whiteboard: [rtm++] waiting for new JRE, ETA 10/25 → [rtm++] waiting for new JRE, ETA 10/19
qa contact to shrir.  Shrirang, expect a new JRE build to test.  This will have
the fix for the regression caused by 57046 and the changes mentioned above
except for the Int'l font properties item.  George - pls confirm.  Thanks.
QA Contact: granrose → shrir
Confirming: those two things are correct.  Delivery should be today.  Awaiting 
the "go" from Java Software (looking in my email queue; it may be there even 
now).
granrose - did we get the delivery yet?
George has sent me the link to the new win32 JRE and jung has confirmed they
have the japanese fix.  I can drop those bits in today.

I'm waiting for word on the linux JRE, if I should use the one Ed sent earlier,
or if we're expecting a new one of those as well.
Oops, my bad.  I sent email but failed to update this bug.
No delivery of Linux yet.  It's due today, possibly this morning.  Awaiting word 
from Java Software once they've completed sanity testing on the Linux bits.
I've checked the new win32 JRE into the trunk and the branch and am starting a
win32 build which should be ready in about 90 minutes.
Whiteboard: [rtm++] waiting for new JRE, ETA 10/19 → [rtm++] win32 JRE checked in, waiting for Linux JRE
George: Any update on the Linux JRE?  We'd really like to get a "good build" in
our pocket early next week, and it would be a Bad Thing if this drop is what
we're waiting for.  Can you give us a new ETA?
Thanks,
Jim (always wanting it yesterday) Roskind ;-)
Oops, I'm tardy in updating this bug.  Delivered via xdrive.com to granrose on
10/20/2000.  Lemme know if there are problems.

I've received the linux JRE and placed it on lithium.  I'm doing a branch build
now which should be done in about an hour.

resolved/fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
cc: gbush. Windows branch build has the correct jre when installed (I checked 
the packaging dates). I cannnot get the jre to work on linux. Seems to install 
on linux but applets do not load. Also, Jonathan, have these bits been updated 
on netcenter, u know? Bcos on linux , I tried to install jre from netcenter and 
I feel that they are the old bits (not sure). Can anyone confirm ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Shrirang,
I highly doubt these new Linux JRE bits have been pushed to Netcenter.  At the 
very least, the jre.xpi module needs to be QA's (implicitly through the 
linux installer) before they can be pushed.  I don't believe there has been a 
request to push the new Linux JRE bits out immediately.  From this we can 
deduce that the new Linux JRE bits would likely hit the wire when Netscape 6 is 
released.
In the meantime, is there some way for people to get the linux Java bits in
order to test them?  Installing today's installer build still installs the wrong
Java bits. 
define "wrong java bits".  I ran the stub installer and it installed Java, but
when I went to java.sun.com it told me I needed to download a different JVM from
Netcenter.  Is this a problem with the JRE, the packaging, the build, Netcenter,
or java.sun.com?
Whiteboard: [rtm++] win32 JRE checked in, waiting for Linux JRE → [rtm++] provided JREs checked in, linux not working.
I had some similar problem when I tried the Java plugin with the fix of 57046. 
In my case, it was because my browser was built with debug enabled, whereas the
plugin was not. After I rebuilt the browser with debug disabled, it worked fine.


I just installed the commercial installer with BUILDID 2000102321 and the linux
jre that George gave to you.  I visited java.sun.com and both applets
successfully displayed.

Make sure that the libjavaplugin_oji.so is exactly 349608 bytes in size and has
a checksum of 3203097682.  If it doesn't then you don't have the right java
plugin!
Problem idenitifed.  Seeking decision on RTM resolution using one of two of the
following recommendations.

Problem:
--------
The location of libjavaplugin_oji.so has changed in the new bits delivered.

Old relative location:
  jre-image-i386/plugin/i386/libjavaplugin_oji.so
New relative location:
  jre-image-i386/plugin/i386/ns600/libjavaplugin_oji.so
                             ^^^^^ new!

We were originally asked to make the jre.xpi create a symlink:
  <n6_dir>/plugins/libjavaplugin_oji.so ->
  <n6_dir>/plugins/java2/plugin/i386/libjavaplugin_oji.so

Obviously with the new Linux JRE bits the symlink in the n6 plugins directory is
invalid sice it points at a non-existent file.

Solution #1:
------------
(IMHO, the solution we should go with for RTM since it is lower risk -- read no
code check in required -- than solution #2.)  Have the Linux JRE release folks
repackage the bits with libjavaplugin_oji.so where it originally was (old
relative location as above).

Solution #2:
------------
Change the jre.xpi's install script to make a symlink to the lib in the "ns600"
directory.  This means we'll need a code change and checkin.  Concerned folks
will need to file a *new* bug since this is a new problem (against me I suppose)
and lobby the PDT to allow me to check this in if we go with this solution.
FWIW, this 6 character change is low risk and trivial.
I would like proposal 1.  George: Would the Java folks be able to do this
without changing any of the underlying Java code?


I'll ask the Java Plug-In p-team (equivalent of Netscape's PDT) at their meeting
tomorrow (Wednesday), 11AM.
Blocks: 57046
No surprises here, I vote for Solution #2.  This is a bug in the
installer and not Java Plug-in.  Therefore the installer should be
modified with the simple fix.  I agree with Samir Gehani with regard
to the relative risk of this change in the installer.
Blocks: 56942
So, is this new jre.xpi file available anywhere for testing?  I think that it
really ought to be available somewhere -- this issue blocks a lot more than the
list above would let on.  It's been more than two weeks since any Unix Java
testing has been possible at all with current builds, and I'd imagine that there
are lots of still unknown issues here.



This thrashing is now starting to impact generation of a candidate build.  Since  
the build for today has been spun, I'm going to back this down to an RTM-plus, 
and consider backing out pav's API change, and freezing on the older Java.
This will be discussed at today's PDT meeting at 4pm in the pit.
Whiteboard: [rtm++] provided JREs checked in, linux not working. → [rtm+] provided JREs checked in, linux not working.
Blocks: 56430
Depends on updating the jre.xpi to point to the correct location for 
libjavaplugin_oji.so, bug 57960.

Please note for the record, that the 10/10 linux java plugin bits have this 
problem as well.  Can someone please confirm that 
plugin/i386/ns600/libjavaplugin_oji.so exists in the 10/10 linux java plugin?
No longer blocks: 56430
Depends on: 57960
James Melvin,
Not to be pedantic, but this is *not* an installer bug.  Solution #2 is a
*change request* to the install script because the directory structure change
was not communicated to the installer team when it was made (in the new Linux
JRE bits).

The reason I am raising this point is simple: the .xpi package generation is
done by the commercial build system at Netcsape so in the future any directory
structure changes (in particular ones to libjavaplugin_oji.so) should be
communicated to the Netscape installer and release folks.  Thanks.
You are correct.  It's a change request.
It seems strange that we'd depend on having "ns600" in the path.  Is this the
case on other platforms?  Are we going to have to go through this all over again
when it's 6.01 or 6.5 or whatever instead of 6.0?  Solution 1 (get rid of the
ns600) seems to make more sense if it's possible at this late date.
The reason we need ns600 in the path is to allow for breakages in backwards 
compatability in future releases.  
PDT would like to see the installer patch that brings us up to speed on this 
name change ASAP.  At this late date, we do not wish to wait for a javasoft 
respin.
Whiteboard: [rtm+] provided JREs checked in, linux not working. → [rtm need info] provided JREs checked in, linux not working.
update whiteboard, reassign to sgehani.
Assignee: granrose → sgehani
Status: REOPENED → NEW
Whiteboard: [rtm need info] provided JREs checked in, linux not working. → [rtm need info] need linux installer hackery
This bug should continue to represent what it was originally filed for: putting
new JRE bits in the builds.  The installer issue is already rtm++'d and is being
tracked by bug 57960.
Assignee: sgehani → granrose
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Since Jon already put the new bits and they are being delivered by the linux
installer this bug can marked fixed but verification depends on bug 57960 being
fixed.
This is fixed. Both linux and windows new jre bits are in the branch. Keyword: 
vtrunk. I will verify this myself on the trunk.
Keywords: vtrunk
verified that both..windows/linux trunk bits have the latest jre bits(10/27). 
VERIFIED.
Status: RESOLVED → VERIFIED
removing vtrunk keyword. sorry for the spam.
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.