Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
I was talking to compnerd today on how to test qtjava and kdejava. He looked at qtjava ebuild and said it needed some work. I have attached what he came up with, and I confirm to have gotten working (with 3.4.3 at least).
Created an attachment (id=73973) [edit] 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 an attachment (id=95961) [edit] 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 an attachment (id=108767) [edit] 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 an attachment (id=108768) [edit] generation-2 java patch for 3.5.2 This should go stable ASAP because current stable is broken.
Created an attachment (id=108770) [edit] generation-2 java revbump patch for qtjava 3.5.6
Created an attachment (id=108771) [edit] new patch for kdejava that also fixes source/target JAVACFLAGS in addition to CLASSPATH similar to the qtjava patch
Created an attachment (id=108772) [edit] generation-2 java revbump patch for kdejava 3.5.2 should go stable ASAP
Created an attachment (id=108773) [edit] generation-2 java revbump patch for kdejava 3.5.5 Should go stable ASAP.
Created an attachment (id=108775) [edit] 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.