[13:01] <lool> w00t
[13:01]  * stgraber waves
[13:01] <lool> barry, stgraber, ogra_, slangasek: hey
[13:01]  * barry blinks
[13:02]  * ogra_ shades his eyes to not get blinded by the bright blinking barry 
[13:02] <lool> we need some background music too to go with the blinking
[13:03] <barry> blinded by science
[13:03] <lool> alright, lets keep this short  :-)
[13:03] <lool> Colin gave me a quick update
[13:04] <lool> he's helping with setting up the signing infrastructure for system-updates.u.c and will likely go physically to London to finish the setup
[13:05] <lool> download service >> barry, Daniel started a thread on this but I've just noticed that you're on it (sorry!); will forward it to you
[13:05] <lool> stgraber: so we have system-updates.u.c now live?  :-)
[13:05] <barry> lool: +1
[13:05] <lool> stgraber: tell us all about it
[13:05] <stgraber> we indeed have the system-image.ubuntu.com server and I've published a bunch of images for testing
[13:06] <lool> \o/
[13:06] <stgraber> those shouldn't be used though as they're signed by fake gpg keys at this point
[13:06] <stgraber> I'm currently in the process of automating the import of the daily rootfs builds (currently manually done) and will have to do the same with the Android builds but that should be easy
[13:07] <stgraber> the images themselves aren't terribly useful at this point though as they need a few changes applied to them to become usable (those changes are related to the container flip and loop-mount which hasn't landed yet in the archive)
[13:08] <lool> stgraber: cool; so essentially we have the real infrastrucure minus signing (in progress by Colin) and you're tuning the maintenance scripts we'll use and hooks to cdimage, then we can mass-generate all the images
[13:08] <stgraber> (well, container flip has, just not the loop-mount+read-only side of things)
[13:08] <stgraber> lool: yep
[13:08] <ogra_> planned to be implemented by end of this week
[13:08] <lool> so I guess this hooks us into ogra or ondra; maybe let's start wit the flipped images
[13:08] <ogra_> we will switch to flipped by default today or tomorrow
[13:08] <ogra_> and then start working on loop stuff
[13:08] <lool> ogra_: so they work on all devices now including n10?  awesome
[13:09] <ogra_> well, n10 still had crashers of the shell yesterday
[13:09] <stgraber> ogra_: cool. I'll paste you the latest version of my patching script, it's working great on at least mako and grouper, so we'll need to look at landing those changes in the archive
[13:09] <ogra_> i know rsalveti looked into that but dont know the outcome
[13:09] <lool> loop stuff > I thought Steve L wanted us to look into repartitioning
[13:09] <ogra_> 3G on mako works now (n4 that is)
[13:09] <lool> is the loop-mounting just for community supported devices? (non-nexus)
[13:09] <ogra_> stgraber, yeah
[13:10] <stgraber> lool: we'll support both
[13:10] <ogra_> lool, loop mounting is for all at the start
[13:10] <ogra_> and re-partitioning will be added in the first half of next month
[13:10] <lool> hmm ok; seems a bit indirect to me, but eh at least we will know it works
[13:10] <ogra_> as an additional option
[13:10] <lool> ok
[13:10] <stgraber> lool: when possible we'll repartition (galaxy nexus, nexus4 and nexus10) and support loop-mount for the rest (nexus7 and community ports)
[13:10] <ogra_> our images will default to it
[13:11] <ogra_> all community images will default to loop
[13:11] <lool> I'm guessing we'll have to revisit phablet-tools quite a bit for the new system-updates; this is a bit far off right now, but might be a good thing to look after once we have the updates working
[13:11] <ogra_> (with the option for the porter to switch indeed, *if* the device allows repartitioning)
[13:12] <lool> stgraber: is there a technical reason nexus 7 doesn't allow partitioning, or is it just that we don't want to spend too much time on it?
[13:12] <lool> or perhaps we keep it as a loop-mounted platform for our own testing
[13:12] <stgraber> lool: completely screwed up gpt setup
[13:12] <lool> eh ok
[13:12] <lool> oh crap, just lost ondra
[13:13] <ogra_> well, the n7 will be our loop reference install then :)
[13:13] <stgraber> lool: the partition table is at the end of the flash, with both the primary and secondary tables at the same place, invalid version number and some other issues, we figured it'd be easier just not to support it
[13:13] <lool> stgraber: OMG
[13:14] <lool> stgraber: and I guess the bootloader relies on these locations too
[13:14] <lool> outside of status of recovery ROM's support of gpg and xz with ondra, are there other points to cover today?
[13:14] <stgraber> lool: yeah, apparently the bootloader is at the location where the primary table should be, so if you use parted on it and you let it write the missing primary partition, you rick the device
[13:14] <lool> "rick" lol
[13:15] <stgraber> *risk :)
[13:15] <lool> your risk the device becomes a rock
[13:15] <stgraber> gah, not awake yet, sorry :)
[13:15] <lool> ondra: wb
[13:15] <stgraber> meant *brick obviously
[13:16] <lool> ondra: I think last point we had to cover was recovery ROM support for gpg and xz
[13:16] <ondra> lool: sorry my nautilus crashed and took whole ubuntu down
[13:16] <lool> np
[13:16] <lool> ondra: how are things going there/
[13:16] <lool> s#/#?#
[13:16] <ondra> so I did last night test recovery images with gpg in them for N4 and N7. stgraber has those now
[13:17] <lool> great; is this using android build system to build gnupg, or is this by copying glibc + other libs + gnupg from ubuntu binaries?
[13:17] <ondra> I managed to compile xz with android, but tar is one I'm still struggling with, so when I was looking for some tar alternative code and I found out that busybox has already tar and unxz support
[13:17] <ogra_> hmm ?
[13:18] <ondra> no this is build with android
[13:18] <lool> great; so you'll just turn on these configs in busybox?
[13:18] <ogra_> our zip contains a tarball
[13:18] <lool> (tar and xz)
[13:18] <ogra_> since forever
[13:18] <ogra_> so there must currenlt be some kind of tar
[13:18] <ogra_> *vurrently
[13:18] <ogra_> bah
[13:18] <ondra> but using NDK for the moment, and Android.mk on the way, hopefully we will soon have it from code
[13:18] <ondra> for now I sent patch with binary gpg to sergio who will add it to the git repo
[13:19] <lool> urgh
[13:19] <lool> that sounds pretty bad maintenance wise
[13:19]  * ogra_ wonders if lool has ever seen phablet.ubuntu.com :P
[13:19] <ondra> lool: so tar was in busybox always, but recently they also added unxz
[13:19] <ogra_> it is full of binary crap
[13:19] <ondra> lool: so this is already there
[13:19] <lool> I knew the toolchains were binary, didn't know we kept tons of binaries around
[13:20] <ogra_> we do
[13:20] <stgraber> ogra_: yep, that's what ondra noticed, so we'll be using busybox's tar and xz for now (they should be enough feature wise) and hack gpg into it until we can get a clean build of it
[13:20] <lool> or is this the repo were we keep things we've built from the source tree?
[13:20] <ogra_> stgraber, ondra ++
[13:20] <ogra_> lool, the plan is to properly weed it out and base on binaries from the archive
[13:20] <ogra_> its just a long and slow process
[13:21] <lool> stgraber: so you'll be hand-patching the recovery initrd to add the gpg binary and the scripts to verify updates?
[13:21] <ogra_> until then one more binary doesnt do harm
[13:21] <ondra> lool: I added gpg as binary just so stgraber can test, I don't plan it to have it that way, so Android build should be used
[13:21] <ondra> lool: same goes for xz and hopefully also for tar
[13:21] <lool> ogra_: who's workong on this part?
[13:21] <ondra> lool: I think we should eventually remove busybox from recovery
[13:21] <lool> ogra_: I'm aware of an effort to build the android daemons in the archive, didn't know about the effort to replace recovery rom (I thought it was just an idea if we're stuck)
[13:22] <ondra> lool: or we can tweak busybox to build only tar and unxz
[13:22] <ogra_> lool, xnox is doing the first shot on packaging the android bits ... then we'll have a base to work with and split it into smaller chunks
[13:22] <lool> ogra_: ok, so it's both for the android runtime and for the recovery rom then?
[13:22] <lool> I guess that makes sense
[13:22] <ogra_> lool, the plan is to have the whole android repo packaged
[13:22] <ondra> ogra_: so are we replacing android recovery with Ubuntu based one?
[13:22] <ogra_> no
[13:22] <stgraber> lool: for now we just want our recovery images to contain the tools we need for testing, after that I'll work on a shell script using those to apply the updates and when that thing works, will get it included too
[13:23] <ogra_> we use what we have, just from a package that we will then split into smaller pieces over time
[13:23] <ogra_> so you can eventually also apt-get install android-gpg ;)
[13:23] <lool> stgraber: assuming we wont have moved to Ubuntu initrds before you're done, will you be fine submitting your additions to phablet.u.c?  I guess sergiusens would be able to help you land these
[13:24] <ogra_> the builds will still spit out the device specific img files as usual during build
[13:24] <stgraber> lool: that's the plan
[13:24] <ogra_> (ramdisk, system, recovery)
[13:24] <lool> alright; anything else for today anyone?
[13:25] <barry> lool: just a quick one
[13:25] <lool> barry: shoot
[13:25] <barry> ondra: i'm almost at the point where i'm ready to work on reboot.  could you make sure that the interface between the client and upgrader is accurately documented here: https://wiki.ubuntu.com/ImageBasedUpgrades/Upgrader
[13:26] <ondra> barry: I will check it, it should be according to what we in android code
[13:26] <barry> ondra: cool, thanks
[13:26] <ondra> barry: but as far ad I understand stgraber wants to use script to apply files
[13:27] <stgraber> ondra, barry: so since we're not actually calling the android upgrader but our own, the interface doesn't have to (and probably shouldn't) match the existing Android one
[13:27] <ondra> barry: so we probably should talk together what command we will actually store in that command file
[13:27] <stgraber> basically keeping the standard Android interface for rollbacks to Android (where we want to call the Android upgrader)
[13:28] <barry> mostly, i want to make sure we've documented, e.g. "write these files here with that content", "call this thing to do the reboot with these args", etc.  i don't want the code to be the only spec :)
[13:28] <ondra> stgraber: what we can do is that we put in that command file actual commands for for update
[13:28]  * barry nods
[13:28] <ondra> barry: agree, there should be documented way you pass information to recovery about downloaded files
[13:29] <stgraber> ondra: I'd prefer to keep the command file generic so avoid actual commands, what we need to pass it is an ordered list of file
[13:29] <stgraber> ondra: so my first thought would be to use an ubuntu_command file (instead of Android's command file) which contains just that (one line per file sorted in flash order)
[13:29] <ondra> stgraber: actually we can change current recovery so in Ubuntu Touch case, it will execute our shell script, passing command file as parameter
[13:30] <stgraber> barry: as for where to put stuff and how to trigger the reboot, I can help you with that part
[13:30] <ondra> stgraber: agree,command file should not have any commands, just list of files
[13:30] <barry> stgraber: ok
[13:30] <stgraber> ondra: my thought being that if the recovery finds /cache/recovery/command => triggers Android update code, if it finds /cache/recovery/ubuntu_command => triggers Ubuntu update code
[13:31] <barry> stgraber: i like that
[13:31] <ondra> stgraber: yeah, agree
[13:31] <stgraber> that way we don't really have to care about what Android does, we just avoid messing with its files
[13:31] <ondra> stgraber: and I'd pass then that ubuntu_command to your script as parameter
[13:31] <stgraber> ondra: yep
[13:32] <ondra> yep, and we keep full compatibility with android, so users can roll back any time
[13:33] <ondra> stgraber: OK I will look into recovery code and add it there, if we find ubuntu command file, we will go for it
[13:33] <stgraber> so I think that's a good plan for now, we may have some more changes on that after that meeting on the recovery environment which I believe slangasek's planning to have this week
[13:33] <lool> so next week: ogra switching to flipped images, shaking bugs; xnox continuing work on android bits in archive with new cross toolchain; stgraber working on scripts to apply updates in recovery ROM; ondra to enable xz in our recovery ROMs; barry joining download service discussion; ondra + barry syncing on reboot interface
[13:34] <barry> +1
[13:34] <lool> alright; slightly over time, but I think we're done; thanks guys!  it's great to see this coming together, update site going live, switching to flipped images etc.  :-)
[13:34] <lool> have a great EOD
[13:34] <stgraber> barry: I'll update the upgrader page on the wiki once I'm actually properly awake and done catching up on e-mail. I expect it to mostly say to dump the files in /android/cache/recovery, write the list of files in /android/cache/recovery/command and then call "reboot -f recovery" to apply
[13:35] <ogra_> ciao ciao
[13:35] <barry> stgraber: sounds easy :)
[13:36] <ondra> stgraber: I will read again android code, to see if they had usecase for something else than list of files in command file and let you know
[13:36] <ondra> see you guys
[15:57] <jamespage> o/
[15:59] <arosales> Hello
[16:00] <smoser> o/
[16:00] <arosales> Looks like it is top of the hour so I will kick this off (looks like I am on point to chair)
[16:00] <arosales> #startmeeting ubuntu-server-team
[16:00] <meetingology> Meeting started Tue Jun 25 16:00:39 2013 UTC.  The chair is arosales. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:00] <Daviey> o/
[16:00] <arosales> #topic Review ACTION points from previous meeting
[16:01] <arosales> looks like not actions from past meeting
[16:01] <arosales> #topic Saucy Development
[16:01] <arosales> #link https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule
[16:01] <arosales> A1 June 27th
[16:01] <arosales> smoser, jamespage is server opting in?
[16:02] <jamespage> nope
[16:02] <arosales> ok
[16:02] <arosales> #subtopic Release Bugs
[16:02] <arosales> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html#server
[16:02] <smoser> no opt in.
[16:02] <arosales> jamespage, would you or smoser like to guide us through this section?
[16:02] <adam_g_> o/
[16:02] <jamespage> sure
[16:02] <arosales> jamespage, thanks.
[16:02] <jamespage> smoser: bug 1180867	
[16:03] <smoser> hm..
[16:03] <jamespage> dosaboy, bug 962046
[16:03] <smoser> that is uploaded to raring
[16:04] <smoser> in the sru review queue
[16:04] <smoser> (the cloud-init bug)
[16:04] <jamespage> bug 1031680 and bug 1162139 need some love if anyone has time
[16:04] <jamespage> smoser, ack
[16:04] <jamespage> bug 1180084 needs to be applied into raring
[16:05] <jamespage> anyone know if we can do seed changes post release?
[16:05] <roaksoax> jamespage: we did it for MAAS
[16:05] <roaksoax> a few packages were promoted to main
[16:05] <jamespage> roaksoax, OK
[16:06] <jamespage> I don't think any other release bugs warrant discussion - alot are SRU's in Fix Committed state
[16:06] <jamespage> so anyone with spare time - verification would be great!
[16:06] <jamespage> arosales, back to you
[16:07] <arosales> jamespage thank you sir
[16:09] <arosales> sorry for the delay
[16:09] <arosales> #subtopic Blueprints
[16:10] <arosales> #link http://status.ubuntu.com/ubuntu-saucy/group/topic-saucy-servercloud-overview.html
[16:10] <arosales> how are BPs looking . . .
[16:10] <arosales> #link http://status.ubuntu.com/ubuntu-s/group/topic-s-servercloud-overview.html
[16:10] <arosales> this one works a little better
[16:10]  * arosales will udpate the IRC commands
[16:11] <jamespage> trend line needs a reset
[16:11] <jamespage> arosales, did you get to the bottom of my missing BP's?
[16:11] <arosales> https://wiki.ubuntu.com/ServerTeam/Meeting/IRCCommands is updated
[16:11] <arosales> did yours ever show up?
[16:11] <arosales> I added a raw work item
[16:11] <arosales> jamespage what was the BP name again?
[16:11] <Daviey> jamespage: Can you let me know what might need component changing ?
[16:12] <jamespage> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-ceph
[16:13] <jamespage> and https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-mongodb
[16:13] <adam_g_> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-openstack-charms
[16:13] <adam_g_> this ones missing, too
[16:13] <arosales> hmm
[16:14] <arosales> jamespage, adam_g_ we may need to open a bug against the tracker for that
[16:14] <Daviey> I wonder if it is status...
[16:14] <arosales> since it is linked to the topic BP
[16:14]  * Daviey set a Priority, which was null
[16:14] <jamespage> "     Proposed for saucy"
[16:14] <jamespage> maybe that needs to be accepted
[16:15] <arosales> the mongodb one looks good . . .
[16:15] <Daviey> Accepted :)
[16:15] <jamespage> nope - thats not it
[16:15] <Daviey> lets see if it appears
[16:15] <Daviey> I'll take the action of following that through
[16:16] <arosales> #action Daviey follow up on missing BPs from overview s-topic
[16:16] <arosales> so BPs updated
[16:16] <arosales> lets take a look at essential ones
[16:17] <arosales> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-s-juju-charm-testing
[16:17] <arosales> that is in progress
[16:17] <arosales> testing harness and plugin made
[16:18]  * arosales needs to update BP .. .
[16:18] <arosales> actually that is the only essential BP
[16:19] <arosales> actually looks like we need to set priority on all our BPs
[16:19] <jamespage> agreed
[16:19] <arosales> can we make that a goal for this week?
[16:19] <jamespage> Daviey, ^^ only you can do that
[16:19] <arosales> #action Daviey set priority on s-cycle BPs
[16:19] <meetingology`> ACTION: Daviey set priority on s-cycle BPs
[16:20] <arosales> previous action didn't take
[16:20] <arosales> #action Daviey follow up on missing BPs from overview s-topic
[16:20] <meetingology> ACTION: Daviey follow up on missing BPs from overview s-topic
[16:20] <arosales> ok
[16:20] <arosales> any other BPs folks would like to discuss?
[16:21] <arosales> overall we look to be in the red on status, but I suspect that is due to BPs not being updated
[16:21] <arosales> ok, sounds like there is no other BPs that needs discussion
[16:21] <arosales> #topic Ubuntu Server Team Events
[16:21] <arosales> OSCON is the only upcoming one for the juju team
[16:21] <arosales> any others
[16:22] <arosales> btw OSCON is end of July
[16:22] <arosales> ok so moving on
[16:22] <arosales> #topic Weekly Updates & Questions for the QA Team (plars)
[16:22] <plars> hi
[16:22] <plars> nothing major from me
[16:23] <plars> psivaa was able to help narrow down the kernel problem causing floodlight failures
[16:23] <plars> and jsalisbury found which change it was I think, so we should have a fix for that soon
[16:23] <arosales> plars, good to hear root cause on floodlight failures
[16:23] <arosales> plars, thanks for the update
[16:23] <arosales> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:24] <arosales> smb: Hello are you available?
[16:26] <arosales> any questions for kernel we need to follow up on?
[16:26] <arosales> for the kernel team that is :-)
[16:26] <arosales> I take it that we are ok there
[16:26] <arosales> next topic
[16:26] <arosales> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:26]  * arosales doesn't see rbask atm
[16:27] <arosales> on the ARM front from Juju we are trying to testing juju-core on ARM for saucy
[16:27] <arosales> any other ARM related topics
[16:27] <jamespage> better get that compiler working for ARM then :-)
[16:28] <arosales> jamespage noted, and dave cheney is working on that bit of work
[16:28] <arosales> #topic Open Discussion
[16:28] <arosales> any other topics to discuss?
[16:29] <arosales> I think we have been saying for a bit now to get BPs udpated
[16:29] <arosales> so lets make a good push this week to get BPs udpated and priority sets so we can see the development picture next week.
[16:30] <arosales> with that we'll close this meeting
[16:30] <arosales> #topic Announce next meeting date and time
[16:30] <arosales> NEXT MEETING: Tuesday 2013-07-02 at 1600 UTC - #ubuntu-meeting
[16:31] <arosales> jamespage, plars, Daviey, adam_g_ , roaksoax , smoser thanks for jonining this week!
[16:31] <arosales> #endmeeting
[16:31] <meetingology> Meeting ended Tue Jun 25 16:31:42 2013 UTC.
[16:31] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-06-25-16.00.moin.txt
[16:31] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-06-25-16.00.html
[16:31] <jamespage> arosales, thanks for chairing
[16:31] <jamespage> ttfn
[16:32] <arosales> np, glad to :-)
[17:00] <smb> \o
[17:00] <jsalisbury> #startmeeting
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## This is the Ubuntu Kernel Team weekly status meeting.
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[17:00] <meetingology> Meeting started Tue Jun 25 17:00:11 2013 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Saucy
[17:00] <jsalisbury> # Meeting Etiquette
[17:00] <jsalisbury> #
[17:00] <jsalisbury> # NOTE: '..' indicates that you are finished with your input.
[17:00] <jsalisbury> #       'o/' indicates you have something to add (please wait until you are recognized)
[17:00] <jsalisbury> Roll Call for Ubuntu Kernel Weekly Status Meeting
[17:00] <apw> o/
[17:00] <ppisati> o/
[17:00] <kamal> o/
[17:00] <sconklin> o/
[17:00] <sforshee> o/
[17:00] <rtg_> o/
[17:00] <cking> o/
[17:00] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:00] <henrix> o/
[17:00] <ppisati> nothing to report this week.
[17:00] <ppisati> ..
[17:01] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> No update from ogasawara since she is traveling.
[17:02] <jsalisbury> [TOPIC] Status: CVE's (sconklin)
[17:02] <sconklin> == 2013-06-25 (7 days) ==
[17:02] <sconklin> Currently we have 61 CVEs on our radar, with 1 CVE added and 3 CVEs retired in the last week.
[17:02] <sconklin> See the CVE matrix for the current list:
[17:02] <sconklin> [LINK] http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:02] <sconklin> Overall the backlog has reduced slightly this week:
[17:02] <sconklin> [LINK] http://people.canonical.com/~kernel/status/cve-metrics.txt
[17:02] <sconklin> [LINK] http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt
[17:02] <sconklin> ..
[17:02] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Raring/Quantal/Precise/Lucid/Hardy (bjf/henrix/sconklin)
[17:02] <sconklin> Status for the main kernels, until today (Jun. 25):
[17:02] <sconklin> *   Lucid - in Verification;
[17:02] <sconklin> * Precise - in Verification;
[17:02] <sconklin> * Quantal - in Verification;
[17:02] <sconklin> * Raring  - in Verification;
[17:02] <sconklin> Current opened tracking bugs details:
[17:02] <sconklin> * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:02] <sconklin> For SRUs, SRU report is a good source of information:
[17:02] <sconklin> * http://people.canonical.com/~kernel/reports/sru-report.html
[17:02] <sconklin> Future stable cadence cycles:
[17:02] <sconklin> * https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
[17:03] <sconklin> ..
[17:03] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:04] <jsalisbury> Thanks everyone
[17:04] <jsalisbury> #endmeeting
[17:04] <meetingology> Meeting ended Tue Jun 25 17:04:02 2013 UTC.
[17:04] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-06-25-17.00.moin.txt
[17:04] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-06-25-17.00.html
[17:04] <kamal> thanks jsalisbury!
[17:04] <cking> blink