#ubuntu-java 2005-07-02 <wasabi> I've about got eclipse 3.1RC4 packages ready to go. As well as a new ecj-bootstrap and ant. <wasabi> I would like somebody to review them before I go breaking shit. <wasabi> I will let ya'll know when I'm ready. ;) <doko_> wasabi: can you put ant and ecj-bootstrap somewhere on the net? #ubuntu-java 2005-07-03 <wasabi> Any opinions on what we call native java packages? <doko> wasabi: we should coordinate the naming with Debian <wasabi> jbailey, ping <jbailey> wasabi: pong! <wasabi> I do not have main upload privs yet (I left a message with elmo at keyring@ about 2 weeks ago now.) Do you mind uploading java-common, ecj-bootstrap, and ant for me? <wasabi> http://kyoto.larvalstage.net/~wasabi/ubuntu <wasabi> And then telling me how to add a hook into a cdbs package to run AFTER dh_install. <jbailey> np. <wasabi> But before building the .deb <jbailey> doko: Does this conflict with anything you're hacking on atm? <wasabi> doko was going to do it, but had to step out. <jbailey> Describe the hook to me? Sometimes there's already magic in there. <wasabi> I ijust figured if you were around you could get it. <jbailey> np =) <wasabi> jbailey, after each package is installed into debian/$pkg/foo, I want to run some steps on each package. <wasabi> To scan for .jar and .so files, etc. <doko> jbailey: no, I'm doing java-gcj-compat. only thing which needs to be added is a build-dep on java-gcj-compat-dev <wasabi> doko, eh what's that about? :) <wasabi> Splitting j-g-c? Okay. <doko> wasabi: yes <doko> binary-post-install/java-gcj-compat33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab <wasabi> What about for EVERY package? <jbailey> wasabi: Should I wait before fetching and uploading? <wasabi> doko, what is your time frame? :) <doko> wasabi: upload it tomorrow, when I'm finished fighting with debhelper and cdbs :-/ <wasabi> ok. <jbailey> doko: Put your package on chinstrap and I can finish it for you. <wasabi> doko, are you saying to upload MINE tomorrow, or that you are uploading yours tomorrow? :) <doko> wasabi: yours tonight, mine tomorrow ... <wasabi> doko, i can get jbailey to do mine Now... so I guess that's a green light. ;) <wasabi> I want to see how they break (if they break) so I can fix em. I have some free time today. <wasabi> I have to organize my uploads around free time to check after them. =. <wasabi> Have to run to work. Be back in a bit <jbailey> wasabi: confirm that I will upload ant, ecj-bootstrap and java-common right awya? <wasabi> I can't. I am not sure if doko means something special is happenign tonight, or that's just the first time HE can get to them. <wasabi> So, don't upload them yet, and I'll ask you again in an hour when I get to work. <doko> jbailey, wasabi: no, it's ok to upload <wasabi> okay, confirmed. Upload. ;) <wasabi> Must go, late. ;) <jbailey> thanks, safe trip to work! <doko> jbailey: chinstrap:~doko/uploads <doko> it works, but is ugly <wasabi_> jbailey, so, about running a make target using cdbs after dh_install for all packages, but before .deb making? <jbailey> A make target? What'cha doing? =) <wasabi_> Eclipse 3.1. I have dh_install installing all the plugins for each eclipse feature into debian/eclipse$featurename/ <wasabi_> Just a normal cdbs package from that point. <jbailey> So you're iterating through a bunch of dh_install calls? <wasabi_> What I want now is a target that iwll run after all the files have been placed in debian/eclipse-$pkgname, which will enumerate all the .jar's and .jar.so files and build classpath mappings. <wasabi_> No. I just need a rul that runs AFTER dh_install has moved files from debian/tmp to debian/$pkgname <jbailey> Is this something that should be added to cdbs in general? <wasabi_> It would be nice, but it's a bit hard, and needs some thought. <jbailey> 'kay, so this will be a lovely prototype. <wasabi_> Well, I am only doing it AFTER the move because that's the easiest way for me to generate mapping files for each individual package. <wasabi_> since all the plugins lib in usr/share/eclipse/plugins <wasabi_> We have a few eclipse packages, eclipse-rcp, eclipse-platform, -jdt, and -pde, which contain different plugins. <wasabi_> dh_install lists what plugins go to what package. <jbailey> binary-post-install/PACKAG33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab <wasabi_> What abouta binary-post-install/ALLPACKAGES, repeat. <wasabi_> Or I can enumerate the packages myself. <jbailey> $(patsubst %,binary-post-install/%,$(DEB_PACKAGES)) 33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab <wasabi_> oh is that how that works? <wasabi_> Generates rules for each member of DEB_PACKAGES? <jbailey> Yup <wasabi_> Is there anyway in that to know which rule is being called? <wasabi_> And thus, which package. <jbailey> Use $(cdbs_curpkg) and it will give you the currnet package you're working on. <wasabi_> Hmm. is patsubst a cdbs construct? <jbailey> That lets us write rules like: <jbailey> dh_installdocs -p$(cdbs_curpkg) $(DEB_INSTALL_DOCS_ALL) $(DEB_INSTALL_DOCS_$(cdbs_curpkg)) <jbailey> and have it JustWork(tm) <wasabi_> Yeah that's basically what I'm going for. <jbailey> Nope, patsubst is a gnu make thing. <wasabi_> How is cdbs_curpkg known? <jbailey> It's both what makes cdbs possible and what makes it so fUgly. <jbailey> cdbs_curpkg = $(filter-out %/,$(subst /,/ ,$@)) <jbailey> Is defined in buildcore.mk <wasabi_> Haha <wasabi_> cdbs is one big giant hack! <wasabi_> I love it! <jbailey> So $@ always has the target being generated. <jbailey> So you would have binary-post-install/eclipse-plugin-foo in there. <jbailey> that magic strips everything that's not the package name by treating it like a path. <jbailey> There's alot of black magic and love that's gone into making it work. <jbailey> It's the 3rd or 4th generation of this idea. <wasabi_> I'm |---| this close to getting Eclipse 3.1 done. <wasabi_> This classmap thing should be the last issue. <wasabi_> for discussion: The gcj-dbtool generation is being done like this by me, for now. Each package that contains a .jar will have a new companion package ending with -gcj. <wasabi_> The .jar.so file will be in that package, in an appropiate path. <wasabi_> For standard java packages, it'll be /usr/lib/java. Multiarch should be considered eventually. <wasabi_> For Eclipse it's /usr/lib/eclipse/plugins. For other packages, it may be arbitrary. <jbailey> multiarch for java itself? Is that for jni bits? <wasabi_> The native GCJ versions of the .jars <jbailey> Oh duh. =) <jbailey> Approaching lunch time, IQ will steadily decrease from here. =) <wasabi_> So, cdbs needs to make it convient take take a) package 1 b) package 2 (-gcj pacakge) c) path 1 and d) path 2, and generate a mapping file in /usr/share/gcj-4.0/classmap.d/$package1name.db. <wasabi_> I think a dh_* is what we need. <jbailey> Quite probably. <jbailey> Hmm, have to be somewhere in 30 minutes, I'm off. <wasabi_> did you upload those? <jbailey> wasabi_: I've done java-common. ant had a checksum mismatch and doko asked me to add a manpage to ecj before uploading it. <wasabi_> k * wasabi_ kicks ant <wasabi_> ttyl. <jbailey> The mismatch is on the .diff.gz, lemme take alook at it, just a sec. <wasabi_> If you have to go, don't worry about it. <wasabi_> I suspect I just moved the wrong file. <jbailey> Mm, so this might not have all the changes you want in it anyway. <jbailey> 'k, I'm off. =) <wasabi_> I didn't bother with a manpage for ecj-bootstrap because it "doesn't matter". It's just to bootstrap packages. ;) <jbailey> Yeah. <jbailey> Do you have one for the full ecj package? <jbailey> I may as well make it complete if I can. <wasabi_> Hmm. I thought I saw one floating around. <wasabi_> My computer at home seems to have frozen, so I can't get to it. <wasabi_> So I can't tell you. <jbailey> No rush. If you box is frozen, I can't d/l the packages anyway. <wasabi_> Yeah. #ubuntu-java 2005-07-04 * netjoined: irc.freenode.net -> kornbluth.freenode.net * netjoined: irc.freenode.net -> kornbluth.freenode.net <jbailey> wasabi: ping? <jbailey> I'm curious if you've got the right ant bits in place, and you said you thought you might have an ecj.1 that I could just take for ecj-bootstrap. <wasabi> http://kyoto.larvalstage.net/~wasabi/ecj.1 <wasabi> Probably needs updating <jbailey> 'kay <wasabi> Ant's fine to the best of my knowledge. What's up? <jbailey> checksum mismatch between the changes file and the diff.gz <wasabi> I have to hurry up and get ready for work. I over slept. bbl. ;) <wasabi> eh? what the hell. <wasabi> I rebuilt that. <jbailey> I can try again. <jbailey> Oo, eclipse is there now too. Do you want that done as well? <wasabi> Yup. ;) <wasabi> Do you mind trying to build it first? <wasabi> I have given it all the tests I can. <wasabi> Redownload ant. <jbailey> No prob. I'll test on ppc and ia64. <wasabi> I have rebuilt it. <wasabi> I know it won't work on those still. <jbailey> thanks <wasabi> But you'r ewelcome to help fix it! <wasabi> Eclipse suffers from a chicken-and-the-egg problem on !i386 <jbailey> Are you able to talk at work? I don't want to make you late. <wasabi> yeah. thanks. bbl. <wasabi> oh wait don't upload eclipse <wasabi> ya'll don't support ~ in versions yet. <wasabi> I'll package the released 3.1 and that'll fix that. ;) <jbailey> 'kay. I'll do a test build anyway though. <jbailey> ant uploaded <doko> jbailey: b-d on java-gcj-compat-dev ? <jbailey> java-gcj-compat (>=1.0.28-4ubuntu1) <jbailey> Should that be tweaked and reuploaded? <jbailey> And will ecj-bootstrap need the same love? <wasabi> what is in -dev? <jbailey> wasabi: HAven't you left yet? =) <wasabi> Just finished shower heh <jbailey> *lol <jbailey> I was wondering if you had started using irssi in a screen session. =) <wasabi> So I just had 15 seconds to think about j-g-c-dev. What's in it? <wasabi> The only thing I can think of is the headers. <jbailey> doko: ^^^ <jbailey> Helps to use nick highlights. =) <wasabi> And if so, everything should depend on both... as it's not a "Sun comaptible JAVA_HOME" without both. <doko> wasabi: and gcj, and rmic, and javah ... <doko> jbailey: ecj is a b-d of java-gcj-compat-dev <wasabi> Well, that's the thing though. <wasabi> THe idea of j-g-c is to provide Sun compatibility. <wasabi> Without both, it isn't Sun compatible. <wasabi> me->work bbs <doko> wasabi: there is runtime compatibility (jre) and compile time compatibility (sdk). we don't want to have a compiler installed for using an application <jbailey> doko: I think he logs in as a separate account at work, he probably won't see that until he gets home. * jbailey does the summon wasabi dance. <doko> <doko> wasabi: there is runtime compatibility (jre) and compile time compatibility (sdk). we don't want to have a compiler installed for using an application <doko> wasabi_: ^^^ <wasabi_> Hmm. Perhaps. <jbailey> wasabi_: Does ecj-bootstrap need to be touched at all then, or can I upload it? <jbailey> I've hacked in the manpage bits. <wasabi_> It should be fine. <jbailey> And the eclipse directory was empty when I looked earlier. <wasabi_> Yeah. I need to upgrade it to 3.1 release. <wasabi_> I'll get it this evening. <jbailey> Ah, np. I can look at the !i386 bootstrap issue for the package, too. <wasabi_> I can describe the problem. <wasabi_> There is a pre-built Jar named swttools.jar. What it does is copy the win32 x86 SWT source code to the other platform directories, and replace the "int" native handles with long for 64 bit. And some other stuff for other platforms. <wasabi_> swttools requires SWT to build from scratch. <jbailey> Joy. <jbailey> ecj-bootstrap uploaded. <wasabi_> So, you can't build SWT without swttools, and you can't build/use swttools without swqt <wasabi_> swt <wasabi_> thanks. <jbailey> Make sure to pull the version from the archive when updating to get the manpage changes, please. <wasabi_> swttools isn't actually distributed though, I don't think. <jbailey> I can poke a friend of mine who works on eclipse. <wasabi_> Right now I am simply removing it before the build starts, to make sure. <wasabi_> So !x86 fails. <doko> wasabi_: http://people.ubuntu.com/~lamont/buildLogs/e/ecj-bootstrap/3.0.1-4ubuntu3/ecj-bootstrap_3.0.1-4ubuntu3_20050629-2111-amd64-failed.gz <doko> please can we keep ecj-bootstrap as solid as possible? <wasabi_> mmap not implemented? <wasabi_> what's that? <wasabi_> doko, there is no way I can test on amd64. ;) <jbailey> Umm, AFAIK mmap is implemented fine on amd64. <wasabi_> it's a bug in gcj. <wasabi_> according to #gcj #ubuntu-java 2005-07-05 <wasabi> jbailey, did you get ant up? <wasabi> I notice a reject from this mornig. <jbailey> wasabi: Can you forward me the reject message? I left you as the maintainer, so I didn't see it. <jbailey> (or paste the relevant bits here) <wasabi> Rejected: ant_1.6.5-0ubuntu1.dsc refers to ant_1.6.5.orig.tar.gz, but I can't find it in the queue or in the pool. <wasabi> I just got added to the keyring! <jbailey> Nice! <wasabi> From: James Troup <linda89@example.com> <wasabi> Done - sorry for the delay. <wasabi> yay! <jbailey> Cool, give it a spin! <wasabi> DId you get ecj up? <wasabi> Oh yeah, you did. <wasabi> It just broke on amd64 <jbailey> If you give me eclipse, I'll look at it on !i386 tomorrow. <wasabi> putting it togheter now. ;) <wasabi> Hmm. It suceeded on i386 but never showed up. <wasabi> Ant appeared in the archive in 10 minutes. ecj-bootstrap still isn't there. <wasabi> Wonder what causes that. <wasabi> http://akita.larvalstage.net/~wasabi/ubuntu/eclipse <doko> wasabi: eclipse-3.1/debian/eclipse-rcp.postinst modifies a file from another package. bad. if we need an update mechanism, it should be in the same packages as gcj-dbtool. <jbailey> wasabi: g'm. Is your uploading and such all working now? <wasabi> yeah <jbailey> Nice. <wasabi> Oh nifty. Even though ecj-bootstrap broke on amd64, it's still available on amd64. <wasabi> Since only the -gcj portion broke, the pure Java part is Arch: all. <wasabi> Yay for that. <wasabi> And the -gcj part simply enhances it. Makes it faster. It's not required. <jbailey> =) <wasabi> Eclipse 3.1 is going up. So you can play with it. It's still in multiverse though. <wasabi> But that's fine until all the kinks are worked out. <jbailey> Well, it would be nice to at least get it shifted to universe. <wasabi> I am quite confident about this package. I have spent hte last 3 days going over it with a fine tooth comb. <wasabi> A fine example of cdbs-powered art. ;) <jbailey> *lol* <jbailey> How much of it should eventually be rolled into a java module? <wasabi> whatcha mean? <wasabi> oh cdbs? <wasabi> Hmm. <wasabi> I'm not really that sure. I think we obviously need a dh_gcj or something. <jbailey> of cdbs / debhelper or whatever. <wasabi> I think you'll have a good idea when you read it. <wasabi> =) <wasabi> I'd like it to be as easy as firing of some dh_* to set up a native gcj version of a package. <wasabi> So, it needs to scan a certain prefix for jars, and map them to a certain other prefix. <wasabi> From one package to another. <jbailey> Can you write the logic out? <wasabi> I'll have to think about it a bit. <wasabi> in the meantime->shower/work/etc <doko> wasabi, jbailey: I disabled -gcj again, maybe a bit too early, but I needed a working package in the archives, and it didn't show up. is there a way to disable one package for an architecture in cdbs? <jbailey> doko: override DEB_ARCH_PACKAGES and DEB_INDEP_PACKAGES <doko> did I mention, that I love the cdbs documentation? <jbailey> doko: Someone has to. =) <jbailey> doko: Documentation is one of the only things holding up the cdbs2 release. <jbailey> Although what we have already is much better than cdbs1 had. <doko> wasabi: I don't like the ecj-bootstrap Recommends: ecj-bootstrap-gcj. did you see my pointer, that ecj is miscompiled? <wasabi> doko, I know that the dbtool thing is bad. <wasabi> The script included with j-g-c wasn't suitable though. I will be building a better script/tool. <doko> wasabi: and why does ecj-bootstrap-gcj depend on ecj-bootstrap? <wasabi> One is required for the other to work. <wasabi> ? <wasabi> The idea is we are going to have the non-native version recommed the native version, so in the default cause, users are using the enhanced gcj version. <wasabi> Debian will knock the recommends down. <wasabi> As they don't care very much about the default case. ;) <wasabi> s/cause/case/ <doko> wasabi: I will knock them down as well, I do not want to recommend a miscompiled ecj <wasabi> That is being fixed. <wasabi> It's apparently a GCC bug or something. <wasabi> jbailey, ? <doko> wasabi: yes, but it's currently broken. <doko> wasabi: again, why does ecj-bootstrap-gcj depend on ecj-bootstrap? <jbailey> doko: Is it causing your grief? The arch indep one should just work in its place automatically. <wasabi> Yup. That's the idea. <wasabi> THe native version isn't REQUIRED, but it's a speed enhancement when it's present. <doko> jbailey: I don't want users to install the -gcj one now. <wasabi> Why? <doko> because it's broken. recommends are installed automatically by synaptic <wasabi> It's only broken on amd64 though, it works as designed on all other platforms? <doko> wasabi: AFAIK it's broken on all platforms <jbailey> doko: The right thing is to extract the patch from gcc CVS head to fix some misdetection causing mmap grief. <wasabi> Well, it' sin the archive on i386, and works. <wasabi> And ppc apparently. <jbailey> What breakage are you seeing? <jbailey> I haven't tested it on ppc, but I can do so if you'd like. <doko> again: what's the reason for ecj-bootstrap-gcj Depends: ecj-bootstrap <wasabi> Gcj native compilation isn't a replacement for the non-native version. <wasabi> It is a runtime enhancement. <jbailey> doko: All the -gcj versions should depend on their -non -gcj counterparts. <wasabi> When the classloader grabs a .class out of the ecj.jar, it looks that .class's hashmap up in the classmap.db <wasabi> And then loads teh cooresponding .so file if present. <jbailey> That way you always can run the Java app, even if you try with a non-gij VM. <wasabi> vs interpreting the code. <wasabi> The original ecj.jar still has to be present. <wasabi> Not only that, but the ecj.jar has more than code in it. Resources. <doko> jbailey: sure, we will have this one with the next gcj upload <doko> wasabi, jbailey: would you mind writing down things as a policy? <jbailey> I beleive it's already in the wiki. That's where Jerry and I did most of the brainstorming. <jbailey> wasabi: It does present the interesting question of what causes the -gcj version to be installed... should the depends go the other way? <jbailey> That has the downside, though, that an arch that can't produce the -gcj for some reason would be uninstallable. <wasabi> Well, I was banking on synaptic automatically installing -gcj's for users. ;) <doko> http://udu.wiki.ubuntu.com/JavaRoadmap ? <doko> no <wasabi> For buildd's, it doesn't matter as much. <jbailey> wasabi: Ah. =) <wasabi> Maybe we didn't write this down. ;) <wasabi> what happened to JavaIntegration <jbailey> I thought there was more in there. <doko> it would be very nice, if we had something as a proposal for a policy ... <jbailey> Sure. I'll try to cook something formal-looking up next week. <doko> you're at debconf? <jbailey> No. <doko> would be nice to have something for a bof however ... <jbailey> I'm moving this weekend, so I'm off the next 4 days, though. <jbailey> I think it's unlikely that Debian and Ubuntu will converge soon. =( <wasabi> the Eclipse debacle sort of highlights that. ;) <wasabi> jbailey, few shells cripts to be shized. ;0 <wasabi> /usr/share/java-common/java-common.sh <jbailey> Joy. =) <wasabi> That one definitly. The binary launcher for eclipse and ecj, I don't care. In fact I like them Just Working in bash. ;) <wasabi> s/binary// <jbailey> wasabi: wimp. =) <wasabi> Just, the common component should be sh compatible. <doko> there are always two sides in a desaster ... <jbailey> The side that covered their asses and the side that didn't? =) <wasabi> Of coruse, whichever side I'm on, is right. ;) <doko> well, introducing conventions without documenting them isn't nice either. hacking all java packages like you did for ecj and eclipse may work for you, but not for Debian. There's a lot of things we can do better in Ubuntu. <jbailey> RIght, but documenting conventions with no experience just means that things have to be changed afterwards. <jbailey> That's why Debian Policy reflects current best practice, not the other way around. <wasabi> jbailey, please grab Eclipse. =) * wasabi anxious! <wasabi> me->work() bbl <doko> jbailey: please could you have a look chinstrap:~doko/ecj-bootstrap, despite DEB_ARCH_PACKAGES it wants to build the binary package <jbailey> scp: /home/doko/ecj-bootstrap: No such file or directory * jbailey looks <jbailey> ecj-bootstrap* <jbailey> doko: And the goal is that on amd64 would do not want with_native, right? <doko> yep <jbailey> hmm. That hack ought to be working. When I test the constructs they work... =( <jbailey> (GNU Make really is quite annoying) <jbailey> Erp. It looks like make rules don't lazy evaluate the variables. <wasabi_> What's that mean? <wasabi_> Something to do with patsubst? :0 <jbailey> Yeah, doko's trying to override the package list from debian/control. <jbailey> It hasn't come up in any other packages, but we planned for it. <jbailey> Usually make variables are lazy evaluated, so you can override them later in the game and have everything work. <jbailey> But it looks like when variables are used in rules, they're hard evaluated once immediately, not after a full pass of the Makefile has been read. <jbailey> cdbs2 solves this by putting all the evaluation into the shell and recursing into Make (so causing a reread each time) <jbailey> cdbs1 doesn't look like it'll have an adequate solution. <doko> !SESSION 2005-06-30 19:26:39.618 -----------------------------------------------eclipse.buildId= <doko> java.version=1.4.2_07 <doko> java.vendor=Sun Microsystems Inc. <doko> BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US <doko> Command-line arguments: -os linux -ws gtk -arch x86 <doko> !ENTRY org.eclipse.update.configurator 2005-06-30 19:26:42.337 <doko> !MESSAGE /usr/local/share/eclipse/plugins is not a valid plugins directory. <doko> !ENTRY org.eclipse.core.runtime 2005-06-30 19:26:43.921 <doko> !MESSAGE Product org.eclipse.sdk.ide could not be found. <doko> !ENTRY org.eclipse.osgi 2005-06-30 19:26:43.930 <doko> !MESSAGE Application error <wasabi_> Hmmmm. <doko> !STACK 1 <doko> java.lang.RuntimeException: No application id has been found. <doko> at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Unknown Source) <doko> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source) <doko> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source) <doko> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) <doko> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) <doko> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) <doko> at java.lang.reflect.Method.invoke(Method.java:324) <doko> at org.eclipse.core.launcher.Main.invokeFramework(Unknown Source) <doko> at org.eclipse.core.launcher.Main.basicRun(Unknown Source) <doko> at org.eclipse.core.launcher.Main.run(Unknown Source) <doko> at org.eclipse.core.launcher.Main.main(Unknown Source) <doko> wasabi_, you don't see the stack trace? <wasabi_> I saw it. I am considering it. <wasabi_> doko, can you mkdir /usr/local/share/eclipse and touch /usr/local/share/eclipse/.eclipseextension <wasabi_> and just let me know if it fixes it for you <doko> they exist <wasabi_> Hmmm. <wasabi_> Well this is odd. <doko> owned by root <wasabi_> readable though, right? <doko> $ eclipse <doko> using specified vm: /usr/lib/j2sdk1.4-sun <doko> yes <doko> hmm, defaults to the non-free jvm? <wasabi_> I have to do some thinking about that still. <wasabi_> If some user manages to get Sun's VM installed... do we want to go ahead and use it? Or make the user edit a config file to switch to it? <wasabi_> I chose the former for now. <doko> hmm, why not use gij as the default? <wasabi_> It does. <wasabi_> If Sun's isn't installed. <wasabi_> Check the file /etc/jvm.d/eclipse <doko> I don't call that a default ;-) <wasabi_> It needs to be thought about. <doko> hmm, and it doesn't like the blackdown installation ... <wasabi_> It should only require /bin/java at the path. <doko> ah, my mistake. typo in the path <wasabi_> Ahh! <wasabi_> I know the problem. <wasabi_> Hmm. That sucks. <wasabi_> apt-get install eclipse-sdk <wasabi_> Hmmmm. <wasabi_> That's going to have to be thought about. <jbailey> wasabi_: http://kyoto.larvalstage.net/ubuntu/ seems to have been down all day... <wasabi_> yeah. <wasabi_> Luckily you don't need it anymore <jbailey> You asked me to grab eclipse earlier for ppc testing, I've been trying occasionally. <wasabi_> archive.ubuntu.com <wasabi_> doko, can you open /usr/share/eclipse/configuration/config.ini, search for the line that contains org.eclipse.sdk.ide and replace it with org.eclipse.platform.ide <wasabi_> save, and try to launch. <doko> yes, that works <wasabi_> Alrighty. <wasabi_> Weird. For the life of me I have no idea what eclipse-sdk actually DOES. I suspect it's just a "metapackage" to upstream. <doko> can you fix the dependency stuff as well? <wasabi_> Which stuff is that? <doko> java-gcj-compat-dev in b-d <wasabi_> You mean add or remove it? It is in b-d <doko> ahh, remove java-gcj-compat <doko> -dev is enough <wasabi_> k <doko> drop libgcj6-dev, ecj-bootstrap, fastjar as well, these are java-gcj-compat-dev deps <doko> btw, is it still multiverse? <wasabi_> Yes. <doko> why? <wasabi_> Because I haven't verified that there are any multiverse deps left, and haven't told anybody to move it. <wasabi_> I suspect it's ready to move. <doko> see https://wiki.ubuntu.com//UbuntuMainInclusionQueue , what's needed ... <doko> I assume, you'll have to write one of these reports #ubuntu-java 2005-07-07 <wasabi> So. This JVM thing. Should I cut out Sun's? <doko> wasabi: hmm, no, make gcj the default. users should switch manually to one of the non-free jvm's. <doko> and add /usr/lib/j2se/1.4 (blackdown) <wasabi> that is non-free. <dalibor> sun-derived, same crappy license. <dalibor> (not literally, but same crap that prevents debian from shipping it) <wasabi> Yup. BLack-down is just Sun's VM. I don't even know what they alter in it. <dalibor> no idea. #ubuntu-java 2005-07-08 <ivoks> hi <wasabi_> hi <ivoks> i'm having problems with eclipse in breezy, if this is good place to ask about it <wasabi_> THe perfect place. <ivoks> hehe <ivoks> well, starting eclipse brings me message A suitable Java Virtual Machine for running the Eclipse platform could not be located <wasabi_> Hmmm. <wasabi_> yeah, I can see that happening. We need to figure out a better way of going about that. <wasabi_> apt-get install java-gcj-compat <ivoks> i did :( <ivoks> i have everything <ivoks> sun java too <wasabi_> Hmm. <wasabi_> Check out /etc/jvm.d/eclipse <ivoks> right <ivoks> that's it, i guess <wasabi_> Does that have /usr/lib/jvm/java-gcj listed in it? <ivoks> yes <ivoks> but before it it has j2sdk1.5 -> 1.3 <wasabi_> Does /usr/lib/jvm/java-gcj exist? <wasabi_> Yeah. <wasabi_> That should be fine. It will attempt to use those before it attempts to use java-gcj-compat <wasabi_> BUt since you don't have those. <ivoks> i have j2sdk1.4 <wasabi_> Hmm. Is the path right? <wasabi_> Basically that file lets you choose the VM search oder. <wasabi_> order <ivoks> i commented j2sdk, same problem <ivoks> i could strace it.. <wasabi_> No need. <ivoks> ok <wasabi_> run this <wasabi_> /usr/share/java-common/find_jvm.sh eclipse <ivoks> JAVA-HOME= <ivoks> s/-/_ <wasabi_> Hmmm. <ivoks> that's the problem :) <wasabi_> what? <ivoks> JAVA_HOME= should point to java libs, right? <wasabi_> You should not have to set Java_home at all anywhere. <wasabi_> It should be working right now. <wasabi_> paste me the contents of /etc/jvm.d/eclipse <wasabi_> and the output from dpkg -l java-common eclipse-rcp java-gcj-compat <wasabi_> Oh. Wait a sec. <wasabi_> I have a suspician. <wasabi_> env | grep JAVA_HOME <wasabi_> send me the output from that <ivoks> no output <wasabi_> that's good <ivoks> it worked before <wasabi_> That find_jvm command is supposed to scan the files in /etc/jvm and find the first working jvm. <wasabi_> but it's returning nothing. <ivoks> yes.. <ivoks> strace shows it drops right after zenity <wasabi_> strace isn't going to do much for you <wasabi_> send me the output of those files. <ivoks> jvm.d? <wasabi_> It's just one very simple shell script. <wasabi_> jvm.d/eclipse <ivoks> query <ivoks_> sorry about that... <ivoks> great job! eclipse starts a lot faster now <wasabi_> thans <wasabi_> thanks <wasabi_> wasabi_ doko, what do you think about integrating a update-gcj-classmaps script into gij? <wasabi_> wasabi_ It doesn't belong in Eclipse, and it doesn't belong in j-g-c <wasabi_> wasabi_ It belongs with gcj-dbtool. #ubuntu-java 2005-07-11 <pere> hm, no jeff bailey? #ubuntu-java 2005-07-14 <ryo> 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: <ryo> JVMXM005: Unable to initialize threads <ryo> Exception Could not create JVM. <ryo> can someone help me? <jbailey> ryo: It might be expecting the old LinuxThreads library. <jbailey> Your best bet is to use one of the Free VMs and hope that it will do everything you need. <ryo> 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 ;) <jbailey> Oh wiat, you said Hoary. <ryo> (no, it's not my final purpouse, i have to run tomcat with an application) <jbailey> So that's not going to be the problem, we did it for Breezy. <ryo> can I paste 5 lines from strace? I grepped "threads" from the output <jbailey> Yeah, running tomcat could be problematic since we don't have the security manager bits in place yet. <jbailey> Sure, but I may not be able to do much with it even if I see the problem. <ryo> strace -e open java 2>&1|grep -i thread <ryo> open("/lib/libpthread.so.0", O_RDONLY) = 3 <ryo> open("/opt/IBMJava2-ppc-142/bin/../jre/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <ryo> open("/opt/IBMJava2-ppc-142/jre/bin/classic/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <ryo> open("/opt/IBMJava2-ppc-142/jre/bin/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <ryo> open("/lib/libpthread.so.0", O_RDONLY) = 3 <ryo> JVMXM005: Unable to initialize threads <jbailey> Right, so the final one succeeds. <ryo> yes, it doesn't look for a particular release <jbailey> So without doing thread traces and whatnot, there's not much I can offer you. <jbailey> And those would only serve to let you file bugs against the IBM jvm. <jbailey> Have they published a 1.5 that you can try instead? <ryo> no, this is their last one :/ <ryo> jbailey: thank you very much for your support, i'm gonna try my last hope: switch back to 1.3.1 :| <ryo> thanks! bye <wasabi> I need a shell script wizard. <wasabi> jbailey, ? :) <jbailey> Can't right now, need food. <wasabi> jbailey, ping <wasabi> oh maybe n/m <jbailey> wasabi: I'm here now. <wasabi> I'm thinking about the gcj classmap thing. <jbailey> Thinking of going and playing video games, anything I can help with? <wasabi> Just wanted to bounce some ideas off you <wasabi> for cdbs <jbailey> 'sho nuff <wasabi> okay... right now I have as an example package: <wasabi> eclipse-rcp. <wasabi> eclipse-rcp-common and eclipse-rcp-gcj also <jbailey> rcp? <wasabi> rich client platform, just one of the eclipse pieces <wasabi> I <wasabi> 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 <wasabi> Also need to specify directories to use for all of those <wasabi> I'm thinking it may be a debian/packagename.gcj file or something, like .install and .dirs, etc. <jbailey> What doe sthe code that goes into the postinst look like? <wasabi> the postinst is very simple. It's the building of the classmaps that is hard. <wasabi> postisnt just runs /usr/sbin/update-gcj-classpamsp <wasabi> maps <wasabi> classmaps are in /usr/share/gcj-4.0/classmap.d, one per package <jbailey> We figured out that /usr/share is alright, even with jni stuff? <wasabi> 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 <wasabi> Yeah, it's fine. <wasabi> So there's 1 or more files in one or more packages which are mapped to 1 or more files in another package <jbailey> Aren't the names 1:1 ? <wasabi> No. <wasabi> Well, the names are. <wasabi> THe paths aren't. <jbailey> Right. <wasabi> There are .jars in /usr/share and /usr/lib, which map to .so's which are all in /usr/lib <jbailey> Is there any risk of conflicts? <wasabi> such as? <jbailey> Like a version being in /usr/share and another being in /usr/lib? <jbailey> (for jars) <wasabi> Oh, yeah. But that won't hurt anything. <wasabi> Not within the same source package. <jbailey> 'k <wasabi> So let's imagine eclipse-rcp-gcj.gcj <wasabi> it has something like <wasabi> eclipse-rcp:usr/share/eclipse/plugins:usr/lib/eclipse/plugins <wasabi> or equally crazy <wasabi> made up random syntax there. <wasabi> and eclipse-rcp-common:usr/share/eclipse/plugins:usr/lib/eclipse/plugins <wasabi> or maybe \t instead of : to keep inline with other dh files. <jbailey> Well, whitespace, but yeah. <jbailey> So thats BASE:jar:so ? <wasabi> yeah <jbailey> Is the only variant acceptable generally s/share/lib/ ? <wasabi> No. <wasabi> I can imagine some various situations. Some .jar's are platform independent. Some are platform dependent. <wasabi> Somebody might want to package them so the path isn't exactly the same s/share/lib <jbailey> Are 90% of the cases like that? <jbailey> Or do you imagine lots of variation in common cases/ <wasabi> yeah <wasabi> 90% would be similar <jbailey> I would do then something like this: <jbailey> usr/share/eclipse/plugins/eclipse-rcp.jar <jbailey> And have it assume it <jbailey> and for the other cases: <wasabi> Hmm? <wasabi> No... <jbailey> usr/share/eclipse/plugins/eclipse-rcp.jar usr/shitbox/foo/eclipse-rcp.so <wasabi> eclipse-rcp is a PACKAGE <wasabi> containing, oh, 10 jars <jbailey> Oh, I see. <jbailey> Does the .so file compile all the jars from one package together? <wasabi> I can see the need for packages which contain both jars and .so files <wasabi> no, seperate .so per jar <wasabi> packages which contain only .so files, and packages which contain .so files which would have mapped to two other packages with jar files. <wasabi> In eclipses case I have every feature broken down into three packages <wasabi> eclipse-name, eclipse-name-common and eclipse-name-gcj <wasabi> 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. <wasabi> eclipse-name-gcj contain the .so files in /usr/lib/eclipse which may map to either one of hte other packages <jbailey> 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. <wasabi> =) <wasabi> Well,go play games. <jbailey> The idea is that packages might be spread across multiple packages besed on arch:all and arch specific? <jbailey> debian packages, that is. <jbailey> (Feh, overloaded term) <wasabi> yeah <jbailey> Could you do something like: <jbailey> Hmm, lemme think through through. <jbailey> Because all the packages will exist in debian/tmp/usr/share/eclipse/plugins/eclipse-rcp <wasabi> Yeah, you see though. <wasabi> No, this is going to have to be done post install <wasabi> I've already figured that out <jbailey> Generating the classmap? <wasabi> that way the proper jars and .sos have already moved to debian/foo <wasabi> There are like, 100 Jars and .so files all in debian/tmp <wasabi> but some go to one package, some go to another <wasabi> dh_install does that <jbailey> Yeah, but aren't they already broken out by package? <wasabi> No. <jbailey> Oh. <wasabi> THey are all spewed in plugins <wasabi> /usr/lib/ecipse/plugins has every plugin... every Har. <wasabi> Jar <wasabi> Allare associated with a different Eclipse feature. <wasabi> 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. <jbailey> make a dh_installjar to handle it in one step? <wasabi> Sure, but it will have to duplicate everything dh_install does. <wasabi> ANd it'll be a bit confusing to know to put Jars in it <jbailey> Nah, we already have that with things like dh_installman <wasabi> ahh. <jbailey> $ ls dh_install* <jbailey> dh_install dh_installemacsen dh_installmime <jbailey> dh_installcatalogs dh_installexamples dh_installmodules <jbailey> dh_installchangelogs dh_installinfo dh_installpam <jbailey> dh_installcron dh_installinit dh_installppp <jbailey> dh_installdeb dh_installlogcheck dh_installwm <jbailey> dh_installdebconf dh_installlogrotate dh_installxfonts <jbailey> dh_installdefoma dh_installman dh_installxmlcatalogs <jbailey> dh_installdirs dh_installmanpages <jbailey> dh_installdocs dh_installmenu <wasabi> that's fine then, as long as it supports globs and everything else #ubuntu-java 2005-07-15 <wasabi> and it's not per-package etiher. <wasabi> which differs from all those, right? <jbailey> which package fo you mean? =) <wasabi> I dunno. This is confusing. <jbailey> Hmm, this doesn't cover the case where make install installs a single package right into the package directory. <wasabi> Heh. <wasabi> Don't those go in debian/tmp? <jbailey> The default case for cdbs where there's only one package is to install right into the package directory. That way you don't have to do any dh_install linda89@example.com. <wasabi> ahh. <jbailey> Well, I guess in the case of a single package, the package can just call the classmap generator itself, or cdbs could do a generic one. <wasabi> jbailey, still around? <wasabi> me->bed <Hikaru79> Does anyone here know what's up with the "Ubuntu Java Project," if those repos are supposed to still be up? <CoreDumped> eclipse or netbeans will be package to ubunto? <wasabi> eclipse already is <CoreDumped> what is the name of package? <wasabi> eclipse-sdk <wasabi> It is in breezy. <CoreDumped> ah, ok <CoreDumped> when will be in hoary <CoreDumped> ? <doko> never <CoreDumped> doko: why? <wasabi> Because Hoary never gets new software? <wasabi> Ever. <doko> correct <CoreDumped> :) oke <CoreDumped> ok #ubuntu-java 2005-07-16 * netjoined: irc.freenode.net -> kornbluth.freenode.net <wasabi> Need some packaging advice. <wasabi> I have totally altered /usr/share/eclipse and /usr/lib/eclipse. Mnay dirs turned to symlinks, many symlinks turned to dirs. <wasabi> dpkg of course plays havok with that. <jbailey_> Yeah. dpkg will follow symlinks to install things. <wasabi> So how do I clean it up proper? I have come up with this less-than-stellar idea. <wasabi> Introduce a new "eclipse-base" package and have it rmdir /usr/share/eclipse and /usr/lib/eclipse on clean install. <jbailey_> First can you tell me why there's a symlink farm? <wasabi> Eclipse's home has been moved to /usr/lib/eclipse <jbailey_> So you're just trying to preserve existing installs? <wasabi> Packages split into eclipse-feature, eclipse-feature-common and eclipse-feature-gcj <wasabi> No. I am just trying to make upgrading possible. <wasabi> -common stuff installs to /usr/share/eclipse <wasabi> non -common stuff installs into /usr/lib/eclipse, including a symlink farm in plugins pointing to /usr/share/eclipse/plugins <wasabi> (arch indep plugins) <wasabi> This is because Eclipse creates different plugins per arch. <jbailey_> Upgrading from what? <jbailey_> Current breezy <wasabi> Previous packages. <jbailey_> ? <wasabi> Yeah <jbailey_> Do the symlinks eventually go away? <wasabi> No. <jbailey_> If not, should eclipse simply be hacked to look in both places? <wasabi> I'd imagine that is pretty hard to do. <wasabi> Here's the thing. take eclipse-rcp <wasabi> It installs plugins/org.eclipse.swt.gtk.linux.x86/ <wasabi> on ppc is's called ppc <jbailey_> That's /usr/lib/eclipse/... ? <wasabi> Yup. <wasabi> /usr/lib/eclipse/plugins <wasabi> My delima was I can't put a file named x86 in /usr/share <wasabi> Or I'd have to put the files named ppc and ppc64 and amd64 blah blah in there also. <jbailey_> But eclipse expects to find things in /usr/share/eclipse/plugins/org... ? <wasabi> It used to. <wasabi> Last version's Eclipse home was /usr/share/eclipse. <wasabi> One dir, it can't search outside it for core plugins. <jbailey_> Ah, hmm. <wasabi> I can't explain this right can I? <jbailey_> No, I think I understand. <wasabi> Eclipse "lives" in one directory. It expects to have the core plugins there. <jbailey_> I'm just trying to think of a way to solve this without needing a symlink farm. <wasabi> Some core plugins are platform dependent. <wasabi> It actually works out pretty decently... it's just annoying on upgrade. <jbailey_> So do you symlink for each plugin then to the common directory? <wasabi> I could nix -common and install EVERYTHING to /usr/lib, but I wanted to put things in -common for archive space <wasabi> Yes. Correct. <wasabi> It's sort of like /usr/lib/X11 <jbailey_> Yeah. <jbailey_> Except fUglier. <wasabi> Well, I wrote a 3 lines bash snippet to do it. <wasabi> hehe. <jbailey_> Sounds like my mother in law is awake, I might be able to use the main terminal now, just a sec. <wasabi> Let me upload my packges for you <wasabi> I mean, I have it working... I just want advice on whether there's a better way. <wasabi> I really don't fancy hacking around in Eclipse to solve it. <jbailey_> The only thing better would be to teach eclipse the concept of looking in multiple places. <wasabi> It has the concept, just not for core plugins. <wasabi> swt is a core one. <wasabi> http://akita.larvalstage.net/~wasabi/eclipse <jbailey> Much better. <wasabi> ANyways, with this trick, if you figure out how to get ppc compiling, it should work. :0 <jbailey> Grab the .orig from the archive? <wasabi> Yes <bebop> hi <wasabi> hi <wasabi> Well, what I ended up doing is creating an eclipse-base package, which everything pre-depends on. <wasabi> I can define that as the base of all eclipse features, put the binary in it, etc. <jbailey> Err. it's not in main? <wasabi> universe <jbailey> Cool, fetching. <bebop> im newbie of java and pbms are already raising: i have error in samples of xerces just downloaded <wasabi> And eclipse-base rm -rf's /usr/lib/eclipse and /usr/share/eclipse on clean install <wasabi> Which is fine since nobody has yet packaged any other plugins. <jbailey> Well..... <jbailey> The risk is clobbering something local that someone has done. <wasabi> Yeah. <jbailey> So it should really only be done on an upgrade, and if type can be narrowed, that would be great. <wasabi> I recognize it as a risk, but I don't think that at this stage it matters.... <wasabi> First off, there's nothing people should be modifying in /usr/share/eclipse. <wasabi> jbailey, it's not an upgrade though. <jbailey> Right, but do thou not try to outthink the sysadmin, for he is mad and is therefore unpredictable. <wasabi> eclipse-base never previously existed. <jbailey> Yeah, hmm. <wasabi> I'm heading to work now. Let me know what you think. ;) <wasabi> bbs <jbailey> Will do, I'm just starting the build here on ppc. <wasabi> I know it won't work. Swt still doesn't build. <jbailey> Yeah, maybe I can convince it. <wasabi> But you are more than welcome to conquer that. ;) <wasabi> cya <jbailey> Compiling 484 source files to /home/jbailey/Programming/packaging/eclipse/eclipse-3.1/linda89@example.com <jbailey> wtf? <jbailey> this is powerpc-linux... <mgalvin> hi all <robilad> hi mgalvin <wasabi_> howdy <jbailey> wasabi_: /tmp/ccDIVnqk.s:5112275: Error: operand out of range (0x0000000000008000 is not <jbailey> between 0xffffffffffff8000 and 0x0000000000007fff) <jbailey> Is this what you were seeing on ppc? <wasabi_> gcj thing? <wasabi_> No. that's new. <wasabi_> What I was talking about was most likely a simple build script problem. <jbailey> Got some info from the gcj folks. Seems there's a hack to aot-compile that we ought to be using to split jar files. <jbailey> wasabi_: Any objections to me updating aot-compile from java-gcj-compat and using it in eclipse? <wasabi_> Depends what aot-compile is <wasabi_> Never noticed it before. <jbailey> It's a jar to .so wrapper script. <wasabi_> Oh. <wasabi_> New to me. <wasabi_> No objection. <jbailey> Apparently it now splits jar files for compilation to work around this bug I'm seeing on ppc. <wasabi_> So you see my symlink stuff? <jbailey> I haven't got that far yet, sorry. <jbailey> I followed the conversation in #gcj while looking at some kernel stuff for Fabio. #ubuntu-java 2005-07-17 <oz_> hi all - I'm trying to work out which packages I need to do some java-gnome dev. Do I really need gcc 4 with libgtk2-java? <jbailey> oz_: The VM we use by default is gij, which is a component of gcc. <jbailey> gcj (used to make native versions of Java packages) might bring in gcc. <jbailey> ecj (the best .class -> .java compiler we have) shouldn't, though. <oz_> does the sun jvm work ok? <jbailey> No idea. Not on my system, which is a powerpc. <jbailey> It generally ought to, though. <jbailey> You might find your best luck with the blackdown jvm, which I think is in multiverse now. <oz_> ah- <oz_> is there a way to avoid installing gcc 4. synaptic want's to uninstall gcc 3.x which I think will cause pain... <oz_> do I just have to build from sources? <jbailey> What release of Ubuntu are you using? <oz_> 5.04 <jbailey> Which piece of gcc-3 is it trying to uninstall? <jbailey> (And blackdown wasn't in the April release, I remember now) <oz_> gcc-3.5-base <wasabi> How did blackdown get in multiverse? <wasabi> Canonical accepted the license? hah. <jbailey> wasabi: I think it's in. sabdfl didn't seem concerned about the problematic clause. <wasabi> Mine as well bundle Sun's then <wasabi> THey are the same. <wasabi> Sun Microsystems, Inc. <wasabi> Binary Code License Agreement <wasabi> for the <wasabi> JAVATM 2 SOFTWARE DEVELOPMENT KIT (J2SDK), STANDARD EDITION, <wasabi> VERSION 1.4.2_X <wasabi> Same exacty license. <wasabi> Blackdown doesn't really serve much of a useful purpose anymore. I think the original idea was to be THE Linux port, but as Sun did it themselves... <wasabi> Pretty much it just introduces an entire new class of crashes heh <jbailey> Right. <jbailey> Well, also given that blackdown is pretty slow about producing new ports. <wasabi> Well, if he doesn't have a problem with that, he won't have a problem with Suns. <jbailey> Tell you what - I don't really want to think about it. =) <wasabi> haha <jbailey> The whole thing gives me the heeby-jeebies. * jbailey prays for alexandria or whatever it's called. <wasabi> What is that? <jbailey> Apache's VM <wasabi> Psssh. <oz_> harmony <jbailey> That's the one. <wasabi> Unless they get a code confusion they are in the same boat as us. <wasabi> In fact they'll probably just end up contributing to Classpath <jbailey> Right, I think that's the idea. <jbailey> And that the result can get certified. <jbailey> It's the certified result that's the important part. <wasabi> Hmm. WHere did you read this about the sabfdl? <jbailey> It was a conversation in a /msg between he and I. <wasabi> iii) you do not distribute <wasabi> additional software intended to replace any component(s) of the <wasabi> Software (unless otherwise specified in the applicable README <wasabi> file) <jbailey> And he's also spoken to elmo about it. <jbailey> Right. <jbailey> His view was something like none of the Free VMs are intended to replace. <jbailey> Suppliment, sure, sit along side. <wasabi> Haha tell that to the people who wrote them. <jbailey> And also that the non-Free VM could conflict against the Free VMs so that they just were never installed side by each. <wasabi> Well, I'm just worried about this one. I'd like to have a public discussion about it. <jbailey> Like I said, I just want to step away from it slowly. I'd be happiest if a lawyer said 'yeah, sure', but if it makes it in, then it also made it past elmo, who's more paranoid than I. <wasabi> jbailey, if I wanted to get some talk about this going, how would I? <wasabi> I suspect the tech board or something <jbailey> Including the Sun JVM rather than the blackdown one? <wasabi> I'd just like to know how the license was "rationalized. <wasabi> I'm curious. <wasabi> Since no other distributer ever has come to that conclusion. hehe. <jbailey> Is it actually in the archive now? <wasabi> Naw. <wasabi> I don't see it. <jbailey> Then probably there was another round of nervousness. <wasabi> Heh. <oz_> wasabi: have a look at http://ubuntuforums.org/archive/index.php/t-8651.html <wasabi> Heh, why? <wasabi> That's almost a year old. <oz_> I don't think the licence has changed since then <wasabi> It hasn't. But that's not related to the current convo about the sabfdl. <oz_> 6 Months old <jbailey> wasabi: Unfortnuetaly, the conversation is in the logs I lost when I wiped my homedir back in February. <wasabi> These people are just ignoring the license in backports. <wasabi> What tools. <wasabi> They didn't even read it. <wasabi> Or read it and dismissed it. <wasabi> I guess it's not exactly my business... it just bugs me. <wasabi> I'd rather they go through the same hell we do so they'll promote free java. ;0 <oz_> I don't suppose anyone could help out with a "ListenerDelegate.create failure" using glade and sun 1.5 jdk? <wasabi> java-gnome? <wasabi> newp. <oz_> java-gtk.. <oz_> Can you guys suggest which gcj version to install? gcj- 3.3.x, 3.4.x or 4.0? <wasabi> 4.0 <oz_> thanks <oz_> do you know what version of java it supports (roughly) <wasabi> That's not a very good question. <wasabi> Mostly because it really doesn't. <wasabi> I'm sure there are missing pieces from java 1 <wasabi> Swing barely works, but sort of. <oz_> yeah - I kinda gathered that.. <wasabi> But it does run Eclipse. <wasabi> So it has that amount of API coverage. <oz_> I'm just trying to get some gnome understanding - so i'm building the latest java-gnome java-gtk etc. <oz_> I was just interested in whether it had support for generics enhanced for loops etc .etc <wasabi> Almost. <oz_> Thanks <oz_> sorry to be a pain - I'm trying to build libgtk-java-2.6.2 from source _but_.. <oz_> I get an error: checking for gtk+-2.0 >= 2.6.0... Package gtk+-2.0 was not found in the pkg-config search path. <oz_> Do you guys know what it's looking for? <wasabi> libgtk something <wasabi> -dev <oz_> hrmm... i was hoping that wasn't it: another 16 packages and a 55 MB download <oz_> I can't believe how difficult and frustrating this has all been. But hey - thanks for the help and info. <oz_> thanks guys - later #ubuntu-java 2005-07-18 <mgalvin> hey guys, does tomcat run on top of gcj/gij <mgalvin> if so will there be a tomcat package for breezy <jbailey> None of the Free VMs have a working security manager. <jbailey> So the problem is that it *could* work, but you don't have any of the usual safety guarantees of Java. <mgalvin> ah i c <mgalvin> thnx <wasabi_> that's not what's holding it back <wasabi_> We just need tomcat 5 packages. <wasabi_> it runs fine (- security manager) <wasabi_> tomcat4 makes use of com.sun classes which are not in free JVMs <mgalvin> wasabi_ are there plans for getting tomcat5 packages into breezy? <wasabi_> I doubt we'll make breezy. <wasabi_> In fact, we won't. <wasabi_> Probably breezy +1 though <jbailey> wasabi_: Well, I wasn't mentioning the state of the packaging so much as why you shouldn't do it even if you can right now. <wasabi_> ahh, the security manager really isn't that big of a deal except for ISVs <jbailey> How do you figure? <wasabi_> The security manager protects you from code you yourself choose to run. <wasabi_> So does running as another user. <wasabi_> Or... more than
{'channel': 'ubuntu-java', 'month': 7}