Please mark sun-j2me-bin stable on x86
I disagree. Reason 1: There are still some dependencies marked as ~x86. So, first they need to be stable. Reason 2: ktoolbar can't create or open projects, because it ALWAYS use the <j2me-path>/apps/ for storing them. I don't think this app should be removed from portage, (at least not now), but leave it as ~x86 or even masked.
FYI Related Bug: 168387 encountered on amd64, but not necessarily known that it will occur on x86.
(In reply to comment #1) > Reason 2: ktoolbar can't create or open projects, because it ALWAYS use the > <j2me-path>/apps/ for storing them. This can be solved in ebuild by creating a directory <j2me-path>/apps/ (or a symlink to some directory) with proper access rights (rights like /tmp has, mainly sticky bit) and maybe create a special group "j2me" for users who want to use the package.
diff sun-j2me-bin-2.2-r3.ebuild* 82c82,87 < use examples && cp -r apps ${D}/${DIR} --- > if use examples; then > cp -r apps ${D}/${DIR} > else > dodir ${D}/${DIR}/apps > fperms 1777 ${D}/${DIR}/apps > fi
(In reply to comment #3) > This can be solved in ebuild by creating a directory <j2me-path>/apps/ (or a > symlink to some directory) with proper access rights (rights like /tmp has, > mainly sticky bit) and maybe create a special group "j2me" for users who want > to use the package. This is a quick and dirty workaround for a badly written program. If this ever gets into ebuild, then also add a big fat warning about this, and also why this is dangerous (giving write-access to such directory to untrusted people is not good).
(In reply to comment #5) I agree with you, it is risky. But what do you suggest? Write our own Ktoolbar? I would be interested :)
Maybe keep this marked as unstable or even mask this! If this is masked, gentoo devs can add a little explanation about why this is masked, and this will be shown when you try to emerge (Try this to see what I'm talking about: emerge -pv nethack or emerge -pv unreal). Personally, I uncompress this software on my own home dir and use it from there, but I know this is not a multi-user solution (Damn, that software has not been written for multi-user use! Not even Windows version!). Another idea is to use NetBeans or Eclipse toolkits for Java ME. Yes, I know, these two are very big.
Hello, i try to work with that software, background is that i begin to develop applications for j2me. currently it is not possible to use the installation via this ebuild - right? (without the dirty solution)
(In reply to comment #8) > Hello, > > i try to work with that software, background is that i begin to develop > applications for j2me. currently it is not possible to use the installation via > this ebuild - right? (without the dirty solution) > It is possible to use the ebuild providing you do not use ktoolbar. In fact, ktoolbar is not the important part of the WTK, you can write your own Makefile and you are ok. You only need classes from WTK (and maybe the emulator which AFAIK does not cause problem) for developing j2me apps. However, it would be better if we provide some easy to use enviroment for users.
I tried the new version from Sun (WTK-2.5.2) and it now works very well. It is now multi-user friendly (no need to change permissions in /opt), the applets are installed in ~/j2mewtk/2.5.2/ by default and /opt/WTK2.5.2 can be kept owned/writable by root only. Maybe we should package this version? I use it with eclipseme, I haven't tested Sun toolbar.
Is stable on x86, closing.
