Summary: | New better tasting kde-base/qtjava and kde-base/kdejava ebuilds (3.4.3 and 3.5) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris White (RETIRED) <chriswhite> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | compnerd, java, zlin |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 138924, 155341, 164547 | ||
Attachments: |
qtjava-3.4.3.ebuild
patch for 3.5.2 patch needed for controlling source/target in gen-2 generation-2 java patch for 3.5.2 generation-2 java revbump patch for qtjava 3.5.6 new patch for kdejava that also fixes source/target JAVACFLAGS in addition to CLASSPATH generation-2 java revbump patch for kdejava 3.5.2 generation-2 java revbump patch for kdejava 3.5.5 generation-2 java revbump patch for kdejava 3.5.6 |
Description
Chris White (RETIRED)
2005-12-03 00:21:48 UTC
Created attachment 73973 [details]
qtjava-3.4.3.ebuild
The ebuild. This should work with 3.5 with a rename, but haven't tested that
yet.
Chris - I'm all for you updating this ebuild yourself (another KDE dev, step in and disagree if you like). I don't use qtjava and I doubt any of the other KDE folks here do as well, so if this works better than what's in portage now I'm all for it. Commited the ebuilds I worked with compnerd on. The java stuff is all solid now. Could someone please reopen this bug (or fix it)? The qtjava-3.4.3 ebuild was committed (as qtjava-3.4.3-r1) but the qtjava-3.5.2 is still wrong. I've just tested fixing this bug is as simple as: # cp qtjava-3.4.3-r1.ebuild qtjava-3.5.2-r1 It does work and as a side effect it resolves bug #138924 (I think this bug should block #138924). Created attachment 95961 [details, diff]
patch for 3.5.2
simple renaming doesn't work because of MAXKDEVER and slot-specific rm -rf command (should be now slot-independent :)
Reopening bug per request. There hasn't any progress on this bug, I don't want it to hold up stabilizing the new Java system. Looks like the patch (and for bug 138924 too) isn't perfect anyway, due to both kde and java defining pkg_setup() and inherit order, only kde's pkg_setup() is executed here, which means gen-1 java environment isn't set correctly. There should be an ebuild-defined pkg_setup() calling both kde and java pkg_setup()'s. Or now that gen-2 java is stable, we can use gen-2 eclasses instead, where initialization is done via phase hooks. Created attachment 108767 [details, diff]
patch needed for controlling source/target in gen-2
Because build system doesn't respect our JAVACFLAGS, we need to inject them like this (inspired by kdejava injecting of CLASSPATH).
Created attachment 108768 [details, diff]
generation-2 java patch for 3.5.2
This should go stable ASAP because current stable is broken.
Created attachment 108770 [details, diff]
generation-2 java revbump patch for qtjava 3.5.6
Created attachment 108771 [details, diff]
new patch for kdejava that also fixes source/target JAVACFLAGS in addition to CLASSPATH
similar to the qtjava patch
Created attachment 108772 [details]
generation-2 java revbump patch for kdejava 3.5.2
should go stable ASAP
Created attachment 108773 [details, diff]
generation-2 java revbump patch for kdejava 3.5.5
Should go stable ASAP.
Created attachment 108775 [details, diff]
generation-2 java revbump patch for kdejava 3.5.6
KDE team, please check these out. If you want, I can commit it myself and add java as second herd. This migration to generation-2 java eclasses will fix all those blocked bugs (once stabled where appropriate).
(In reply to comment #15) > If you want, I can commit it myself and add > java as second herd. Please do both. Thanks :) In CVS. |