=== topic_ [~topic@mpiat2305.ag2.mpi-sb.mpg.de] has joined #ubuntu-java === doko [~doko@a130-233-4-29.debconf5.hut.fi] has joined #ubuntu-java === wasabi_ [~wasabi@207.55.180.100] has joined #ubuntu-java === wasabi [~wasabi@c-67-174-81-195.hsd1.tx.comcast.net] has joined #ubuntu-java === wasabi [~wasabi@c-67-174-81-195.hsd1.tx.comcast.net] has joined #ubuntu-java === egi [~egi@202.154.50.78] has joined #ubuntu-java === egi [~egi@202.154.50.78] has joined #ubuntu-java === doko [~doko@a130-233-4-29.debconf5.hut.fi] has joined #ubuntu-java === ryo [~ryo@adsl-79-75.38-151.net24.it] has joined #ubuntu-java [03:14] hi, i'm trying to install SDK 1.4.2 in my hoary on a macintosh (G3 ppc). I have followed the instructions on the web, but i got this error launching any command: [03:15] JVMXM005: Unable to initialize threads [03:15] Exception Could not create JVM. [03:15] can someone help me? [03:22] ryo: It might be expecting the old LinuxThreads library. [03:22] Your best bet is to use one of the Free VMs and hope that it will do everything you need. [03:25] jbailey: ok, but that sounds really strange, isn't it? i mean, i have found lot of howto explaining how to run eclipse using this VM, but i can't run the compiler at least ;) [03:25] Oh wiat, you said Hoary. [03:25] (no, it's not my final purpouse, i have to run tomcat with an application) [03:25] So that's not going to be the problem, we did it for Breezy. [03:26] can I paste 5 lines from strace? I grepped "threads" from the output [03:26] Yeah, running tomcat could be problematic since we don't have the security manager bits in place yet. [03:26] Sure, but I may not be able to do much with it even if I see the problem. [03:27] strace -e open java 2>&1|grep -i thread [03:27] open("/lib/libpthread.so.0", O_RDONLY) = 3 [03:27] open("/opt/IBMJava2-ppc-142/bin/../jre/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) [03:27] open("/opt/IBMJava2-ppc-142/jre/bin/classic/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) [03:27] open("/opt/IBMJava2-ppc-142/jre/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) [03:27] open("/lib/libpthread.so.0", O_RDONLY) = 3 [03:27] JVMXM005: Unable to initialize threads [03:27] Right, so the final one succeeds. [03:27] yes, it doesn't look for a particular release [03:28] So without doing thread traces and whatnot, there's not much I can offer you. [03:29] And those would only serve to let you file bugs against the IBM jvm. [03:29] Have they published a 1.5 that you can try instead? [03:29] no, this is their last one :/ [03:31] jbailey: thank you very much for your support, i'm gonna try my last hope: switch back to 1.3.1 :| [03:31] thanks! bye === ryo [~ryo@adsl-79-75.38-151.net24.it] has left #ubuntu-java [] === jbailey [~jbailey@modemcable134.23-201-24.mc.videotron.ca] has joined #ubuntu-java === doko [~doko@a130-233-5-210.debconf5.hut.fi] has joined #ubuntu-java [05:40] I need a shell script wizard. [05:40] jbailey, ? :) [06:20] Can't right now, need food. [11:37] jbailey, ping [11:37] oh maybe n/m [11:38] wasabi: I'm here now. [11:38] I'm thinking about the gcj classmap thing. [11:38] Thinking of going and playing video games, anything I can help with? [11:38] Just wanted to bounce some ideas off you [11:38] for cdbs [11:38] 'sho nuff [11:38] okay... right now I have as an example package: [11:38] eclipse-rcp. [11:39] eclipse-rcp-common and eclipse-rcp-gcj also [11:39] rcp? [11:39] rich client platform, just one of the eclipse pieces [11:39] I [11:39] I'm thinking about how to hand that information to a dh_* tool to take eclipse-rcp, eclipse-rcp-common and make the mapping with the .so's in eclipse-rcp-gcj [11:39] Also need to specify directories to use for all of those [11:40] I'm thinking it may be a debian/packagename.gcj file or something, like .install and .dirs, etc. [11:40] What doe sthe code that goes into the postinst look like? [11:41] the postinst is very simple. It's the building of the classmaps that is hard. [11:41] postisnt just runs /usr/sbin/update-gcj-classpamsp [11:41] maps [11:41] classmaps are in /usr/share/gcj-4.0/classmap.d, one per package [11:41] We figured out that /usr/share is alright, even with jni stuff? [11:42] THe eclipse thing has .jars in /usr/lib/eclipse/plugins in packages eclipse-rcp and eclipse-rcp-common, and .so's in /usr/lib/eclipse/plugins in eclipse-rcp-gcj [11:42] Yeah, it's fine. [11:43] So there's 1 or more files in one or more packages which are mapped to 1 or more files in another package [11:43] Aren't the names 1:1 ? [11:44] No. [11:44] Well, the names are. [11:44] THe paths aren't. [11:44] Right. [11:44] There are .jars in /usr/share and /usr/lib, which map to .so's which are all in /usr/lib [11:44] Is there any risk of conflicts? [11:44] such as? [11:44] Like a version being in /usr/share and another being in /usr/lib? [11:45] (for jars) [11:45] Oh, yeah. But that won't hurt anything. [11:45] Not within the same source package. [11:45] 'k [11:45] So let's imagine eclipse-rcp-gcj.gcj [11:45] it has something like [11:46] eclipse-rcp:usr/share/eclipse/plugins:usr/lib/eclipse/plugins [11:46] or equally crazy [11:46] made up random syntax there. [11:46] and eclipse-rcp-common:usr/share/eclipse/plugins:usr/lib/eclipse/plugins [11:47] or maybe \t instead of : to keep inline with other dh files. [11:47] Well, whitespace, but yeah. [11:47] So thats BASE:jar:so ? [11:47] yeah [11:48] Is the only variant acceptable generally s/share/lib/ ? [11:48] No. [11:48] I can imagine some various situations. Some .jar's are platform independent. Some are platform dependent. [11:48] Somebody might want to package them so the path isn't exactly the same s/share/lib [11:49] Are 90% of the cases like that? [11:49] Or do you imagine lots of variation in common cases/ [11:49] yeah [11:49] 90% would be similar [11:49] I would do then something like this: [11:50] usr/share/eclipse/plugins/eclipse-rcp.jar [11:50] And have it assume it [11:50] and for the other cases: [11:50] Hmm? [11:50] No... [11:50] usr/share/eclipse/plugins/eclipse-rcp.jar usr/shitbox/foo/eclipse-rcp.so [11:50] eclipse-rcp is a PACKAGE [11:50] containing, oh, 10 jars [11:51] Oh, I see. [11:51] Does the .so file compile all the jars from one package together? [11:51] I can see the need for packages which contain both jars and .so files [11:51] no, seperate .so per jar [11:52] packages which contain only .so files, and packages which contain .so files which would have mapped to two other packages with jar files. [11:52] In eclipses case I have every feature broken down into three packages [11:52] eclipse-name, eclipse-name-common and eclipse-name-gcj [11:52] eclipse-name is platform-dependent files in /usr/lib/eclipse and symlinks to indep files in /usr/share, eclipse-name-common contains /usr/share/eclipse files which are platform indep. [11:53] eclipse-name-gcj contain the .so files in /usr/lib/eclipse which may map to either one of hte other packages [11:53] I think I'd have to play with an example in hand to get it. Might be just trying to think through the headache I have, though. [11:53] =) [11:53] Well,go play games. [11:54] The idea is that packages might be spread across multiple packages besed on arch:all and arch specific? [11:54] debian packages, that is. [11:54] (Feh, overloaded term) [11:55] yeah [11:57] Could you do something like: [11:58] Hmm, lemme think through through. [11:58] Because all the packages will exist in debian/tmp/usr/share/eclipse/plugins/eclipse-rcp [11:58] Yeah, you see though. [11:58] No, this is going to have to be done post install [11:58] I've already figured that out [11:59] Generating the classmap? [11:59] that way the proper jars and .sos have already moved to debian/foo [11:59] There are like, 100 Jars and .so files all in debian/tmp [11:59] but some go to one package, some go to another [11:59] dh_install does that [11:59] Yeah, but aren't they already broken out by package? [11:59] No. [11:59] Oh. [11:59] THey are all spewed in plugins [12:00] /usr/lib/ecipse/plugins has every plugin... every Har. [12:00] Jar [12:00] Allare associated with a different Eclipse feature. [12:01] Either the logic about which Jar and .so file exists in which package has to be duplicated for this new routine, or it has to be done after dh_install has taken care of it. [12:02] make a dh_installjar to handle it in one step? [12:02] Sure, but it will have to duplicate everything dh_install does. [12:02] ANd it'll be a bit confusing to know to put Jars in it [12:02] Nah, we already have that with things like dh_installman [12:02] ahh. [12:03] $ ls dh_install* [12:03] dh_install dh_installemacsen dh_installmime [12:03] dh_installcatalogs dh_installexamples dh_installmodules [12:03] dh_installchangelogs dh_installinfo dh_installpam [12:03] dh_installcron dh_installinit dh_installppp [12:03] dh_installdeb dh_installlogcheck dh_installwm [12:03] dh_installdebconf dh_installlogrotate dh_installxfonts [12:03] dh_installdefoma dh_installman dh_installxmlcatalogs [12:03] dh_installdirs dh_installmanpages [12:03] dh_installdocs dh_installmenu [12:04] that's fine then, as long as it supports globs and everything else