| mib_hku7zs1f | Can an applet that is compiled on a 64bit open in a 32bit ? | 00:01 |
|---|---|---|
| david_yu | has there been a java project being packaged by debian that was built by maven? | 04:55 |
| david_yu | we are trying get jetty6 have an official debian/ubuntu release | 04:57 |
| persia | There's been a lot of discussion about maven. Last I knew it wasn't quite ready to be used to build packages. | 05:34 |
| persia | Most of the work on this has been happening in Debian. | 05:35 |
| persia | Seems I'm out of date. See http://wiki.debian.org/Java/MavenBuilder | 05:36 |
| persia | And http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425152 is probably of most direct interest | 05:36 |
| ubottu | Debian bug 425152 in jetty "jetty: New upstream 6.1.3" [Wishlist,Open] | 05:36 |
| david_yu | thanks ... so basically, there has not been any maven-based java projects out there that has been packaged by debian | 06:54 |
| persia | Not as such. | 06:56 |
| persia | Or rather, not packaged normally. | 06:56 |
| persia | There's a means by which freely redistributable binary blobs can be distributed alongside Debian, and some of those are also distributed in Ubuntu's multiverse component. | 06:56 |
| persia | This mechanism has been used in the past for distributing the results of a build, but it's neither typical packaging nor generally considered optimal. | 06:57 |
| persia | I'd suggest that if you're working on jetty, you contact Tormod. He's probably the most knowledgeable about the current state of things, and how that affects Jetty. | 06:58 |
| persia | Once the remaining issues are resolved, Ubuntu would prefer to just sync. | 06:58 |
| david_yu | persia: hmm, so u mean debian accepts pre-built jars and just package it? or do they require that they build the whole project itself? | 06:59 |
| persia | For proper inclusion, it is required that everything be built from source. | 07:00 |
| persia | There's a means to distribute other bits (e.g. firmware), which has been abused in the past to work around issues with Java. | 07:00 |
| persia | If at all possible, I recommend trying to get it done the normal way. | 07:01 |
| david_yu | persia: if we could provide them our pom.xml files that they can build for themselves (using maven) and generate the debs (using maven), would they accept that? | 07:02 |
| david_yu | since I've noticed most packages I've seen are built with ant ... if they dont have a problem building with maven, that would work | 07:03 |
| persia | david_yu, Um. Could you more explicitly define "we" and "them" in that sentence? | 07:04 |
| david_yu | persia: we as in the jetty devs, and them as in the uploaders | 07:04 |
| persia | OK. | 07:04 |
| persia | I don't even think it's quite that much. I think it's that there might be some issues with building everything (with maven) from within Debian. | 07:05 |
| ttx | persia: What was the question ? | 07:06 |
| persia | And I still think that your best path is to chat with Tormod. I know he's been trying to build jetty, and a closer relationship between you and he would likely determine any remaining issues in short order. | 07:06 |
| david_yu | ah, where do I reach him? | 07:06 |
| persia | ttx, david_yu> persia: if we could provide them our pom.xml files that they can build for themselves (using maven) and generate the debs (using maven), would they accept that? | 07:06 |
| ttx | david_yu, persia: Torsten Werner was working on Maven support with the final objective of packaging Jetty6 with it | 07:07 |
| persia | ttx, Right. | 07:07 |
| persia | Ah, darn. I hate it when I misremember names. | 07:07 |
| * ttx looks up email address | 07:08 | |
| persia | david_yu, I'd recommend email right now. He doesn't seem to be in #debian-java@OFTC right now. | 07:08 |
| ttx | david_yu: see pm | 07:09 |
| david_yu | ttx: yea I saw his attempt to build jetty... I actually sent him a mail 3 days ago | 07:10 |
| ttx | http://wiki.debian.org/Java/MavenBuilder tracks his progress | 07:10 |
| persia | Well, and Debian bug 425152 | 07:10 |
| ubottu | Debian bug 425152 in jetty "jetty: New upstream 6.1.3" [Wishlist,Open] http://bugs.debian.org/425152 | 07:10 |
| persia | But he's really the best person to chat with about it. | 07:11 |
| david_yu | hopefully he's not too busy, sent him mail 3 days ago | 07:11 |
| ttx | david_yu: iirc the key issue was getting all the dependencies properly packaged | 07:12 |
| ttx | since we cannot use maven to /just/ provide them | 07:12 |
| ttx | david_yu: anyway, I am very much interested in getting jetty6 somewhere, so if I can act as facilitator somewhere, let me know | 07:13 |
| david_yu | actually with jetty6, the 3rd party dependencies are: slf4j (core), ant(jsp), eclipse-compiler(jsp) ... everything else are jetty modules | 07:14 |
| ttx | david_yu: it's not reasonable to try to emulate the build process using a simple ant build.xml ? That would remove the complexity of using maven on our build system from the equation | 07:15 |
| david_yu | so like when maven downloads the other depenencies, they are build-time dependencies, but not runtime dependencies | 07:15 |
| ttx | david_yu: unfortunately we need to package the build deps as well :) | 07:15 |
| david_yu | ttx: hmm, why is that ... most of them are maven-plugins required for build ... and junit | 07:16 |
| ttx | david_yu: then they should all be packaged already, good | 07:16 |
| ttx | (in Debian, maybe not synced to Ubuntu yet) | 07:17 |
| persia | One factor that may be important to note is that the buildds don't have network access, which is part of why we have to take special care, because maven can't download anything, so has to be convinced it's already present. | 07:18 |
| ttx | and you cannot install anything else on the buildds than packaged build dependencies. | 07:19 |
| ttx | david_yu: you can cc me on future emails with Torsten. At one point if it's a question of disponibility I might be able to stand in for him. | 07:21 |
| david_yu | persia: hmm, could we provide an initial repo(temporary ... just for the maven-plugins required along the way)? | 07:21 |
| persia | david_yu, If you'd like to help get the plugins packaged, that'd be great. | 07:22 |
| david_yu | yea I'd like to help | 07:22 |
| persia | I don't think it's best to try to hack around packaging them: that just increases the chance of some integration issue once they are packaged. | 07:22 |
| ttx | david_yu: basically we have been trying to make maven-built things compatible with our build-daemons for some time | 07:23 |
| ttx | david_yu: the initial Ubuntu spec was https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec | 07:24 |
| persia | So, based on the Plans on the Debian wiki page, I think building agreement on http://wiki.debian.org/Java/MavenRepoSpec is probably the next step. | 07:24 |
| ttx | it outlines the challenges and proposes a solution | 07:24 |
| ttx | but Torsten went faster with his solution | 07:24 |
| persia | And then adding the hooks to all the required libraries. | 07:25 |
| ttx | MavenRepoSpec and MavenBuilder | 07:25 |
| ttx | so we met in Berlin to discuss convergence and agreed that he was on the right track | 07:25 |
| ttx | david_yu: what TZ are you in ? | 07:26 |
| david_yu | +8 | 07:27 |
| ttx | hm, that doesn't help to join our #ubuntu-java meetings, unless we don't sleep, like persia | 07:27 |
| ttx | unless you don't sleep, I mean | 07:28 |
| david_yu | what time (GMT) do the meetings start? | 07:29 |
| ttx | 1400 | 07:33 |
| ttx | but we could move the time. It's not as if so much people came in | 07:33 |
| ttx | persia: no meeting this week ? | 15:11 |
| persia | Yes, I'm just not paying enough attention to the clock :/ | 15:11 |
| astromme | Hi all. I've got a question about https://bugs.launchpad.net/ubuntu/+source/soprano-backend-sesame/+bug/334186 | 18:57 |
| ubottu | Ubuntu bug 334186 in soprano-backend-sesame "soprano-backend-sesame requires missing /usr/lib/libjvm.so" [Undecided,Confirmed] | 18:57 |
| astromme | It looks like all that needs to happen is a symlink to /usr/lib/libjvm.so | 18:58 |
| astromme | Is that something that could happen for a Jaunty SRU? ScottK pointed me here | 18:58 |
| astromme | The bug currently prevents Soprano and Strigi (A pillar of kde, part of the search framework) from working at all with the java backend. | 18:59 |
| persia | Glah. Native libraries suck. | 18:59 |
| astromme | And the java backend is needed for anything resembling decent performance | 18:59 |
| persia | Right. | 19:00 |
| astromme | One of the comments on the bug report said that this is something that update-java-alternatives should probably be setting this symlink | 19:00 |
| persia | I'm not sure which of the fixes is the right one, unfortunately. | 19:00 |
| astromme | :( | 19:01 |
| persia | There's a fairly good argument that nothing should use /usr/lib/libjvm.so directly, because there's no promise the ABI is constant for different implementations. | 19:01 |
| persia | Which would make this a bug in the way that soprano-backend-sesame was built. | 19:01 |
| astromme | It looks like a symlink from $JAVA_HOME/jre/lib/i386/server/libjvm.so to /usr/lib/libjvm.so is what is needed | 19:02 |
| astromme | persia: hmm, interesting | 19:02 |
| astromme | but wait... then why are there headers for libjvm.so and why can things be built against it? | 19:02 |
| astromme | and what would be the 'correct' way? (I'm a true java packaging/library newb) | 19:03 |
| persia | Well, see, one builds against the .so and headers, and *should* end up linked against some specific implementation with a known ABI (e.g. libfoo.so.3.4.1) | 19:03 |
| persia | But that's in C. | 19:03 |
| astromme | persia: but java has many implementations | 19:04 |
| astromme | and you don't know which will be installed | 19:04 |
| persia | Right, which makes it tricky to know how to deal with something like this. | 19:04 |
| astromme | how do other java apps do this? | 19:04 |
| astromme | s/java apps/things that link against java libs/ | 19:04 |
| persia | 99% of java applications don't need to access libraries directly. | 19:04 |
| persia | Nearly nothing does, and arguably nothing should, except for JVM implementations. | 19:05 |
| persia | In an ideal world, each library that isn't written in Java provides Java bindings that link against the specific implementation. | 19:05 |
| persia | Then the JVM just runs itself, java apps, and the bindings glue. | 19:06 |
| persia | This looks like an extra-special case. | 19:07 |
| persia | Personally, I think that it ought link directly to openjdk's implementation, and depend on openjre, rather than on java2-runtime, but that's clearly not ideal. | 19:08 |
| persia | The risk of doing it any other way is that since it builds against openjdk, if someone has another implementation, we can't know it's ABI-compatible (since I don't think it must be for Java compliance) | 19:09 |
| persia | Of course, my knowledge of this corner of stuff isn't very deep, as it's the part of Java that I hide from the most. I prefer pure-java apps and libraries. | 19:10 |
| astromme | persia: ok, I think I understand | 19:12 |
| astromme | persia: this is something that really hurts kde users who want desktop search | 19:12 |
| persia | astromme, Then it needs fixing. How do you think it ought be fixed? | 19:13 |
| astromme | because the only way around it is to symlink manually (and of course that assumes an abi) | 19:13 |
| persia | Or hack ld.conf, which comes to the same thing. | 19:13 |
| astromme | true | 19:13 |
| persia | Or change the build instructions for the package, and rebuild to hardlink against openjdk (which means that people can't use it with Sun Java) | 19:13 |
| astromme | persia: For the Karmic cycle it is likely that soprano will move to a c++ library called virtuoso by default, which means this may not be as important after Jaunty | 19:14 |
| astromme | persia: Is java updated to be an abi break during the Jaunty update cycle? | 19:14 |
| astromme | persia: if not, I would suggest doing the symlink/ld.conf | 19:14 |
| astromme | (after testing it using openjvm, sun jvm) | 19:15 |
| persia | astromme, Would you mind testing that against all Java implementations in jaunty? | 19:15 |
| persia | If it happens to work with all of them, I'm happy with that solution. | 19:15 |
| persia | If it only works with some of them, then I think that's not complete | 19:15 |
| persia | (and only worry about java2-runtime providers: we don't care about the others, because they wouldn't satisfy the dependencies anyway) | 19:15 |
| astromme | persia: sure, I would test against all of them. Other than openjvm and sun java, what are the others? | 19:19 |
| persia | astromme, `aptitude show java2-runtime` should give you the list. | 19:20 |
| persia | It's basically openJDK, 2 versions of Sun java, and GCJ. | 19:20 |
| astromme | persia: I assume 'default-jre' is a metapackage? | 19:41 |
| persia | No, it's an actual package, with some bits here and there, but it doesn't contain a JVM implementation. | 19:42 |
| persia | It depends on different implementations for different architectures though. | 19:42 |
| persia | So, extra points if you also test against cacao :) | 19:42 |
| * astromme has never even heard of cacao! :P | 19:43 | |
| persia | http://www.cacaovm.org/ | 19:44 |
| astromme | So my plan would be purge old package, install new one, start all the daemons/etc fresh, test basic features (if it failed it would fail from the starting of the binary, right?), do a checkoff? | 19:44 |
| persia | Right. | 19:44 |
| persia | Install your package. | 19:44 |
| persia | Install a JVM | 19:45 |
| persia | make the symlink | 19:45 |
| persia | run it. | 19:45 |
| persia | purge the JVM, and install the next | 19:45 |
| persia | make the (different) symlink. | 19:45 |
| persia | run it. | 19:45 |
| persia | etc. | 19:45 |
| persia | To test cacao I think you need powerpc. | 19:45 |
| astromme | persia: if you can belive it, I had a Jaunty running powerpc until last week | 19:45 |
| astromme | we have a bunch of G5s here | 19:46 |
| astromme | Sadly it got reverted to osx. No nvidia drivers, meh | 19:46 |
| persia | Cool! It'd be lovely if you could test with cacao, as it's one of the less well tested JVMs, and I know that powerpc has a kubuntu userbase. | 19:46 |
| persia | pity. | 19:47 |
| astromme | truely is | 19:53 |
| astromme | the machine ran great | 19:53 |
| astromme | just that silly video card | 19:53 |
| astromme | (we need the machine as a media center, more or less) | 19:53 |
| persia | Oh well. For extra points, find someone who can test that case :) | 19:55 |
| astromme | ok | 19:55 |
| astromme | I'll see what I can do | 19:55 |
| astromme | I wonder if a livecd would be enough... | 19:55 |
| persia | But I suspect the package doesn't even build properly for architectures that don't have openjdk, so it probably doesn't matter that much. | 19:55 |
| persia | Nevermind. Looks like openjdk on powerpc does work to some degree. | 19:57 |
| astromme | hmm, interesting | 19:57 |
| astromme | Uh oh.... starting the server, terminate called after throwing an instance of 'CLuceneError' | 19:57 |
| astromme | I wonder if that has any relation to the java stuff | 19:58 |
| * astromme doesn't know how it all fits together really | 19:58 | |
| persia | astromme, So it worked with openJDK, and failed with the next JVM? | 19:59 |
| astromme | persia: that might just be my fault, I'm restarting my session. And it might be something else. It *looks* like it loaded the library correctly | 19:59 |
| astromme | (Soprano::PluginManager) loaded plugin from "/usr/lib/soprano/libsoprano_sesame2backend.so" | 19:59 |
| astromme | sesame2backend.so sesame2 is the java component that it uses | 20:00 |
| persia | Right, but that indicates that it loaded that library. The trick is when that library actually makes a call to java. | 20:00 |
| persia | Or rather to libjvm.so | 20:00 |
| astromme | hmm, ok | 20:00 |
| astromme | well let me see | 20:00 |
| persia | If the entry points don't match then it crashes (or executes something unexpected if you're particularly unlucky) | 20:01 |
| astromme | ok | 20:02 |
| astromme | Well, it appears to be indexing, which is a good sign | 20:02 |
| * astromme tries a search | 20:02 | |
| astromme | It found some music files, this is looking like it is working | 20:03 |
| astromme | Nepomuk is eating ram as usual.... lol they really need to figure out if the ram usage is a: reasonable and b: worth it | 20:06 |
| persia | That's encouraging. I don't suppose one of the ones you tried was gcj? | 20:08 |
| astromme | persia: not yet, the sun and openjdk | 20:09 |
| persia | They share some code history, which makes it easier that they match :) | 20:09 |
| * astromme is on stage 3 of four, sun-java6-jre | 20:12 | |
| astromme | persia: bad news bears... We might have problems with gcj | 20:28 |
| astromme | the nepomuk search process just hung on me | 20:28 |
| persia | That was the reason I feared this might not be the right solution. | 20:29 |
| persia | At least it makes it easier to fix, because it's only the one package that needs updating and testing, rather than the fuss involved in an update to how the JVM shared libaries are coordinated between JVMs. | 20:30 |
| persia | So, just change the build in such a way that the link is against the real location, rather than /usr/lib/libjvm.so | 20:30 |
| persia | And have the package depend on the openjdk jre, rather than java2-runtime | 20:31 |
| astromme | this is curios... now it is working | 20:32 |
| astromme | curious* | 20:32 |
| astromme | Hmm, ok, I suppose that would work | 20:32 |
| astromme | especially if we know it does work with one specific java implementation | 20:32 |
| astromme | wow, gcj is much slower, at least it seems so | 20:33 |
| === ttx is now known as ttx_ | ||
| === ttx_ is now known as ttx | ||
| persia | gcj is much slower when running java bytecode. Many gcj users prefer to compile java to native code. | 20:34 |
| astromme | interesting | 20:35 |
| astromme | persia: ok, I need your suggestion. It appears to work on all 4 java2-runtime providing-packges. I had a bit of instability with gcj, but that could have just as easily been nepomuk doing its "I'm going to hang" dance that it likes to do | 20:39 |
| astromme | Should we do the symlink? | 20:40 |
| astromme | Or should I run off to find whoever maintains the sesame2 package to get them to change how it is built | 20:40 |
| persia | astromme, You tell me which you think is less work for you (as you'll be the person who chases it, or so I guess from your interest). | 20:41 |
| persia | I can't upload the fixes for either solution. | 20:42 |
| persia | I'm not happy with the situation existing, but I'm not sure which solution is less bad. | 20:42 |
| astromme | hmm | 20:42 |
| persia | The real fix would be for the package not to link against that, but that's not going to happen in an SRU, because it would require massive code changes. | 20:43 |
| astromme | persia: I would go for option 1, symlink. My only worry is that would this give others a 'conceptual license' to exhibit the same bad behavior? | 20:44 |
| astromme | and if I understand it correctly, "symlink" can be replaced with "ld.conf change" and would result in the same thing? | 20:45 |
| astromme | how would this affect apps that linked against a specific (say openjvm) libjvm.so? Could they potentially get screwed up? | 20:45 |
| persia | Umm, maybe? | 20:49 |
| persia | I don't know how ld works well enough to answer that. | 20:49 |
| astromme | persia: Ok. Thank you for all of your help. Where would I go to move this further towards people who can actually make the change? | 20:56 |
| persia | I'd start by documenting the results in the bug. | 20:57 |
| persia | Then, I'd prepare a debdiff for any packages you want to change to fix it, and generally follow the guidelines for SRU | 20:57 |
| persia | !sru | 20:57 |
| ubottu | Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates | 20:57 |
| persia | When you get to the upload point, find a sponsor using one of the sponsoring queues. | 20:58 |
| persia | And I'm fairly certain the sponsoring will get bounced about until someone who understands the problem well enough gets it. | 20:58 |
| astromme | persia: ok, yikes sounds involved :P | 21:02 |
| persia | Well, yeah. | 21:02 |
| * astromme is just a humble kde dev, he hasn't messed with packages. | 21:02 | |
| astromme | But I understand the critical situation | 21:02 |
| persia | Oh, in that case, grab someone in kubuntu-devel to help you out. | 21:02 |
| astromme | I will, I came from there originally | 21:02 |
| persia | I know :) | 21:02 |
| persia | I'm hoping my explanations can help describe the issue better. | 21:03 |
| astromme | But not now, I've got other work :) | 21:03 |
| astromme | And I also understand how updates have to be taken very seriously, it is not good to break things in a release distro... not good at all | 21:03 |
| persia | Truth be told, the symlink solution scares me, largely because we rely so heavily on Debian to decide if things like that are safe. | 21:03 |
| astromme | That's true, I kept mulling it over | 21:04 |
| persia | And I'm just not sure the hack-the-build-to-force-openjdk is right either. | 21:04 |
| astromme | And in theory if something is packaged internally to a libjvm.so it could find (wrongly) /usr/lib/libjvm.so | 21:04 |
| astromme | which could cause bad bad problems if these things aren't ABI compat | 21:04 |
| astromme | well, that's the reason why we have multiple java implementations in the first place... so we don't depend on one single one | 21:05 |
| astromme | In any case, I'm out for now. Thanks persia, I will likely be back for more advice :) | 21:07 |
| persia | Happy to help to my limited ability :) | 21:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!