| ScottK | Anyone around and awake and interested enough to look at a Java packaging bug? | 05:13 |
|---|---|---|
| ScottK | https://bugs.edge.launchpad.net/ubuntu/+source/jlha-utils/+bug/256275 | 05:14 |
| catto | hello | 08:47 |
| catto | when I run aptitude show sun-java6-jre | 08:47 |
| catto | exist a conflict with j2se-common | 08:48 |
| catto | so the virtual machine doesnt work | 08:48 |
| persia | ScottK: I'm tempted to say NotABug: the dependencies are mostly that of Java itself. That said, there's some efforts to make headless java (not requiring X, sound, etc.) work better, at which time this is more soluable. | 09:16 |
| kaaloo | Hi I'm working on packaging grails, learning a lot about packaging ! :) There are existing packages for most build dependencies, however some major ones are missing, like hibernate3 or spring for instance. Is it ok for the source package to include the needed jars ? Or am I facing a recursive packaging problem ? | 09:39 |
| persia | kaaloo: There is a need for recursive packaging. | 09:44 |
| persia | The main reasoning for this is 1) it's best to have code in only one place, so by packaging the dependencies separately, any package that wants then can use the same one (and bugs fixed provide common benefit). 2) There's an interest in linking one package to one upstream release file for ease of updating later: this vastly simplifies the work of keeping the packages up to date. | 09:45 |
| persia | I suppose 3) it makes licensing easier when using one source might also apply, but it may not, depending on the specific packages considered. | 09:46 |
| kaaloo | persia: thanks for the insights ! so I should start with a subcomponent then. There is actually something small I would like to change in the existing groovy package which is a build and runtime dependency for grails. It depends on sun-java6-jdk instead of default-jdk. Once I've made that change in the control file I can test the build with pbuilder. If it builds ok, how do I submit a patch for that ? | 10:06 |
| persia | kaaloo: Ideally, file a bug and attach a debdiff for a new candidate revision that fixes it. Then subscribe the sponsors queue. For help getting your work into Ubuntu, #ubuntu-motu can help | 10:08 |
| persia | (for help figuring out Java packaging, this is a good place) | 10:08 |
| kaaloo | persia: thanks I'll work on doing that then for the groovy package, and work on it from there for grails. first things first ! :) | 10:12 |
| persia | kaaloo: Thanks for helping! | 10:12 |
| kaaloo | persia: yes I would like to help, have to learn more about packaging though, I hope there are not too many dependent packages to do from scratch though. Oh ! One more thing, I was wondering about debian, if I manage to package grails and the missing dependent packages for intrepid, will they get included in the upstream distribution at some point ? | 10:18 |
| persia | kaaloo: Not automatically. If you get them in shape, it would be great to also get them in Debian. | 10:22 |
| kaaloo | persia: ok I'm going to file a bug on the groovy package then and I will try to submit the patch then for the default-jdk dependency, hope that will get me started ! | 10:23 |
| persia | I'll admit that I'm not sure exactly how the Debian Java team takes new packages, but perhaps you can discover it from http://java.debian.net/ | 10:24 |
| persia | kaaloo: Excellent. | 10:24 |
| kaaloo | persia: what's strange is that there is a groovy project in launchpad, and there is the groovy package in the ubuntu project in lp, they don't seem to be related | 10:24 |
| kaaloo | persia: oh there is already another dependency bug listed for another component, I can check that one out at the same time | 10:25 |
| persia | kaaloo: Yeah. Name conflicts are interesting. For amusement, take a look at the git and epiphany packages some time. | 10:25 |
| kaaloo | persia: hmm, better stick to my original intent, but I'm going to see what I can do | 10:27 |
| kaaloo | persia: oh its not a name conflict, its the same stuff, it talks about linking to upstream, but its now a package in ubuntu since hardy apparently | 10:28 |
| kaaloo | persia: to maintain compatibility with hardy, should I add default-jdk as an alternative to the existing sun-java6-jdk build dep ? I see you can combine them with pipe | 10:49 |
| slytherin | kaaloo: hardy doesn't have default-jdk package | 10:49 |
| kaaloo | slytherin: yes I know, I wanted to update the groovy package build dep to default-jdk | 10:50 |
| kaaloo | slytherin: for instance in the jbossas4 package I see depends like default-jre | java1-runtime | java2-runtime | 10:51 |
| slytherin | kaaloo: if you are doing that for intrepid, sure go ahead. Of course you need the dependency or only if you ever plan to request backport for hardy. | 10:51 |
| slytherin | kaaloo: otherwise default-jdk | sun-java6-jdk is not really needed. | 10:51 |
| kaaloo | slytherin: ok thanks, yes I'm doing it for intrepid, but I suppose since hardy is a its its better to be compatible with hardy backports, what do you think ? (I'm quite new at this) | 10:52 |
| kaaloo | slytherin: sorry an LTS | 10:52 |
| kaaloo | slytherin: I suppose if default-jdk is backported then we're ok, I'll focus on intrepid | 10:53 |
| slytherin | kaaloo: backports are not officially supported package. The only reason to keep sun-java6-jdk is to allow backport without change. May be you can remove sun jdk and add it later to facilitate backport if someone requests it. | 10:54 |
| kaaloo | slytherin: yes that's what I meant :) cool. Now I just want to try to build the new package with pbuilder, how can I updated the .dsc file ? The instructions I have are pbuilder *.dsc but its the original version | 10:55 |
| slytherin | kaaloo: when you change control file, add an entry in debian/changelog with an increased version number. 'dch -i' should help you. Then do a debuild -S -sa which will generate .dsc for new version. | 10:57 |
| kaaloo | syltherin: ok thanks ! yes I updated the changelog, but didn't know about the -i option. I'll generate the new .dsc and try that build then | 10:59 |
| slytherin | kaaloo: the dch -I was for auto adding a changelog entry. | 11:00 |
| kaaloo | slytherin: ok thanks | 11:01 |
| kaaloo | slytherin: let's see if the pbuilder build works | 11:03 |
| persia | kaaloo: Personally, I think it's better to make the transition for intrepid, even though it won't backport: we should really clean up the Java dependencies. See https://bugs.edge.launchpad.net/ubuntu/+source/jlha-utils/+bug/256275 for an example of what can go wrong. | 11:22 |
| slytherin | persia: if it is a command line program, shouldn't it have *-jre-headless as dependency? | 11:26 |
| persia | slytherin: Yes. I thought I remembered Koon saying something about headless not being ready yet. If you think it can just be switched, that sounds good to me. | 11:27 |
| slytherin | persia: I will talk with Koon first to understand what exactly means by 'not ready' | 11:28 |
| persia | slytherin: It could also be my poor memory. | 11:30 |
| kaaloo | persia: yes I'll stick to intrepid, but I'm currently having problems with JAVA_HOME and pbuilder not having that env var setup | 11:30 |
| slytherin | persia: please take a look at the attachments on the gtk LNF bug. | 11:31 |
| slytherin | kaaloo: check debian/rules file. The JAVA_HOME should be /usr/lib/jvm/default-java | 11:31 |
| persia | slytherin: As I said before, personally I think that switching it is sensible. I just fear complaints from Kubuntu folk. | 11:31 |
| slytherin | persia: I have left message for yuriy and subscribed him to the bug. | 11:32 |
| kaaloo | slytherin: oh sorry, I should have looked in the jbossas4 package for that | 11:32 |
| kaaloo | pbuilder is amazing ! 8-) | 11:37 |
| kaaloo | I'm now having an issue with dpkg-source: error: cannot represent change to groovy-1.5.6/target/docs/api/resources/inherit.gif: binary file contents changed. It seems to pop up frequently in google, otherwise the build went well. | 11:45 |
| kaaloo | so that's done ! I submitted the debdiff on lp. | 12:20 |
| persia | kaaloo: You can't add binary files (e.g. a .gif) in the debdiff. You'd have to encode it in ascii somehow. | 12:32 |
| kaaloo | persia:well I didn't attempt to add binaries, it seems to be a consequence of javadoc generating the groovy doc | 12:58 |
| persia | kaaloo: How did you generate the source package? | 13:00 |
| persia | I suspect you may need to delete something extra in the clean rule. | 13:00 |
| slytherin | I wonder why people use gif files for static images. | 13:01 |
| kaaloo | persia: I'm using pdebuild, ok I'll look into that | 13:01 |
| persia | slytherin: Legacy habits, mostly. | 13:06 |
| persia | kaaloo: I'll recommend building the source package with `debuild -S` and then building binaries. That helps separate build problems from source build problems. | 13:06 |
| kaaloo | persia: yes I first used debuild -S, then pbuilder, then I tried pdebuild when I learned about it, what's strange is that I did not change anything related to that part, just some dependencies | 13:09 |
| persia | kaaloo: It may be that you've discovered another bug. No reason to only fix one at a time. | 13:10 |
| kaaloo | persia : exactly ! :) I'll look into that so I can understand how that works | 13:11 |
| persia | kaaloo: Good luck. | 13:11 |
| kaaloo | persia: Thanks, and thanks for your help ! I posted a debdiff on the bug report already though, should I bump the version again for this problem ? | 13:13 |
| slytherin | kaaloo: no, your latest debdiff will be used anyway. So don't bump the version. | 13:15 |
| kaaloo | slytherin: ok thanks | 13:16 |
| ScottK | persia: I filed it because it prevents me using that package in a situation where it might be useful and because I knew headless Java was something that was being worked on in Intrepid, so I thought it might actually be solvable. | 15:36 |
| ScottK | Thanks | 15:36 |
| persia | ScottK: It's being looked at for intrepid, but I believe it unlikely to be solved for Hardy. Note that those who have reviewed it so far are not yet entirely sure, but if it's safe, it will be fixed. | 15:37 |
| ScottK | Right, I didn't figure it'd be backportable. | 15:38 |
| persia | More generally, there's likely a lot of these that need review to better support server-side stuff. As a server developer, might you have time to complain about this? | 15:38 |
| ScottK | Isn't that what the bug is? | 15:39 |
| persia | (Because most of the Java devs have complete JREs, so may not notice the problem, except where there is a specific goal of headless use that is part of the post-packaging testing) | 15:39 |
| persia | Yes: There's probably about 30-50 of those bugs, Finding them is more tricky. It is hoped that the general review to migrate to openJDK will do most of it, but more eyes always help. | 15:39 |
| ScottK | I'll keep filing bugs if I find cases. Is there a tag you want on such bugs and it sounds like some policy needs writing if it hasn't. | 15:40 |
| persia | doko sent instructions to the ML talking about the need for changing dependencies: I'm not sure we need more explicit policy. | 15:41 |
| persia | How about "java-headless" as a tag? | 15:41 |
| * persia tags the current bug as an example | 15:41 | |
| persia | Grr. edge. | 15:42 |
| ScottK | What tag to use would be an important thing to have written down and communicated to bugsquad I'd think. | 15:42 |
| persia | Indeed. | 15:42 |
| * ScottK notes that there is a current job posting on the Canonical web site for a Launchpad U/I developer and it includes a requirement for Flash experience. | 15:43 | |
| kaaloo | I fixed the clean problem for groovy and submitted the debdiff for intrepid. | 16:00 |
| persia | kaaloo: Excellent. Which bug? | 16:00 |
| kaaloo | https://bugs.edge.launchpad.net/ubuntu/+source/groovy/+bug/256325 | 16:01 |
| kaaloo | persia: I'm going to check out the other bug that's listed there | 16:01 |
| kaaloo | persia: hmm, I have a doubt, should my debdiff be named groovy_1.5.6-1ubuntu1.debdiff or rather groovy_1.5.6-2ubuntu1.debdiff ? I didn't add an ubuntu suffix at all. | 16:06 |
| persia | kaaloo: Your version in the changelog should be 1.5.6-1ubuntu1 | 16:07 |
| persia | Also, don't forget the Debian Maintainer Field adjustment. | 16:08 |
| kaaloo | persia: ok I'll fix that then, yes I just saw that going through the other bug, thanks | 16:08 |
| persia | You may find that #ubuntu-motu is a good place to ask about general Ubuntu packaging and procedures (when it isn't Java specific) | 16:08 |
| kaaloo | persia:ok thanks I'll join that channel | 16:15 |
| kaaloo | persia: I updated the debdiff file, now taking a look at the other bug which doesn't seem valid to me. | 16:38 |
| persia | kaaloo: Excellent. Ideally you'll be able to close all the bugs (either fixing or deciding that they aren't actually bugs) for the upload. | 16:41 |
| kaaloo | persia: I can close it myself once the debdiff is attached ? | 16:42 |
| persia | kaaloo: No, it gets closed when it gets uploaded. Include the string (LP: #nnnnnn) in your changelog for each thing you did to indicate which bug to close. | 16:44 |
| kaaloo | persia: Ouch, I put (Closes LP: #256325), do you think it will still get caught ? | 16:45 |
| persia | kaaloo: Avoid "closes" for uploads to Ubuntu: that is reserved for uploads to Debian. | 16:54 |
| kaaloo | persia: ok thanks | 16:56 |
| kaaloo | persia: I'm getting problems with groovysh, I saw this yesterday for another java program, java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-openjdk/jre/lib/i386/motif21/libmawt.so | 17:21 |
| persia | kaaloo: Hmm.. I remember there being issues with Motif, but don't remember the details. Some Motif is considered non-free. Does it run with sun-java6 ? | 17:23 |
| kaaloo | persia: I think so, let me check. The program yesterday was PortableSigner for signing pdf files and it run ok with sun-java6 | 17:24 |
| persia | kaaloo: Might be an issue with what is implemented in OpenJDK vs. what is implemented in sun-java6. | 17:25 |
| istarex | Did you run a particular program in groovysh? I can run it okay w/ openjdk | 17:29 |
| persia | istarex: So the dependency on sun-java6 would be for the programs run under groovysh, rather than groovysh itself? | 17:37 |
| istarex | maybe | 17:38 |
| istarex | I just executed groovysh at the commandline and it starts okay | 17:38 |
| kaaloo | istarex: sorry I was testing some stuff | 17:42 |
| kaaloo | istarex: the problem is that openjdk does not support the MToolkit for awt | 17:43 |
| kaaloo | istarex: I did export AWT_TOOLKIT=XToolkit and groovysh runs fine under openjdk | 17:43 |
| kaaloo | istarex: be careful because startGroovy doesn't seem to take update-alternatives into account, you have to manually set JAVA_HOME | 17:44 |
| persia | kaaloo: Ah, if that's all, just be sure to set a different toolkit by default: it's better to only require OpenJDK than it is to provide Motif widgets (especially because almost nobody is used to them anymore) | 17:46 |
| kaaloo | persia: yes I'm just wondering how to set that env variable up in the package, anyhow open jdk says they won't support MToolkit because too old | 17:47 |
| * persia suspects it's something about licensing as well | 17:47 | |
| persia | kaaloo: One mechanism used to set environment variables at runtime is to have /usr/bin/$(package) be a shell script that sets stuff up and calls a real binary somewhere. | 17:48 |
| kaaloo | persia: http://www.openjdk.org/groups/awt/ -> '... Here you will also find code for MToolkit, requiring a proprietary Motif library. However, this is considered obsolete and isn't built as part of OpenJDK. ...' | 17:48 |
| kaaloo | persia: oh of course, I'll patch the groovyStart script or the groovysh script, but actually this should be in the openjdk package, its general to openjdk | 17:49 |
| kaaloo | There are some bugs about this in openjdk, I'll post my findings there. | 17:50 |
| persia | kaaloo: Good idea. | 17:51 |
| kaaloo | persia: actually they are all over the place in different application packages (of course) :( | 17:52 |
| kaaloo | persia: I'll go through that later on today and patch the openjdk package, I hope it won't be too hairy | 17:53 |
| persia | kaaloo: Good luck. | 17:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!