Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369896

Summary: Experiment with --segment-limit=-1 for pack200
Product: [Tools] Orbit Reporter: David Williams <david_williams>
Component: relengAssignee: Project Inbox <orbit.releng-inbox>
Status: RESOLVED INVALID QA Contact: Project Inbox <orbit.releng-inbox>
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description David Williams CLA 2012-01-27 01:05:39 EST 
Given bug 361628, I search VM pack200 bugs for possibly related bugs. Seems one that might be related is 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5078608
titled: Digital signatures are invalid after unpacking

While (I think) some fixes were put in 1.5, some reports sounds like it can still be a problem with later VMs, thought 1.7 isn't mentioned explicitly. 

That bug suggest that using --segment-limit=-1 in the pack200 invocation (for both the conditioning step, and the pack step) will cause the process to behave a bit more predictably. 

It is a little "trial and error" attempt to solve the problem, but I think worth a simple experiment with orbit build to see if our 4 "easy to reproduce" cases are fixed by this simple workaround. And, this bugzilla is just to document the experiment.
Comment 1 David Williams CLA 2012-01-27 03:41:06 EST 
No effect, on unpack behavior, but ... thinking about it, these "test ok" with using the raw gzip and unpack200 tools ... so ... fairly clear there is nothing wrong with the jars/bundles themselves ... just thow they are being read by Java code. It appears Ian has some initial ideas in bug 361628.