[02:53] <wasabi> jbailey, did you get ant up?
[02:53] <wasabi> I notice a reject from this mornig.
[02:55] <jbailey> wasabi: Can you forward me the reject message?  I left you as the maintainer, so I didn't see it.
[02:55] <jbailey> (or paste the relevant bits here)
[03:00] <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.
[03:00] <wasabi> I just got added to the keyring!
[03:00] <jbailey> Nice!
[03:00] <wasabi> From: 	James Troup <james@nocrew.org>
[03:00] <wasabi> Done - sorry for the delay.
[03:00] <wasabi> yay!
[03:00] <jbailey> Cool, give it a spin!
[03:02] <wasabi> DId you get ecj up?
[03:02] <wasabi> Oh yeah, you did.
[03:02] <wasabi> It just broke on amd64
[03:13] <jbailey> If you give me eclipse, I'll look at it on !i386 tomorrow.
[03:13] <wasabi> putting it togheter now. ;)
=== _ivan_ [~ivan@61.132.89.106]  has joined #ubuntu-java
[03:27] <wasabi> Hmm. It suceeded on i386 but never showed up.
=== _ivan_ [~ivan@61.132.89.106]  has left #ubuntu-java [] 
[04:14] <wasabi> Ant appeared in the archive in 10 minutes. ecj-bootstrap still isn't there.
[04:14] <wasabi> Wonder what causes that.
[04:53] <wasabi> http://akita.larvalstage.net/~wasabi/ubuntu/eclipse
[09:37] <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.
=== doko_ [~doko___@dsl-084-059-065-082.arcor-ip.net]  has joined #ubuntu-java
=== rtcm [~jman@217.129.142.72]  has joined #ubuntu-java
=== jbailey [~jbailey@CPE00501836c657-CM014260028338.cpe.net.cable.rogers.com]  has joined #ubuntu-java
[01:40] <jbailey> wasabi: g'm.  Is your uploading and such all working now?
=== doko [~doko___@dsl-084-059-065-082.arcor-ip.net]  has joined #ubuntu-java
[03:14] <wasabi> yeah
[03:17] <jbailey> Nice.
[03:22] <wasabi> Oh nifty. Even though ecj-bootstrap broke on amd64, it's still available on amd64.
[03:23] <wasabi> Since only the -gcj portion broke, the pure Java part is Arch: all.
[03:23] <wasabi> Yay for that.
[03:24] <wasabi> And the -gcj part simply enhances it. Makes it faster. It's not required.
[03:24] <jbailey> =)
[03:25] <wasabi> Eclipse 3.1 is going up. So you can play with it. It's still in multiverse though.
[03:26] <wasabi> But that's fine until all the kinks are worked out.
[03:27] <jbailey> Well, it would be nice to at least get it shifted to universe.
[03:27] <wasabi> I am quite confident about this package. I have spent hte last 3 days going over it with a fine tooth comb.
[03:27] <wasabi> A fine example of cdbs-powered art. ;)
[03:28] <jbailey> *lol*
[03:28] <jbailey> How much of it should eventually be rolled into a java module?
[03:29] <wasabi> whatcha mean?
[03:29] <wasabi> oh cdbs?
[03:29] <wasabi> Hmm.
[03:29] <wasabi> I'm not really that sure. I think we obviously need a dh_gcj or something.
[03:29] <jbailey> of cdbs / debhelper or whatever.
[03:29] <wasabi> I think you'll have a good idea when you read it.
[03:30] <wasabi> =)
[03:30] <wasabi> I'd like it to be as easy as firing of some dh_* to set up a native gcj version of a package.
[03:30] <wasabi> So, it needs to scan a certain prefix for jars, and map them to a certain other prefix.
[03:30] <wasabi> From one package to another.
[03:31] <jbailey> Can you write the logic out?
[03:31] <wasabi> I'll have to think about it a bit.
[03:31] <wasabi> in the meantime->shower/work/etc
[03:39] <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?
[03:40] <jbailey> doko: override DEB_ARCH_PACKAGES and DEB_INDEP_PACKAGES
[03:41] <doko> did I mention, that I love the cdbs documentation?
[03:41] <jbailey> doko: Someone has to. =)
[03:42] <jbailey> doko: Documentation is one of the only things holding up the cdbs2 release.
[03:42] <jbailey> Although what we have already is much better than cdbs1 had.
[03:44] <doko> wasabi: I don't like the ecj-bootstrap Recommends: ecj-bootstrap-gcj. did you see my pointer, that ecj is miscompiled?
[03:45] <wasabi> doko, I know that the dbtool thing is bad.
[03:45] <wasabi> The script included with j-g-c wasn't suitable though. I will be building a better script/tool.
[03:45] <doko> wasabi: and why does ecj-bootstrap-gcj depend on ecj-bootstrap?
[03:45] <wasabi> One is required for the other to work.
[03:45] <wasabi> ?
[03:46] <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.
[03:46] <wasabi> Debian will knock the recommends down.
[03:46] <wasabi> As they don't care very much about the default case. ;)
[03:46] <wasabi> s/cause/case/
[03:46] <doko> wasabi: I will knock them down as well, I do not want to recommend a miscompiled ecj
[03:47] <wasabi> That is being fixed.
[03:47] <wasabi> It's apparently a GCC bug or something.
[03:47] <wasabi> jbailey, ?
[03:47] <doko> wasabi: yes, but it's currently broken.
[03:47] <doko> wasabi: again, why does ecj-bootstrap-gcj depend on ecj-bootstrap?
[03:47] <jbailey> doko: Is it causing your grief?  The arch indep one should just work in its place automatically.
[03:48] <wasabi> Yup. That's the idea.
[03:48] <wasabi> THe native version isn't REQUIRED, but it's a speed enhancement when it's present.
[03:48] <doko> jbailey: I don't want users to install the -gcj one now.
[03:48] <wasabi> Why?
[03:48] <doko> because it's broken. recommends are installed automatically by synaptic
[03:49] <wasabi> It's only broken on amd64 though, it works as designed on all other platforms?
[03:49] <doko> wasabi: AFAIK it's broken on all platforms
[03:49] <jbailey> doko: The right thing is to extract the patch from gcc CVS head to fix some misdetection causing mmap grief.
[03:49] <wasabi> Well, it' sin the archive on i386, and works.
[03:50] <wasabi> And ppc apparently.
[03:50] <jbailey> What breakage are you seeing?
[03:50] <jbailey> I haven't tested it on ppc, but I can do so if you'd like.
[03:50] <doko> again: what's the reason for ecj-bootstrap-gcj Depends: ecj-bootstrap
[03:50] <wasabi> Gcj native compilation isn't a replacement for the non-native version.
[03:50] <wasabi> It is a runtime enhancement.
[03:50] <jbailey> doko: All the -gcj versions should depend on their -non -gcj counterparts.
[03:51] <wasabi> When the classloader grabs a .class out of the ecj.jar, it looks that .class's hashmap up in the classmap.db
[03:51] <wasabi> And then loads teh cooresponding .so file if present.
[03:51] <jbailey> That way you always can run the Java app, even if you try with a non-gij VM.
[03:51] <wasabi> vs interpreting the code.
[03:51] <wasabi> The original ecj.jar still has to be present.
[03:51] <wasabi> Not only that, but the ecj.jar has more than code in it. Resources.
[03:51] <doko> jbailey: sure, we will have this one with the next gcj upload
[03:52] <doko> wasabi, jbailey: would you mind writing down things as a policy?
[03:52] <jbailey> I beleive it's already in the wiki.  That's where Jerry and I did most of the brainstorming.
[03:52] <jbailey> wasabi: It does present the interesting question of what causes the -gcj version to be installed...  should the depends go the other way?
[03:53] <jbailey> That has the downside, though, that an arch that can't produce the -gcj for some reason would be uninstallable.
[03:53] <wasabi> Well, I was banking on synaptic automatically installing -gcj's for users. ;)
[03:53] <doko> http://udu.wiki.ubuntu.com/JavaRoadmap ?
[03:53] <doko> no
[03:53] <wasabi> For buildd's, it doesn't matter as much.
[03:53] <jbailey> wasabi: Ah. =)
[03:54] <wasabi> Maybe we didn't write this down. ;)
[03:55] <wasabi> what happened to JavaIntegration
[03:57] <jbailey> I thought there was more in there.
[03:58] <doko> it would be very nice, if we had something as a proposal for a policy ...
[03:59] <jbailey> Sure.  I'll try to cook something formal-looking up next week.
[03:59] <doko> you're at debconf?
[03:59] <jbailey> No.
[03:59] <doko> would be nice to have something for a bof however ...
[04:00] <jbailey> I'm moving this weekend, so I'm off the next 4 days, though.
[04:00] <jbailey> I think it's unlikely that Debian and Ubuntu will converge soon. =(
[04:00] <wasabi> the Eclipse debacle sort of highlights that. ;)
[04:00] <wasabi> jbailey, few shells cripts to be shized. ;0
[04:00] <wasabi> /usr/share/java-common/java-common.sh
[04:01] <jbailey> Joy. =)
[04:01] <wasabi> That one definitly. The binary launcher for eclipse and ecj, I don't care. In fact I like them Just Working in bash. ;)
[04:01] <wasabi> s/binary//
[04:01] <jbailey> wasabi: wimp. =)
[04:01] <wasabi> Just, the common component should be sh compatible.
[04:03] <doko> there are always two sides in a desaster ...
[04:03] <jbailey> The side that covered their asses and the side that didn't? =)
[04:04] <wasabi> Of coruse, whichever side I'm on, is right. ;)
[04:07] <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.
[04:10] <jbailey> RIght, but documenting conventions with no experience just means that things have to be changed afterwards.
[04:11] <jbailey> That's why Debian Policy reflects current best practice, not the other way around.
[04:17] <wasabi> jbailey, please grab Eclipse. =)
=== wasabi anxious!
[04:19] <wasabi> me->work()    bbl
[04:22] <doko> jbailey: please could you have a look chinstrap:~doko/ecj-bootstrap, despite DEB_ARCH_PACKAGES it wants to build the binary package
[04:26] <jbailey> scp: /home/doko/ecj-bootstrap: No such file or directory
=== jbailey looks
[04:27] <jbailey> ecj-bootstrap*
[04:29] <jbailey> doko: And the goal is that on amd64 would do not want with_native, right?
[04:29] <doko> yep
=== Bylli_79 [~bylli79@host1-107.pool81116.interbusiness.it]  has joined #ubuntu-java
[04:42] <jbailey> hmm.  That hack ought to be working.  When I test the constructs they work... =(
[04:42] <jbailey> (GNU Make really is quite annoying)
=== wasabi_ [~wasabi@207.55.180.100]  has joined #ubuntu-java
=== Bylli_79 [~bylli79@host1-107.pool81116.interbusiness.it]  has left #ubuntu-java [] 
[04:45] <jbailey> Erp. It looks like make rules don't lazy evaluate the variables.
[04:46] <wasabi_> What's that mean?
[04:46] <wasabi_> Something to do with patsubst? :0
[04:47] <jbailey> Yeah, doko's trying to override the package list from debian/control.
[04:47] <jbailey> It hasn't come up in any other packages, but we planned for it.
[04:47] <jbailey> Usually make variables are lazy evaluated, so you can override them later in the game and have everything work.
[04:48] <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.
[04:48] <jbailey> cdbs2 solves this by putting all the evaluation into the shell and recursing into Make (so causing a reread each time)
[04:49] <jbailey> cdbs1 doesn't look like it'll have an adequate solution.
[07:29] <doko> !SESSION 2005-06-30 19:26:39.618 -----------------------------------------------eclipse.buildId=
[07:29] <doko> java.version=1.4.2_07
[07:29] <doko> java.vendor=Sun Microsystems Inc.
[07:29] <doko> BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US
[07:29] <doko> Command-line arguments:  -os linux -ws gtk -arch x86
[07:29] <doko> !ENTRY org.eclipse.update.configurator 2005-06-30 19:26:42.337
[07:29] <doko> !MESSAGE /usr/local/share/eclipse/plugins is not a valid plugins directory.
[07:29] <doko> !ENTRY org.eclipse.core.runtime 2005-06-30 19:26:43.921
[07:29] <doko> !MESSAGE Product org.eclipse.sdk.ide could not be found.
[07:29] <doko> !ENTRY org.eclipse.osgi 2005-06-30 19:26:43.930
[07:29] <doko> !MESSAGE Application error
[07:29] <wasabi_> Hmmmm.
[07:29] <doko> !STACK 1
[07:29] <doko> java.lang.RuntimeException: No application id has been found.
[07:29] <doko>         at org.eclipse.core.internal.runtime.PlatformActivator$1.run(Unknown Source)
[07:29] <doko>         at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
[07:29] <doko>         at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source)
[07:29] <doko>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[07:30] <doko>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[07:30] <doko>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[07:30] <doko>         at java.lang.reflect.Method.invoke(Method.java:324)
[07:30] <doko>         at org.eclipse.core.launcher.Main.invokeFramework(Unknown Source)
[07:30] <doko>         at org.eclipse.core.launcher.Main.basicRun(Unknown Source)
[07:30] <doko>         at org.eclipse.core.launcher.Main.run(Unknown Source)
[07:30] <doko>         at org.eclipse.core.launcher.Main.main(Unknown Source)
=== jbailey [~jbailey@CPE00501836c657-CM014260028338.cpe.net.cable.rogers.com]  has joined #ubuntu-java
[08:06] <doko> wasabi_, you don't see the stack trace?
[08:07] <wasabi_> I saw it. I am considering it.
=== tashiro [~stephan@p213.54.197.246.tisdip.tiscali.de]  has joined #ubuntu-java
[08:38] <wasabi_> doko, can you mkdir /usr/local/share/eclipse and touch /usr/local/share/eclipse/.eclipseextension
[08:38] <wasabi_> and just let me know if it fixes it for you
[08:40] <doko> they exist
[08:41] <wasabi_> Hmmm.
[08:41] <wasabi_> Well this is odd.
[08:42] <doko> owned by root
[08:42] <wasabi_> readable though, right?
[08:42] <doko> $ eclipse
[08:42] <doko> using specified vm: /usr/lib/j2sdk1.4-sun
[08:42] <doko> yes
[08:43] <doko> hmm, defaults to the non-free jvm?
[08:43] <wasabi_> I have to do some thinking about that still.
[08:43] <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?
[08:44] <wasabi_> I chose the former for now.
[08:46] <doko> hmm, why not use gij as the default?
[08:46] <wasabi_> It does.
[08:46] <wasabi_> If Sun's isn't installed.
[08:46] <wasabi_> Check the file /etc/jvm.d/eclipse
[08:46] <doko> I don't call that a default ;-)
[08:47] <wasabi_> It needs to be thought about.
[08:47] <doko> hmm, and it doesn't like the blackdown installation ...
[08:48] <wasabi_> It should only require /bin/java at the path.
[08:49] <doko> ah, my mistake. typo in the path
[08:55] <wasabi_> Ahh!
[08:55] <wasabi_> I know the problem.
[08:56] <wasabi_> Hmm. That sucks.
[08:56] <wasabi_> apt-get install eclipse-sdk
[08:56] <wasabi_> Hmmmm.
[08:56] <wasabi_> That's going to have to be thought about.
[08:59] <jbailey> wasabi_: http://kyoto.larvalstage.net/ubuntu/ seems to have been down all day...
[09:00] <wasabi_> yeah.
[09:00] <wasabi_> Luckily you don't need it anymore
[09:00] <jbailey> You asked me to grab eclipse earlier for ppc testing, I've been trying occasionally.
[09:00] <wasabi_> archive.ubuntu.com
[09:25] <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
[09:25] <wasabi_> save, and try to launch.
[09:27] <doko> yes, that works
[09:27] <wasabi_> Alrighty.
[09:28] <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.
[09:28] <doko> can you fix the dependency stuff as well?
[09:28] <wasabi_> Which stuff is that?
[09:28] <doko> java-gcj-compat-dev in b-d
[09:29] <wasabi_> You mean add or remove it? It is in b-d
[09:31] <doko> ahh, remove java-gcj-compat
[09:31] <doko> -dev is enough
[09:31] <wasabi_> k
[09:32] <doko> drop libgcj6-dev, ecj-bootstrap, fastjar as well, these are java-gcj-compat-dev deps
[09:32] <doko> btw, is it still multiverse?
[09:32] <wasabi_> Yes.
[09:33] <doko> why?
[09:33] <wasabi_> Because I haven't verified that there are any multiverse deps left, and haven't told anybody to move it.
[09:33] <wasabi_> I suspect it's ready to move.
[09:35] <doko> see https://wiki.ubuntu.com//UbuntuMainInclusionQueue , what's needed ...
[09:35] <doko> I assume, you'll have to write one of these reports
=== rtcm [~jman@217.129.142.72]  has joined #ubuntu-java