#ubuntu-java 2006-08-19
<NewtoUbuntu> hey
<Skippy9> hello
#ubuntu-java 2006-08-20
<adorablepuppy> hi
#ubuntu-java 2007-08-13
* Starting logfile irclogs/ubuntu-java.log
<gen> i'm looking for a web cms to go, ready to use open souce. myspace type. can someone help me?
#ubuntu-java 2007-08-15
* #ubuntu-java  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
* Starting logfile irclogs/ubuntu-java.log
* Starting logfile irclogs/ubuntu-java.log
<xhaker> man-di, Hi, i'm wondering if you could help me get eclipse 3.3 into ubuntu gutsy :d
<xhaker> anyone here willing to help packaging eclipse 3.3?
<xhaker> man-di?
<vil> yeah, man-di does all the fun stuff
<vil> seriously, man-di, how can we help?
<vil> last time you mentioned jetty
<vil> is that still valid?
<xhaker> vil, are you lapacek?
<vil> xhaker, that's me :)
<xhaker> ohh, atleast i can guess :D
<xhaker> what's man-di real name?
<xhaker> doko directed me to him/her
<vil> hope that it's not secret :)
<vil> type in /whois man-di
<vil>  ;)
<xhaker> had figured it out before
<xhaker> omg
<xhaker> that whois command is awesome <\sarcasm>
<xhaker> i forget that in these irc servers people actually identify themselves
<xhaker> well, there's qualified manpower then. let's see if there's enormous power of will
<vil> man-di is very active here and at debian-java
<xhaker> yep, i can see that from the changelogs
<xhaker> i've apt-get source eclipse
<xhaker> not sure how to get the orig.tar.gz
<xhaker> it is clearly smaller than the tar.gz i downloaded
<vil> well, I don't remember exactly as I did not care about it for a while now
<vil> but it is either a snapshot from the web
<vil> or export from the eclipse cvs
<xhaker> there is a watch file
<vil> either way, the size will differ because it has all .jar .so .dll etc. deleted
<xhaker> version=3
<xhaker> ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-([\d\.-] *)/eclipse-sourceBuild-srcIncluded-(.*)\.zip
<xhaker> is there a script to do that trimming?
<vil> I don't think so
<vil> although it is a good idea to create one either as part of rules or stand-alone
#ubuntu-java 2007-08-17
<xhaker_> man-di, poke
<man-di> xhaker_: just ask and I will answer when online
<xhaker_> man-di, hmm, i'm getting warnings when building a package for eclipse
<man-di> and?
<xhaker_> man-di, i'm trying to merge your changes from latest debian in gutsy
<xhaker_> would a sync be enough?
<xhaker_> man-di, I also fail to see how to get the orig.tar.gz
<xhaker_> it seems handcrafted
<man-di> it is handcrafted
<man-di> and no, a sync is not enough
<man-di> the debian/control need to be regenerated
<xhaker_> how do you do it?
<man-di> touch debian/control.in ; debian/rules debian/control
<man-di> but I doubt this version builds on the ubuntu buildds
<man-di> the last version didnt either
<man-di> neither on debian
<man-di> its some really strange bug
<xhaker_> bummer
<xhaker_> debian/rules debian/control
<xhaker_> debian/rules:256: /usr/share/dpatch/dpatch.make: No such file or directory
<xhaker_> debian/rules:917: warning: overriding commands for target `debian/control'
<man-di> aptitude install dpatch
<man-di> but you dont need it for this
#ubuntu-java 2007-08-18
<xhaker_> man-di, i think i fixed the eclipse FTBFS 
<xhaker_> doko_, i think i fixed the eclipse FTBFS 
<xhaker_> bummer
<xhaker_> failed after 37 min
<xhaker_> man-di, doko_: this is where it fails http://pastebin.com/m2a5114ca
* Starting logfile irclogs/ubuntu-java.log
#ubuntu-java 2007-08-19
* Starting logfile irclogs/ubuntu-java.log
<vil> xhaker, ping
<xhaker> hey
<xhaker> man
<xhaker> i think i found something
<vil> hi
<vil> last time we were talking about the orig sources
<vil> I am just finishing the 3.3 orig.tar.gz
<xhaker> http://pastebin.com/me22e3f3
<xhaker> do you think that patch is broken?
<xhaker> omg
<xhaker> i have to check if it's commented on the rules file
<xhaker> brb
<xhaker> dinner
<vil> ok
<vil> xhaker, the patch should be ok, cause it is not used in rules
<xhaker> i think it should
<vil> why?
<xhaker> I'm not being able to build
<xhaker> http://pastebin.com/m2772011f
<vil> that is strange
<vil> it is obviously buildable as we have the package
<vil> you can maybe try with pbuilder
<vil> anyway, I am going to sleep
<vil> see you later
#ubuntu-java 2008-08-11
<dholbach> good morning
<slytherin> persia: FYI ... I have setup debian pbuilder. I will try to forward the jftp patch tonight. I will also join pkg-java mailing list.
<persia> slytherin: Excellent.  Some of what we do is Ubuntu-specific, but where are deriving from Debian, it's always best to try to get the change made there.
<slytherin> persia: yes. By the way, Vincent Fourmond is already working on getting batik and it's dependency in Debian. xml-commons-external has entered Debian.
<persia> Excellent news indeed.
<slytherin> persia: if you are administrator of Java Team, can you please auto-subscribe to bugs related to some important packages?
<persia> slytherin: I'm not an admin: I just lead the weekly meetings.
<slytherin> :-)
<persia> Koon: Are you sure Debian bug #413906 matches LP bug #256052?  I'd recommend creating a separate bug, against the tomcat6 source itself.
<ubottu> Debian bug 413906 in tomcat6 "tomcat5.5: Tomcat6 released as stable" [Wishlist,Closed] http://bugs.debian.org/413906
<ubottu> Launchpad bug 256052 in tomcat6 "Build the complete tomcat6 stack" [Wishlist,In progress] https://launchpad.net/bugs/256052
<Koon> hmm
<Koon> "ITP: tomcat6 -- servlet container"
<persia> My reasoning is that although I agree that the tomcat6 packaging may not have been "complete", that your work is done against the current package, rather than being a complaint about how it was packaged in the first place.
<persia> Not an ITP: that specifically means a new source package, but rather as an update to the existing package.
<Koon> ah.
 * Koon struggles withe the bug history
<persia> Heh.  Yeah.
<Koon> ah ok, it was filed as tomcat5.5 then reassigned as wnpp
<persia> Also, are you still working on that individually?  I notice you remain assigned, and it's not gone to any sponsor queues.
<Koon> then closed
<persia> Yes, which is the right path for the "Gimme tomcat6" bug.  Your work is something else.
<Koon> persia: ok, will file a new bug against tomcat6
<persia> Koon: Thanks.  That will probably get the attention of the right people.
<persia> Remember that unless we work with Debian to accept changes, we're bound to maintain every byte of variation until the end of days...
<Koon> persia: about subscribing universe-sponsors: I was waiting on mathiaz to confirm that every problem he found on the package has been fixed to his likings before pushing it to a sponsor queue (or let him sponsor it) -- and given the size of the update that's why I asked a couple others to have a look as well
<Koon> I can push it to the queue now, I just didn't want to rush him
<persia> Koon: Personally, I think it's best practice to put everything to the queue as soon as it's ready.  If someone has time to get to it, great.  If not, someone else might have the time.
<persia> Anyway, no point subscribing the queue now: if you're done with it, I'll push it.
<Koon> persia: so you had time to look at it ?
<persia> Koon: Yep.  Looks fairly reasonable.  My main issue is how the bug is triaged, rather than the work itself.
<Koon> (do you sleep sometimes ?)
<persia> Mind you, I'd probably be more careful if we were in freeze.
<persia> Yes, I sleep :p
<kaaloo> Koon: hi, slytherin told me yesteday that you are working on a way of working with maven for building packages ?  Also, I just saw your work on tomcat6 on intrepid-changes the webapps are installed as packages with links to their jar dependencies ?
<Koon> kaaloo: about maven -- yes, see https://wiki.ubuntu.com/JavaTeam/Specs/MavenSupportSpec for details
<Koon> kaaloo: about tomcat6 -- webapps are installed as packages but didn't require any link, the tomcat6 webapps have no specific library depends
<acuster> Hey all, is there any status page maintained on where we are with java/eclipse/... ?
<slytherin> acuster: There is no specific work going on in regards to eclipse in Ubuntu. You may want to keep watch on debian-java mailing list. As for the other work in Ubuntu, check https://wiki.ubuntu.com/JavaTeam/Roadmap
<kaaloo> Koon: thanks for the information !  I'll take a look, see if I can help.
<Koon> kaaloo: you're welcome :)
<acuster> thanks
<slytherin> persia: any idea why there are so many failures on ppc in regards to java related to packages. I think I have found the problem. Need your comment.
 * persia wants something to comment upon
<slytherin> persia: if you check rules file in java-common, the jvmdir is being set to cacao-6-openjdk. As found from checking the cacao-oj6-jre-headless package file it looks like correct name would be java-6-cacao.
<persia> slytherin: If you make that as a local change in the build chroot, can you build them on powerpc?
<slytherin> persia: I don't have powerpc machine as of now. I am still waiting for my ibook's power adapter to be repaired. :-(
<slytherin> persia: I will log a bug and wait for doko to stumble upon it.
<persia> slytherin: That's probably best.  You might also try checking with the powerpc team (and no, I don't know if they have a channel)
<slytherin> persia: they have a channel but don't think anyone is interested in java there.
<persia> slytherin: But given a test case, they may be willing to try something for you.
<slytherin> let me try.
<slytherin> persia: in any case the build failures are clearly evident on FTBFS page.
<persia> slytherin: Right, but the powerpc FTBFS folk may not understand Java well enough to understand how to address it :)
<slytherin> persia: I guess doko will handle it. And he is smart enough. :-D
<persia> Oh, certainly that :)
<slytherin> persia: filed a bug, should I subscribe only doko or entire java team?
<persia> slytherin: i'd subscribe only the Java team.  doko is a member, and will see it.  I suspect he's fairly busy with Debian right now though: you might also add it to the meeting agenda to see if anyone else has thoughts or can test.
<slytherin> ok
<slytherin> persia: that reminds me, do I need to log a bug for moving jftp to universe?
<persia> slytherin: Indeed you do.
<slytherin> ok
<persia> Well, technically you don't, but as the alternative is finding an archive admin who feels like doing it just then, filing a bug might be easier :)
<slytherin> I will see if I can find an archive admin, if not then file a bug.
<persia> Archive Admins can be tricky to find :)
<LucidFox> slytherin, have you seen that xml-commons-external has been accepted into Debian?
<LucidFox> by Fourmond, and it's based on your package
<slytherin> LucidFox: yes, saw that yesterday. :-)
<slytherin> LucidFox: I had added comments to debian bug for batik update that the version was available in Ubuntu.
<LucidFox> ah
<slytherin> LucidFox: I didn't expect him to retain the Ubuntu changelog entry. :-D
<LucidFox> heh
<persia> Vincent tends to be careful about attribution, but can be very helpful.
<slytherin> persia: 'careful' as in?
<cody-somerville> http://packages.debian.org/changelogs/pool/main/c/catfish/catfish_0.3-2/changelog
<persia> slytherin: Tries never to exclude credit where things are borrowed from others.  It's a habit we could all adopt, although I sometimes think he's over-careful.  Were I updating based on your package, I'd have modified the same changelog entry, rather than adding a new onw.
<slytherin> :-)
<persia> cody-somerville: Good example, although uploaded by a different person.
<persia> (although it looks like someone forgot how to use -k in 0.3-0ubuntu2)
 * cody-somerville nods.
<slytherin> persia: do you have idea how pkg-java SVN works? Upload once you have commited changes to SVN or commit to SVN after updated package has been uploaded?
<persia> slytherin: I don't know, but suspect that debian-java@lists.debian.org is the place to ask.
<persia> For most teams, it seems that work gets committed to SVN first.
<slytherin> hmm, will do.
<slytherin> I will send some patches first. So I don't have to justify why I need SVN access.
<persia> Heh.  *lots* of patches to the BTS are often a good argument all on their own :)
<slytherin> Is patches to BTS good idea? I was planning to send them to pkg-java list.
<slytherin> ï»¿/me heads home
<slytherin> damn pidgin
 * slytherin heads home
 * persia hopes slythering reads backscroll
<persia> The BTS is typically the preferred means by which patches are submitted, reviewed, and discussed.  While this is also email, it allows the set of subscribers to change over time, and keeps a single URL for the entire thread.
#ubuntu-java 2008-08-12
<dholbach> good morning
<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 ?
<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.
<slytherin> Koon: are you subscribed to the list?
<Koon> slytherin: I suppose I have to join the team first
<persia> Koon: I haven't seen your email.
 * Koon grumbles.
<slytherin> Koon: me too didn't see any mail.
<Koon> persia: is it supposed to be closed-post, moderated or open ?
<persia> Koon: No idea, actually.
<Koon> I didn't get any error message
<persia> Probably either closed-post or moderated.
<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
<Koon> I'm in vacation this Thursday so I can't make it to the team meeting
<Koon> slytherin: I'd say those recommends should be moved to suggests...
<slytherin> Koon: that is my opinion too. But want either persia or geser to confirm it.
<Koon> slytherin: sure. That's what I've proposed in my bug 249178 patch
<ubottu> Launchpad bug 249178 in ecj "libecj-java shouldn't recommend java2-runtime" [Low,Triaged] https://launchpad.net/bugs/249178
<persia> Koon: Got your mail now.
<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.
<slytherin> persia: right. So should I file one bug per package? I will start with ant.
<persia> Yes, one bug per package.  Extra points for making things headless where you can.
<Koon> persia: is it ok to file a single bug and make it affect multiple packages ? Or discouraged ?
<persia> Koon: That is discouraged except in the case where multiple packages need to be changed to fix a single bug.
<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.
<persia> An example of this, look at bug 257178
<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
<persia> slytherin: Excellent!
<robilad> glassfish2 also just moved into debian main, afaict
<robilad> (on top of openjdk)
<slytherin> robilad: is that glassfish2? I thought it was glassfish 1
<robilad> http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2008-August/017623.html
<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.
<persia> robilad: Great news!
<persia> slytherin: For maven?  I think it's a bigger effort than a bugfix.
<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.
<Koon> slytherin: we need to validate the approach
<slytherin> hmm
<Koon> the effort of patching maven is... nothing compaed to the effort of repackaging all potentiall javalibs
<persia> slytherin: Of course, if you want to step through and test with it to validate it, that would be a great help :)
<slytherin> robilad: persia: I think we have more than one glassfish version. Any idea what glassfishv2 is?
 * robilad guesses glassfish version 2.
<slytherin> persia: I don't have maven knoledge but I can help with packaging efforts.
<persia> slytherin: There was a bit of a communications mess, and we have too many glassfishes right now.
<Koon> slytherin: we have one in multiverse (prebuilt binary) and a few libraries in universe
<persia> Which can probably be dropped if glassfish2 is available to be sync'd from Debian main into universe.
<slytherin> persia: I tried to avoid it when Sun developers were packaging it. But was busy with some other things then.
<persia> slytherin: Understood.  We all were.
<robilad> slytherin: ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448509
<ubottu> Debian bug 448509 in wnpp "ITP: glassfish -- Open source Java EE 5 Application Server" [Wishlist,Closed]
 * persia laments the existence of *4* different repackagings of Apache Derby currently in the archives
<slytherin> anyway, robilad, you are in charge of server stack. :-)
<robilad> done ;)
<robilad> ah, wait ... ;)
 * slytherin has to go for a meeting.
<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
<robilad> afaik, yes
<Koon> but the landscape may have changed
<robilad> but i think this is a new package -
<robilad> since it moves a lot of things from contrib to main.
<robilad> may want to ping twerner
 * robilad wonders what in charge means - koon is actually getting things done, i'm just pointing out hurdles
<persia> robilad: You're responsible for identifying things that need doing.  You mentioned maven, and Koon has been running with that.  What's next?
<robilad> good question - I'm tying to beat that out of glassfish folks
<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
<robilad> for that I need to know what the dep graph of glassfish & geronimo etc. looks like.
<robilad> and compare that with what we + debian have
<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.
<robilad> ok, will  do
 * persia knows Sun is an easy target, but surely there's more as well
<robilad> there is tons more
<robilad> the web framework explosion in javaland has been quite ... special.
<Koon> I've been working on headless -- I think it should have reasonable depends soon.
<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.
<Koon> there is a libnss-mdns recommend that brings a lot of things in... I've been asking doko why he put it in
<Koon> otherwise it's looking good, just a few libs to switch to -headless depends
<persia> Isn't that the piece for dynamic networking to better connect with 169.254.0.0/16 ?
<Koon> yes -- I just don't know what it enables in the JRE-headless that warrants a Recommends rather than a Suggests
<Koon> because it pulls avahi, dbus... on a server install
<persia> Right.
<Koon> but doko added it on purpose at one point, so I want to hear his reasons before I push to remove it :)
<persia> Makes sense.
<Koon> the final goal is to have tomcat6 installation as a tasksel in intrepid
<Koon> (server)
<persia> Well, one of the goals :)
<Koon> heh
<persia> Personally, I'd settle for being able to install Java on a server without X and have a reasonable number of libraries.
<Koon> persia: try "apt-get install --no-install-recommends default-jre-headless", looks pretty reasonable
<Koon> 9 extra packages, including openjdk-6-jre-lib and java-common
<persia> Koon: Sure, but that doesn't happen with apt-get libfoo-java in intrepid :)
<persia> (it ought though).
<persia> (and probably will)
<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
<Koon> they also need to be migrated to build with default-jdk in parallel
<persia> Koon: I think not on the RoadMap, but something like slytherin's MoveToUniverse page.
<Koon> sure
<persia> Then we could have a Roadmap item "enable headless for libaries".
<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
<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.
<robilad> ack
<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?
<Koon> I won't be there this meeting, vacation time
<persia> Anyone else?  Maybe someone who isn't already taking care of a Roadmap item?
<Koon> robilad: could that library status tracking be part of the library tracking work you've talked about a few minutes ago ?
<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.
<robilad> yeah, i think so -
<robilad> please add it to the wiki for the next meeting
<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.
<Koon> what we have -- what we should have -- what we have but with bad depends -- what we have but without default-jdk building support
<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
<robilad> right - i think keeping them separate is useful for other tasks as well.
<robilad> as it is a bit of a general breakdown along different goals (default-jdk/headless/server)
<robilad> so two axes ;)
<Koon> robilad: and if there is a semi-automated way of seeing what should need non-headless, that would be great :)
<robilad> heh ;)
<robilad> 'build it wiuth headless, see if it breaks?' ;)
<Koon> hmm, you can't build with headless
<Koon> default-jdk is a full one :)
<Koon> so you run it with headless, but you never know if you don't miss a class that would call the wrong package
<robilad> ah, ok - then it really comes down to checking strings in package class fuiles.
<Koon> I have no clue about that, but that sounds great :)
<Koon> bbl
<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
<robilad> to do charting, graphical presentations, etc.
<Koon> sure, nothing prevents them from doing so
<robilad> ah, then I have to look at the difference between headless and non headless
<Koon> non-headless installs headless
<Koon> so you install, say, tomcat6, it pulls the jre-headless in
<Koon> you happen to need more, install openjdk-6-jdk
<Koon> it would still work :)
<Koon> (really bbl)
<persia> Headless also pulls the support libraries to emit sound and manage video display.
<kaaloo> Koon: Hi I wanted to get back to you after going through the maven support spec
<Koon> kaaloo: sure
<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
<Koon> kaaloo: interesting approach. I'm just not sure this would be acceptable on buildd's...
<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?
<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.
<Koon> note that pom.xml files could also be auto-generated without a proxy implementation
<Koon> the proxy implemnattion avoids patching maven
<persia> autogenerated at build time?  That saves patching N library sources, which would be a win.
<kaaloo> persia: So a build could launch a smart proxy for maven ?
<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
<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
<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.
<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.
<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
<Koon> kaaloo: please draft the alternate implementation on the spec, adding your name to the Contributors on top
 * Koon is also missing the necessary Maven foo to evaluate how difficult autogenerating poms would be
<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.
<Koon> It also looks cleaner on paper. We just emulate what maven wants to find.
<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
<persia> kaaloo: man apt-cache will show you lots of the easy interfaces.  dctrl-tools has some of the more complex query methods.
<persia> Be prepared to manipulate strings.
<Koon> Then it's more a question to the Maven project: do they intend to include the JPP patchset in main sources or not
<Koon> if they don't, we should definitely consider a proxy wrapper
<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
<persia> kaaloo: Err.  Sure.  Let us know how it goes :)
<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
<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.
<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.
<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.
<slytherin> LucidFox_: ping
<LucidFox_> hello slytherin
<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.
<slytherin> LucidFox_: And expect a docbook -> PDF post on planet by tomorrow. :-)
<LucidFox_> heh
<slytherin> using fop
<LucidFox_> heh... "teh package"
<slytherin> :-(
 * slytherin heads home
#ubuntu-java 2008-08-13
<dholbach> good morning
<slytherin> persia: there?
<slytherin> LucidFox: your comment is expected on the fop bug. :-)
<LucidFox> I'm budy
<LucidFox> * budy
<LucidFox> * busy
<slytherin> LucidFox: no issues, whenever you have time.
#ubuntu-java 2008-08-14
<dholbach> good morning
<slytherin> persia: FYI ... default-jdk in Debian still points to java-gcj-compat-dev and jftp fails to build with GCJ. :-(
<persia> :(
<persia> I'm guessing that is exceedingly unlikely to change in the next month, assuming the sarge release is still targeted for 15th September.
<slytherin> so should I tell submit the patch and tell them to specifically use openjdk to build?
<slytherin> I thought doko usually keeps tool chain in sync in both teh distros
<persia> He does, but Debian is fairly hard frozen in the run up to the lenny release: http://asdfasdf.ethz.ch/~tar/bts/
<persia> 31 days to go, with 134881 open bugs
<persia> http://bugs.debian.org/release-critical/ is also interesting: only 1557 RC bugs, with 322 patches to review / process.
<persia> (still something like 50 bugs a day that need to get closed, so big changes are unlikely)
<slytherin> hmm
<persia> So, we may have to diverge some stuff, and can feed the patches back to Debian in late September.
<slytherin> persia: any chance, we can have today's java meeting an hour earlier?
<persia> slytherin: Not with that much notice :)
<persia> That said, if you can't make it, and want to send a short summary of your status to the list, that works too.
<slytherin> persia: hmm. then I will miss the later half of meeting.
<persia> OK.  We'll do you first in Roadmap.  Did you have any other items on the agenda?
<slytherin> persia: I just added two.
<persia> slytherin: Hmm.  Well, we'll hope there is time then :)
<slytherin> ok
<slytherin> persia: free to sponsor a small fix?
<persia> slytherin: No.  I'm about 4 deep in my stack, and trying to eat before the Java meeting.  I've reserved some time to pound the sponsors queue soon, so putting it there will likely be best (and someone else might get to it first).
<slytherin> persia: Ok. It is already in sponsors queue.
<robilad> meeting is in 90 mins?
<robilad> or 150?
<robilad> looks more like 30 ;)
<persia> 20 now :)
<Juli__> persia: hi, have you had a chance to take a look on netbeans6.1 packages?
<persia> Juli__: Not as much as I'd like, unfortunately.  Work has been too busy.  I've a holiday tomorrow, and ought be able to look at them.
 * persia wants a physical duplicator with support for biological structures
<Juli__> oh, I really appreciate that
<slytherin> Juli__: WHy are netbeans packages on REVU? Shouldn't the .diff.gz be attached to a bug?
<Juli__> there are some new packages
<slytherin> Juli__: I don't udnerstand
<Juli__> some packages are updated from 6.0.1 to 6.1, but there are new libs required
<Juli__> jna for example
<Juli__> and we decided to change platform source package name, so it is the new source package now
<persia> My memory from the last time I looked was that there was some stuff on REVU, and some as diff.gz in bugs.
<Juli__> on REVU there are only platform, resolver and jna packages
<persia> slytherin: If you have time to look through them, that'd be a great help, as you've a fair degree of experience with how things ought be packaged.
<Juli__> netbeans and other updated libs are in bugs
<persia> Juli__: My memory is faulty: were the differences between xml-commons-resolver and libnb-resolver ever tracked down?
<slytherin> persia: I will try but I am not sure what is complexity. But everything will be on hold till Monday
<persia> slytherin: Heh.  You're off tomorrow too, but that means you're unable to review, as opposed to me ?
<Juli__> the difference is in the patch only, but I haven't got in touch with somebody about that
<persia> RIght, it's something that needs doing soon, as duplication of code is often grounds for rejection (causes hassles with security support, etc.)
<persia> Meeting in 5 minutes in #ubuntu-meeting
<slytherin> persia: I will not be able to do review on weekend. Won't have access to my machine over weekend.
<persia> slytherin: Understood.
<Juli__>  xml-commons-resolver is under java-pkg team  now, Michael Koch is active with this package for last year
<robilad> that's man-di
<Juli__> http://java.debian.net/
<persia> Team meeting in #ubuntu-meeting starting now
<robilad> persia: http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-7392&yr=2008&track=javaee
<robilad> for an introduction into major performance improvements over the past year
<robilad> basically, a very good dynamic compiler, i.e. hotspot, can afford to defer optimization decisions until runtime
<robilad> and then optimize for the actual system it's running on
<robilad> for example (hotspot does that now) reorder fields in a class so that the number of cache lines used for accessing frequantly used fields is minimized
<robilad> or optimisitically inline code depending on 'hot paths'
<robilad> and deinline it again once lightweight profiling shows that would be better
<persia> Ah, whereas for native compilation, if one did that one would have to target specific processors, rather than relatively broad ISAs
<robilad> (how much you can usefully inline depends on the cache of the system you're running on, obviously, and that's a hard choice you have to make in a native compiler)
<robilad> yep
<persia> OK.  Then for most processors, I'll agree with you.  For lpia, I think the number of variants are still small enough that native could be better, but even that probably won't last the lifetime of intrepid.
<persia> Thanks for the explanantion.
<robilad> so basically, hotspot has a ton of optimizations specifically for specific processors from intel, amd etc. developed together with their compiler engineers to try to optimize for that case.
<robilad> see PDF above for explanation of some of them
<robilad> and there is a lot of general optimizations that become possible at runtime
<persia> intel, amd, via, and sun?  Any chance of IBM processors being supported soon?
<robilad> no idea
<robilad> for example, you can at runtime figure out that a certain excaption is never being thrown
<persia> Oh well.  Ubuntu doesn't actually support s/390, but PPC still has a following.
<robilad> and get rid of the code handling it, etc.
<persia> Right.
<robilad> it's a pretty mighty tool ;)
<persia> Indeed.
<robilad> and it's going to get a whole lot mightier with the da vinci vm
<robilad> that#s a project to expose some of those optimization opportunities to dynamic language implementors
<robilad> (jruby, jython, etc.)
<robilad> so that they can rely on hotspot to optimize their method dispatch, etc. a lot more efficiently than a classic runtime for those languages would do.
<robilad> so if you have jruby now matching performance of c ruby despite a lot of hacks to work around the lack of a hotspot api for dynamic languages,
<robilad> picture the thing two years from now with a lot less code necessary, and the performance improvements outlined in the pdf above
<robilad> and then the open source jvm becomes a very mighty tool in general.
<persia> That will be powerful indeed.  Whlie Ruby in Ubuntu is still not so common, there's a lot of python.
<robilad> yep
#ubuntu-java 2008-08-15
<dholbach> good morning
<james_w> Hi Java team
<james_w> I think it would be great to have a java packaging session in developer week, and it may attract some new people to the team
<james_w> would somebody be willing to lead a session on this?
<persia> james_w: We've a bit of a shortage of those that can, although I'd certainly like to attend one :)
#ubuntu-java 2008-08-16
<tuxmaniac> hi folks. Cacao (OpenJDK dev kit) is in Debian Unstable. Just thought will be interesting for a few folks down here
<tuxmaniac> http://packages.debian.org/sid/main/cacao-oj6-jdk
<persia> tuxmaniac: Indeed.  It's also in intrepid :)
<tuxmaniac> persia: oh ok. Kust thought people would be interested
<tuxmaniac> just*
<persia> tuxmaniac: And you were right :)
<tuxmaniac> :)
<jpds> persia: I have assigned your mailing list request to jorge, please give him hugs for approval.
<persia> jpds: Thanks.
<jpds> https://rt.ubuntu.com/Ticket/Display.html?id=2919 - user/passwd: "ubuntu" if you would like to track the request.
#ubuntu-java 2009-08-12
<NonvocalScream> Is there anyway that a update can be released in Jaunty to address the vulnerability here https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/410297
<ubottu> Launchpad bug 410297 in sun-java6 "Sync sun-java6 6-15-1 (multiverse) from Debian unstable (non-free)" [High,Fix released]
#ubuntu-java 2009-08-13
<drubin> ko/b close
<Disconnect> having issues with tomcat 6.0.18 on jaunty. for some reason it stopped finding log4j in /usr/share/java. is there an obvious fix? ("stopped" as in when I left on tues, it worked. when I came in this morning, the email from the testers was "it doesn't start" and I'm getting nested exception is java.lang.NoClassDefFoundError: org/apache/log4j/Level)
#ubuntu-java 2009-08-14
<nicolasvw> Hello, when packaging a java app and setting Build-Deps to default-jdk instead of openjdk-6-jdk, how should one set the JAVA_HOME variable in rules? If using CDBS, does it do that for you?
#ubuntu-java 2009-08-15
<blknite> Hi - I need to make an array of objects (balls) ....any ideas? obviously new to Java - Thanks
<blknite> thanks
#ubuntu-java 2009-08-16
<shp1> anybody knows server side of java?
#ubuntu-java 2010-08-18
<miramardesign>  pane.add(progPanel, "South");  i want to not show this progressbar panel til upload starts
#ubuntu-java 2010-08-21
<panda59> hi
<panda59> i go here, because i have a problem
#ubuntu-java 2011-08-17
<duende> hola???
#ubuntu-java 2011-08-18
<Bu11et_Pr00f> scupper
<Bu11et_Pr00f> you here?
<Bu11et_Pr00f> waaa hossame
<scupper> yo
<Bu11et_Pr00f> 3el slama
<scupper> wiep
<scupper> hhhhhhhh
<scupper> passe sur ##resolve/java
<Bu11et_Pr00f> ok
#ubuntu-java 2011-08-19
<duende> hi, I have a problem
<duende> I wish change color to a JtoggleButton when is pushit
<duende> o selected
#ubuntu-java 2014-08-15
<basaatw> I need hlp with downloading and installing java
<basaatw> is there anyone in here that is kind and want to help a newbe out?
#ubuntu-java 2015-08-14
<indistylo> There is strange behavior with my ubuntu system,  I have just changed openJDK to Java 8, echo $JAVA_HOME is still showing openJDK, Full problem details, see this URL > http://paste.ubuntu.com/12077122/
#ubuntu-java 2019-08-16
<alec> test
#ubuntu-java 2020-08-16
<lbrazb> Are you a Java developer? Are you willing to invest 20min in the science to improve code review? If so, it would be great if you could take part in our experiment
<lbrazb>  http://campanella.ifi.uzh.ch
<lbrazb> As an appreciation token, we will donate 5 USD to a non-profit organization on your behalf!
