Please bump.
Created attachment 91188 [details] Just a quick edit of the rc2 ebuild Compiles for me on x86 and tested with azureus 2.4.0.2
SWTMessages.properties is upstream for some time. https://bugs.eclipse.org/bugs/show_bug.cgi?id=96479 The correct version.txt is in ${S}.
Created attachment 91203 [details, diff] update diff from rc2 to release - delete cruft - fix comment #2 issues - use generation 2 java-config - mozilla -> seamonkey depend - do not compile Java code twice!
in migration-packages overlay - works for x86 and x86_64
I use the RSSOwl as a rssreader and it depends on the swt. But I can't use the internal browser view of the rssowl. So I modified the current version of the swt-3.2.ebuild file. And now, it works like a charm. I can use the internal browser of the rssowl. Attached the patch file.
Created attachment 91952 [details, diff] This makes the rssowl use the internal browser.
Created attachment 91966 [details] swt-3.2-cairo-signedness.patch failed Attached output from attempt to apply swt-3.2-cairo-signedness.patch; each failed with: missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option?
Updated and bumped InOverlay - add GECKO* variables - apply swt-3.2-cairo-signedness.patch for x86_64
Created attachment 91991 [details, diff] fixed swt-3.2-cairo-signedness.patch
(In reply to comment #9) > Created an attachment (id=91991) [edit] > fixed swt-3.2-cairo-signedness.patch > The swt-3.2-cairo-signedness.patch doesn't work, the patch file uses jint, has to be jlong. I have fixed the patch in the last attachment.
Patch fixed in portage without bump. Someone want to buy me an x86_64 box?
Still unsolved issues here. - mozilla -> seamonkey useflag change (they did change that, didn't they?!) - missing GECKO_SDK and GECKO_LIBS exports (comment #5) - do not compile the Java source twice - use supplied version.txt and SWTMessages.properties
All mentioned issues are fixed in -r2. There are no supplied version.txt or SWTProperties.txt. Upstream has already said no against including these in the sources. Marking as fixed.
Still ... - do not compile the Java source twice - use supplied version.txt and SWTMessages.properties So why are there version.txt and SWTMessages.properties in the sources of my swt zips?! Because upstream included them. So, please, use them. Location: anomalie ~ # find /var/tmp/portage/swt-3.2-r1/work/ -name version.txt /var/tmp/portage/swt-3.2-r1/work/version.txt anomalie ~ # find /var/tmp/portage/swt-3.2-r1/work/ -name SWTMessages.properties /var/tmp/portage/swt-3.2-r1/work/org/eclipse/swt/internal/SWTMessages.properties
The sources are NOT compiled twice. Perhaps you have an overlay or something to that effect, make sure that you are compiling from the version that is in portage proper. As for the included files, my mistake, I never looked outside of the org subtree, and thus did not notice the version.txt Using the distributed files now.
Ah, I did not have a look at the build.xml. ;) Fixed quite some time ago. My fault.
