[10:08] <x_hunter> Hello
[15:03] <persia> Who's here for the Java meeting?
[15:03] <Koon> o/
[15:04]  * slytherin is
[15:05] <persia> OK.  Not so many of us, but let's get started and see if others join as we go.
[15:06] <persia> The agenda is posted at https://wiki.ubuntu.com/JavaTeam/Meeting
[15:06] <persia> First up is roadmap review.
[15:07] <persia> FIrst item is OpenJDK in main.  doko, could you share status and plans?  I see the bug is closed.
[15:08] <Koon> doko is not here afaict
[15:08] <persia> Oh well.  It seems to be in main.  I'll move it to the done list.
[15:09] <slytherin> persia: rmadison doesn't say so.
[15:10] <persia> slytherin: Hmm.  I was looking at bug #246249
[15:10] <Koon> slytherin: it's been promoted like 6 hours ago, the archives may not have caught up
[15:10] <slytherin> Koon: ahh, thanks for info
[15:11] <persia> Ah, right.  That would do it.  It probably needs something else in main to depend on it to actually get pulled (and some archive-admin to act on the anastacia output)
[15:12] <persia> Right.  Next.  Integration of Java into the server stack.  Robilad doesn't appear to be here: does anyone else know the current status of the breakdown planning?
[15:12] <Koon> no, he identified maven2 as a blocker, and that's one of my agenda points
[15:12] <Koon> otherwise I don't really know
[15:13] <slytherin> Koon: Can you explain what needs to be done for maven2? The other day I was planning to package geronimo but it uses maven
[15:13] <Koon> slytherin: sure, that's one of the next agenda items
[15:13] <persia> Koon: Thanks.  Let's work from that, and try to get the breakdown for next week.  Would you be able to touch base with him over the next week to get some more breakdown published?
[15:13] <Koon> yes, hopefully he will post it as a w-i-p wiki page
[15:14] <persia> Koon: Thanks.
[15:14] <Koon> here he comes
[15:14] <mareks> netbeans depends on ini4j which uses maven for build in its newest version so I would like to know maven2 status can it be used as build-dep?
[15:14] <dalibor> hello, sorry for being late
[15:14] <persia> dalibor: No worries.  We had just gotten to your item.
[15:15] <Koon> mareks: that's one of the next agenda items, be patient :)
[15:15] <persia> Can you share the current status of the breakdown of "Integration of Java in the server stack"?
[15:15] <dalibor> i listened in last week on the work the glassfish team has been doing on creating their ubuntu packages, and
[15:16] <dalibor> afaict it boils down (for them) to a bunch of things
[15:16] <dalibor> a) like other large java projects, they need to build with maven
[15:16] <dalibor> so a fully funtioning, well intergrated maven 2 would be a good thing
[15:17] <Koon> dalibor: we'll discuss issues and plans in one of the next meeting items
[15:17] <Koon> (for maven)
[15:17] <dalibor> b) for glassfish and other app server, to package them in acceptable ways, they need to be broken into dependencies,
[15:17] <dalibor> and the dependency graphs are both large and quite challenging to figure out
[15:18] <persia> b) is just a matter of getting the libraries together, right?
[15:18] <dalibor> yes, and making sure that forexample duplicates of libraries are either eliminated,
[15:18] <dalibor> or in case of abi breakage packaged separately.
[15:19] <dalibor> ASM is a typical example there in general, I don't havea galssfish example at hand.
[15:19] <persia> Right.  Like the current mess with Derby
[15:20] <dalibor> why it is so challengeing to figure out the complete dependency graph is not clear to me yet, but I assume that it's basically the circular mess problem
[15:20] <persia> So, for next week, can we identify several tasks for the roadmap so that people can better work in parallel?
[15:20] <dalibor> whenre you have multiple different version of the same loibrary with different dependencies in the same product
[15:21] <dalibor> so that rather than having a simple tree, you have a lot of branching spirals, if you can follow my mental picture
[15:22] <slytherin> right, we have more than one libservlet, libxalan etc.
[15:22] <dalibor> there are some tools that can assist that process, afaict, we have some jar analyzer tools in debian for example
[15:22] <dalibor> it would be useful to evalute how well they would support such packaging analysis tasks
[15:23] <dalibor> and as far as api/abi compatibility goes, there are some tools from the community/sun that can help with that (japitools, sigcheck)
[15:23] <persia> Shall we target have consistent version of libraries for everything for intrepid?  That seems fairly ambitious to me, but we can try.
[15:24] <dalibor> i think it's a good goal, but we may need to make some compromises.
[15:24] <persia> Anyone willing to lead that initiative?
[15:25] <dalibor> 7me is scrambling trying to find the loig of the meeting so far
[15:26] <persia> dalibor: It's not available yet.  Only topic was JDK in main (seems done), and looking at the server stuff, which mostly waited for you.
[15:26] <slytherin> persia: Can we get input from Debian guys on that part?
[15:27] <dalibor> yes, please
[15:27] <persia> slytherin: Likely, but need to have someone willing to be ambassador.
[15:27] <dalibor> i'd suggest bring this up on debian-java, now that openjdk 6 is in sid,
[15:27] <persia> OK.  Anyone up for that, and willing to report at the next meeting?
[15:27] <dalibor> and trying to work out a good way to sync up.
[15:28] <slytherin> persia: I can not promise anything as of now. :-)
[15:28] <persia> dalibor?  Koon?
[15:28] <persia> mareks?
[15:28] <dalibor> I'll be at OSCON during the next meeting, so I#ll have to pass that one on to someone else.
[15:28] <Koon> I have no links, I prefer to pass on that one
[15:29] <slytherin> keep it open. I will see what I can do.
[15:29] <dalibor> thanks, slytherin
[15:29] <persia> slytherin: Thanks.  We'll not add it to the roadmap unless you can confirm next week.
[15:29] <persia> OK.  Moving on...
[15:30] <persia> slytherin: Could you give us an update on the effort to migrate packages to universe?
[15:30] <slytherin> Sure.
[15:31] <slytherin> The only package that has been moved recently to universe is statcvs. Apart from that I have not worked on anything else specific as I was working on batik update.
[15:32] <slytherin> I have compiled a list of packages that build depend on Sun JDK and will evaluate one by one in coming weeks.
[15:32] <persia> Great!  Do you need help for anything specific, or have any questions others might be answer?
[15:32] <slytherin> Oh, wait, statcvs has not yet moved to universe. The sync is pending.
[15:32] <persia> (err ... able to ... )
[15:33] <slytherin> None as of now.
[15:33] <dalibor> i xn areport on the debian side that two packages have moved to main as a result of openjdk6 making it in so far.
[15:34] <dalibor> tinylaf and libcodemodel-java
[15:34] <persia> Excellent.  Can we get promotion bugs in Ubuntu for those?
[15:34] <slytherin> Yes, I will do that.
[15:34] <persia> Great.
[15:34] <dalibor> thanks, slytherin
[15:34] <mareks> we would like to update lucene2 from contrib to main in debian
[15:35] <mareks> is there any info how to do that?
[15:35] <persia> mareks: Probably best to work with slytherin in #ubuntu-java on specifics after the meeting.
[15:35] <dalibor> lucense is a bit of a hard item, there was a thread on that recently
[15:36] <dalibor> i'll dig out the URL post meeting
[15:36] <persia> That's the Roadmap review.  Next agenda item is to look at our team report.
[15:36] <slytherin> I think Debian is using Sun JDk for lucene2. Hence I will first have to ask them to use openjdk
[15:36] <slytherin> I mean for build
[15:36] <persia> We need to publish our monthly  team report on the 22nd.
[15:37] <persia> Anyone willing to look over the meeting minutes so far and update https://wiki.ubuntu.com/JavaTeam/TeamReport ?
[15:38] <dalibor> re lucene2, see http://thread.gmane.org/gmane.linux.debian.packages.java.devel/12593/focus=462167
[15:39] <dalibor> i can have a go at it on saturday
[15:40] <slytherin> dalibor: Don't. :-) lucene2 is a dragon. I will try it today. Can you instead take up task of updating team report?
[15:40] <dalibor> yeah, sorry - i meant the report
[15:41] <dalibor> thanks for keeping me unambiguous ;)
[15:41] <persia> OK.  In the absence of volunteers, I'll compile the report.  I'll ask all of those assigned an item on the roadmap to please make some time to review on the 20th or 21st to make sure their activities are accurately represented.
[15:41] <persia> (This will be before the next meeting, so please try to schedule some time)
[15:41] <slytherin> persia: When I tried in hardy cycle, lucene2 was not building with gcj due to some problem in gcj. Let me try again today. If it builds with GCJ, nothing better than that.
[15:41] <persia> Next item: Using maven in packaging.  Koon?
[15:41] <persia> dalibor: That'd be great, as I'll be mostly offline this weekend.  THanks.
[15:41] <Koon> yes
[15:42] <Koon> So I've been investigating that area -- I'm no maven specialist so anyone knowing more than me, please interrupt/correct me
[15:42] <Koon> Maven is in main, but cannot really be used to build Debian packages
[15:42] <Koon> The 3 problems are :
[15:43] <Koon> 1/ maven uses heavily online download of deps, we need to do everything offline
[15:43] <Koon> in particular, it downloads dependency info
[15:43] <Koon> (.pom files)
[15:44] <Koon> in a kind of recursive process. so we would have to have every required .pom file before even starting to build
[15:44] <Koon> this can be done in two ways (at least)
[15:45] <Koon> one is the fedora way, shipping poms with libraries and a bunch of them in a default_poms package
[15:45] <Koon> the other is to download every pom file required to bulid and ship it inside the sources
[15:45] <Koon> s/bulid/build/
[15:45] <persia> Is that not in some ways duplicate to te information we want in debian/contro?  Can we maybe create a tool to recursively walk the tree and update debia/control for build-deps?
[15:46] <Koon> that would be a possibility, but hacking maven so that it uses debian/control rather than XML .pom files is probably complicated
[15:46] <Koon> 2/ maven should use installed packages rather than their own JAR repository
[15:47] <Koon> so you have to patch it so that it supports getting libraries from /usr/lib/java
[15:47] <Koon> (or share)
[15:47] <Koon> *and* you have to provide a dependency map file so that you map whatever version maven requires to the one you have in lib
[15:48] <Koon> both of those patches are in the Fedora maven-jpp thing
[15:48] <Koon> 3/ maven heavily uses plugins
[15:49] <Koon> some of them are "official" maven ones, some other are found in maven repos, and some of them are build-support ones that are built during the maven build
[15:49] <persia> Ah.  I guess I like the Fedora way then.  .pom files provided by the providing libraries.
[15:49] <slytherin> Koon: Why not make maven generate build dependencies from .pom file. ex. You have a variable in control - ${maven-depends} which will be replaced by the dependencies generated by maven.
[15:49] <Koon> persia: that's more work, but it's definitely cleaner
[15:50] <persia> cleaner means we can propose it to Debian which means more helping hands :)
[15:50] <dalibor> i should add that deepak bhole, the author of the fedfora patchset for maven, offered to be of assistance if someone wanted to merge his patches in
[15:50] <Koon> slytherin: why not. the idea is to try to write a spec on how we want to do the maven thing
[15:50] <slytherin> dalibor: DO you have his email id?
[15:51] <Koon> I've absolutely no clue on what would be the best way (or the most Debian-compatible way) of doing it
[15:51] <Koon> so I can start the spec but there are probably more knowledgable people to propose implementation details
[15:51] <slytherin> Let's try fedora way first. No point in reinventing the wheel. If it is working for them, it will surely work for us.
[15:51] <persia> Probably best to catch man-di in #ubuntu-java to ask about the most Debian-compatible way
[15:52] <persia> (and otherwise I agree with slytherin)
[15:52] <slytherin> As long as the solution is not dependent on how rpm works, I am all for it.
[15:53] <Koon> slytherin: their way of storing Java libraries is slightly different so it would need adaptations, but the Fedora patchset is definitely a good starting point
[15:53] <Koon> (in fact it's the JPackage patchset)
[15:53] <dalibor> slytherin: dbhole@redhat.com
[15:53] <nixternal> we used maven here at work for our RPMs
[15:53] <persia> Koon: Can you drive that for now, and work with Deepak to at least identify the patchset for presentation for next week?
[15:54] <nixternal> I have since switched to using just apache-ant and rpmbuild...much easier and quicker
[15:54] <Koon> persia: yes
[15:54] <persia> nixternal: Have you tried with glassfish?  That seems to be the big target.
[15:54] <persia> Koon: Thanks.
[15:54] <slytherin> nixternal: Not a solution here. We can not ask every upstream project to change their build.
[15:54] <nixternal> no I haven't...I will check it out
[15:55] <nixternal> slytherin: wasn't reccomending it as a solution
[15:55] <Koon> persia: I can also start a spec with use cases and identified problems -- but we should find the right guy to write the implementation proposal
[15:55] <dalibor> build systems tend to be sacred ;)
[15:56] <slytherin> nixternal: Sorry, i misunderstood
[15:56] <mareks> ini4j (as I said :) is simple enough to test concept let me know I can help
[15:56] <nixternal> hehe, no problem
[15:56] <persia> Koon: Starting something would be great, and we ought be able to discuss on #ubuntu-java, with our weekly review.  Would you mind adding it to the roadmap so we catch it every week.
[15:56]  * nixternal is looking at glassfish now
[15:56] <Koon> will do
[15:57] <persia> OK.  Next topic: standard runtimes/depends for packaging.  Koon?
[15:58] <Koon> I wanted us to have a quick discussion on what /should/ be the right depends/recommends/suggests set for a java library
[15:58] <Koon> so that I can start filing bugs about those who are not compliant
[15:58] <Koon> as an example, see bug #249178
[15:58] <Koon> libecj-java recommends java2-runtime
[15:59] <Koon> so in intrepid a full JRE gets installed
[15:59] <persia> slytherin: Could you address that: you seem to have the most experience of adjusting those.
[15:59] <Koon> for servers we would like a simple JRE-headless to be pulled in
[15:59] <slytherin> Koon: right. But does ecj need a runtime at all?
[15:59] <Koon> the right depend should be java2-runtime-headless, or maybe "default-jre | java2-runtime-headless"
[16:00] <Koon> or maybe it should not be a recommend but a depend
[16:00] <Koon> or maybe it should not depend/recommend anything
[16:00] <Koon> what is the right way to do it you think ?
[16:00] <Koon> slytherin: precisely :)
[16:00] <Koon> libecj-java doesn't need a runtime. An application using it would
[16:01] <slytherin> The problem is that trying to suggest that Debian should set some policy in this matter has not yielded any result. So I guess we do it ourselves and stick to it.
[16:01] <Koon> currently I find various sets used. The end results is that most of the time, you get a full JDK or JRE installed
[16:01] <Koon> where for most server packages you really don't want that (a jre-headless would be better)
[16:02] <slytherin> Also I have seen many packages that land in debian contrib has very weird build/runtime dependencies. Theer are still some packages which have hard coded dependencies on gij or kaffe.
[16:03] <slytherin> Koon: Can you draft a policy and put it on wiki for review under java team? We will make changes to it as and when needed.
[16:03] <slytherin> persia: Can you suggest any way to enforce such policy in Ubuntu?
[16:03] <Koon> slytherin: I have no clue what the right answer is. I am pretty sure doko has a preference on that
[16:04] <slytherin> Koon: That is why I said draft. :-)
[16:04] <Koon> in fact I wished he would be here to answer :)
[16:05] <Koon> like for the maven thing, I can start a document that lays out the problem
[16:05] <slytherin> Koon: But your are right in one aspect. Most of the packages really need on -jre-headless
[16:06] <persia> slytherin: For the most part, if we establish a policy, we can then enforce it by uploading fixes to anything not in compliance.
[16:06] <slytherin> hmm
[16:06] <persia> Most developers are likely to defer to the Java team about Java packaging.
[16:06] <slytherin> then let's establish one.
[16:07] <Koon> slytherin: what would be your take on it ? Not having any runtime dep for libraries ?
[16:07] <Koon> or a minimal "recommends" ? or a minimal "depends" ?
[16:08] <slytherin> Koon: If you mean no runtime jre dep then we will have to discuss that.
[16:08] <slytherin> Koon: What if you downloaded some program form somewhere which depends on a lib. You install lib but not JRE, you can not run the program.
[16:09] <persia> That's a big enough change we also want to closely coordinate with the Debian Java team.  Getting that into the Debian Java policy would reduce our work considerably.
[16:09] <persia> Also, most desktop users ought get a JRE for the browser plugins.  Server users would likely hav a headless JRE if they are using Java.
[16:10] <Koon> slytherin: you could just say it's the program from somewhere that should depend on the runtime
[16:10]  * persia likes that interpretation
[16:10] <dalibor> slytherin: the hard coded dependencieson kaffe/gcj come froma dark time before we had openjdk and had not settled on gcj yet.
[16:10] <slytherin> Koon: Nope, that is bug change. Let's keep it aside for now.
[16:11] <Koon> there is a corner case too
[16:11] <Koon> There could be a JAR which provides graphical features as well as non-graphical features
[16:11] <Koon> your server program depends on that library
[16:12] <Koon> that depends on the -jre one
[16:12] <Koon> having the program depend on the lib and the jre-headless runtime would fix that
[16:12] <slytherin> Koon: I haev to yet see a server program that depends on AWT/SWING unless it is an applet
[16:13] <Koon> slytherin: that's my point, let me reexplain
[16:13] <slytherin> Koon: Let's discuss this in #ubuntu-java at some later time. We should now close the meeting.
[16:13] <Koon> sure
[16:14] <Koon> so I can start a wiki document to lay out the issue and the cases we want to cover
[16:14] <persia> OK.  Are there any other topics for discussion today?
[16:14] <Koon> then anyone with a good implementation idea can participate
[16:15] <persia> Koon: That would be great.
[16:17] <slytherin> None form my side.
[16:18] <persia> Right.  Meeting adjourned.  We'll meet again on Thursday at 14:00 UTC.
[16:18] <persia> Any volunteers to draft the minutes for this week?
[16:18] <slytherin> Two weeks from now, right?
[16:20] <persia> Let's do one week.  The meetings have been pretty active, and we've run over.  If we get below 30 minutes, every two weeks makes more sense.
[16:20] <slytherin> Ok.
[16:20] <Koon> see you then
[16:21] <slytherin> persia: There is volunteer for minutes. You. :-P
[16:21]  * persia will write the minutes then.
[16:23] <slytherin> Good bye. I am leaving for home.
[16:25] <dalibor> thanks everyone, bye1
[17:00]  * ogra waves
[17:00] <davidm> Meeting starting in moments
[17:00] <davidm> #startmeeting
[17:00] <MootBot> Meeting started at 11:02. The chair is davidm.
[17:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:01] <davidm> There are no action items from last week.
[17:01] <davidm> And there are no current agenda items.
[17:05] <davidm> Does anyone have any thing they want to add to the agenda?
[17:06] <GrueMaster> Any status on intrepid?
[17:08] <StevenK> GrueMaster: Work on Intrepid images is underway. I expect to have something in a couple of weeks.
[17:08] <GrueMaster> ok, thanks.  Just curious on when a core image will be available.  Nothing fancy.
[17:08] <StevenK> GrueMaster: "Soon" :-)
[17:14] <davidm> Any other items?
[17:20] <davidm> OK endmeeting going once ..................................................................
[17:23] <davidm> OK endmeeting going twice ...............................
[17:26] <davidm> #endmeeting
[17:26] <MootBot> Meeting finished at 11:28.
[21:00] <kees> #startmeeting
[21:00] <MootBot> Meeting started at 15:02. The chair is kees.
[21:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[21:00] <kees> hello!  anyone here for the Ubuntu Security Team meeting?
[21:01] <jdstrand> o/
[21:01] <kees> :)
[21:01] <kees> well, for the record, I'll just mention a few quick things.
[21:02] <kees> first, the Smack how-to has been written up, and is here: https://help.ubuntu.com/community/SmackConfiguration
[21:02] <kees> I'd like to see it made specific to Ubuntu (i.e. instead of "2.6.25 and later", have it say "Intrepid and later")
[21:02] <kees> two things need doing: 1) enable it in the kernel, 2) package smack-utils
[21:03] <kees> SELinux was syncd from Debian.  This caused a few minor problems with the "selinux" package, and I've fixed that by bumping epoch on it, and patching checkpolicy to do a correct versioned Conflict on the old Debian "selinux" package
[21:04] <kees> aaand, okay, that's it.  :)  I'll send some email to the hardened list.
[21:04] <kees> jdstrand: anything?  :)
[21:05] <jdstrand> I've been working on a php5 update this week, and it should be out soon
[21:05] <jdstrand> dnsmasq also will be out soon, but upstream has been refining the security fix
[21:05] <jdstrand> (which is why there has been a delay)
[21:09] <kees> cool.  Okay, we'll close up shop this week, and schedule another meeting in 2 weeks.  :)
[21:09] <kees> #endmeeting
[21:09] <MootBot> Meeting finished at 15:11.
[21:14] <emgent> ?
[21:15] <emgent> argh, I was late. np go to next meeting \o/