| dholbach | good morning | 06:43 |
|---|---|---|
| Koon | persia: I sent my Maven status email last Friday to ubuntu-java@lists.launchpad.net but it doesn't appear on the list archives : did you receive it ? or is the ML posting restricted to team members ? | 09:35 |
| slytherin | persia: lots of java libraries currently recommend -gcj package which pulls gcj runtime on intrepid. Any thoughts on this? Even ant recommends ant-gcj. | 09:35 |
| slytherin | Koon: are you subscribed to the list? | 09:36 |
| Koon | slytherin: I suppose I have to join the team first | 09:37 |
| persia | Koon: I haven't seen your email. | 09:37 |
| * Koon grumbles. | 09:37 | |
| slytherin | Koon: me too didn't see any mail. | 09:38 |
| Koon | persia: is it supposed to be closed-post, moderated or open ? | 09:38 |
| persia | Koon: No idea, actually. | 09:38 |
| Koon | I didn't get any error message | 09:38 |
| persia | Probably either closed-post or moderated. | 09:38 |
| Koon | I'll apply for membership... To win some time, I'll send you the email, if you can post it to the list that would be great | 09:39 |
| Koon | I'm in vacation this Thursday so I can't make it to the team meeting | 09:40 |
| Koon | slytherin: I'd say those recommends should be moved to suggests... | 09:40 |
| slytherin | Koon: that is my opinion too. But want either persia or geser to confirm it. | 09:41 |
| Koon | slytherin: sure. That's what I've proposed in my bug 249178 patch | 09:42 |
| ubottu | Launchpad bug 249178 in ecj "libecj-java shouldn't recommend java2-runtime" [Low,Triaged] https://launchpad.net/bugs/249178 | 09:42 |
| === dholbach_ is now known as dholbach | ||
| persia | Koon: Got your mail now. | 09:46 |
| persia | slytherin: Given that we're focusing on OpenJDK, I suspect it makes sense not to recommend -gcj for everything, especially as we're installing recommends by default. | 09:49 |
| slytherin | persia: right. So should I file one bug per package? I will start with ant. | 09:50 |
| persia | Yes, one bug per package. Extra points for making things headless where you can. | 09:50 |
| Koon | persia: is it ok to file a single bug and make it affect multiple packages ? Or discouraged ? | 09:51 |
| persia | Koon: That is discouraged except in the case where multiple packages need to be changed to fix a single bug. | 09:53 |
| slytherin | persia: By the way, Debian guys are moving many libraries to openjdk. So expect loads of sync/merge requests in next week from me. | 09:53 |
| persia | An example of this, look at bug 257178 | 09:53 |
| ubottu | Launchpad bug 257178 in debian-edu "education-chemistry: fails to install: err 67: Custom distribution education does not exist" [High,Fix released] https://launchpad.net/bugs/257178 | 09:53 |
| persia | slytherin: Excellent! | 09:54 |
| robilad | glassfish2 also just moved into debian main, afaict | 10:30 |
| robilad | (on top of openjdk) | 10:30 |
| slytherin | robilad: is that glassfish2? I thought it was glassfish 1 | 10:31 |
| robilad | http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2008-August/017623.html | 10:32 |
| slytherin | Koon: why don't you add the patch to some bug so that it gets some review. May be someone will pickup from there. | 10:34 |
| persia | robilad: Great news! | 10:34 |
| persia | slytherin: For maven? I think it's a bigger effort than a bugfix. | 10:34 |
| persia | More critically, I think we need some maven users to try it out, and comment on whether it looks like it's worth generating all the .pom files. | 10:35 |
| Koon | slytherin: we need to validate the approach | 10:35 |
| slytherin | hmm | 10:35 |
| Koon | the effort of patching maven is... nothing compaed to the effort of repackaging all potentiall javalibs | 10:35 |
| persia | slytherin: Of course, if you want to step through and test with it to validate it, that would be a great help :) | 10:36 |
| slytherin | robilad: persia: I think we have more than one glassfish version. Any idea what glassfishv2 is? | 10:36 |
| * robilad guesses glassfish version 2. | 10:36 | |
| slytherin | persia: I don't have maven knoledge but I can help with packaging efforts. | 10:36 |
| persia | slytherin: There was a bit of a communications mess, and we have too many glassfishes right now. | 10:36 |
| Koon | slytherin: we have one in multiverse (prebuilt binary) and a few libraries in universe | 10:36 |
| persia | Which can probably be dropped if glassfish2 is available to be sync'd from Debian main into universe. | 10:37 |
| slytherin | persia: I tried to avoid it when Sun developers were packaging it. But was busy with some other things then. | 10:37 |
| persia | slytherin: Understood. We all were. | 10:37 |
| robilad | slytherin: ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448509 | 10:38 |
| ubottu | Debian bug 448509 in wnpp "ITP: glassfish -- Open source Java EE 5 Application Server" [Wishlist,Closed] | 10:38 |
| * persia laments the existence of *4* different repackagings of Apache Derby currently in the archives | 10:38 | |
| slytherin | anyway, robilad, you are in charge of server stack. :-) | 10:38 |
| robilad | done ;) | 10:38 |
| robilad | ah, wait ... ;) | 10:38 |
| * slytherin has to go for a meeting. | 10:38 | |
| Koon | robilad: in my understanding the GFv2 libraries that went to main were not sufficient to run GFv2, that's why Sun packaged a prebuilt binary in multiverse | 10:40 |
| robilad | afaik, yes | 10:40 |
| Koon | but the landscape may have changed | 10:40 |
| robilad | but i think this is a new package - | 10:41 |
| robilad | since it moves a lot of things from contrib to main. | 10:41 |
| robilad | may want to ping twerner | 10:41 |
| * robilad wonders what in charge means - koon is actually getting things done, i'm just pointing out hurdles | 10:46 | |
| persia | robilad: You're responsible for identifying things that need doing. You mentioned maven, and Koon has been running with that. What's next? | 11:00 |
| robilad | good question - I'm tying to beat that out of glassfish folks | 11:00 |
| robilad | I'll try my diplomatic approach again - I think the next bit is to identify what kind of deps are used by app servers that aren't packaged yet and aren't part of app servers | 11:01 |
| robilad | for that I need to know what the dep graph of glassfish & geronimo etc. looks like. | 11:01 |
| robilad | and compare that with what we + debian have | 11:02 |
| persia | robilad: Also, there's been various talk about tomcat & headless. If you've time to outline what we ought be doing for that sort of thing, it would be grand. | 11:03 |
| robilad | ok, will do | 11:03 |
| * persia knows Sun is an easy target, but surely there's more as well | 11:03 | |
| robilad | there is tons more | 11:03 |
| robilad | the web framework explosion in javaland has been quite ... special. | 11:04 |
| Koon | I've been working on headless -- I think it should have reasonable depends soon. | 11:04 |
| persia | Heh. That's about what I thought. At issue being that I'm not sure anyone has a good overview of what is outstanding to make a first-class Java server. | 11:04 |
| Koon | there is a libnss-mdns recommend that brings a lot of things in... I've been asking doko why he put it in | 11:05 |
| Koon | otherwise it's looking good, just a few libs to switch to -headless depends | 11:06 |
| persia | Isn't that the piece for dynamic networking to better connect with 169.254.0.0/16 ? | 11:06 |
| Koon | yes -- I just don't know what it enables in the JRE-headless that warrants a Recommends rather than a Suggests | 11:07 |
| Koon | because it pulls avahi, dbus... on a server install | 11:08 |
| persia | Right. | 11:08 |
| Koon | but doko added it on purpose at one point, so I want to hear his reasons before I push to remove it :) | 11:08 |
| persia | Makes sense. | 11:09 |
| Koon | the final goal is to have tomcat6 installation as a tasksel in intrepid | 11:09 |
| Koon | (server) | 11:09 |
| persia | Well, one of the goals :) | 11:09 |
| Koon | heh | 11:10 |
| persia | Personally, I'd settle for being able to install Java on a server without X and have a reasonable number of libraries. | 11:10 |
| Koon | persia: try "apt-get install --no-install-recommends default-jre-headless", looks pretty reasonable | 11:11 |
| Koon | 9 extra packages, including openjdk-6-jre-lib and java-common | 11:12 |
| persia | Koon: Sure, but that doesn't happen with apt-get libfoo-java in intrepid :) | 11:12 |
| persia | (it ought though). | 11:12 |
| persia | (and probably will) | 11:12 |
| Koon | persia: would be good to have some kind of library tracker on the roadmap, to see how much libraries have been fixed to use the new Depends/headless things | 11:13 |
| Koon | they also need to be migrated to build with default-jdk in parallel | 11:14 |
| persia | Koon: I think not on the RoadMap, but something like slytherin's MoveToUniverse page. | 11:14 |
| Koon | sure | 11:14 |
| persia | Then we could have a Roadmap item "enable headless for libaries". | 11:15 |
| Koon | I've been cherrypicking my fixes so far, with the tomcat6 objective in mind, but it's worth trying to get the global picture | 11:15 |
| persia | Note that the final solution ought allow either headless or headful installation. We don't want to disable the desktop in the pursuit of the server. | 11:15 |
| robilad | ack | 11:15 |
| persia | So: 1) someone needs to propose this for the roadmap at the next meeting, 2) someone needs to volunteer to coordinate and keep the page up to date. Any volunteers? | 11:16 |
| Koon | I won't be there this meeting, vacation time | 11:16 |
| persia | Anyone else? Maybe someone who isn't already taking care of a Roadmap item? | 11:17 |
| Koon | robilad: could that library status tracking be part of the library tracking work you've talked about a few minutes ago ? | 11:17 |
| persia | robilad: That's a good idea: you can add it to the list of things that need takers, and it gets automatic mention in each meeting until someone takes it. | 11:18 |
| robilad | yeah, i think so - | 11:18 |
| robilad | please add it to the wiki for the next meeting | 11:19 |
| persia | Oh, I thought it might just feed into your regular item about organising server-side stuff. We can have a separate item if you think it's worthwhile. | 11:19 |
| Koon | what we have -- what we should have -- what we have but with bad depends -- what we have but without default-jdk building support | 11:20 |
| Koon | at least it would give an idea of the work that needs to be done, see if fixing it can be an intrepid target | 11:21 |
| robilad | right - i think keeping them separate is useful for other tasks as well. | 11:22 |
| robilad | as it is a bit of a general breakdown along different goals (default-jdk/headless/server) | 11:22 |
| robilad | so two axes ;) | 11:22 |
| Koon | robilad: and if there is a semi-automated way of seeing what should need non-headless, that would be great :) | 11:23 |
| robilad | heh ;) | 11:23 |
| robilad | 'build it wiuth headless, see if it breaks?' ;) | 11:24 |
| Koon | hmm, you can't build with headless | 11:24 |
| Koon | default-jdk is a full one :) | 11:24 |
| Koon | so you run it with headless, but you never know if you don't miss a class that would call the wrong package | 11:25 |
| robilad | ah, ok - then it really comes down to checking strings in package class fuiles. | 11:26 |
| Koon | I have no clue about that, but that sounds great :) | 11:27 |
| Koon | bbl | 11:27 |
| robilad | the real problem with headless and servers is that applications deployed in the server may very well want to actually use the full jdk | 11:27 |
| robilad | to do charting, graphical presentations, etc. | 11:27 |
| Koon | sure, nothing prevents them from doing so | 11:27 |
| robilad | ah, then I have to look at the difference between headless and non headless | 11:28 |
| Koon | non-headless installs headless | 11:28 |
| Koon | so you install, say, tomcat6, it pulls the jre-headless in | 11:29 |
| Koon | you happen to need more, install openjdk-6-jdk | 11:29 |
| Koon | it would still work :) | 11:29 |
| Koon | (really bbl) | 11:29 |
| persia | Headless also pulls the support libraries to emit sound and manage video display. | 11:49 |
| kaaloo | Koon: Hi I wanted to get back to you after going through the maven support spec | 13:03 |
| Koon | kaaloo: sure | 13:04 |
| kaaloo | Koon: Yes I was thinking that an alternative to the design you describe there could be to write a "smart" proxy that could be configured on a standard maven during a package build process. It would have the advantage of not requiring the pom.xml files in the libraries because these could be generated (maybe) dynamically using packaging dependecy information. It would also ensure offline mode automatically. And it could also do a | 13:11 |
| Koon | kaaloo: interesting approach. I'm just not sure this would be acceptable on buildd's... | 13:13 |
| persia | As long as no information not already available on the machine is required, it should be safe. Some sort of interaction with apt-cache maybe? | 13:19 |
| persia | The buildds don't have internet access, but they are permitted to do a fair bit at build time to get the right package. | 13:20 |
| Koon | note that pom.xml files could also be auto-generated without a proxy implementation | 13:22 |
| Koon | the proxy implemnattion avoids patching maven | 13:22 |
| persia | autogenerated at build time? That saves patching N library sources, which would be a win. | 13:22 |
| kaaloo | persia: So a build could launch a smart proxy for maven ? | 13:23 |
| kaaloo | The only thing is maven would still need patching to link to /usr/share/java jars instead of copying them, but its an optimisation | 13:23 |
| Koon | persia: well, this is an issue that's unrelated to proxy/patched-maven. In both cases you could imagine autogenerating the required information from (carefully double-checked) control files | 13:24 |
| persia | kaaloo: I'm not sufficiently familiar with maven to answer that, but a buildd is permitted to run any code, but note that 1) it runs in a chroot, and 2) the buildds have no internet access. | 13:24 |
| persia | Koon: Double-checking control files is easy, but we don't have the control files for the libraries at build time: we only have the current control file and the apt-cache. | 13:25 |
| kaaloo | persia: no internet acces will be needed thats for sure, everything goes through the smart proxy, I tried it out using an existing localhost port and doing mvn clean on a project with an empty repository | 13:25 |
| Koon | kaaloo: please draft the alternate implementation on the spec, adding your name to the Contributors on top | 13:25 |
| * Koon is also missing the necessary Maven foo to evaluate how difficult autogenerating poms would be | 13:26 | |
| persia | kaaloo: Also, try doing that in a PPA, and see if it works. The buildd configuration ought be the same. It sounds like it could solve us a lot of labour. | 13:28 |
| Koon | It also looks cleaner on paper. We just emulate what maven wants to find. | 13:31 |
| kaaloo | Koon, persia: ok will do ! I am leaving on vacation tomorrow but will work on it during that time. I will need some pointers for autogenerating the poms though for the relevant files / commands into the apt cache | 13:31 |
| persia | kaaloo: man apt-cache will show you lots of the easy interfaces. dctrl-tools has some of the more complex query methods. | 13:33 |
| persia | Be prepared to manipulate strings. | 13:33 |
| Koon | Then it's more a question to the Maven project: do they intend to include the JPP patchset in main sources or not | 13:33 |
| Koon | if they don't, we should definitely consider a proxy wrapper | 13:34 |
| kaaloo | persia : thanks that should get me started ! Yes the thing is they patch bootstrap code which is unfortunate because the plugin architecture doesn't reach into that. An alternative to patching the code would be to provide an alternate bootstrap component or set of components by subclassing the required classes. There is a components.xml file that determines the instanciation of these which could then be patched to point to a debi | 13:35 |
| persia | kaaloo: Err. Sure. Let us know how it goes :) | 13:36 |
| kaaloo | persia: well its based on plexus which is just a component container, I think that would be the right layer to do that integrated into the maven project. I can ask some friends who know more about it than me and get back to you | 13:38 |
| persia | kaaloo: Getting back to me isn't so important. Getting the maven wiki page updated, putting together a PoC, and bringing it for discussion at one of our weekly meetings (14:00 Thursdays) is important. | 13:40 |
| kaaloo | persia: yes I have not been able to attend, I'll try Thursday but not sure I will have a POC by then. I'm updating the wiki page now. | 13:41 |
| persia | kaaloo: We don't have so many deadlines in this team, mostly because we're still getting people together adn getting started. We'll probably organise a couple sessions at the next UDS in December, and have a schedule for the next release. | 13:42 |
| slytherin | LucidFox_: ping | 14:19 |
| LucidFox_ | hello slytherin | 14:29 |
| slytherin | LucidFox_: I logged a bug against fop. I intended you to look at it but someone has already jumped in. Let's see how it goes. | 14:30 |
| slytherin | LucidFox_: And expect a docbook -> PDF post on planet by tomorrow. :-) | 14:30 |
| LucidFox_ | heh | 14:31 |
| slytherin | using fop | 14:31 |
| LucidFox_ | heh... "teh package" | 14:33 |
| slytherin | :-( | 14:33 |
| * slytherin heads home | 16:49 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!