[12:52] <ogra> popey, do you or anyone else who has admin on the ubuntu-users ML monitor the "Ubuntu 10.04.1 LTS released" thread ? it seems to be running out of bounds (once again thanks to karl)
[12:54] <dholbach> popey, make ogra admin, quick! :)
[12:55] <ogra> dholbach, shush, i have enopugh responsibilities
[12:55] <dholbach> popey, quick! :)
[13:08] <czajkowski> popey: is on hols
[13:08] <czajkowski> ogra: is there ever a thread on that ML that actually doesnt run out of bounds
[13:09] <ogra> czajkowski, well, if people say "fuck you" or STFU or discussing trhe meaning of rape thats a bit more out of bounds than normally
[13:12] <czajkowski> ugh
[14:00] <lag> o/
[14:02] <mpoirier> mpoirier \o
[14:02] <ogra> persia, do you run it ?
[14:03] <lag> mpoirier: mpoirier o/ :D
[14:03] <mpoirier> he... sleeping...
[14:05] <davidm> NCommander, you running this show?
[14:05] <NCommander> #startmeeting
[14:05] <MootBot> Meeting started at 08:05. The chair is NCommander.
[14:05] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[14:05]  * NCommander grumbles
[14:05] <NCommander> sorry, alarm failed to go off
[14:05] <ogra> oh, i thought you had handed over to persia
[14:05] <persia> no grumbling :)
[14:05] <davidm> G'day all
[14:05] <NCommander> ogra: I took it back because my normal dinner plans were canceled
[14:05] <ogra> ah
[14:05] <NCommander> [link] https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100824
[14:06] <MootBot> LINK received:  https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100824
[14:06] <ogra> no meow-burgers today ?
[14:06]  * NCommander throws his cat at ogra's head
[14:06] <ogra> heh
[14:06] <NCommander> [topic] Action Item Review
[14:06] <MootBot> New Topic:  Action Item Review
[14:06] <NCommander> [topic] NCommander to unbreak apport retracer (c/o)
[14:06] <MootBot> New Topic:  NCommander to unbreak apport retracer (c/o)
[14:06]  * NCommander coughs
[14:07] <NCommander> This is poriving to be a damn pain because I can't rebuild the chroots on the porter box
[14:07] <ogra> does it still make sense to re-enable it ? we have beta soon :)
[14:07] <NCommander> and my bandwidth is ... limited
[14:07] <NCommander> so c/o
[14:07] <NCommander> [topic] Standing Items
[14:07] <MootBot> New Topic:  Standing Items
[14:07] <NCommander> [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html
[14:07] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html
[14:08] <NCommander> [link] http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-ubuntu-10.10-beta.html
[14:08] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-ubuntu-10.10-beta.html
[14:08] <ogra> both look just horrid
[14:08] <ogra> please please please guys, get your items done or postponed
[14:08] <GrueMaster> I should have my 1 item done today.
[14:09] <ogra> \o/
[14:09] <ogra> NCommander, how about yours ?
[14:09] <NCommander> there's been some VERY slow work on subarch, but I have to add additional work items because cjwatson wants me to review with d-boot before we implement in Ubuntu which is slowing things down
[14:09] <ogra> Have new warning message about usage of generic fallback code approved and implemented [1 day]
[14:09] <NCommander> so I can strrike two items, but I have to add two more in there place :-/
[14:09] <ogra> that doesnt look like it should take much time
[14:09] <NCommander> hrm, strike one
[14:10] <NCommander> ogra: it won't, but I've had to rebase some of my code against sid, and spin new patches to submit to d-boot for review
[14:10] <NCommander> Building a sid chroot on an internet connection that acan make dialup look fast is painful.
[14:10] <ogra> erm, wasnt that in flash-kernel ?
[14:10] <ogra> just put it into our tree
[14:11] <NCommander> ogra: I need an API change in libd-i
[14:11] <ogra> for the message ?
[14:11] <NCommander> cjwatson nixed any changes without discucsion from Debian.
[14:11] <NCommander> ogra: for the code that triggers the message
[14:11] <ogra> oh, ok, i thought it was a message inside flash-kernel
[14:11] <NCommander> ogra: thats just a warning that shows up on STDERR, we need one that pops up during install as well
[14:12] <ogra> NCommander, btw, asac and linaro have massive probs since your code was added to flash-kernel
[14:12] <ogra> it now runs in any case, even if you are in a build chroot
[14:12] <NCommander> ogra: have they filed a bug? :-)
[14:12] <ogra> no, they are working on fixes
[14:12] <NCommander> ogra: strikely speaking, that's the correct behavior
[14:12] <ogra> ha !
[14:12] <NCommander> *strictly
[14:12] <ogra> they just have
[14:12] <ogra> Have new warning message about usage of generic fallback code approved and implemented [1 day]
[14:12] <ogra> ugh
[14:13] <NCommander> yeah, I should change the time estimate
[14:13] <ogra> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/623375
[14:13] <NCommander> probably looking a full week out
[14:13] <ogra> no, that was mis-pasted :)
[14:13]  * NCommander looks
[14:13] <ogra> f-k wasnt executed inside chroots before your change eneterd it
[14:13] <NCommander> well, it was
[14:13] <NCommander> f-k just exitted silently :-)
[14:14] <NCommander> if you have a chroot on a properly supported arch, it works as expected. The problem is our buildds aren't quite supported
[14:14] <NCommander> [action] NCommander to discuss with linaro and asac on improved-generic-subarch-support
[14:14] <MootBot> ACTION received:  NCommander to discuss with linaro and asac on improved-generic-subarch-support
[14:14] <ogra> it doesnt work "as expected"
[14:15] <ogra> since it tries to access the NAND of the buildd
[14:15] <NCommander> ogra: well .... er, crap
[14:15] <NCommander> yeah
[14:15] <NCommander> that's a bug
[14:15] <ogra> (if your buildd is omap3)
[14:15] <NCommander> It shouldn't try and do that on a generic fallback install
[14:15] <NCommander> yeah
[14:15] <NCommander> oops
[14:16] <ogra> well, lool and asac are looking into it atm
[14:16] <NCommander> ogra: I'll work with asac and linaro to get it sorted. My Beagle is in Texas, so someone else will have to test
[14:16] <ogra> we're simply not affected in livecd-rootfs because update.initramfs is diverted during the build
[14:16]  * NCommander avoided breaking the world by sheer luck :-/
[14:16] <ogra> anyway, lets not hold up the meeting
[14:16] <NCommander> yeah
[14:17] <NCommander> [topic] Kernel Status (cooloney, mpoirier, lag)
[14:17] <MootBot> New Topic:  Kernel Status (cooloney, mpoirier, lag)
[14:17] <NCommander> ^- ericm
[14:17] <ogra> hey
[14:17] <lag> * Marvel (mvl-dove)
[14:17] <lag>    * FIXED    : ABI bumping and module checking errors after the branch sync'ed with LSP 5.3.2
[14:17] <lag>    * MISC     : Discussion of moving forward mvl-dove branch into Maverick
[14:17] <lag>  * Freescale (fsl-imx51)
[14:17] <lag>    * Nothing new this week
[14:17] <lag>  * Texas Instruments (ti-omap)
[14:17] <lag>    * MISC     : lag's Panda is broken - awaiting replacement from davidm
[14:17] <lag>    * MISC     : Still waiting for TI to release L24.9 to us
[14:17]  * ogra wasnt done with specs
[14:17] <lag>    * FIXED    : B591941 work around applied - working on correct fix
[14:17] <lag>    * FIXED    : B608266 GPMC was not initialized before accessing NAND
[14:17] <ogra> sigh
[14:17] <lag>    * FIXED    : B608279 now able to read the EDID from userspace
[14:17] <lag>    * RESUMED  : B563650 problem can be reproduced on latest 2.6.35-18 with non-UNR file system
[14:17] <lag>    * ON GOING : B605488 still unable to reproduce - will test on full-build when new HW arrives
[14:17] <lag> ..
[14:18] <mpoirier> https://bugs.launchpad.net/bugs/608266 - waiting for mobile team to test
[14:18] <NCommander> ogra: er, whoops. I took "not hold up" as "move on" :-)
[14:18]  * NCommander will go back after kernel discussion
[14:18] <mpoirier> https://bugs.launchpad.net/bugs/608279 - Fix committed
[14:18] <ogra> soryy, i wasnt clear
[14:18]  * ogra hugs mpoirier 
[14:18] <mpoirier> ouf ...
[14:19] <mpoirier> ..
[14:19] <rsalveti> ogra: mpoirier: did you see my email?
[14:19]  * NCommander hugs mpoirier 
[14:19] <mpoirier> yes, did not read yet.
[14:19] <rsalveti> about edid parsing at u-boot
[14:19] <rsalveti> mpoirier: the code is basically from omap 4, so in the future it should be easy to port to omap 3
[14:19] <mpoirier> duly noted.
[14:19] <mpoirier> very interesting.
[14:20] <ogra> rsalveti, did dyfet work on that at all (after all its his spec)
[14:20] <mpoirier> there might be a little bit of time before aI get a new panda.
[14:20] <mpoirier> I'll look at it.
[14:20] <rsalveti> ogra: don't know, he's still sleeping it seems dyfet_sleeping :-)
[14:20] <ogra> hrm
[14:20]  * NCommander head thunks
[14:20] <rsalveti> ogra: and he was fixing other bugs
[14:21] <NCommander> does anyone want to call dyfet?
[14:21] <ogra> rsalveti, well ...
[14:21] <rsalveti> could be interesting for him, that's why I added him at the email
[14:21] <GrueMaster> I will test 608266 today and report back.
[14:22] <rsalveti> I'm getting i/o errors at mtd now
[14:22] <rsalveti> but should be normal, probably missing a correct partition table
[14:22] <rsalveti> [    4.979064] end_request: I/O error, dev mtdblock0, sector 128
[14:22] <ogra> the table is hardcoded in the kernel iirc
[14:22] <ogra> if you write to an mtdblock you need to zero it first
[14:22] <rsalveti> I know, but it's probably empty or never created
[14:22] <rsalveti> like uImage and rootfs partition
[14:23] <ogra> what does /proc/mtd report ?
[14:23] <ogra> if you see partitions there its fine
[14:23] <rsalveti> ogra: shows fine, because the partition table is in the kernel
[14:23] <ogra> right
[14:23] <rsalveti> probably it's trying to mount or something like that
[14:23] <rsalveti> need to check
[14:24] <ogra> yeah
[14:24] <rsalveti> let's also wait GrueMaster to test
[14:25] <ogra> right
[14:25] <rsalveti> lag: any news regarding TI tree?
[14:25] <ogra> and file bugs so mpoirier doesnt get bored :)
[14:25] <rsalveti> sure :-)
[14:25] <ogra> NCommander, so since we touched the EDID spec, there is no need to return to specs
[14:25] <lag> rsalveti: No, nothing :(
[14:25] <ogra> (and since dyfet_sleeping isnt here)
[14:26] <lag> rsalveti: We're waiting on sebjan
[14:26] <NCommander> ogra: np
[14:26] <rsalveti> lag: hm, ok
[14:26]  * NCommander still thinks someone should call dyfet_sleeping 
[14:26] <rsalveti> thanks, anyway :-)
[14:26] <NCommander> can I move on?
[14:26] <lag> rsalveti: There's nothing I can do ...
[14:27] <ogra> NCommander, if the kernel team is happy
[14:27] <lag> rsajdok: <rock> lag <hard place>
[14:27] <lag> Doh!
[14:27] <ogra> heh
[14:27] <rsalveti> lag: np :-)
[14:27] <lag> rsalveti: <rock> lag <hard place>
[14:27]  * ogra steals lag's tab key
[14:27] <lag> ogra: It was you who told me I could use tab
[14:27] <ogra> use tab enough times ;)
[14:28] <lag> heh
[14:28] <ogra> three tabs and you get what you need ;)
[14:28] <ogra> oh, i started to see a new bug
[14:29]  * NCommander files a bug on ogra and lag's use of tabs
[14:29] <ogra> seems neither omap nor omap4 reboot anymore if reboot is issued
[14:29] <ogra> at least in initramfs
[14:29] <rsalveti> ouch
[14:29] <NCommander> ogra: ugh.
[14:29] <ogra> i'm not sure yet if thats the kernel or the reboot command from busybox
[14:29] <NCommander> ogra: does it work in the userland?
[14:29] <ogra> NCommander, yes
[14:30]  * NCommander can't see it being a utiluty problem, busybox generally just does a syscall to reboot()
[14:30] <ogra> but not in initramfs
[14:30] <NCommander> ooh, ugh
[14:30] <NCommander> That's nasty
[14:30] <ogra> and initramfs uses a different reboot
[14:30] <NCommander> that's fugly
[14:30] <NCommander> ogra: have fun debugging it :-)
[14:30] <ogra> :P
[14:31] <rsalveti> but did we change busybox?
[14:31] <ogra> thats the issue, i dont think we did
[14:31] <ogra> and we had at least one kernel upload per subarch since i saw it working
[14:32]  * NCommander should check if it works on dove tomorrow
[14:32] <ogra> so i'm tending towards the kernel has changed
[14:32] <ogra> and busybox calls something it stopped understanding
[14:33] <ogra> something like that
[14:33] <lag> ogra: Blames the kernel - shock!
[14:33] <rsalveti> ogra: busybox (1:1.15.3-1ubuntu2) 19 Aug 2010
[14:33] <ogra> rsalveti, oh, thanks :)
[14:33] <ogra> yeah, that might be it
[14:33] <rsalveti> doesn't seems related, but anyway
[14:34] <ogra> "* armel seems to build fine without -marm nowadays, so remove it."
[14:34] <ogra> well
[14:34] <ogra> (from the changelog)
[14:34] <NCommander> that seems like a bug :-)
[14:34] <rsalveti> hm, true, was looking at previous upload message
[14:35] <ogra> so it builds ...
[14:35] <ogra> just doesnt run properly :P
[14:35] <rsalveti> but we can pretend it's a kernel issue so we can keep lag and mpoirier busy
[14:35] <rsalveti> hehe
[14:35] <rsalveti> ogra: haha :-)
[14:35] <GrueMaster> Are we still in meeting mode, or are we deep diving into bugs & possible workarounds?
[14:35]  * lag has enough to do
[14:36] <ogra> GrueMaster, meeting indeed
[14:36] <NCommander> can I move on to QA?
[14:36] <ogra> NCommander, move !
[14:36] <rsalveti> goes
[14:36] <NCommander> [topic] QA Status (GrueMaster)
[14:36] <MootBot> New Topic:  QA Status (GrueMaster)
[14:36]  * NCommander does as he is commanded
[14:36] <GrueMaster> Attended QA CoP sprint last week.  Lots of daily test tracking ideas were shared.  Will review and implement something hopefully before Beta.  Need to explore more in detail.
[14:36] <GrueMaster> Received # new platforms in the last week.  Working to rearrange office to accomodate by EOD.
[14:36] <GrueMaster> Filed bugs against Banshee and F-Spot.  Possibly mono specific, but I don't know.  Need test suite that can help narrow down mono specific bugs.
[14:36] <GrueMaster> No new images since Aug 19.
[14:36] <ogra> GrueMaster, yep
[14:37] <NCommander> GrueMaster: did you get dove stuff yet?
[14:37] <NCommander> ^- davidm too
[14:37] <ogra> GrueMaster, waiting for dyfet_sleeping to fix the FTBFS of telepathy-glib
[14:37] <GrueMaster> I have received a Dove A0 (part of total # new systems received)
[14:37] <GrueMaster> ogra: Is that why Empathy is not installing on the new image?
[14:38] <ogra> yep
[14:38] <GrueMaster> ok
[14:38] <NCommander> GrueMaster: good to know. We were still having some issues getting confirmation where they were
[14:38] <ogra> and it is why i asked him about 6 weeks ago to look at it :P
[14:38] <dyfet_sleeping> ogra: just rebuild from archive, it is no longer broken
[14:38] <NCommander> davidm: did you get the two boards sent to you?
[14:38] <rsalveti> and there you go
[14:38]  * NCommander kicks the retry button
[14:38] <ogra> dyfet_waking, it is, i gave it back right after you pinged me today
[14:38] <ogra> and still fails with the same issues
[14:38]  * NCommander blinks
[14:38] <NCommander> ACK
[14:38]  * NCommander goes into shock from ia64 and sparc's deaths
[14:39] <dyfet_waking> ogra: what version did you build?
[14:39] <ogra> dyfet_waking, the one that failed
[14:39] <dyfet_waking> it's been updated in the archive
[14:40] <dyfet_waking> 0.11.13
[14:40] <NCommander> dyfet_waking: and what's what failed
[14:40] <GrueMaster> NCommander: Looks like the topic moved to FTBFS.
[14:40] <davidm> NCommander, I have all hardware now
[14:40] <ogra> dyfet_waking, 0.11.13-1ubuntu1 is what fails
[14:40] <NCommander> davidm: thanks. I'll inform the powers that be that everything was recieved
[14:40] <NCommander> dyfet_waking: are you building the source package?
[14:40] <dyfet_waking> Yes
[14:40] <NCommander> or are you building the upstream tarball?!
[14:41] <NCommander> dyfet_waking: how are you building it?
[14:41] <ogra> dyfet_waking, and the former debian sync also failed already since weeks
[14:41] <dyfet_waking> libtelepathy-glib-dev_0.11.13-1ubuntu1_armel.deb
[14:41] <dyfet_waking> libtelepathy-glib-dev_0.11.8-1_armel.deb
[14:41] <dyfet_waking> libtelepathy-glib-doc_0.11.13-1ubuntu1_all.deb
[14:41] <dyfet_waking> libtelepathy-glib-doc_0.11.8-1_all.deb
[14:41] <dyfet_waking> libtelepathy-glib0-dbg_0.11.13-1ubuntu1_armel.deb
[14:41] <dyfet_waking> libtelepathy-glib0-dbg_0.11.8-1_armel.deb
[14:42] <dyfet_waking> libtelepathy-glib0_0.11.13-1ubuntu1_armel.deb
[14:42] <dyfet_waking> libtelepathy-glib0_0.11.8-1_armel.deb
[14:42] <NCommander> 09:42:02 < dyfet_waking> libtelepathy-glib-dev_0.11.8-1_armel.deb
[14:42] <NCommander> 09:42:02 < dyfet_waking> libtelepathy-glib-doc_0.11.13-1ubuntu1_all.deb
[14:42] <NCommander> 09:42:02 < dyfet_waking> libtelepathy-glib-doc_0.11.8-1_all.deb
[14:42] <NCommander> argh
[14:42] <ogra> guys !
[14:42] <ogra> use a pastebin
[14:42] <NCommander> that was an accident
[14:42] <dyfet_waking> sorry :)
[14:42] <NCommander> irssi likes to paste when I middleclick
[14:42] <dyfet_waking> that was what I got to build this morning on arm on maverick
[14:42] <ogra> https://edge.launchpad.net/ubuntu/+source/telepathy-glib/0.11.13-1ubuntu1
[14:42] <NCommander> dyfet_waking: what platform are you building on?
[14:43] <dyfet_waking> beagle...it was slow :)
[14:43] <ogra> given back twice today, still failing on the same tests
[14:43] <dyfet_waking> lets discuss this after then...
[14:43] <GrueMaster> dyfet_waking: YOu should use the dove I have available.  Much faster.
[14:44] <NCommander> [action] dyfet and ogra to discuss telepathy-glib and report back
[14:44] <MootBot> ACTION received:  dyfet and ogra to discuss telepathy-glib and report back
[14:44] <ogra> anyway, beta is next thu,
[14:44] <NCommander> [topic] ARM Porting/FTBFS status (NCommander, dyfet)
[14:44] <MootBot> New Topic:  ARM Porting/FTBFS status (NCommander, dyfet)
[14:44]  * rsalveti is using his panda with usb disk, and it's fast
[14:44] <ogra> it needs to be fixed before friday
[14:44] <NCommander> I have nothing to report, I haven't had time to work on FTBFS
[14:44] <ogra> how is kde going dyfet_waking ?
[14:44] <dyfet_waking> I was going to work from what Michael gave me after waking :)
[14:45] <ogra> well, please priorize telepathy first
[14:45] <NCommander> dyfet_waking: please focus on telepathy
[14:45] <NCommander> d'oh
[14:45] <ogra> heh
[14:46] <NCommander> anyway
[14:46] <NCommander> [topic] ARM Image Status (ogra, NCommander)
[14:46] <MootBot> New Topic:  ARM Image Status (ogra, NCommander)
[14:46] <ogra> bad bad bad
[14:46] <NCommander> very bad
[14:46] <ogra> as you could see above already
[14:46]  * NCommander has some good though
[14:46] <ogra> but ...
[14:46] <ogra> oem-config has a fix thats pending upload
[14:46] <NCommander> wooo
[14:46] <rsalveti> cool
[14:46] <NCommander> if we could fix telepathy-glib, we can get our images going again
[14:46] <ogra> (i need to coordinate with cjwatson about uploading it soon)
[14:46] <ogra> yeah
[14:47] <ogra> well, there is also a filesystem corruption i have seen
[14:47] <NCommander> So, I have some news
[14:47] <NCommander> We've started building dove images again
[14:47] <ogra> with the preinstalled images
[14:47] <NCommander> currently only daily-live/ubuntu-netbook
[14:47] <ogra> lool even sees it *after* jasper has run
[14:47] <NCommander> I'll be re-enabling alternates sometimes this week for normal ubuntu, as building ubuntu-netbook alternates really goes south
[14:47] <cjwatson> ogra: coordinate with ev
[14:47] <ogra> cjwatson, will do
[14:48] <NCommander> speaking of ubuntu-netbook going south
[14:48] <GrueMaster> NCommander: Looks like alt-inst images are building too.
[14:48] <ogra> NCommander, we decided to not support alternates anymore
[14:48] <NCommander> GrueMaster: no, that was actually a separate issue
[14:48] <ogra> NCommander, can you instead enable server ?
[14:48] <GrueMaster> oh.
[14:48] <NCommander> ogra: cjwatson: can i delete these (http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily/) out of www or do we need to do something special
[14:48] <ogra> NCommander, just rm it
[14:48] <NCommander> thanks
[14:49]  * NCommander didn't know if they were safe to RM directly, or if I would break image building, and get fired
[14:49] <cjwatson> I think I already said to rm -rf it
[14:49] <ogra> indeed, thats why i suggested it :P
[14:49] <NCommander> cjwatson: oh, I must have missed that. Sorry
[14:49] <cjwatson> no problems
[14:49] <NCommander> [action] NCommander to clean out the stale dove alternates
[14:49] <MootBot> ACTION received:  NCommander to clean out the stale dove alternates
[14:49] <NCommander> [action] NCommander to smoke test ubuntu-server dove alternates
[14:49] <MootBot> ACTION received:  NCommander to smoke test ubuntu-server dove alternates
[14:50] <ogra> NCommander, there are other dirs too that could need cleaning
[14:50] <ogra> seems someone tried to build daily-preinstalled in /
[14:50] <NCommander> ogra: indeed, but my link to antimony is so damn slow that I don't want to try to cleanout the www folder until I'm state side again
[14:50] <NCommander> the lag is so bad that typing something takes about 2-3 secends per char
[14:51] <ogra> yeah, just have a look around, there is other mess to clean up if you're at it :)
[14:51] <NCommander> [action] NCommander to flush antimony's expired images
[14:51] <MootBot> ACTION received:  NCommander to flush antimony's expired images
[14:51] <NCommander> :-)
[14:51] <ogra> ... and stale empty dirs :)
[14:51] <NCommander> ogra: IT SHALL BE DONE!
[14:51] <ogra> haha
[14:52] <NCommander> [topic] ABO
[14:52] <MootBot> New Topic:  ABO
[14:52] <ogra> stop shouting, move
[14:52] <ogra> bah
[14:52]  * NCommander wins
[14:52] <ogra> youre to fast :P
[14:52] <rsalveti> ian_brasil: ^
[14:52] <ian_brasil> rbelem patched startkde  (and this was accepted) to start the plasma-mobile desktop and kubuntu mobile default settings package just needs some marketing text changing now - so we are ready to start building images..well, we still need to change the text in the seed to actually call this new default settings and we need a small change to plasma board to add this to the mobile systray but these are very minor things..
[14:52] <NCommander> ian_brasil: what archs are you planning to build for?
[14:53] <ian_brasil> armel and i386
[14:54] <NCommander> ian_brasil: I ask that you only target armel+omap4 and armel+omap for now. We're somewhat strapped for buildd power. Once we get all the kinks worked out o dove images, we can add it
[14:54] <ogra> well, i wonder if you really want to attempt to run it on omap3
[14:54] <NCommander> (omap4 is on a dedicated builder, omap and dove are sharing one :-/)
[14:54] <ian_brasil> NCommander: Ok..we can do that
[14:54] <ogra> whats the ram requirements ?
[14:54] <ogra> beagle only has 256M
[14:55] <NCommander> ogra: I thought there were some omap3 platforms with 512M
[14:55] <ogra> there is the beagle XM but its still not on the market
[14:55] <NCommander> ogra: I thought it was out
[14:55] <ogra> essentially all omap3 512M platforms currently are unavailable
[14:55] <NCommander> ogra: ugh.
[14:55] <ogra> apart from the touchbook for which we dont have kernel patches
[14:56] <NCommander> ian_brasil: if you want to trade omap for dove (which is also not out on the market), that's fine :-)
[14:56] <ogra> the other 512M hw you saw was all prototypes or not on the market yet
[14:56] <NCommander> ogra: I never saw any 512M hw directly
[14:56] <ian_brasil> NCommander: thx
[14:56] <ogra> NCommander, you were in prague, no ?
[14:56] <ogra> i'm sure i showed you some :)
[14:57] <NCommander> ogra: I was working on omap4
[14:57] <NCommander> :-)
[14:57] <NCommander> anyway. I think that's everything
[14:57] <NCommander> anyone got anything else
[14:57] <ogra> nope
[14:57] <NCommander> #endmeeting
[14:57] <MootBot> Meeting finished at 08:57.
[14:57] <ian_brasil> so persia was looking at how we can do the builds and hosting
[14:57] <NCommander> Cya next week!
[14:58] <ian_brasil> any news on that?
[14:58] <NCommander> ian_brasil: persia is AFK, I can assist you with this discussion :-)
[14:58] <ian_brasil> NCommander: great
[14:58] <NCommander> ian_brasil: let's move to #ubuntu-arm
[14:58] <ian_brasil> NCommander: ok
[15:00] <pitti> Keybuk, cjwatson, kees, mdz: TB meeting now?
[15:00]  * pitti pings sabdfl
[15:00] <cjwatson> I'm here, although robbiew also scheduled a catch-up call for now
[15:00] <cjwatson> I /msged him to ask whether it could be rescheduled
[15:00] <cjwatson> consider me here for the moment
[15:01] <mdz> pitti, yep
[15:01] <mdz> who is chairing?
[15:01] <cjwatson> agenda says Keybuk
[15:01] <Keybuk> yup
[15:01] <cjwatson> now that his internet works ... :)
[15:01] <Keybuk> was just loading the agenda
[15:01] <pitti> Keybuk: welcome back to the internets!
[15:01] <Keybuk> cjwatson: WILL EVERYONE PLEASE STOP SAYING THAT!
[15:01] <sabdfl> what did i miss?
[15:02] <highvoltage> pretty much just people welcomming Keybuk back to the interwebs
[15:02] <Keybuk> #startmeeting
[15:02] <MootBot> Meeting started at 09:02. The chair is Keybuk.
[15:02] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[15:02] <Keybuk> [LINK] Today's Agenda: https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:02] <MootBot> LINK received:  Today's Agenda: https://wiki.ubuntu.com/TechnicalBoardAgenda
[15:03] <Keybuk> [TOPIC] Action Review
[15:03] <MootBot> New Topic:  Action Review
[15:03] <Keybuk> I don't see any actions in the TeamReports, and my e-mail is still trickling through so I don't have a last-mailed-out agenda
[15:03] <Keybuk> does anyone know of any actions they were supposed to do? :-)
[15:04] <mdz> I missed the previous meeting due to travel
[15:04] <pitti> we didn't have any last time AFAIR
[15:04] <pitti> mdz: there was no real previous meeting
[15:04] <Keybuk> ok, no problem
[15:04] <mdz> there's nothing on https://wiki.ubuntu.com/TeamReports/August2010#Technical Board
[15:04] <cjwatson> pitti: welcome to the first ever meeting of the Ubuntu TB
[15:04] <Keybuk> mdz: indeed, as I said
[15:05] <pitti> we had two agenda points from Keybuk and mdz, but both of you were offline, so we skipped it
[15:05] <Keybuk> [TOPIC] brainstorm.ubuntu.com
[15:05] <MootBot> New Topic:  brainstorm.ubuntu.com
[15:05] <mdz> there's nothing in https://wiki.ubuntu.com/TeamReports/July2010#Technical Board either :-/
[15:05] <Keybuk> mdz: your topic
[15:05] <pitti> cjwatson: pah semantics :)
[15:05] <mdz> so, this came up in some engineering management discussion recently
[15:05] <mdz> and I wanted to discuss it with the TB
[15:06] <mdz> basically, the question is how to best utilize brainstorm as a mechanism to communicate with our user community
[15:06] <pitti> mdz: July> that got cancelled as well, due to lack of topics and people
[15:07] <mdz> my feeling on it is that brainstorm hasn't turned out to be a great way to filter suggestions
[15:07] <mdz> however, it has been pretty good at highlighting common concerns
[15:08] <mdz> in other words, it can tell us what people are thinking about
[15:08] <mdz> as such, I think the right way for the Ubuntu project to use brainstorm is to review the highest-voted items from time to time, and respond to them
[15:08] <cjwatson> also, without it we'd get even more flooded with bugs :)
[15:08] <mdz> a response might be:
[15:08] <cjwatson> I agree, in fact I thought that was what we used to do
[15:09] <pitti> at least in some UDS preparations we used to look at it
[15:09] <mdz> - an explanation of what we think about that issue, and how we might approach it
[15:09] <pitti> but indeed we never paid that much attention to it
[15:09] <mdz> - a link to some work in progress in that area, to illustrate what we're doing there
[15:09] <mdz> - feedback on why the idea isn't useful/relevant given the current goals of the project
[15:10] <mdz> cjwatson, we did that at one time, but it wasn't kept up
[15:10] <sabdfl> some official feedback on the top n could be useful, but could also just cause a flashpoint to flash
[15:10] <mdz> pitti, we used to look at it during UDS preparations as a source of ideas: i.e., is there anything here we haven't thought of which we should add to the list of features to examine?
[15:10] <cjwatson> I don't think we need to commit to reviewing the top n
[15:10] <mdz> it turned out not to be very useful for that
[15:10] <sabdfl> fwiw, the design team looked at the top 50 in kicking off the 11.04 thinking
[15:10] <pitti> mdz: I agree
[15:10] <mdz> because the items in it are things like "wireless doesn't work as well as we would like"
[15:10] <cjwatson> we can respond to things which are particularly worth responding to
[15:11] <mdz> the things in brainstorm are in most cases not "features" at all, not as we would think of them
[15:11] <cjwatson> and have informal criteria for that
[15:11] <mdz> they're feedback
[15:11] <mdz> consolidated, collaboratively filtered feedback
[15:11] <mdz> and the right thing to do with feedback is to read it and respond publicly
[15:11] <sabdfl> further, responding well to the most useful feedback encourages more like that
[15:11] <mdz> sabdfl, they looked at them with what in mind? inspiration?
[15:11] <sabdfl> and prioritization
[15:12] <mdz> right, so I think I'm coming at this from a different angle, looking at it as a communication facility rather than as a data source
[15:12] <mdz> it gives us our best chance at having a dialogue with the user community about things
[15:12] <mdz> without being overwhelmed
[15:13] <mdz> so first, do we agree that that is a useful way to position brainstorm?
[15:14] <mdz> not as a wishlist, or a way to get features implemented, but a way to have a structured conversation with our users about what's important to them
[15:14] <pitti> that makes it very close to a bug tracker with voting facility
[15:14] <pitti> but we don't require very precise information there
[15:14] <mdz> pitti, in functionality, yes, but we don't get bugs that say "wifi doesn't work" :-)
[15:14] <cjwatson> most of the things in brainstorm are too vague to be bugs
[15:14] <Keybuk> right, that'd be what I'd ask in return
[15:14] <pitti> so I concur with your perspective
[15:15] <Keybuk> how does this fit in with the existing bug tracker, spec tracker and the new stack exchange?
[15:15] <mdz> the bug tracker is a tool for developers and testers to track technical defects in Ubuntu
[15:15] <pitti> mdz: right, it keeps that kind of fuzzy information out of the bug tracker (or, rather, we get a little less of those)
[15:15] <mdz> the spec tracker is a project management tool to keep track of what we're working on
[15:16] <pitti> so, it's indeed a nice way to get a filtered view what area causes most problems
[15:16] <pitti> (not that it would be very surprising in most cases, though)
[15:16] <mdz> stack exchange is Q&A among anyone who is interested in Ubuntu, and is fairly new so we'll see how it ends up fitting in
[15:16] <mdz> brainstorm, I propose, should be a gateway between the people who make Ubuntu, and the people who use Ubuntu
[15:16] <mdz> Keybuk, make sense?
[15:16] <Keybuk> that's a good answer
[15:17] <Keybuk> how would the people who make Ubuntu (us) use brainstorm?
[15:17] <mdz> so that's the next question
[15:17] <mdz> my proposal is that, on a periodic basis, some grouping of the top voted items in brainstorm gets an official response from the project
[15:17] <Keybuk> I guess a better question, which teams become responsible for reading every single thing posted to brainstorm?
[15:17] <mdz> nobody is responsible for reading every single thing
[15:18] <pitti> it just tends to aggregate votes in a rather useless way -- if some people say "my wifi isn't working", others +1 that, but it doesn't tell us much
[15:18] <Keybuk> I'm a bit worried that that kind of approach turns into "Petition the Prime Minister"
[15:18] <mdz> but, say, once a quarter or so, a few people spend a few hours going through the *highest voted* items and responding to those
[15:18] <Keybuk> where the community rally to get something on brainstorm voted highly, and we respond telling them that it's not a problem, etc.
[15:18] <mdz> pitti, it tells us that our users care about wifi, and that they might appreciate us telling them what's going on
[15:18] <cjwatson> there are bound to be some we can't respond to in any particularly useful way; IME in the past that has been the case for some of them but by no means all
[15:19] <cjwatson> indeed I've often got to say "yes, we think this is a good idea, and furthermore we did it three months ago", which is rather satisfying
[15:19] <pitti> so, we could just try that "respond to the top items where appropriate" and see how it goes
[15:19] <mdz> cjwatson, yes, there are probably some which fall into that category, and I don't think we should waste time on them if they're noise
[15:19] <mdz> I think it's OK to respond to say "I can't make sense of this" if it's noise
[15:20] <mdz> Keybuk, I think the quality of our responses will count for a lot
[15:20] <Keybuk> *nods* sounds reasonable
[15:20] <mdz> which is why I think it's OK to limit it to a fairly small number
[15:20] <mdz> but do a good job of responding
[15:20] <Keybuk> if we pick the ones we can write the best responses to, we'll get more top suggestions of that kind
[15:20] <cjwatson> right, there really is no point to the site if nobody looks at it in a semi-organised way, and I think the site is a useful lightning rod, so ... yes
[15:20] <Keybuk> (people will get the idea of what kind of thing gets responses)
[15:21] <mdz> taking the wifi example, I think it would be great to have a blog post from somebody very knowledgeable in that area explaining the current state of wifi, why it is the way it is, how we'd like it to be, how it has changed recently, what we're working on to make it better, etc.
[15:22] <mdz> and would hope to strike a balance between the amount of time we invest in it, and the perceived benefit to the user community
[15:23] <mdz> I think a couple of hours per response, spread out across the team to the people best equipped to respond, every 3 months, shouldn't be too much of a burden
[15:23] <mdz> and could be much appreciated
[15:23] <pitti> so this could become a routine part of the "prepare UDS" or "prepare specs" part of the cycle, to be done by the team/tech leads
[15:23] <Keybuk> I think there's a consensus here that that would be a good thing; do you want to take an action to make it a formal proposal?
[15:23] <sabdfl> glitch
[15:23] <pitti> with "done" -> review and fan out to the experts
[15:23] <mdz> sounds like consensus, great
[15:23] <mdz> so at this point in my own thinking, the question became: whose responsibility should this be?
[15:24] <mdz> and I thought it appropriate to start with the TB
[15:24] <mdz> I think this should definitely be an Ubuntu voice rather than a Canonical voice
[15:24] <Keybuk> I was going to suggest the Community team
[15:24] <cjwatson> I think it should be a technical task as well
[15:25] <cjwatson> perhaps the TB with guidance from the community team on particularly urgent items
[15:25] <mdz> I'm not too fussed; I think there are plenty of people and teams who could do a good job at coordinating the process
[15:25] <cjwatson> and we can fan things out to individuals as needed
[15:25] <Keybuk> I would be worried that the overly technically minded of us would not be good at identifying the hot topics of our users
[15:25] <cjwatson> that's why they're voted on by users :-)
[15:25] <mdz> the important thing to me is to get consensus that this is useful and worth investing in
[15:25] <pitti> that's why I suggested doing it around UDS -- that's when managers and TLs are in the mood for design and writing tech stuff anyway
[15:26] <mdz> pitti, so do you suggest a 6 month cadence rather than 3 months?
[15:26] <mdz> I thought that might be a bit long
[15:26] <pitti> mdz: 3 months works for me as well
[15:26] <pitti> mdz: just trying to fit it into existing rhythms
[15:26] <dholbach> I think it'd make sense for all teams to have a look at it in their respective areas :)
[15:26] <mdz> pitti, yes, I like that idea as well
[15:26] <pitti> and around feature freeze there's usually not a lot we can/want to do about changing things
[15:26] <sabdfl> does it change that fast?
[15:27] <mdz> dholbach, I don't think that brainstorm can be neatly divided up that way, unfortunately
[15:27] <cjwatson> dholbach: I think a lot of things would fall through the cracks that way
[15:27] <cjwatson> cf. "that's a kernel problem" "no it's not, it's a foundations problem"
[15:27] <cjwatson> ad nauseam
[15:27] <mdz> pitti, I think it's more about what we say than what we do
[15:27] <cjwatson> you need a coordinating group or lots of things will just be ignored
[15:27] <dholbach> sure, I just think we'll get better results if more than just the community team has a look at it :)
[15:27] <cjwatson> I agree that it should not be just the community team
[15:28] <pitti> dholbach: I agree; at best, teh community team could ask some expert to respond to a particular question
[15:28] <mdz> dholbach, I don't think the tech board can delegate work to the Canonical community team anyway ;-)
[15:28] <mdz> to be perfectly honest we tried that and it didn't work all that well
[15:29] <mdz> jono tried to route brainstorm items to people, get responses and publish them, and it was a pain
[15:29] <mdz> I'd like to try to keep it simple
[15:29] <cjwatson> personally, I think that this fits well into the TB's remit of providing technical direction and guidance
[15:29] <mdz> cjwatson, exactly
[15:29] <cjwatson> even if we don't personally write all the responses
[15:29] <mdz> I think in practice, members of the TB are great candidates for writing responses
[15:29] <mdz> and where we aren't, we know who to go to
[15:30] <mdz> so I wondered if this should be a TB responsibility
[15:30] <Keybuk> it seems there's also a consensus that the TB can be responsible for this
[15:31] <pitti> *nod*
[15:31] <mdz> great
[15:31] <Keybuk> [ACTION] mdz to draft plan/process for brainstorm
[15:31] <MootBot> ACTION received:  mdz to draft plan/process for brainstorm
[15:31] <mdz> thanks for the feedback
[15:32] <mdz> why yes, I would be happy to take an action to draft a proposal
[15:32] <mdz> no problem Keybuk ;-)
[15:32] <Keybuk> :-)
[15:32] <mdz> next topic?
[15:32] <Keybuk> [TOPIC] Check accuracy of voting procedure on TechnicalBoard wiki page
[15:32] <MootBot> New Topic:  Check accuracy of voting procedure on TechnicalBoard wiki page
[15:32] <Keybuk> mdz: stop back-seat chairing
[15:32] <cjwatson> ok, that was mine
[15:33] <Keybuk> cjwatson: you're up
[15:33] <cjwatson> this came from a brief conversation I had with Raphaël Hertzog where he was trying to establish how the TB was appointed/elected
[15:33] <mdz> interesting, where did this come from?
[15:34] <mdz> I'm looking at the part where it describes how the board operates
[15:34] <cjwatson> mdz: it turned into that LWN article he wrote, I think, although most of this is not really relevant to that
[15:34] <Keybuk> it sounds like it came from the LWN response of Jef Spaleta to Raphael's article?
[15:34] <cjwatson> pitti told him that Mark appointed candidates and that the vote was only a "confirmation vote", which is roughly what it says on the wiki
[15:34] <cjwatson> Keybuk: it was before the article was published, so no
[15:34] <dholbach> https://wiki.ubuntu.com/CommunityCouncil/Restaffing has some bits about it too
[15:34] <cjwatson> let me finish?
[15:35] <cjwatson> before realising that pitti's comments came from the wiki, I said 'the last one was a vote among several possible candidates, though, so I'm not sure "confirmation vote" is a good way to think about it'
[15:35] <cjwatson> so now I wonder whether we ought to clarify the wiki a little bit
[15:35] <cjwatson> https://wiki.ubuntu.com/TechnicalBoard, specifically
[15:35] <cjwatson> "Appointments to the board are made by Mark Shuttleworth subject to confirmation by a vote amongst Ubuntu developers."
[15:35] <Keybuk> has that formally changed?
[15:36] <cjwatson> to me a confirmation vote is an up/down vote for a single person, which is not what the last one was
[15:36] <mdz> there's also http://www.ubuntu.com/project/about-ubuntu/governance
[15:36] <mdz> that page says that sabdfl nominates candidates
[15:36] <mdz> and the candidates are then voted upon
[15:36] <cjwatson> the text on http://www.ubuntu.com/project/about-ubuntu/governance is much better
[15:37] <cjwatson> "In each case, a poll of relevant members of the project is conducted to select, or veto, the final membership of the Community Council and Technical Board."
[15:37] <mdz> I think it's also...well, accurate
[15:37] <cjwatson> that doesn't tie us down to a particular voting strategy
[15:37] <sabdfl> i think i commented on the LWN article, too
[15:38] <cjwatson> I didn't really want to drag the whole LWN article into it; it got into rather a lot more detail and from my POV my conversation with buxy was essentially independent of it
[15:38] <sabdfl> showing how the same approach applies to broader governance structures - it's top down delegation, with bottom up tests of confidence
[15:38] <mdz> I haven't read the LWN article
[15:38] <mdz> I'm about 3 issues behind
[15:38] <cjwatson> I really just wanted to check whether we could revise the text on TechnicalBoard to avoid (appearing to) conflict with current electoral practice
[15:39] <mdz> I think revising the wiki page to match the (authoritative) text on the website is fine
[15:39] <cjwatson> ok, I'll take an action to do that then
[15:39] <mdz> I think there are other things on that wiki page which are misleading or wrong as well
[15:39] <cjwatson> if there are no objections
[15:39] <Keybuk> none from me
[15:39] <mdz> it also has far too many Capitalized Phrases
[15:39] <mdz> we're just not that formal around here
[15:39] <Keybuk> [ACTION] cjwatson to review and defraft TB wiki pages to match current governance practice
[15:39] <MootBot> ACTION received:  cjwatson to review and defraft TB wiki pages to match current governance practice
[15:40] <mdz> cjwatson, would you mind fixing up the rest of the page a bit while you're in there?
[15:40]  * cjwatson nods at Matt Zimmerman, Board Member
[15:40]  * mdz chuckles
[15:40] <Keybuk> [TOPIC] Fate of ia64/sparc in Maverick
[15:40] <MootBot> New Topic:  Fate of ia64/sparc in Maverick
[15:40] <cjwatson> or perhaps I should salute, given that tone
[15:40] <cjwatson> right :)
[15:40] <mdz> this is done, I read about it in LWN
[15:40] <Keybuk> we've announced and agreed to drop these ports, but I've been unable to find any documentation or buttons for actually doing it
[15:40] <cjwatson> mdz: I thought you were behind
[15:40] <mdz> cjwatson, just now
[15:40] <Keybuk> cjwatson: do you remember when we dropped lpia what we did?
[15:41] <mdz> it's still on the front page
[15:41] <cjwatson> we made lamont do it
[15:41] <Keybuk> haha, right
[15:41] <Keybuk> so this is "invoke IS/duckie" ?
[15:41] <cjwatson> I suggest getting him to write it up this time :)
[15:41] <cjwatson> it involved some rather terrifying Launchpad operations
[15:41] <Keybuk> I thought that might be the case
[15:41] <Keybuk> I'll continue to action that
[15:41] <Keybuk> [ACTION] Keybuk to invoke lamont for ia64/sparc drop
[15:41] <MootBot> ACTION received:  Keybuk to invoke lamont for ia64/sparc drop
[15:42] <cjwatson> I turned off CD image building for those architectures already, in anticipation
[15:42] <Keybuk> [TOPIC] Mailing list archive
[15:42] <MootBot> New Topic:  Mailing list archive
[15:42] <Keybuk> is there anything on there that needs an action?
[15:42] <mdz> it's still awfully spammy
[15:42] <mdz> didn't somebody take an action to ask IS for help with that?
[15:43] <mdz> there's https://lists.ubuntu.com/archives/technical-board/2010-August/000426.html
[15:43] <Keybuk> mdz: if someone solves that particular problem, they would stop working for us due to being a billionaire
[15:43] <mdz> (bdmurray's drivers proposal)
[15:43] <cjwatson> we need to agree on the chromium-browser stuff, but I doubt we can do that in 17 minutes
[15:43] <mdz> i.e.https://lists.ubuntu.com/archives/technical-board/2010-August/000459.html
[15:44] <mdz> I haven't read the rest of the thread yet
[15:44] <mdz> cjwatson, we could make a start on it
[15:44] <cjwatson> I don't quite understand what's going on with the spam; the list is moderated and I'm certainly not approving all that stuff
[15:45] <cjwatson> oh, hm, generic_nonmember_action is set to Accept
[15:45] <sabdfl> Keybuk: why would that stop someone working for us?
[15:45] <cjwatson> I've changed that to Hold, will just mean a bit more manual moderation
[15:45] <mdz> given chromium is a) in universe, and b) fairly immature upstream (on Linux), I'm inclined to be flexible
[15:45] <cjwatson> maybe that will help
[15:45] <mdz> until one or both of those things change
[15:45] <pitti> cjwatson: ah, thanks
[15:46] <pitti> cjwatson: but there's usually tons of spam in the moderation queue as well; I wonder why only some is caught
[15:46] <mdz> once my pinned tabs become visible again, for example
[15:46] <pitti> mdz: I thought the request was to move it to main
[15:46] <cjwatson> do not meddle in the affairs of mailman, for you are tasty and good with custard
[15:46] <cjwatson> ... I don't know
[15:46] <pitti> (which I'm not at all happy about, FWIW -- chromium is a steaming pile of bugs still :-/
[15:46] <mdz> pitti, oh, I see
[15:46] <mdz> I think that's a bigger question than how to do security updates
[15:46] <mdz> I'm not sure chromium is ready
[15:47] <mdz> has the archive team taken a view?
[15:47] <pitti> the main problem is that it's (non-)release strategy is fundamantally incompatible with distros
[15:48] <mdz> pitti, well, it's incompatible with distros who don't have the same rolling release model
[15:48] <pitti> mdz: which is "all but Debian testing?"
[15:48] <pitti> well, and gentoo
[15:48] <mdz> there are several
[15:48] <cjwatson> or Arch
[15:49] <mdz> or Chrome OS
[15:49] <Keybuk> Fedora
[15:49] <pitti> they do 6-monthly releases?
[15:49] <Keybuk> they update after release
[15:49] <Keybuk> a release is not a static blessed thing
[15:49] <pitti> but even 6 months is too long for chromium
[15:51] <mdz> the problem at hand seems to be that it takes too long for security updates to reach chromium users
[15:51] <mdz> when they use the Ubuntu packaged version anyway
[15:52] <mdz> our usual solution to that is backporting them
[15:52] <mdz> has that been evaluated with chromium?
[15:53] <pitti> mdz: not sure, but given that the code changes a magnitude faster than firefox, I think it's even less practical to do there
[15:54] <mdz> it seems worth doing an analysis of actual security fixes and backporting feasibility
[15:54] <mdz> what other options do we have other than backporting and ship-bleeding-edge-everywhere?
[15:55] <pitti> ship an installer package, like flash
[15:55] <pitti> and then use the builtin update
[15:55]  * mdz gets the feeling that some fellow Board Members are reading their email ;-)
[15:55] <sabdfl> do they flag the security fixes particularly? seems that if their view is "everything rolls" they'd be less inclined to do that
[15:55] <pitti> sabdfl: there are CVEs for that
[15:56] <mdz> they treat security bugs differently, use CVEs, etc.
[15:56]  * kees gets onto after-security-check airport wifi for the last 5 minutes, whee.
[15:56] <kees> they roll bug fixes in with security updates, though.
[15:56] <pitti> or, rather, they seem to mark their bugs accordingly
[15:56] <pitti> https://edge.launchpad.net/ubuntu/+source/chromium-browser/5.0.375.127~r55887-0ubuntu1
[15:57] <mdz> http://www.chromium.org/Home/chromium-security
[15:57] <MootBot> LINK received:  http://www.chromium.org/Home/chromium-security
[15:57] <mdz> explains their policies and procedures
[15:58] <mdz> Keybuk, time?
[15:58] <Keybuk> I think so
[15:58] <Keybuk> who should take the action to further review chromium?
[15:58] <Keybuk> pitti: ?
[15:59] <pitti> Keybuk: I think I gave plenty of feedback in the thread already
[15:59] <pitti> I can do some investigations about backporting fixes
[15:59] <mdz> delegate to the security team?
[15:59] <Keybuk> sure, who gives them the bad news? :p
[16:00] <kees> what is the "question" about it?
[16:00] <mdz> kees, https://lists.ubuntu.com/archives/technical-board/2010-August/000459.html
[16:00] <pitti> kees: whether it's feasible to backport chromium security patches to older releases
[16:00] <mdz> pitti, I meant delegate the whole issue
[16:00] <kees> we do it already for firefox; it's up to the desktop team.
[16:00] <pitti> I just think that even if we do that, people wouldn't be satisfied, though
[16:00] <mdz> I'm not sure why the TB should be the ones to decide on such a specialist issue
[16:00] <kees> there is no choice about doing it; there is no sensible way to do per-fix backporting of patches
[16:01] <pitti> chromium is way too buggy still to ship older releases in something like an LTS
[16:01] <chrisccoulson> it won't be feasible to backport security fixes to a stable release
[16:01] <kees> sorry "do it" meaning "take full version updates"
[16:01] <pitti> ah, there are the experts :)
[16:01] <chrisccoulson> that would be a crazy amount of work
[16:01] <jdstrand> we don't backport firefox, we do microversion updates
[16:01] <mdz> I'm joining a conf call now, goodbye
[16:01] <jdstrand> kees: ah, yes, right :)
[16:01] <cjwatson> I have to go as well
[16:01] <pitti> continue on the list then?
[16:01] <kees> okay
[16:02]  * chrisccoulson goes to read scrollback
[16:02] <pitti> I'll ask Chris/Kees to reply there
[16:02] <Keybuk> great
[16:02] <Keybuk> [ACTION] pitti to follow up with kees on-list
[16:02] <MootBot> ACTION received:  pitti to follow up with kees on-list
[16:02] <Keybuk> [TOPIC] Community bugs
[16:02] <MootBot> New Topic:  Community bugs
[16:02] <Keybuk> the only open bug is the drivers one of mdz
[16:02] <Keybuk> bdmurray has a recent follow up, we should make sure that ends up on the bug
[16:03] <Keybuk> bdmurray: could you forward it to bug #174375 ?
[16:03] <Keybuk> [ACTION] Chair for next meeting
[16:03] <MootBot> ACTION received:  Chair for next meeting
[16:03] <Keybuk> I believe it's mdz next alphabetically ;-)
[16:03] <mdz> ok
[16:04] <Keybuk> [AGREED] mdz to chair
[16:04] <MootBot> AGREED received:  mdz to chair
[16:04] <Keybuk> #endmeeting
[16:04] <MootBot> Meeting finished at 10:04.
[16:04] <Keybuk> thanks all
[16:04] <pitti> thanks everyone
[16:15] <ogra> wow, you finished at lucid time :)
[16:17] <JFo> boo hiss ;)
[16:22] <czajkowski> ogra: thats bad
[16:22] <ogra> why ?
[17:58] <JFo> o/
[17:58] <lag> o/
[17:59] <mpoirier> o?
[17:59] <kamal> o/
[17:59] <lag> mpoirier: Something wrong with your arm?
[17:59] <smb> \o
[17:59] <JFo> heh
[17:59] <kamal> something wrong with his ARM?
[17:59] <mpoirier> french keyboard...
[17:59] <lag> kamal: There's lots wrong with our ARMs
[17:59] <kamal> shhh
[18:00] <manjo> \o
[18:00] <bjf> #startmeeting
[18:00] <MootBot> Meeting started at 12:00. The chair is bjf.
[18:00] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[18:00] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[18:00] <bjf> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[18:00] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/Meeting
[18:00] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick
[18:00] <bjf> #
[18:00] <bjf> # NOTE: '..' indicates that you are finished with your input.
[18:00] <bjf> #
[18:01] <bjf> I want to start by welcoming Sarvatt to the team!
[18:01] <smb> +1
[18:01] <JFo> welcome Sarvatt
[18:01] <Sarvatt> Thanks, nice to meet you all! :)
[18:01] <bjf> [TOPIC] ARM Status (lag)
[18:01] <MootBot> New Topic:  ARM Status (lag)
[18:01] <lag>  * Marvel (mvl-dove)
[18:01] <lag>    * FIXED    : ABI bumping and module checking errors after the branch sync'ed with LSP 5.3.2
[18:01] <lag>    * MISC     : Discussion of moving forward mvl-dove branch into Maverick
[18:01] <lag>  * Freescale (fsl-imx51)
[18:01] <lag>    * Nothing new this week
[18:01] <lag>  * Texas Instruments (ti-omap)
[18:01] <lag>    * MISC     : lag's Panda is broken - awaiting replacement from davidm
[18:01] <lag>    * MISC     : Still waiting for TI to release L24.9 to us
[18:01] <lag>    * FIXED    : B591941 work around applied - working on correct fix
[18:01] <lag>    * FIXED    : B608266 GPMC was not initialized before accessing NAND
[18:01] <lag>    * FIXED    : B608279 now able to read the EDID from userspace
[18:02] <lag>    * RESUMED  : B563650 problem can be reproduced on latest 2.6.35-18 with non-UNR file system
[18:02] <lag>    * ON GOING : B605488 still unable to reproduce - will test on full-build when new HW arrives
[18:02] <lag>    * ON GOING : B517841 KEXEC support broken - need to backport some upstream patches to Maverick
[18:02] <lag>    * ON GOING : B588243 Oops from TI's DSS driver - waiting for upstream merge the fixing patch
[18:02] <lag> ..
[18:02] <bjf> [TOPIC] Release Metrics: (JFo)
[18:02] <MootBot> New Topic:  Release Metrics: (JFo)
[18:02] <JFo> Release Meeting Bugs (4 bugs, 9 Blueprints)
[18:02] <JFo> [18:02] <JFo>  * 2 linux kernel bugs (down 2)
[18:02] <JFo>  * 0 linux-fsl-imx51 bugs (no change)
[18:02] <JFo>  * 0 linux-ec2 bugs (no change)
[18:02] <JFo>  * 0 linux-mvl-dove bugs (no change)
[18:02] <JFo>  * 0 linux-ti-omap bugs (no change)
[18:02] <JFo>  * 0 linux-meta-ti-omap bug (no change)
[18:02] <JFo> [18:02] <JFo>  * 17 linux kernel bugs (down 6)
[18:02] <JFo>  * 1 linux-fsl-imx51 bugs (up 1)
[18:02] <JFo>  * 0 linux-ec2 bugs (no change)
[18:02] <JFo>  * 2 linux-mvl-dove bugs (no change)
[18:02] <JFo>  * 1 linux-ti-omap bugs (down 1)
[18:02] <JFo>  * 0 linux-meta-ti-omap bug (no change)
[18:02] <JFo> [18:02] <JFo>  * 14 blueprints
[18:02] <JFo> *** NOTE: This listing includes HWE Blueprints***
[18:03] <JFo> [18:03] <JFo>  * https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on
[18:03] <JFo>  * Breakdown by status:
[18:03] <JFo>    http://qa.ubuntu.com/reports/ogasawara/csv-stats/bugs-with-patches/linux/
[18:03] <JFo> ..
[18:03] <bjf> [TOPIC] Blueprint: kernel-maverick-apparmor (jjohansen)
[18:03] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
[18:03] <MootBot> New Topic:  Blueprint: kernel-maverick-apparmor (jjohansen)
[18:03] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-apparmor
[18:03] <jjohansen> no change from last week
[18:03] <jjohansen> ..
[18:04] <bjf> [TOPIC] Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)
[18:04] <bjf> [LINK] https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
[18:04] <MootBot> New Topic:  Blueprint: kernel-maverick-pv-ops-ec2-kernel (jjohansen)
[18:04] <MootBot> LINK received:  https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-pv-ops-ec2-kernel
[18:04] <jjohansen> Bug #613083 - awaiting a response from amazon
[18:04] <jjohansen> Bug #606373 - in progress
[18:04] <jjohansen> Bug #613022, Bug #613273 - I haven't really looked at yet
[18:05] <jjohansen> Bug #574910  - fixed for Lucid and we have a work around for Maverick
[18:06] <jjohansen> other than that pv-grub and pv-ops are real nice :
[18:06] <jjohansen> ;)
[18:06] <jjohansen> ..
[18:06] <bjf> [TOPIC] Blueprint: kernel-maverick-bug-handling (JFo)
[18:06] <bjf> [LINK] https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling
[18:06] <MootBot> New Topic:  Blueprint: kernel-maverick-bug-handling (JFo)
[18:06] <MootBot> LINK received:  https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-bug-handling
[18:06] <JFo> Nothing to report. Lots in the wings to be finished soon.
[18:06] <JFo> ..
[18:07] <bjf> [TOPIC] Status: Maverick (ogasawara)
[18:07] <MootBot> New Topic:  Status: Maverick (ogasawara)
[18:07] <ogasawara> Our Maverick kernel is now rebased to v2.6.35.3 and uploaded as linux-2.6.35-18.24.  We've also most notably dropped support for ia64 and sparc per the Tech Board decision.
[18:07] <ogasawara> Maverick Beta is Thurs Sept 2nd, ie ~1week away.  Beta Freeze is this Thurs, so I'll be uploading our Beta kernel today.  Also, keep in mind that Kernel Freeze is Thurs Sept 16th, ie ~3weeks away.  Remember after Kernel Freeze, we transition to our SRU policy in order to apply patches to Maverick.
[18:07] <ogasawara> We are above our Beta burn down chart's trend line but below our overall trend line for the cycle.  I'll be following up with individuals who have open work items to see if we can close any out.
[18:07] <ogasawara> [LINK] http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-ubuntu-10.10-beta.html
[18:07] <ogasawara> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone ubuntu-10.10-beta
[18:07] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/maverick/canonical-kernel-team-ubuntu-10.10-beta.html
[18:07] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Maverick#Milestone ubuntu-10.10-beta
[18:07] <ogasawara> ..
[18:08] <bjf> [TOPIC] Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)
[18:08] <MootBot> New Topic:  Security & bugfix kernels - Karmic/Jaunty/Intrepid/Hardy/Others (smb)
[18:08] <smb> ||                   || Upd./Sec.     || Proposed      || TiP || Verified    ||
[18:08] <smb> || Dapper: Kernel    || 2.6.15-55.87  ||               ||     ||             ||
[18:08] <smb> || Hardy:  Kernel    || 2.6.24-28.75  || (postponed)   ||     ||             ||
[18:08] <smb> || Jaunty: Kernel    || 2.6.28-19.64  ||               ||     ||             ||
[18:08] <smb> || Karmic: Kernel    || 2.6.31-22.63  || 2.6.31-22.64  ||   0 ||  0/ 4       ||
[18:08] <smb> || =       mvl-dove  || 2.6.31-214.30 || 2.6.31-214.31 ||   0 ||  0/ 4       ||
[18:08] <smb> || =       fsl-imx51 || 2.6.31-112.28 ||               ||     ||             ||
[18:08] <smb> || =       ec2       || 2.6.31-307.17 || 2.6.31-307.18 ||   0 ||  0/ 4       ||
[18:08] <smb> || Lucid:  Kernel    || 2.6.32-24.41  || 2.6.32-24.42  ||   4 ||  0/ 2       ||
[18:08] <smb> || =       LBM       || 2.6.32-24.17  || (pending)     ||     ||             ||
[18:08] <smb> || =       mvl-dove  || 2.6.32-208.24 || (pending)     ||     ||             ||
[18:08] <smb> || =       fsl-imx51 || 2.6.31-608.19 ||               ||     ||             ||
[18:08] <smb> || =       ti-omap   || 2.6.33-502.10 ||               ||     ||             ||
[18:08] <smb> || =       ec2       || 2.6.32-308.15 ||               ||     ||             ||
[18:08] <smb> New security release was done (currently trying to figure out a Hardy
[18:08] <smb> regression in Xen that was caused by that).
[18:08] <smb> Uploads to proposed have been re-done for Karmic and Lucid. The uploads
[18:08] <smb> for Lucid-LBM and Lucid-mvl-dove still pending acceptance.
[18:08] <smb> One regression fix from Lucid proposed have been moved into the security
[18:08] <smb> update as the severity was high enough.
[18:09] <smb> The security update for Lucid-fsl-imx51 included all proposed patches in
[18:09] <smb> order to prevent any further bricking issues with babbage2.5 boards.
[18:09] <smb> ..
[18:09] <bjf> [TOPIC] Incoming Bugs: Regressions (JFo)
[18:09] <MootBot> New Topic:  Incoming Bugs: Regressions (JFo)
[18:09] <JFo> 324 Maverick Bugs (up 72)
[18:09] <JFo> 915 Lucid Bugs (up 29)
[18:09] <JFo> Current regression stats (broken down by release):
[18:09] <JFo> [18:09] <JFo>   * 158 maverick bugs (up 32)
[18:09] <JFo>   * 159 lucid bugs (up 2: to be converted to regression-release)
[18:09] <JFo> [18:09] <JFo>   * 42 lucid bugs (up 7)
[18:09] <JFo>   * 6 karmic bugs (no change)
[18:09] <JFo>   * 4 jaunty bugs (no change)
[18:09] <JFo>   * 0 hardy bug (down 1)
[18:09] <JFo> [18:09] <JFo>   * 156 lucid bugs (up 1)
[18:09] <JFo>   * 38 karmic bugs (down 1)
[18:09] <JFo>   * 17 jaunty bugs (down 1)
[18:09] <JFo>   * 2 hardy bugs (no change)
[18:09] <JFo> [18:09] <JFo>   * 4 lucid bugs (up 1)
[18:09] <JFo>   * 1 karmic bug (no change)
[18:10] <JFo> ..
[18:10] <bjf> [TOPIC] Incoming Bugs: Bug day report (JFo)
[18:10] <MootBot> New Topic:  Incoming Bugs: Bug day report (JFo)
[18:10] <JFo> Today's focus is on bugs with patches. I'll be reviewing them to ensure that there is a patch actually attached. Per Pete, there will then be a review of the bugs to see if the patch has already been included or if it is sufficient to be included. This process will be getting further defined once I submit my rough plan to Pete for how to complete the review and inclusion of patches in the future. The next bug day will be next Tuesday. We will be f
[18:10] <JFo> ocusing on bugs in the confirmed state and working to move them either into incomplete or triaged states. We will continue to have the Team Bug Day to address the Top 50 list as half days on Friday and Monday, as these seem to be working out very well. Reviewers, please take a look at your needs-review lists and help us keep the process moving. Please also take ownership of your bugs as you work them so we can get them fixed or otherwise off the l
[18:10] <JFo> ist.
[18:10] <JFo> ..
[18:11] <bjf> [TOPIC] Triage Status (JFo)
[18:11] <MootBot> New Topic:  Triage Status (JFo)
[18:11] <JFo> I'm getting pinged by the Ubuntu Studio folks who are concerned about whether the realtime kernels will be available for Maverick. I was in Oxford last week, so I don't have much on this yet. I'd be interested to hear if any of you encountered any triagers or their questions over the last week.
[18:12] <JFo> realtime or preempt kernels that is
[18:12] <JFo> ..
[18:12] <tgardner> JFo, I'm getting bugged by it as well
[18:12] <JFo> tgardner, not surprisin
[18:12] <JFo> g
[18:12] <JFo> scott over there was very worried
[18:13] <JFo> I think his concern was more that his impression was that we didn't care about the -rt kernels
[18:13] <smb> That probably needs some action on getting abogani some upload right for it. He got a bit frustrated by the process and probably by our lack of being able to endorse him,
[18:13] <JFo> yeah, he has been upset about it
[18:13] <JFo> and that has the studio folks in a tizzy :)
[18:14] <tgardner> where is Luke in all of this? he's their core-dev
[18:14] <smb> He should feel proud about that. :) Yeah, the only two people that sponsored him were Luke and Ben
[18:14] <JFo> no idea, but my understanding is that there are only a few folks working on it
[18:14] <JFo> the rest are only in the channel briefly
[18:14] <smb> Well, I did now once, but that is not much
[18:14] <JFo> right
[18:15] <JFo> we can discuss that more offline
[18:15] <JFo> if you guys want
[18:15] <smb> Daniel kicked something off, pgraner may fwd to you as well
[18:15] <smb> ..
[18:15] <JFo> ok
[18:15] <JFo> ..
[18:15] <bjf> we've got 45 minutes left in the meeting so if there is more to discuss we can do it here
[18:16] <JFo> I'm good either way, tgardner?
[18:16] <tgardner> JFo, we're dealing with it offline
[18:16] <JFo> k
[18:16] <JFo> ..
[18:17] <bjf> [TOPIC] Open Discussion or Questions: Anyone have anything?
[18:17] <MootBot> New Topic:  Open Discussion or Questions: Anyone have anything?
[18:17] <bjf> I'll be out next week so if we want to have a meeting someone will have to chair it
[18:17] <bjf> and then deal with all the reporting.
[18:17] <bjf> So the first question is "Do we want to have next week's meeting?"
[18:17] <smb> What is next week?
[18:17] <smb> Oh
[18:18] <smb> nm
[18:18] <tgardner> ogasawara loves to chair meetings.
[18:18] <ogasawara> dammit!
[18:18] <JFo> LOL
[18:18] <ogasawara> I don't mind chairing the meeting
[18:18] <smb> I guess I can chair it too, if we want it and ogasawara doesn't
[18:19] <JFo> bjf, enjoy your vacation either way :)
[18:19] <bjf> JFo: that's a given :-)
[18:19] <ogasawara> we might as well keep it on the schedule in case something needs discussing
[18:19] <ogasawara> we can cancel it last minute if anything
[18:19] <bjf> ogasawara: right, it's your call
[18:19] <bjf> anyone else have anything?
[18:20] <ogasawara> bjf: I've already got the runes to run the meeting, can you send me an email where all the minutes need posting to.
[18:20] <ogasawara> bjf: or it is in the wiki?
[18:20] <bjf> ogasawara: all documented in the wiki :-)
[18:20] <bjf> ogasawara: will send you the link (it's at the top of the agenda page)
[18:20] <ogasawara> bjf: got it, thanks
[18:20] <bjf> that sounds like a wrap
[18:20] <bjf> #endmeeting
[18:20] <MootBot> Meeting finished at 12:20.
[18:21] <sconklin> thanks bjf
[18:21] <kamal> thanks bjf
[18:21] <smb> ta bjf
[18:21] <JFo> thanks bjf
[18:57] <kirkland> o/
[18:59] <ttx> \o
[18:59] <Daviey> õ/
[18:59] <SpamapS> |o
[18:59] <hallyn> o/
[18:59] <mathiaz> :p
[18:59] <SpamapS> \ø
[19:00] <SpamapS> ≥º≤
[19:00]  * mathiaz  wonders if SpamapS just discovered utf-8 support in ubuntu
[19:01] <ttx> waiting for zul, he is the lucky chair
[19:01] <zul> i am crap
[19:01] <zul> #startmeeting
[19:01] <MootBot> Meeting started at 13:01. The chair is zul.
[19:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[19:02] <zul> [TOPIC] Review ACTION points from previous meeting
[19:02] <MootBot> New Topic:  Review ACTION points from previous meeting
[19:02] <zul> so the points were:
[19:02] <zul> SpamapS to submit rubygems change proposal as Important bug in Debian and CC ubuntu-devel
[19:02] <zul> is this done?
[19:03] <zul> SpamapS: ^^^
[19:03] <SpamapS> I had a chat with some of they ruby debian maintainers, specifically Lucas Nussbaum, and he explained that a bit more care is in order when discussing the matter with Daigo, the debian maintainer.
[19:03] <zul> heh so whats next?
[19:03] <SpamapS> So I've reworked the wording a bit, and will be submitting it today or tomorrow.
[19:03] <zul> cool
[19:03] <zul> zul to nudge forward upstart script review process
[19:03] <zul> is done
[19:04] <zul> jjohansen to review bug 493156
[19:04] <zul> jjohansen: ^^^
[19:04] <zul> doesnt seem to be here
[19:04] <jjohansen> right, I haven't gotten to this yet.  The next SRU kernel is a few weeks out so it hasn't been high priority
[19:04] <zul> nifty thanks
[19:05] <jjohansen> nah, just a slow typist
[19:05] <smoser> o/
[19:05] <zul> and finally zul to review papercut status of bug 582963
[19:05] <zul> havent done yet
[19:05] <zul> so
[19:05] <zul> [TOPIC] Maverick development (jib)
[19:05] <MootBot> New Topic:  Maverick development (jib)
[19:05] <ttx> jib is marked "absent" so I guess I'll take care of this one
[19:06]  * SpamapS prepares for the beating
[19:06] <ttx> We should be at ~ 60% completion
[19:07] <ttx> we are a bit behind, but with a nice trends
[19:07] <ttx> especially on my "don't count sundays please" graph version
[19:07] <ttx> Thursday is BetaFreeze
[19:07] <mathiaz> ttx: sunday *and* saturday?
[19:07] <ttx> mathiaz: yes :)
[19:07] <zul> yes i call it family time :)
[19:07] <SpamapS> ttx: are you publishing those graphs in parallel somewhere?
[19:08] <ttx> SpamapS: no. But I could.
[19:08] <ttx> so past Thursday only the RC fixes will be accepted, until Beta release
[19:08] <zul> do we have a list of rc fixes alreayd?
[19:08] <ttx> you should take that into account in organizing your work...
[19:08] <Daviey> ttx: It would be interesting to see those graphs, can you publish them under ~ttx/?
[19:09] <ttx> zul: yes, bug targeted to a maverick milestone
[19:09] <ttx> that means, for example, that papercuts must be taken care of before Thursday :)
[19:09] <ttx> (or dropped forever)
[19:10] <Daviey> *forever* sounds so final, how about deferred to N? :)
[19:10] <ttx> As usual, if yo uthink you are overloaded and can't complete the work items assigned to you in time, please tell me and/or jib
[19:10] <ttx> so that we can adjust/postpone/reassign accordingly
[19:10] <zul> its ok to say narwhal although awkward
[19:10] <ttx> the sooner we know, the better
[19:11] <zul> so i guess moving on
[19:11] <zul> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:11] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:11] <ttx> zul: action me on trying to make the burnup charts available
[19:11] <zul> sorry
[19:11] <mathiaz> ttx: where is the completion percentage coming from?
[19:11] <zul> [ACTION]  action me on trying to make the burnup charts available  ttx
[19:11] <MootBot> ACTION received:   action me on trying to make the burnup charts available  ttx
[19:11] <ttx> mathiaz: the 60% ?
[19:11] <mathiaz> ttx: should we publish it in the WI tracker?
[19:11] <mathiaz> ttx: yes
[19:12] <mathiaz> ttx: I don't see that number anywhere in the WI tracker
[19:12] <mathiaz> ttx: I'd like to know where I am now, and where I'm supposed to be
[19:12] <ttx> a rough eye estimate of the number of days completed / vs. total number of days in milestone
[19:12]  * Daviey finds it less than fun trying to find out where the %'s are based.  The WI tracker has an emphasis on assigned blueprints, not WI on non-assigned blueprints
[19:12] <SpamapS> mathiaz: its not obvious, but its from the trend line.
[19:12] <Daviey> making it somewhat of a PITA to locate.
[19:12] <mathiaz> SpamapS: ^^ could we make this available in the WI tracker?
[19:13]  * Daviey fears he has some hidden %'s in blueprints he hasn't checked recently.
[19:13] <mathiaz> SpamapS: well - the % is actually shown in the burndown chart
[19:13] <SpamapS> mathiaz: pretty simple to add a Y axis on the right w/ %, and draw horizontal lines every 7 days bisecting the trend line.
[19:13] <mathiaz> SpamapS: anyway - food for though
[19:13] <SpamapS> s/bisecting/intersecting
[19:14] <mathiaz> may be I should look again at how to read a burndown chart
[19:14] <zul> ok so
[19:14] <ttx> for the record, the burnup chart looks like http://people.canonical.com/~ttx/after.svg
[19:14] <ttx> the branch implementing it is proposed for merging in lp-work-item-tracker
[19:14] <zul> [TOPIC] Weekly Updates & Questions for the QA Team (hggdh)
[19:14] <MootBot> New Topic:  Weekly Updates & Questions for the QA Team (hggdh)
[19:15] <hggdh> hi
[19:15] <hggdh> nothing new, except still testing euca
[19:15] <mathiaz> hggdh: how was the QA sprint?
[19:15] <hggdh> mathiaz: I did not go, did not have time
[19:16] <Daviey> :(
[19:16] <zul> any interesting bugs?
[19:16]  * Daviey cheers hggdh for his QA'ing of euca.
[19:16] <hggdh> at QA we are going thru the regression-potential bugs now; as I find server bugs, I will ping you all
[19:16] <hggdh> we hope to get to the regression-release bugs soon...
[19:16] <zul> any other questions?
[19:17]  * kirkland highfives hggdh 
[19:17] <kirkland> (as usual)
[19:17]  * hggdh gets a bit more happy
[19:17]  * zul hugs hggdh 
[19:17]  * mathiaz hightens hggdh 
[19:18]  * jdstrand heightens hggdh 
[19:18] <jdstrand> wait, what?
[19:18] <hggdh> :-)
[19:18] <zul> ok so moving on
[19:18] <zul> [TOPIC] Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:18] <MootBot> New Topic:  Weekly Updates & Questions for the Kernel Team (jjohansen)
[19:18] <kirkland> jdstrand: can you heighten me?
[19:18] <jjohansen> first up
[19:18] <jjohansen> Bug #620994 - security fix breaks Xen kernels
[19:19] <jdstrand> kirkland: hehe
[19:19] <zul> jjohansen: oh thats fun
[19:21] <zul> jjohansen: did you see how opensuse fixes it?
[19:21] <jdstrand> iirc, they didn't apply the security update because they had some other patch in place
[19:22] <jjohansen> zul: as far as I know they don't yet.  Its actively being discussed upstream
[19:22] <zul> jjohansen: nifty
[19:22] <jjohansen> jdstrand: is right that they have a different patch in place so the security vul didn't hit their kernels
[19:23] <zul> bah...xen is fun
[19:23] <jjohansen> however, they don't have a fix for this bug and the patch applied upstream
[19:23] <jjohansen> yeah, and the details are ugly
[19:23] <zul> xen is also the cause of male pattern baldness
[19:23] <jjohansen> Bug #574910  - fixed for Lucid, also affects Maverick we have a work around that can be applied but don't have a patch yet
[19:23] <jjohansen> the SRU should hit proposed kernels in about 3 weeks
[19:24] <zul> anything else?
[19:24] <jjohansen> Bug #606373 - I am looking at currently and hope to have fixed soon :)
[19:24] <SpamapS> jjohansen: fixed in lucid! huzzah!
[19:25] <jjohansen> SpamapS: yes, but the fix won't land in proposed for a few weeks
[19:25] <zul> i guess new kernels in ec2 mean new images?
[19:26] <SpamapS> jjohansen: having an SRU to point at means no longer explaining to people why lucid on EC2 "lags" or "is slow" or "is t3h suck" ;)
[19:26] <smoser> it shoudl, yes, but only if they boot
[19:26] <smoser> i was planning on a new image later this week, we're currently one kernel behind as it is.
[19:26] <Daviey> rockin'
[19:27] <jjohansen> ..
[19:27] <zul> so i guess no has anything else moving on to the next topic
[19:28] <zul> [TOPIC] Weekly Updates & Questions for the Documentation Team (sommer)
[19:28] <MootBot> New Topic:  Weekly Updates & Questions for the Documentation Team (sommer)
[19:28] <Daviey> He have his apologies :(
[19:28] <zul> which will be skipped since sommer cant make it
[19:28] <zul> [TOPIC] Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[19:28] <MootBot> New Topic:  Weekly Updates & Questions for the Ubuntu Community Team (kim0)
[19:28] <Daviey> He gave his apologies :)
[19:28] <Daviey> but...
[19:28] <Daviey> he sent me an email with his update:
[19:28] <Daviey> I've been focusing on consolidating "cloud" communication channels
[19:28] <Daviey> Currently the official Ubuntu IRC channel for anything cloud related is #ubuntu-cloud
[19:28] <Daviey> As for the forums, we now have a forum for "cloud" at http://ubuntuforums.org/forumdisplay.php?f=392
[19:28] <Daviey> The forums council were worried whether a cloud forum would attract enough members to justify it's own forums, but since its an egg and chicken problem, they agreed to allow us the forum till 11.04 and then evaluate how strong it's been going
[19:28] <Daviey> Finally, I'm building a web portal that aims to be a resource and news aggregator for new community members
[19:28] <Daviey> If you have ideas as to what should be present on that portal that helps members engage in a developer path, please drop me a line over IRC or email
[19:28] <Daviey> That should be all for me
[19:29] <zul> cool....
[19:29] <zul> so next
[19:29] <zul> [TOPIC] Papercuts status (ttx)
[19:29] <MootBot> New Topic:  Papercuts status (ttx)
[19:29] <ttx> yo
[19:29] <ttx> Status at https://launchpad.net/server-papercuts/+milestone/maverick-beta
[19:29] <ttx> We have until Thursday to fix tha last 6
[19:30] <ttx> If you can't make it, unassign yourself to give someone else a chance :)
[19:30] <ttx> zul: done :)
[19:30] <SpamapS> bug 375371 is awaiting sponsorship
[19:30] <zul> SpamapS: has it been tested yet?
[19:31] <SpamapS> zul: Right, it failed on some tests, but the previous revision failed the same tests, so I think I'm failing on how to run the tests.
[19:31] <zul> SpamapS: ok ill have a look at it this afternoon
[19:31] <zul> anyone else?
[19:31] <SpamapS> causing me to think there should be another bug opened against mysql-testsuite that asks for documentation explaining how one is supposed to run them.
[19:32] <zul> heh ask sbeattie
[19:32] <zul> anyways
[19:32] <zul> [TOPIC] Open Discussion
[19:32] <MootBot> New Topic:  Open Discussion
[19:32] <Daviey> Can we go home now? :)
[19:32] <SpamapS> That was like, way too fast.
[19:32] <SpamapS> we need more hyperbole
[19:32] <zul> Daviey: thats what I was thinking...oh wait..
[19:33] <ttx> SpamapS: twss ?
[19:34] <zul> so if there is no discussion
[19:34] <zul> Tuesday 2010-08-31 at 1800 UTC - #ubuntu-meeting
[19:34] <zul> is when the next meeting is
[19:34] <zul> thanks everyone
[19:35] <mathiaz> zul: thanks!
[19:35] <Daviey> o/
[19:35] <zul> #endmeeting
[19:35] <MootBot> Meeting finished at 13:35.
[19:35]  * Daviey cheers zul for running the quickest meeting in living memory.
[19:38] <sbeattie> SpamapS: mysql-testsuite was failing on lucid or maverick?
[19:39] <sbeattie> SpamapS: feel free to redirect to #ubuntu-server if you'd like.