[00:00] <bryce> maybe NM talk can continue on, but we can call the official meeting done :-)
[00:00] <bryce> thanks
[00:00] <ogra> night all
[00:00] <asac> ArneGoetje: ok. open a bug then for sure and add to wiki
[00:00] <liw> guten Nacht, everyone
[00:00] <james_w> thanks all
[00:00] <asac> ArneGoetje: ill come back to you
[00:00] <ArneGoetje> asac: ok
[00:00] <asac> liw: its: "Gute Nacht"
[00:00] <asac> ;)
[00:00] <asac> not Guten
[00:00] <liw> asac, only in the real world
[00:00] <asac> oh right
[00:00] <liw> in _my_ world it's "guten Nacht und Wienerschnitzel mit Bananenkartoffeln"
[00:01] <asac> Bananenkartoffeln :)
[00:01] <ogra> yummy
[00:02] <asac> on top of wienerschnitzel ;)
[00:02] <asac> "dann mal gute nacht ;)"
[00:02] <asac> thanks all
[12:59]  * ogra waves
[12:59]  * yannick waves
[12:59] <davidm> good day ogra I'm glad you are back
[13:00] <davidm> #startmeeting
[13:00]  * ogra too :)
[13:00] <MootBot> Meeting started at 07:04. The chair is davidm.
[13:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[13:00] <davidm> Mootbot's time sense is off
[13:00] <lool> yannick: Perhaps add an entry in the agenda on the wiki page if you like to discuss ekiga/lpia
[13:00] <davidm> We have one item from last week
[13:00] <yannick> for the next meeting?
[13:00] <lool> yannick: For this one is ok
[13:01] <yannick> ok
[13:01] <davidm> lool was to investigation of xulrunner, langpacks and linux-lpia bits
[13:01] <lool> Ah I didn't investigate linux-lpia bits
[13:01] <davidm> OK, I'll carry it forward
[13:01] <lool> Concerning langpacks, the point was to support midbrowser in intrepid
[13:02] <lool> It seems this is quite easy to enable, but it requires poking Jeroen and a prerequirement is for translations to be enabled in intrepid
[13:02] <lool> Unfortunately, despite already being at alpha 4, translations aren't enabled in intrepid yet
[13:03] <lool> So i'll pole jeroen to get an ETA on this and see whether he can enable the flag for midbrowser translation inclusion in intrepid's langpacks when they get available
[13:03] <davidm> I would think that would get turned on soon
[13:03] <davidm> OK, thanks
[13:04] <davidm> lool, anything else on this?
[13:04] <StevenK> lool: pitti and seb128 have been discussing that with Jeroen, I believe.
[13:04] <lool> On the topic of xulrunner, I clarified what remained to be done to merge the gconf backend with asac; he gave me detailed instructions on what we want to do there; it's not too hard from a high level perspective, but it might not be easy to achieve as we need to move code at a later stage of the build process
[13:04] <lool> I've started looking into this, and will report progress
[13:05] <davidm> Sounds good.  Thanks.
[13:05] <lool> davidm: I don't have immediate access to the minutes of last meeting; do you recall what was to be checked with linux-lpia?
[13:05] <lool> I had a brief exchange with Michael, perhaps I have the information
[13:06] <davidm> I don't off the top of my head but I'll pull the logs and post them.
[13:06] <lool> Ok
[13:06] <davidm> Mootbot is a bit slow posting logs these days
[13:06] <StevenK> My guess is, "Why doesn't it exist yet?"
[13:06] <davidm> But I have mine.
[13:06] <lool> I'm happy to report on progress on xulrunner, langpacks and linux-lpia next week again; I know what needs to be done, and there are no critical blocker apart of translation enablement
[13:06] <lool> StevenK: It does exist?!
[13:07] <davidm> OK, I'll carry to complete action forward
[13:07] <lool> linux-lpia | 2.6.26-1.1 |      intrepid | source
[13:07] <ogra> (out of topic question for later discussion) regarding the question just popped up in -mobile ... are we planning SRUs for the bootspeed issues ?
[13:07] <StevenK> Oh, neat
[13:07] <davidm> [action] lool was to investigation of xulrunner, langpacks and linux-lpia bits
[13:07] <MootBot> ACTION received:  lool was to investigation of xulrunner, langpacks and linux-lpia bits
[13:07] <lool> It even builds udebs and cjwatson enabled d-i support for lpia!
[13:07] <StevenK> Oh, sorry, I was thinking about the meta binary package "linux-lpia"
[13:07] <lool> ogra: Lets discuss this towards the end of meeting as a separate topic?
[13:07] <davidm> ogra, can you add that to the agenda please
[13:08] <yannick> lool, ekiga/lpia added in the agenda.
[13:08] <ogra> lool, right,just didnt want it to be lost
[13:08] <lool> yannick: thanksely
[13:08] <davidm> lets review the status of intrepid tasks: merge of ppa, installer, images etc.
[13:09] <davidm> [topic] Stevenk livecd-rootfs
[13:09] <MootBot> New Topic:  Stevenk livecd-rootfs
[13:09] <StevenK> I am working on hacking the trigger scripts on antimony, and need to check with Adam. I will be writing him an e-mail after this meeting which the basic idea is, "Help!"
[13:10] <lool> StevenK: What could be a rough ETA of this working daily in the datacenter?
[13:11] <StevenK> lool: If I could clear my plate, concentrate on it and have Adam to bounce ideas off, less than a day. Realistically, next week.
[13:11] <ogra> StevenK, adam and elmo have moved my classmate builder over to antimony afaik due to me not being available and havung to generalize the build there should be a lot similarities now
[13:12] <lool> Ok; I guess it's up to davidm whether to give priority to your other tasks (which I guess are hardy ones) versus intrepid stuff; thanks for the update!
[13:12] <StevenK> ogra: I'm guessing that triggers one of the i386 builders to chug over it.
[13:12] <davidm> lool, I'd love to change priority but I can't :-(
[13:13] <davidm> OK
[13:13] <StevenK> So would I.
[13:13] <StevenK> I'm sick of OMGKITTENSURGENT hardy tasks popping up.
[13:13] <ogra> StevenK, i havent talked to either of thembut building images locally atm with the changes that were applied by colin and it seems to work fine here
[13:13] <davidm> StevenK, do you have any merges still on your plate
[13:13] <StevenK> Hand-wavy, modest. Ish.
[13:14] <ogra> so i suspect its just a matter of runing cron.daily in the right dir on antimony
[13:14] <davidm> OK,
[13:14] <StevenK> lool: Oh, Mr. pkg-maemo person, when is modest and libwpeditor-plus going to hit Debian?
[13:14] <ogra> lets corner them later today ;)
[13:14] <davidm> [topic] StevenK open merges
[13:14] <MootBot> New Topic:  StevenK open merges
[13:15] <StevenK> ogra: Actually, that's not a bad idea. I'll hit up Colin for help with the scripts, if I can, since he isn't in a ohmigodmyeyeshurt timezone.
[13:15] <StevenK> lool, davidm: ^
[13:15] <ogra> StevenK, colin is away until monday
[13:15] <StevenK> Doh!
[13:15] <StevenK> Okay, Monday it is.
[13:15] <davidm> StevenK, Good enough, let me know if I can help, but ogra is right Colin is on holiday this week.
[13:15] <ogra> but we have my builder and can look at differences
[13:15] <StevenK> Is this merges from Debian, or merges from the PPA?
[13:15] <persia> MInd you, we'll probably get lpia alternate CDs for Tuesday
[13:16] <davidm> StevenK, I'll be in London so can poke Colin if that helps
[13:16] <davidm> StevenK, outstanding merges of any kind
[13:16] <lool> StevenK: Good question; no idea what's holding them up; last time I checked libwpeditor-plus had been uploaded, but it was probably rejected as I don't see it; modest had trivial non-critical packaging issues, but was otherwise ready
[13:16] <StevenK> davidm: Colin or Adam are good people for me to beg for help. Colin is easier, due to timezones.
[13:16] <davidm> StevenK, We are coming close to feature freeze
[13:17] <StevenK> davidm: Add a action item for lool to chase libwpeditor-plus + modest?
[13:17] <davidm> StevenK, Adam is on my timezone can I bug him for anything for you?
[13:17] <davidm> lool, is that action OK for you?
[13:18] <StevenK> Just a status update. If pkg-maemo are going to do the work, I'm happy to get them sync'd and borrow credit.
[13:18] <persia> Can we pull from SVN to speed that?
[13:18] <StevenK> bzr
[13:18] <lool> davidm: Yup
[13:19] <StevenK> I can't think of any outstanding merges from Debian. I will hit up MoM tomorrow and grab stuff with my name on it.
[13:19] <persia> s/SVN/VCS/
[13:19] <lool> davidm: Just pinged the relevant person on IRC already; I'll help him push them to Debian and then sync them to Ubuntu
[13:19] <davidm> [action] lool to Debian to chase libwpeditor-plus + modest status
[13:19] <MootBot> ACTION received:  lool to Debian to chase libwpeditor-plus + modest status
[13:19] <davidm> OK next topic
[13:19] <StevenK> In terms of merges from the PPA, I'm not sure if anything has my name on it. persia?
[13:19] <persia> StevenK: Not any more: you've done a bunch.
[13:20] <davidm> [topic] persia status of the installer
[13:20] <MootBot> New Topic:  persia status of the installer
[13:20] <StevenK> davidm: The problem is, I really need to talk stuff over with Adam, since I often have questions while I'm doing the work. And working from 4am until 8am would just *suck*.
[13:20] <davidm> StevenK, understood
[13:20] <StevenK> s/Adam/Adam or Colin/
[13:20] <persia> Well, we don't have d-i for intrepid: it seems it needs to get dropped from P-a-s.  I'm expecting that to happen early next week.
[13:21] <lool> persia: Did you ask for it?
[13:21] <persia> lool: I didn't: as we discussed previously, I thought I'd confirm with Colin first.
[13:21] <persia> I can request it if we all feel sufficiently confident that such confirmation is deemed unnecessary.
[13:21] <lool> persia: Ok; I think you should mail Colin to allow him to forward to lamont/elmo asap
[13:22] <lool> lamont was very responsive to my latest Pas request
[13:22] <StevenK> lamont/elmo/infinity
[13:22] <persia> Actually, one needs to email all three of them, or they reject the request as invalid: documentation purposes and all.
[13:22] <ogra> i think lamont is away as well atm
[13:22] <persia> ogra: Doesn't matter who is there: any of them will do it, but they all need the email.
[13:22] <ogra> (not sure if he took one or two weeks off)
[13:22] <lool> StevenK: infinity has Pas access?
[13:22] <davidm> lots of folks are away this week
[13:22] <persia> lool: OK.  I'll push that sooner rather than waiting for Monday.
[13:23] <StevenK> lool: I believe so.
[13:23] <lamont> ogra: am not.
[13:23] <persia> Yes.
[13:23] <ogra> lamont, ah, hey :)
[13:23] <StevenK> I'd have to check, that's from memory.
[13:23]  * lool hugs lamont
[13:23] <persia> lamont: Don't interfere by presenting reality :p
[13:23] <StevenK> lamont: Well, since you're here.
[13:23] <StevenK> :-)
[13:23] <lamont> email.  all 3 of us.  kthx
[13:23] <lamont> :-)
[13:23]  * persia will send the request email, and cc: Colin in case he wants to object
[13:23] <lamont> ta
[13:23] <davidm> [topic] persia status of merges?
[13:23] <MootBot> New Topic:  persia status of merges?
[13:24] <persia> Oh.  Still on installer: glade hates me.  I'm still waiting for our images, but I think I can install ubuntu-mobile on 1024x600, but not yet 800x480.
[13:25] <davidm> Good luck on that.....
[13:25] <persia> Merges: treb & ume-announcer need me to comment on how good they are, and upload with slightly different changelogs (and a one-line fix to treb).
[13:26] <davidm> persia, anything outstanding?
[13:26] <persia> That ought happen tomorrow.  I'm planning to hit the remaining PPA stuff next week, and suspect it will take about a week.
[13:26] <davidm> sounds good
[13:27] <persia> outstanding?
[13:27] <davidm> Any other merger that you are aware of that need doing..
[13:28] <davidm> s/merger/merges/
[13:28] <persia> Oh, lots, but those are what I planned to do next week :)
[13:28] <davidm> persia, OK then I shall move on
[13:28] <davidm> [topic] lool status?
[13:28] <MootBot> New Topic:  lool status?
[13:29] <persia> I'm not aware of anything new coming from Debian, although I've not checked.  I am pulling a new BlueZ-gnome, but that's as much -desktop as -mobile.
[13:29] <lool> Hmm status is catchup done; working on MIC with moblin/Intel folks and on misc things already covered here
[13:30] <lool> Oh and I'm on national holiday tomorrow
[13:30] <StevenK> persia: bluez-{libs,utils} are all dealt with, right.
[13:30] <StevenK> s/.$/?/
[13:30] <lool> Will try attending the team phone call though
[13:30] <davidm> lool, thanks :-)
[13:30] <persia> StevenK: Yes, the entire BlueZ stack is good, but there's an overflow possible in bluez-gnome that I want to pull.
[13:32] <davidm> [topic] ogra status of the Classmate image
[13:32] <MootBot> New Topic:  ogra status of the Classmate image
[13:32] <ogra> i am currently poking a new bug that was introduced after colins changes with the image
[13:32] <ogra> (installer doesnt reboot automatically after install anymore)
[13:33] <ogra> beyond that the image is fine and has no regressions, the new kernel archive seems to work well and i need to discuss the remaining build changes that were done to run it in the DC with elmo or inifinity
[13:34] <davidm> ogra, what is the QA plan for the image?
[13:34] <ogra> to my knowledge it should be possible to just trigger builds for cmpc images in the DC by running the cron.daily script in my tree
[13:34] <ogra> well, QA was supposed to be done until the topic with security updates came up
[13:35] <ogra> the RC is an RC ... :)
[13:35] <lool> ogra: Will you release an image with current kernel or new security fixed kernel?
[13:35] <ogra> so the only change we had after RC is the new location and different signature for the kernel archive
[13:35] <lool> I guess the later since you're rebuilding it
[13:35] <ogra> lool, afaik the new kernel is the security one
[13:35] <lool> Yes
[13:35] <davidm> Ah, that is good
[13:36] <ogra> we will re-roll images regulary is the areement
[13:36] <ogra> if the amount of updates justifies
[13:36] <ogra> and for each pointrelease of ubuntu
[13:36] <lool> ogra: Will your cmpc kernel patches be merged in the next hardy-updates kernel?
[13:36] <ogra> with 8.04.2 the kernel patches i use are in the mainline kernel, so no separate builds for that are needed anymore
[13:37] <ogra> they already sit in hardy-proposed
[13:37] <ogra> 2.6.24-20.39 has them
[13:37] <lool> Ok so >= <IP_ADDRESS>.22 has your changes
[13:37] <lool> err 2.6.24-21.40 sorry
[13:37] <lool> Was looking at wrong line
[13:38] <ogra> (current proposed kernel is 2.6.24-21.40
[13:38] <ogra> right
[13:38] <davidm> ogra, Thanks for the update
[13:38] <davidm> next topic
[13:38] <ogra> so if i find the reason for the missing reboot i will be done
[13:39] <davidm> I think we will skip the next topic as we are waiting status from lool on the Debian status of modest libwpeditor-plus
[13:39] <davidm> moving on
[13:39] <davidm> [topic] ian_brasil ...start the weekly team reports again?. Is there a need?
[13:39] <MootBot> New Topic:  ian_brasil ...start the weekly team reports again?. Is there a need?
[13:40] <ian_brasil> i want to propose starting the weekly team reports again...i think they are valuable and a good way for others to find out what is going on in ume..the downside is a bit more work for the developers writing the reports every week
[13:40] <ian_brasil> thoughts?
[13:40] <davidm> ian_brasil, I will be posting a weekly report it's in progress now.
[13:40] <persia> ian_brasil: How about having minutes from this meeting sent to the list every week instead?
[13:41] <davidm> I'll aggregate team info and also post logs of this meeting with URL pointing at it.
[13:41] <ian_brasil> persia: that might be possible but an email tends to be a bit more detailed
[13:42] <persia> ian_brasil: Makes sense.  I'm just not sure that all changes will be usefully represented as Ubuntu Mobile becomes more integrated with the rest of Ubuntu.
[13:42] <lool> ian_brasil: davidm has been aggregating status from Canonical mobile team and has prepared internal reports for the last 2/3 weeks; I think he plans to send a stripped down versions without the private bits to the public list soon, but that's all quite recent organization still
[13:43] <davidm> lool, exactly, that is my plan.
[13:43] <lool> ian_brasil: So instead of everybody sending individual reports, we will have a weekly report for the team
[13:43] <lool> davidm: The server team is really good at this since some weeks
[13:43] <ian_brasil> lool: ah, that sounds ideal
[13:43] <davidm> Yes they are and I plan on matching them ;-)
[13:43] <lool> davidm: Not only do they post to internal, and public mailing list, they also blog it; quite nice  :-)
[13:43] <davidm> interesting
[13:44] <ian_brasil> yes, the server team are good at this
[13:44] <davidm> I'll have to look at the blog, that I've not seen
[13:44]  * davidm hates to blog
[13:44] <ogra> just copy and paste the mail content ;)
[13:44] <davidm> ian_brasil, does this address your concern?
[13:44] <ian_brasil> yes
[13:44] <davidm> OK, moving on then
[13:44] <davidm> :-)
[13:45] <davidm> [topic] Ekiga 3, LPIA (Yannick Defais)
[13:45] <MootBot> New Topic:  Ekiga 3, LPIA (Yannick Defais)
[13:45] <yannick> I'm asking you to do some testing about our current Ekiga (2.9) on LPIA as none of us do have those devices. We have special interest in usability with the new Ekiga GUI. We are still in the process of bug fixing and GUI reworking. We hope to release in september for the next GNOME.
[13:47] <lool> yannick: Can you give a high level summary of the changes?
[13:47] <lool> Especially those we should be concerned to test, or impacting lpia specifically
[13:48] <lool> yannick: e.g. die the UI change, did you work on hildonization, or is it simply the build system?
[13:49] <yannick> quit huge changes since we are working on it since years... A new GUI like most IM (roster + presence), new video codecs: theora (free) and h264 for the better one which match low bandwidth, hotplug device (using HAL)...
[13:50] <lool> yannick: Ok; so testing should be around basic IM and audio/video functionality as well as device setup?
[13:51] <lool> I personally have menlow hardware as well as a Q1, but neither of these has a (supported) webcam
[13:51] <lool> I don't have any webcam apart of the Q1U one which isn't supported
[13:51] <yannick> You can use Ekiga for audio calls only too
[13:51] <lool> Sure, I can test that with a happy second candidate, any taker?  :-)
[13:52] <lool> Well I'll phone myself then
[13:52] <davidm> lool, you and I can test
[13:52] <lool> yannick: Could you send me a recommendation for a good USB webcam which is known to be well supported for audio/video in ekiga?
[13:52] <lool> davidm: let's do this
[13:53] <yannick> do those device have usb port? you maybe can plug an usb webcam.
[13:53] <lool> yannick: They do have USB
[13:53] <yannick> lool, better use a UCV driver based webcam
[13:53] <davidm> less then 10 minute warning
[13:53] <lool> yannick: i'll buy a webcam and test video as I receive it
[13:53]  * ogra can test with a cmpc which has a proper uvcvideo cam
[13:53] <persia> I've a working webcam on my Kohjinsha, but don't yet have an intrepid lpia install for it.
[13:53] <yannick> s/UCV/UVC
[13:53] <lool> yannick: Ok; I'll check ekiga resources or the uvc's documentation; thanks
[13:53] <ogra> davidm, pick up one of the classmates if you are in london ;)
[13:54] <davidm> ogra, I will
[13:54] <davidm> OK moving on
[13:54] <lool> davidm: [action] lool+davidm+... test ekiga
[13:54] <davidm> [action]  lool+davidm+... test ekiga
[13:54] <MootBot> ACTION received:   lool+davidm+... test ekiga
[13:54] <yannick> You can report any comment/suggestion/bug in our BTS: http://bugzilla.gnome.org/enter_bug.cgi?product=ekiga
[13:54] <davidm> [topic] Bootspeed improvements in hardy, do we do SRUs ?
[13:54] <MootBot> New Topic:  Bootspeed improvements in hardy, do we do SRUs ?
[13:54] <yannick> Tnak you very much :-)
[13:54] <yannick> Thank*
[13:55] <davidm> ogra, was that your new topic?
[13:55] <pitti> hey
[13:55] <ogra> davidm, yeah
[13:56] <davidm> personally I think we do IF it does not impact the rest hardy, lool your thoughts?
[13:56] <ogra> not sure how important we consider it at all though
[13:56] <davidm> If it does we document how to do it and keep it in a testing image.
[13:56] <ogra> imho devices are rarely rebooted anyway
[13:56] <ogra> and rather put into suspend instead
[13:56] <davidm> It's very important to some.
[13:57] <davidm> Almost out of time
[13:57] <davidm> ogra, we may have to take this off line
[13:57] <ogra> fine with me
[13:57] <ogra> probably soething for the ML
[13:58] <ogra> that way we also might get more user feedback how much its needed
[13:58] <davidm> Yes, it is critical to document any boot speed wins and how to achieve them.
[13:58] <lool> ogra: If it's in any way dangerous you can fork to ppa
[13:58] <davidm> OK, endmeeting in 1 miunute
[13:58] <lool> But in general, we should be using SRUs which we are confident with as a mean to push things to hardy and not take the ppa route whenever possible
[13:59] <lool> I think this was the last topic?
[13:59] <davidm> lool, correct
[13:59] <persia> Has to have been :)
[13:59] <lool> Excellent timing then
[13:59] <davidm> endmeeting going twice
[13:59] <MacSlow> greetings
[13:59] <davidm> #endmeeting
[13:59] <MootBot> Meeting finished at 08:04.
[14:00] <davidm> Got to get mootbot time fixed ;-)
[14:00] <Keybuk> heh
[14:00] <davidm> Thanks everyone.
[14:00] <lool> Thanks for chairing
[14:01] <lool> davidm: It's displaying Ubuntu releases time; it's at hardy currently
[14:01] <lool> (08:04)
[14:01] <ogra> thanks
[14:01] <Keybuk> ok https://wiki.ubuntu.com/DesktopTeam/Meeting/2008-08-14
[14:01] <Keybuk> I had reports from everyone except tedg
[14:01] <Keybuk> let the public shaming begin ;)
[14:01] <Keybuk> Ken is on Leave, and mpt is awaiting the arrival of his new laptop
[14:01]  * pitti hopes that mpt's broken laptop is not due to intrepid
[14:02] <Keybuk> no, physically broken aiui
[14:02] <Keybuk> since he had to actually buy a new one
[14:02] <Keybuk> we have an outstanding action from last week
[14:02] <Keybuk>  * Riddell to follow up on MIR bug for libzip to remind pitti.
[14:02] <Keybuk> did that happen?
[14:02] <pitti> ugh, didn't see a bug mail about that
[14:02] <pitti> but Riddell is on akademy, so...
[14:03] <pitti> too many stuff to do and sleepless nights for alpha-4, sorry, forgot about it
[14:03] <Keybuk> no problem
[14:03] <Keybuk> it was his action ;)
[14:03] <pitti> doko should be there next week to do MIRs
[14:03] <Keybuk> mvo: you had an action about apt installation reports?
[14:03] <mvo> yes
[14:04] <mvo> * How useful are the apt filed installation failed reports? Should we
[14:04] <mvo>   not file them against the failed package (e.g. gedit) but against
[14:04] <mvo>   a central virtual component (like install-failurs) because most
[14:04] <mvo>   likely the problem is not with gedit, but with e.g. scrollkeeper
[14:04] <mvo>   that is run in the gedit postinst? This way triaggers
[14:04] <mvo>   can pinpoint the problem and assign to the right packages.
[14:04] <mvo>   I got some complaints that the apt bugreports clutter the
[14:04] <mvo>   buglists too much.
[14:04] <mvo> well, that is a agenda item for this meeting :)
[14:05] <pitti> mvo: TBH, they are quite annoying
[14:05] <pitti> not as a bug report as such
[14:05] <seb128> for the record I'm the one who complain
[14:05] <pitti> but because they seldomly hit the right package
[14:05] <mvo> right, that is what seb128 said too
[14:05] <pitti> and often it is PEBCAK
[14:06] <mvo> pebcak?
[14:06] <seb128> 95% of the bugs on GNOME packages are either scrollkeeper, or local corruption, or user doing ctrl-C, or no space, etc
[14:06] <pitti> mvo: problem exists between chair and keyboard
[14:06] <mvo> seb128: I added code to filter out the no space now
[14:06] <mvo> right
[14:06] <mvo> lcoal corruption is something I see quite often too (bad ram for example)
[14:07] <mvo> I see the following options a) disable them entirely b) move them to a new pseudo package and let them be triaged there c) leave them as they are
[14:07] <seb128> I suggested to create an "installation-issue" component and send those there
[14:07] <pitti> mvo: my gut feeling is that we should start paying attention once we get two or three duplicates
[14:07] <seb128> since they are usually incident reports rather than bugs
[14:07] <Keybuk> mvo: it seems to me that this issue would be best raised with the QA team
[14:08] <seb128> and bugsquad could triage there and reassign bugs when it makes sense
[14:08] <Keybuk> since they are the team that would need to triage those reports and get them on to to the right package
[14:08] <mvo> I should add that while they are annoying to us, they are much more annoying to our users so I'm not happy with a)
[14:08] <pitti> so, if we had automatic duplication for package install failures, we could do that
[14:08] <pitti> the auto-duplicater could set a bug to confirmed and public once it hits the third dup, or something like htat
[14:08] <pitti> that should get rid of a lot of noise
[14:08] <pitti> mvo: right, pure a) is bad
[14:08] <mvo> right, d) is "better filtering"
[14:09] <mvo> that is probably the best option
[14:09] <pitti> mvo: b) would just be an excuse to ignore them entirely, and is thus not really better than a) IMHO
[14:09] <pitti> I think for intrepid+1 we should sit down and talk about possibilities of auto-duplicating
[14:09] <seb128> pitti: that would still pollute bugs list
[14:09] <pitti> I'd love to work on that, if time permits
[14:09] <Keybuk> mvo: I think you should take this up with the QA team ;)
[14:09] <pitti> seb128: not more than crashes, ceratinly? we could leave them private?
[14:10] <mvo> pitti: I don't like (b) either for the same reaosons
[14:10] <pitti> mvo: e) !
[14:10] <seb128> pitti: the new component should be something to triage for bugsquad, not something to ignore ;-)
[14:10] <seb128> pitti: don't get me started on crashes ;-) I spent most of my week cleaning those and there is still around 3000 apport-crash open bugs which are not confirmed
[14:11] <mvo> I will talk to the QA people and see how they feel about a "package-failures" pseudo component and if they think they could do triaging on it
[14:11] <pitti> seb128: I don't think we should even *attempt* to exhaustively triage them
[14:11] <pitti> seb128: they just look like bugs because we currently don't have another place to report them to, but they aren't as precious as real bug reports
[14:11] <pitti> ok, different topic
[14:12] <seb128> right
[14:13] <Keybuk> ok
[14:13] <pitti> mvo: we'd lose the ability to match those to packages, though
[14:13] <pitti> mvo: s/ability/LP facilities/
[14:14] <pitti> mvo: please also mention the possibility of auto-duping (which requires quite some engineering, but that's still better than humans doing duplication)
[14:14] <mvo> hm, right. that is another problem with this solution, because everything gets dumped into it, I feel that people will be less inclinded to look at the reports
[14:14] <mvo> I don't care for haskell failures for example
[14:15] <mvo> but anyway, I will talk to QA and see what comes out of it (maybe they have some good ideas)
[14:15] <seb128> that's like the current package association was making sense, most of the time it's something the postinst calls which breaks and not due to the package which calls the command
[14:16] <seb128> "that's not like" rather
[14:16] <Keybuk> ok, I think we're going round in circles here now
[14:16] <Keybuk> mvo: I've added you an action to talk to QA
[14:16] <mvo> thanks
[14:16] <Keybuk> did I miss any other items from the agenda?
[14:16]  * pitti would like to quickly talk about empathy
[14:16] <Keybuk> pitti: go for it
[14:17] <pitti> so, I guess we all tested empathy in the last week, right? :)
[14:17] <pitti> my personal expression: looks a little less slick, ICQ connection is quite unreliable, and I didn't manage to get SIP working
[14:17]  * tedg thought Empathy was broken this morning, but it actually turns out none of his contacts are online -- for real :)
[14:17] <pitti> but apparently upstream is very active and keen on it
[14:17] <pitti> so, I currently don't see a convincing argument for or against it
[14:17] <seb128> pitti: does SIP work in pidgin?
[14:18] <pitti> seb128: I don't think it is supposed to
[14:18] <pitti> I just thought empathy was eventually meant to merge the pidgin and ekiga use cases
[14:18] <seb128> ok, so it's not in comparison to pidgin but just what noted
[14:18] <tedg> I wasn't able to get an A/V chat going in Intrepid, though I had in Hardy.
[14:18] <pitti> seb128: right
[14:18] <tedg> There may be a farsight issue in Intrepid.
[14:18] <pitti> a big ++ for listening to netwokr-manager, though
[14:19] <pitti> pidgin doesn't, adn thus never notices when I suspend or resume
[14:19] <seb128> nobody screamed on the list so far
[14:19] <seb128> somebody complain about some protocol not being supported and upstream added the corresponding profiles to svn
[14:19] <pitti> the "SIP working" is apparently just the lack of an input box for the registrar/server, upstream said he'd fix it ASAP
[14:20] <Keybuk> it's nice to have a responsive upstream ;)
[14:20] <pitti> but the inability to connect to ICQ for two days (while pidgin worked) concerned me a bit
[14:20] <seb128> my main motivation for the switch is that empathy should have a realiable schedule now since they are part of GNOME
[14:20] <pitti> Keybuk: ++
[14:20] <seb128> upstream is responsive
[14:20] <seb128> and that's the way to go
[14:20] <pedro_> I've testing it with butterfly and jabber and it works pretty fine for me, but the UI has some annoyances like that you can disable the notification sounds trough it instead you need to use gconf, etc
[14:20]  * mvo also had trouble with icq, but otherwise it was fine
[14:20] <pitti> so currently I am mildly in favor of empathy, if we do the default switch ASAP
[14:20] <seb128> where pidgin doesn't care about GNOME, claim they are not a GNOME application, don't have schedules apparently and are not responsive
[14:20] <pedro_> that's true
[14:20] <seb128> pitti: I was going to suggest setting it as default for the next alpha
[14:21] <Keybuk> that's not a bad idea
[14:21] <seb128> it's easy enough to roll back to pidgin if needed
[14:21] <pitti> I wished it would import my libpurple settings from pidgin
[14:21] <Keybuk> see who screams ;)
[14:21] <pitti> but otherwise it's fairly ok IMHO
[14:21] <seb128> pitti: there is a patch upstream for that
[14:21] <Keybuk> those using pidgin, after all, will still have it installed
[14:21] <pitti> right, updates won't autobreak
[14:21] <mvo> I don't like that some actions seemed to be only availabe on right-click on the notification area item
[14:21] <pitti> and we are going to support pidgin for at least intrepid, too
[14:21] <seb128> mvo: did you open bugs about those?
[14:21] <pitti> minor things like "missing auto-popup of windows" can certainly be fixed quickly
[14:22] <pitti> seb128: do you know if upstream would be willing to have a look at LP bugs?
[14:22] <pitti> that worked so well with tracker back then
[14:22] <seb128> pitti: they already do
[14:22] <mvo> seb128: no, it didn't bother me enough for that, but I can do
[14:22] <seb128> mvo: please do
[14:22] <pitti> reports were actually *acted* upon and fixed :)
[14:22] <seb128> pitti: Zdra on #ubuntu-desktop is upstream so you can ping him there too
[14:22] <pitti> so my impression is that empathy is in about the state of tracker when we adopted it
[14:23] <seb128> it's in better shape I would say
[14:23] <pitti> and tracker got much better very fast towards the end of the release
[14:23] <pitti> lots of little buglets, but by and large works
[14:23] <pitti> and the underlying technology is good
[14:23] <Keybuk> err
[14:23] <seb128> but I would like to try empathy by default for next alpha, that's not going to cost a lot and rolling back is trivial
[14:23] <Keybuk> please don't compare things with tracker as a compliment ;)
[14:24] <seb128> the main issue there is that we will need some main promotion
[14:24] <pitti> Keybuk: to be fair, upstream was *very* responsive and fixed our incoming bugs almost as fast as they came in
[14:24] <seb128> and that will cost some CD space
[14:24] <Keybuk> that's true
[14:24] <Keybuk> tracker upstream was much faster than tracker ;-)
[14:24] <pitti> Keybuk: the issue with tracker is that the entire concept is broken/painful :)
[14:24] <mvo> heh
[14:24] <Keybuk> I'm being unnecessarily mean and mdz-like
[14:24] <Keybuk> tracker's fault wasn't upstreams, it's Linux's and the kernels refusal to help
[14:24] <seb128> I'm waiting to see what the tracker rewritting will give
[14:24] <pitti> seb128: well, we'd drop pidgin in exchange, I suppose?
[14:25] <pitti> but empathy needs more plugins, so it might be a bit bigger
[14:25] <seb128> pitti: we still need libpurple for all those protocoles which have no telepathy connection managers
[14:25] <pitti> seb128: absolutely
[14:25] <pitti> empathy itself is 400 KB smaller than 'pidgin'
[14:25] <pitti> add some extra plugins for empathy
[14:25] <seb128> should be equivalent
[14:26] <pitti> telepathy-gabble alone is 214 KB
[14:26] <pitti> but a must (jabber)
[14:26] <pitti> anyway, we can sort out the details off-meeting
[14:26] <seb128> right
[14:26] <pitti> but general consensus seems to be to give it a chance and flip?
[14:26] <Keybuk> yup, looks that way
[14:26] <seb128> we will need you or doko to mir the telepathy-* and empathy
[14:26] <Keybuk> seb128: you can have an action for the seed changes, and pitti you can have one too ;)
[14:26]  * pitti will be on vacation for two weeks
[14:26] <seb128> probably doko since you will be on holidays tomorrow
[14:27] <seb128> Keybuk: deal ;-)
[14:27] <yannick> do you plan to replace Ekiga wuth Empathy?
[14:27] <seb128> no
[14:27] <pitti> the only seeds I'll be dealing with will be the ones in my morning cereals, I'm afraid :)
[14:27] <seb128> it's not ready to do that yet
[14:28] <pitti> would be cool to get sip, though
[14:28] <pitti> screw video, ekiga's video support is pretty bad unfortunately (compared to skype's)
[14:28] <Keybuk> ok
[14:28] <pitti> but it should already have moderate sip support?
[14:28] <Keybuk> any other items for today?
[14:28] <yannick> Issue is EMptathy is not telephony software: no DTMF, no call transfert etc. You'll get a basic SIP, not a real softphone.
[14:29] <seb128> yannick: we don't plan to replace ekiga don't worry
[14:29] <yannick> ok
[14:29] <pitti> (not _yet_ *grin*)
[14:29] <seb128> pitti: ;-)
[14:29] <Keybuk> seb128: new gdm battle looks to be getting nasty upstream
[14:29] <yannick> I've been able to get a audio+video call between Empathy and Ekiga 2.9.
[14:29] <seb128> Keybuk: aka fedora against the rest of the world?
[14:29] <pitti> as in, which gdm 2.24 will ship with?
[14:30] <Keybuk> indeed
[14:30] <Keybuk> DavidKit keeps posting me links to the thread
[14:30] <seb128> pitti: no, fedora guys are unhappy about GNOME not being decided to ship it yet
[14:30] <Keybuk> and I can never tell whether he's posting them because the guys (like the Mandriva guy) have good points and gdm is being silly
[14:30] <Keybuk> or whether he's doing the "Fedora rules the world, look at the pitiful people not obeying"
[14:30] <Keybuk> thing
[14:30] <pitti> /etc/udev/gdm.rules
[14:30] <seb128> not sure but I know some people upstream don't like the fedora guys attitude
[14:31] <Keybuk> pitti: /lib/udev/rules.d/gdm.rules
[14:31] <seb128> the discussion is not really constructive I've to say
[14:31] <Keybuk> seb128: no, I got that impression
[14:31] <seb128> it's "it's fine this way", "no it's not", "yes it is"
[14:31] <pitti> maybe it should be called 'fdm' then and become a separate project?
[14:31] <MacSlow> seb128, do you mean Jon?
[14:31] <pitti> (that's half-serious)
[14:32] <seb128> MacSlow: nobody specifically
[14:33] <MacSlow> ok
[14:33] <seb128> and the new gnome-session seems to be a new gdm bis
[14:34] <Keybuk> how is that doing?
[14:34] <MacSlow> seb128, William Jon, who's also one of the new gdm upstream-devs, rewrites that afaik
[14:34] <MacSlow> seb128, Keybuk: also full rewrite iirc
[14:35] <seb128> Keybuk: slowing, lucas who started on it is changing job and moving and has no time for it now, vuntz is travelling and the fedora guys seem rather interested by the dbus api rather than getting basic things working
[14:35] <Keybuk> heh
[14:35]  * Keybuk feigns shock
[14:35] <seb128> the dbus api is to inhibit session closing, etc
[14:36] <Keybuk> do you have a feel for which gnome-session we should ship?
[14:36] <Keybuk> since you're on holiday next weej
[14:36] <Keybuk> and then until after feature freeze
[14:37] <Keybuk> you only have a couple of days ;)
[14:37] <seb128> well, it's not easy
[14:37] <seb128> we can't start refusing to ship all the new GNOME things ;-)
[14:38] <Keybuk> well, no :
[14:38] <Keybuk> :p
[14:38] <pitti> could it roughly be described as "the new one is faster, elegant, and useless"?
[14:38] <seb128> I would have rolled back if that was easy
[14:38] <seb128> but gnome-panel uses the new gnome-session dbus api now for example
[14:38] <Keybuk> does that actually work yet?
[14:38] <Keybuk> the Reboot button has done nothing for me since the new stuff went in
[14:38] <pitti> well "less useful", in terms of not having any session management or user session configuration?
[14:38] <seb128> the inhibit thing no, but there is a dbus api to reboot, logout, etc which is working
[14:39] <seb128> pitti: I think those will be fixed before GNOME 2.24
[14:39] <Keybuk> ok
[14:39] <seb128> the real question is the session dialog
[14:39] <pitti> Keybuk: known problem, but tricky to solve
[14:39] <Keybuk> seb128: unlikely to be solved before FF
[14:39] <seb128> I'm too busy to rewrite the old one for the new gnome-session right now
[14:39] <Keybuk> so at this point, I'm not going to worry about it :p
[14:39] <pitti> "accept William's braindead solution" vs. "sane technical solution we don't have"
[14:39] <seb128> Keybuk: right
[14:40] <Keybuk> which brings me onto my next point ;)
[14:40] <seb128> Keybuk: that's a consolekit bug
[14:40] <Keybuk> pitti: you are away until after Feature Freeze
[14:40] <Keybuk> so tomorrow is your deadline for specs, all done?
[14:40] <seb128> Keybuk: debian and pitti refuses to have consolekit using policykit
[14:40] <pitti> seb128: if you are concerned about that, we can ship the shutdown/reboot scripts until we have something better
[14:40] <pitti> well, "refuse"
[14:40] <pitti> I just pointed out that it is a very problematic setup which will sooner or later bite back
[14:41] <pitti> as long as we use the defautl configuration, it shuold work ok, but don't you dare to customize it
[14:41] <seb128> ok, let's talk about that after your holidays
[14:41] <seb128> maybe gnome-session will have settled meanwhile
[14:41] <pitti> as I said, we can enable it in CK for now
[14:41] <pitti> to avoid blocking on that bug for long
[14:42] <seb128> up to you
[14:42] <Keybuk> guys, we only have 20 minutes left and I'd like to address the minor point of FF first, so could you take that discussion offline for now ? :)
[14:42] <seb128> we will have increasing complains but can wait 2 extra weeks to sort that
[14:42] <seb128> Keybuk: alright
[14:43] <Keybuk> pitti: ?
[14:43] <pitti> WFM
[14:43] <Keybuk> I was referring to my question to you above
 pitti: you are away until after Feature Freeze
[14:43] <Keybuk>  so tomorrow is your deadline for specs, all done?
[14:43] <pitti> intrepid-device-perms is blocked on slangasek getting in the new pam framework
[14:44] <Keybuk> when is that likely to happen?
[14:44] <pitti> in particular, that affects enabling libpam-ck-connector by default
[14:44] <Keybuk> is the new framework done and just waiting for upload?
[14:44] <pitti> Keybuk: "RSN" according to Steve
[14:44] <Keybuk> everything else works?
[14:44] <pitti> but that will just affect VT logins
[14:44] <pitti> nothing critical
[14:44] <Keybuk> sounds like Beta Available to me
[14:44] <Keybuk> jockey printer driver support?
[14:44] <pitti> its' installed by default, but needs to be enabled manually for now in PAM
[14:44] <Keybuk> is this going to be used by the frontend?
[14:45] <pitti> Keybuk: upstream s-c-p didn't add the support yet
[14:45] <Keybuk> when will upstream add the support?
[14:45] <pitti> but it's still useful for installing drivers with the jockey UI
[14:45] <pitti> Keybuk: unknown
[14:45] <Keybuk> ok
[14:45] <Keybuk> it sounds like that is backend work for a future release
[14:45] <pitti> I need some more small frontend changes, though
[14:45] <Keybuk> so beta available, and defer the frontend to a spec for the next release
[14:45] <pitti> like a checkbox to enable third-party driver sources
[14:45] <pitti> but the heavy lifting is done
[14:45] <Keybuk> and good work on gdm-guest-login
[14:45] <pitti> that's beta-available
[14:46] <Keybuk> indeed
[14:46] <pitti> just some bugs to squash, after FF
[14:46] <Keybuk> all beta available for FF, well done!
[14:46] <Keybuk> (update the statuses please :p)
[14:46] <pitti> ok
[14:46] <pitti> well, UI bits in jockey missing is sort of UI freeze
[14:46] <Keybuk> seb128: you are on Leave from Thursday next week through to after Feature Freeze
[14:46] <pitti> bad timing
[14:46] <Keybuk> so your FF deadline is Wednesday
[14:46] <seb128> right
[14:46] <Keybuk> the spell checkers stuff is mostly done?  are there any packages still to be demoted or removed as deps?
[14:47] <seb128> spellchecking is done and just needs testing
[14:47] <Keybuk> good work
[14:47] <Keybuk> intrepid menus review?
[14:47] <seb128> existant hunspell dictionnaries should still be added as depends, ArneGoetje is supposed to do that
[14:47] <pitti> Keybuk: (I still leave device-perms as "blocked" as it is now, to better reflect the state)
[14:47] <seb128> menus review will be done before my holidays
[14:48] <Keybuk> seb128: Loïc is back, and David's team are lightly loaded
[14:48] <seb128> those are mostly trivial changes
[14:48] <pitti> seb128: did you ping Arne about updating the l-support packages for new hunspell dicts?
[14:48] <Keybuk> so if you need some extra help, I can ask David
[14:48] <seb128> pitti: not yet, was too late yesterday, will do that today
[14:48] <pitti> seb128: great, thanks
[14:48] <Keybuk> seb128: likewise better login speed, there's a few bullet points there not addressed by gnome-session ?
[14:48] <seb128> Keybuk: help is always welcome, especially when we will have to sort those gnome-session issues
[14:48] <Keybuk> again, if you need help, let me know asap and I'll arrange for some of Loïc's time if possible
[14:48] <Keybuk> ok
[14:49] <Keybuk> mvo: intrepid desktop systemprefs
[14:49] <seb128> Keybuk: login speed, I'll look at the other points but not sure I'll manage to do all the changes, anywhere points where loic help would be welcome
[14:49] <seb128> Keybuk: thanks
[14:49] <Keybuk> it's in your PPA?  any particular reason it's not in the archive?
[14:49] <mvo> Keybuk: the proxy stuff is availabe in my ppa
[14:49] <mvo> Keybuk: the global selection of the default language is part of language-selector
[14:50] <Keybuk> the proxy stuff is the one we reallly wanted :)
[14:50] <mvo> upstream was not very keen on taking a patch so I implemented most of it in a external dbus backend package
[14:50] <Keybuk> ok, but any reason it's still in your PPA and not uploaded?
[14:50] <mvo> and just patch gnome-network-settings to do the dbus calls (relatively small patch)
[14:51] <mvo> no, just I will do that before the weekend
[14:51] <Keybuk> ok great
[14:51] <Keybuk> then it sounds beta available
[14:51]  * mvo nods
[14:51] <Keybuk> you have a little longer than everyone else, since you have all of next week before you go on leave
[14:51] <Keybuk> so your deadline is next friday
[14:51] <Keybuk> package supportedness ui
[14:52] <mvo> the hardy bits are done and are blocked on the final list of what is actually a server package
[14:52] <Keybuk> the Hardy bits are in your bzr branches and you say they're done?
[14:52] <mvo> yes
[14:52] <Keybuk> which bits go into Intrepid?
[14:52] <mvo> for intrepid mpt had some more suggestions for UI changes and more flexibility when the archive reoganization comes
[14:52] <Keybuk> is that on target for FF?
[14:53] <mvo> so that is mostly ground work for that right now, to better deal with debtags (we may use that as the vehicle)
[14:53] <Keybuk> at least is the backend bits you need done?
[14:54] <mvo> not all is done in the backend yet, sorry. I'm not sure if I manage FF with that, but that should be ok because for intrepid none of that will be actually used (as its a regular release and not a lts)
[14:54] <Keybuk> ok
[14:54] <mvo> so the package support status is much easier to figure out than in a lts
[14:54] <Keybuk> if you can get it to good progress next week, that would be great
[14:54] <Keybuk> upgrade testing in sandbox is beta available? well done!
[14:54] <mvo> I will do that
[14:54] <mvo> yeah, I got some feedback too (positive!)
[14:55] <mvo> I wil upload it into the archive too before the weekend, but its most useful currently for people running hardy obviously
[14:55] <Keybuk> ok great
[14:55] <Keybuk> Riddell: mostly beta available, well done, and nice to see KDE 4.1 in
[14:56] <Keybuk> (even though you're not here, at least I get to put that in the meeting log :p)
[14:56] <Keybuk> --
[14:56] <Keybuk> next topic: meeting times
[14:56] <Keybuk> I'm at a manager's sprint in London next week, I'll be still available for emergencies, but not regular calls, etc.
[14:56] <Keybuk> so I won't be able to lead this meeting
[14:56] <Keybuk> since Martin is away, he won't be able to either
[14:57] <Keybuk> and Seb is away as well
[14:57] <Keybuk> so there won't be a meeting next week
[14:57] <Keybuk> the week after that, Martin, Seb and Michael are awy
[14:57] <Keybuk> so I suggest we don't have meeting that week either
[14:57] <Keybuk> which means the next meeting will be the 4th September
[14:58] <Keybuk> (kwwii, mpt, Mirco and Macslow all attend Mark's weekly user experience calls - so they won't be without a weekly meeting :p)
[14:59] <Keybuk> err, and that's the end of this one ;)
[14:59] <Keybuk> thanks all
[14:59] <mvo> thanks
[14:59] <MacSlow> cheers
[14:59] <seb128> thanks
[14:59] <pedro_> thanks
[15:00] <pitti> thanks all
[15:00] <pitti> and those who have, enjoy your holidays
[15:00] <pitti> but now, off to releasing that alpha...
[15:00] <seb128> oh btw tomorrow is a national holiday here
[15:00] <seb128> I'll probably be around to catch up on some things but not full day
[15:00] <persia> #startmeeting
[15:00] <MootBot> Meeting started at 09:05. The chair is persia.
[15:01] <persia> Who's here for the Java meeting?
[15:01]  * robilad is
[15:01]  * slytherin raises hand
[15:01]  * persia suspects there are some lurkers
[15:02] <persia> Right.  Agenda is up.
[15:02] <persia> [LINK] https://wiki.ubuntu.com/JavaTeam/Meeting
[15:02] <MootBot> LINK received:  https://wiki.ubuntu.com/JavaTeam/Meeting
[15:02] <persia> First item, as always, is the Roadmap review
[15:02] <persia> [topic] Roadmap review
[15:02] <MootBot> New Topic:  Roadmap review
[15:02] <persia> [link] https://wiki.ubuntu.com/JavaTeam/Roadmap
[15:02] <MootBot> LINK received:  https://wiki.ubuntu.com/JavaTeam/Roadmap
[15:03] <persia> [topic] Integration of Java into server stack
[15:03] <MootBot> New Topic:  Integration of Java into server stack
[15:03] <persia> robilad: How is the breakdown progressing?
[15:03] <robilad> ok, looked a bit around, and we've said last week, that we want to see what the packaging structure would look like
[15:04] <robilad> so, the first thing that you'll find if you look for say, glassfish v3 dependencies, is
[15:05] <robilad> http://weblogs.java.net/blog/kohsuke/archive/20080107/modules.png
[15:05] <MootBot> LINK received:  http://weblogs.java.net/blog/kohsuke/archive/20080107/modules.png
[15:05] <robilad> which is a graph of modules generated by kohsuke for glassfish v3
[15:05] <robilad> it's impressive
[15:05] <robilad> it's huge. ;)
[15:06] <robilad> fortunately, most of those dependencies seem to be sun-specific, and presumably a part of glassfish and/or related projects.
[15:06] <robilad> the ones that aren't and are sticking out are jruby, (and it's subdependecies), ant, backport of java.util.concurrent, etc.
[15:06] <robilad> that's largely stuff hanging in the bottom of the tree
[15:07] <robilad> now, as the URL shows up there, this is the status of affairs back in january
[15:07] <robilad> so, we'd ideally want to avoid having to spend too much time with old data
[15:08] <robilad> i.e. how do we go about getting useful data what we need to package from projects using maven2 to build?
[15:08] <robilad> it turns out we're not the only ones considering that problem ;)
[15:08] <robilad> ideally, what we'd want for a project using maven2 to build, would be something like http://myfaces.apache.org/tobago/tobago-sandbox/dependency-analysis.html
[15:09] <robilad> http://myfaces.apache.org/tobago/tobago-sandbox/dependency-analysis.html
[15:09] <MootBot> LINK received:  http://myfaces.apache.org/tobago/tobago-sandbox/dependency-analysis.html
[15:09] <robilad> you can see that the project has dependecies it needs during the build, some dependencies are declared wrong, etc.
[15:09] <robilad> getting that kind of output from glassfish, etc. would be useful to match against our own package database
[15:10] <robilad> and we can get it through (in theory at least, havenT tried this yet)
[15:10] <robilad> http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
[15:10] <MootBot> LINK received:  http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
[15:10] <persia> And presumably such tools could be used to validate all dependencies, and better track e.g. what can be headless, etc.
[15:10] <robilad> yep
[15:10] <robilad> that's for maven, of course
[15:10] <persia> Is the generation code available somewhere, or can arbitrary packages be submitted?
[15:10] <persia> Ah, maven only.  That's trickier :)
[15:10] <robilad> for the general problem of what needs to depend on what, there is another nifty tool
[15:11] <robilad> http://www.kirkk.com/main/Main/JarAnalyzer
[15:11] <MootBot> LINK received:  http://www.kirkk.com/main/Main/JarAnalyzer
[15:11] <robilad> it can be used on a directory of jar files, and will tell you how they interdepend
[15:11] <slytherin> that reminds me, jaranalyzer is not in Ubuntu
[15:11] <robilad> if only we had a directory of all jar files in ubuntu ...
[15:11] <robilad> ah, wait, we do!
[15:11] <persia> Do we have a needs-packaging bug?
[15:11] <slytherin> It should be a sync from Debian.
[15:11] <persia> Ah, that's easier then.  Do we have that bug?
[15:12] <slytherin> No. I will log one.
[15:12] <persia> slytherin: Thanks.
[15:13] <robilad> ok - so much for the tools research - i haven't had time to apply this yet to generate concrete packaging tasks
[15:13] <robilad> but it should make our life a lot easier wrt what to package next.
[15:13] <persia> robilad: Still, excellent to know there are such tools.  Do you think you'll be able to identify some tasks for next week?
[15:13] <robilad> yeah
[15:13] <persia> Great.
[15:14] <persia> [action] robilad to prepare draft wiki page of server stack integration work for next meeting
[15:14] <MootBot> ACTION received:  robilad to prepare draft wiki page of server stack integration work for next meeting
[15:14] <persia> [topic] Identify possible opportunities to optimise the Java stack
[15:14] <MootBot> New Topic:  Identify possible opportunities to optimise the Java stack
[15:14] <persia> Does anyone want this?  We've had it up for a month, and nobody is running it.  I'd like to drop it from the roadmap.
[15:15] <slytherin> I would like to break this task in multiple
[15:15] <robilad> the tools, plus http://sparcs.kaist.ac.kr/~tinuviel/package/list.cgi?name=java should work fine
[15:15] <robilad> (the code for generating that status listing is on his site)
[15:16] <persia> slytherin: OK. Do you want to lead that then, and prepare a breakdown, etc?
[15:16] <slytherin> persia: One of the sub task I had already added to agenda. Removing -gcj packages from 'Recommends'
[15:17] <persia> Right.  We'll talk about that specific item soon, but I think either someone should volunteer to handle the general case, or we shouldn't talk about it every meeting :)
[15:17] <persia> (not to fix it, just to identify the opportunities)
[15:18] <slytherin> For now keep it, I will break it down in next week.
[15:18] <persia> [action] slytherin to take over identification of possible opportunities to optimise the Java stack.
[15:18] <MootBot> ACTION received:  slytherin to take over identification of possible opportunities to optimise the Java stack.
[15:18] <persia> [topic] Transition Java packagse from multiverse to universe where possible.
[15:18] <MootBot> New Topic:  Transition Java packagse from multiverse to universe where possible.
[15:19] <persia> slytherin: How is that going?
[15:19] <slytherin> I logged 2 bugs today, one each for libgdata-java and libcodemodel-java.
[15:19] <persia> OK.  Are we catching up with Debian, or is there still a long way to go?
[15:20] <slytherin> Another bug for libswingx-java will come soon
[15:20] <persia> Also, is it mostly packaging changes, or just component changes?
[15:20] <slytherin> It is mostly sync. In some cases it will be merge.
[15:20] <slytherin> I am keeping an eye on pkg-java list to see which packages are migrated to openjdk
[15:20] <persia> OK.  Do you need anything from anyone else?
[15:21] <slytherin> No.
[15:21] <persia> OK.  Moving on.
[15:21] <persia> [topic] Maven packaging support options
[15:21] <MootBot> New Topic:  Maven packaging support options
[15:21] <persia> Koon seems to be absent.
[15:22] <persia> kaaloo had an interesting idea of dynamically generating pom files based on apt-cache and fooling maven.  Any comments on that idea?
[15:22] <persia> (kaaloo is also absent)
[15:22]  * slytherin didn't get time to look into that part of spec.
[15:24] <persia> OK.  That's it for roadmap then.  On to other items.
[15:24] <persia> [topic] Discuss possibility of putting JRE on desktop and/or server CD images
[15:24] <MootBot> New Topic:  Discuss possibility of putting JRE on desktop and/or server CD images
[15:25] <persia> Personally, I think those decisions are best made by the Desktop and Server teams, but if there is support here, maybe we can appoint an ambassador to attend one of their meetings?
[15:25] <slytherin> In my opinion it should be possible to server CD since the size of CD is pretty small, around 580MB
[15:26] <slytherin> I would like Koon or robilad to take it up with server team.
[15:26] <robilad> i'd suggest koon, too.
[15:26] <persia> Koon sounds like a good person to be ambassador to the server team, since he's also active there.  Let's give him an action for the minutes :)
[15:27] <robilad> ;)
[15:27] <persia> [action] Koon to talk to server team about putting JRE on the CD.
[15:27] <MootBot> ACTION received:  Koon to talk to server team about putting JRE on the CD.
[15:27] <persia> Who here also works with the Desktop team?
[15:27] <slytherin> For desktop it is impossible now. But we would like to analyze if it is possible to split JRE in different packages ex. separate localizations. We should target this for intrepid +1
[15:28] <persia> slytherin: That sounds good.  Shall we defer until intrepid+1 opens?
[15:28] <slytherin> Sure.
[15:28] <persia> OK.  Next item:
[15:29] <persia> (and splitting it up into sensible chunks)
[15:29] <persia> [topic] default look and feel
[15:29] <MootBot> New Topic:  default look and feel
[15:30] <slytherin> On that topic, we have almost agreed that if Kubuntu team has no issues we shuold make GTK as default look and feel. I had added yuriy to the particular bug and dropped a message for him on IRC but haven't got any reply.
[15:31] <persia> Anyone from the Kubuntu team here?
[15:31] <persia> Anyone willing to go talk to the Kubuntu team and report back next week?
[15:32] <persia> Any objections to using GTK as the default look & feel?
[15:33] <slytherin> I guess we need to raise this question on KDe devel list. Otehr than that I have no idea how to approach the problem.
[15:33] <slytherin> oops, I meant Kubuntu devel list
[15:33] <persia> slytherin: Are you up for drafting that mail?  Maybe cc: the java list?
[15:34] <slytherin> persia: won't be possible today, will be travelling to home town in an hour or 2.
[15:34] <persia> slytherin: Maybe next week then.  No rush.
[15:34] <slytherin> For Kubuntu we could propose Nimbus look and feel but it is not part of any jre yet. - http://java.sun.com/developer/technicalArticles/javase/java6u10/#nimbus Also question remains as to how do we select different look and feel depending on DE.
[15:35] <persia> Let's start the discussion with them, and see what they think about metal vs. GTK.  Getting per-DE themes is probably intrepid+1
[15:35] <slytherin> So let's keep that topic aside till we receive response from Kubuntu team
[15:35] <persia> [action] slythering to contact kubuntu team re: look & feel
[15:35] <MootBot> ACTION received:  slythering to contact kubuntu team re: look & feel
[15:36] <persia> [topic] removal of -gcj packages from 'Recommends'
[15:36] <MootBot> New Topic:  removal of -gcj packages from 'Recommends'
[15:36] <slytherin> This is an important one.
[15:36] <robilad> sounds useful, now that openjdk is the default.
[15:37] <slytherin> Currently many java libraries try to pull *gcj* packages in intrepid because their corresponding -gcj package is in 'Recommends'
[15:37] <slytherin> I have already worked on bsh and patch is waiting sponsorship. bug 257402
[15:38] <persia> gcj is still useful for many things, but may no longer make sense as the default.
[15:38] <robilad> cool - is this something we'll be able to sync on with debian?
[15:38] <robilad> (post lenny, I assume)
[15:38] <slytherin> robilad: For Debian default-jdk will be java-gcj-compat-dev for lenny.
[15:40] <persia> Even post-lenny it's tricky, as OpenJDK only works on three architectures.
[15:40] <persia> Even so, the proper solution is likely to be using default-jdk, and only selecting -gcj when that is the default jdk.
[15:40] <robilad> right, makes sense
[15:41] <robilad> indirection ftw
[15:41] <slytherin> persia: Can you please explain what is advantage of -gcj package?
[15:42] <persia> slytherin: It's compiled natively, so it doesn't need JIT, and runs faster.  That said, it's compiled natively, so you can't do some of the runtime tricks you can do with pure Java.
[15:42] <slytherin> hmm
[15:42] <robilad> aeh, the runs faster bit is a bit wrong ;)
[15:43] <robilad> (at least with hotspot on x86, amd64, sparc)
[15:44] <slytherin> anyway, let's target end of this month for removing -gcj from recommends for all the packages.
[15:44] <persia> robilad: Really?  VM with JIT and hotspot will be faster than native?  I suspect that's due to the compiler more than the VM.
[15:44] <robilad> nah, it's due to the vm
[15:45] <robilad> basically, hotspot optimizes the code for actual usage and hot paths
[15:45] <persia> robilad: After the meeting, if you have time to explain, I'd like to hear more.
[15:45] <robilad> and can heavily opitmize and deoptimize it depending on very lightweight profiling, etc.
[15:45] <robilad> sure.
[15:45] <persia> slytherin: That seems sane.  Do we have a way to automatically generate a list of affected packages that need work?
[15:46] <slytherin> persia: Not sure. but we should check all the 'lib*-java packages.
[15:47] <persia> OK.  Any volunteers to lead this cleanup effort?
[15:48] <slytherin> not me, but I will be doing it as and when possible.
[15:49] <persia> Heh.  OK We'll just note it as an initiative then, but not roadmap it, as you've aleady two items :)
[15:49] <slytherin> sure
[15:49] <persia> [topic] last minute additions
[15:49] <MootBot> New Topic:  last minute additions
[15:49] <persia> Anybody have anything else they want to discuss?
[15:49] <slytherin> I have 2 and then I run
[15:49] <persia> 2 more?  What?
[15:50] <slytherin> ant had a bug fix release 1.7.1. It will be good if we can get it in before FF.
[15:50] <persia> Do we have a bug?
[15:50] <slytherin> didn't check.
[15:51] <persia> And the other one?
[15:51] <slytherin> I have logged bug for jaranalyzer- bug 257904
[15:51] <slytherin> :-)
[15:51] <robilad> thanks, slytherin
[15:51] <persia> Excellent.
[15:51] <persia> Anyone else have anything?
[15:52] <slytherin> Done from my side. I have to rush. Will be back on Monday. Happy hacking to everybody. :-)
[15:53] <persia> OK.  Anyone up for writing minutes?  I used MootBot this time, so it might be easier.
[15:53] <robilad> i'll take it over
[15:53] <persia> robilad: Thanks.
[15:53] <persia> #endmeeting
[15:53] <MootBot> Meeting finished at 09:57.


[02:14] <hyperair> Sarvatt_: okay, i think my gpu hangs are related to multihead. over the weekend my laptop didn't hang, but an hour or so after i plugged it into the monitor at work, it hung again.
[02:14] <hyperair> and my i915_error_state complains about not being able to allocate memory again.
[02:15] <hyperair> oh, vm/drop_caches=2 fixed that.
[02:16] <RAOF> hyperair: Hm, I was maybe noticing something similarish, but I think that got fixed.
[02:17] <hyperair> RAOF: which one? the gpu hang or the unable to allocate memory issue?
[02:17] <RAOF> GPU hang.
[02:17] <hyperair> ah
[02:17] <hyperair> which component's at fault here?
[02:17] <hyperair> the i915 kernel module or X?
[02:18] <RAOF> Hangs are always the kernel's fault :)
[02:19] <RAOF> But plausibly upgrading either could help.
[02:19] <hyperair> so the kernel got fixed recently?
[02:19] <RAOF> I'm not sure; I'm on Saucy, so things are moving fairly quickly.
[02:19] <hyperair> ah, i see
[02:19] <hyperair> is saucy running 3.10?
[02:20] <hyperair> In the past there was also the problem of not having a way to “close” a branch, which means that over time the list of branches could get huge. This was fixed in Mercurial 1.2 which introduced the --close-branch option for hg commit.
[02:20] <hyperair> oops
[02:20] <hyperair> http://people.ubuntu.com/~hyperair/i915-error-state
[02:21] <RAOF> Sorry, I didn't actually do any significant digging into my hangs before they got magically fixed, so your error-state isn't going to mean much to me :(
[02:22] <hyperair> haha
[02:22] <hyperair> okay
[05:24] <mlankhorst> morning