[12:59] <lool> Hey!
[13:00] <lool> barry, ogra_, slangasek: hey!
[13:00] <barry> lool: hi
[13:01]  * ogra_ fells heyed 
[13:01] <ogra_> *feels
[13:01] <lool> so stgraber is on a plane today
[13:01] <lool> hmm maybe we should invite didrocks here too
[13:01] <barry> lool: +1
[13:02]  * barry is pvtmsg with him now :)
[13:02] <lool> hey didrocks
[13:03] <lool> barry: same here :_)
[13:03] <lool> hye seb128  :-)
[13:03] <didrocks> hey!
[13:03] <lool> no sergio sadly
[13:03] <lool> but let's get started
[13:03] <seb128> lool, hey ;-)
[13:04] <lool> I would like to focus this meeting on the transition plan to new images and remaining blockers
[13:04] <lool> we can discuss longer term plans next week during vUDS
[13:04] <lool> I've registered this session: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1308-os-updates
[13:05] <lool> the goal for OS updates is to ditch the old images by the end of august; IOW have everyone use the new images and OS updates by end of august
[13:05] <lool> which, given that vUDS is mid next week, means that we should be ready to flip the switch this week
[13:05] <lool> there are IMO two things that would be good to get before the switch
[13:06] <lool> one is the updated dbus interface that didrocks and barry have been working on
[13:06] <lool> because otherwise the user experience is fragile (launch syste msettings twice and you can't update unless you wait x minutes or reboot)
[13:06] <lool> the other nice to have would be to land the repartitioning changes
[13:07] <barry> LP: #1212781
[13:07] <lool> slangasek told me he has some bandwidth to hopefully do the repartitioning research+impl this week, but there's a chance he wont be able to complete this week
[13:07] <lool> the main blocker I see for the transition is that we currently wipe userdata when switching
[13:08] <lool> sergiusens told me he'd implement a flag to save+restore userdata _on the host_ in phablet-flash
[13:08] <lool> there are other things in progress, like QA team switching to new images, the daily-proposed channels etc.
[13:08] <lool> and minor annoyances like the fact that we don't see progress updates when applyings updates or the fake manifest when applying an update
[13:09] <lool> but these shouldn't get in the way to switching to the new images  :-)
[13:09] <lool> So, first of all, is this a decently accurate picture of where we stand?
[13:09] <barry> lool: two other big things on my plate
[13:09] <lool> barry: shoot
[13:10] <barry> 1) switching to the download service.  i have a wip branch that is on hold pending changes to the d/l service dbus api that i need.  i need to get status on that work, but i've pushed that below my own dbus update
[13:10] <barry> 2) stgraber and i discussed some changes needed in order to support alternative channels.  we need to move some stuff currently in client.ini to a separate channels.ini file, but we can't do that until the server is updated
[13:11] <barry> so, my plan is to work on the dbus api which i think is the most critical.  #2 should be easy-ish
[13:11] <barry> #1 is currently blocked
[13:11] <barry> #1 probably shouldn't block the transition, we'll just have crappier download control until that lands
[13:12] <lool> [ it's completely optional to get the download service integration for OS updates in 13.10; it's nice, but it's not required; the main things this buys is protection from app lifecycle, but OS updates client isn't under app lifecycle anyway, and testing for the download service ]
[13:12] <barry> #2 needs to happen i think (stgraber estimated the server changes would land on wednesday)
[13:12] <lool> right
[13:12] <barry> eot
[13:12] <lool> barry: I agree pointing at different channels is important; is this for daily-proposed?
[13:12] <barry> lool: i believe so, yes
[13:13] <barry> LP: #1214009
[13:13] <lool> ok, that's mainly to allow QA to have a proposed image to update to, but I don't think it stops us from switching the images
[13:13] <barry> (currently assigned to stgraber - he'll reassign that to me when his side is done)
[13:13] <lool> it's typically to implement new QA tests
[13:13] <lool> (upgrade tests)
[13:13] <lool> which we don't have right now
[13:13] <barry> cool.
[13:14] <lool> today we only test an image in itself, not upgrades
[13:14] <lool> (IIUC)
[13:14] <lool> however that makes me remember that we might be publishing new daily images from the latest cdimage image rather than from /current or something like that
[13:15] <lool> we need to give control to updating the daily image, which is a server side tweak
[13:15] <lool> at the moment I guess we autopublish the latest build to system-image.u.c
[13:15] <barry> i think so
[13:15] <lool> while cdimage is in manual mode to update /current
[13:15] <lool> ogra_: ^
[13:16] <lool> so it seems to me the two "blockers" to the transition are the backup/restore flag in phablet-flash and some mean to block what gets published, which indeed might require the QA team to be able to point at some other channel
[13:17] <lool> barry, didrocks: Concerning new DBus API impl, what's the ETA on it?  is it something we should wait for before switching
[13:17] <lool> ?
[13:17] <didrocks> lool: I think so, my personal ETA is before EOW
[13:17] <didrocks> as I'm on holidays starting next week
[13:17] <ogra_> lool, stgraber has a WI to implement the /current -> /pending stuff on the ayatem-image server
[13:18] <ogra_> *system
[13:18] <didrocks> I think we just need a quick dicussion with barry (that we started just before this meeting)
[13:18] <didrocks> to finish acking the API
[13:18] <didrocks> then, I need barry's mock
[13:18] <didrocks> to validate the UI
[13:18] <lool> ogra_: ack, that seems similar to what I described
[13:18] <barry> let's say my side also by eow, but could be a day or so earlier
[13:18] <ogra_> lool, imho he should go on pulling from pending
[13:18] <didrocks> before helping him on the backend as much as I can
[13:18] <didrocks> barry: do you think we can have the mock done by EOD with the different cases?
[13:19] <ogra_> lool, we cant drop the cdimage images until we have a solution for the ports ... so oth will have to exist in paralllel for a while
[13:19] <ogra_> *both
[13:19] <lool> didrocks, barry: isn't it risky to land the changes just at the time where we're switching everyone to the new update system and just before didrocks going on leave?
[13:19] <didrocks> that will enable me to ensure I finish the UI and unblock for helping you
[13:19] <barry> didrocks: in a branch, yes, i think so
[13:19] <lool> didrocks, barry: If you guys think we could switch on e.g. thursday, that would be ok I guess
[13:19] <didrocks> lool: if the mock is working, the ui implementation will be validated
[13:19] <didrocks> as we now listen to the same bus :p
[13:20] <lool> ogra_: sure, the cdimage images stay anyway
[13:20] <didrocks> so the ui will be finished like tomorrow
[13:20] <didrocks> not a big risk, barry will know the backend for sure
[13:20] <barry> right
[13:20] <barry> didrocks: do you have a backup person for the ui if needed?
[13:20] <ogra_> lool, well, i would like to drop then from the public webserver at some point ... once we have a solution for ports
[13:20] <lool> it's not like we were hit by a bus the first time we tried to land this  ;-)
[13:21] <lool> seb128: ^ would you be able to deal with all the bugs in didrocks' code?  ;-)
[13:21] <barry> lool: don't get hit by the system bus
[13:21] <didrocks> lool: IIRC, there was no bug in my code :p
[13:21] <lool> seb128: (didrocks on leave next week)
[13:21] <seb128> lool, "all"? ;-)
[13:21] <didrocks> I trusted the mock! then, didn't change anything ;)
[13:21] <seb128> lool, I'm there and can debug/fix stuff yes
[13:22] <lool> ogra_: we still need the base images to compute deltas against anyway; ports can progressively transition to the new images when they are ready for it?
[13:22] <ogra_> lool, but there is no need to have the interim product in public imho
[13:23] <ogra_> we dont have the livefs build in public either
[13:23] <lool> it's not by design though
[13:23] <ogra_> it is just one step towards the real image ... once it isnt needed to have that step public i would think we should just hide it
[13:23] <lool> it's just a security/infrastructure side effect that these are in a protected environment
[13:24] <lool> anyway, I don't really care what happens to the cdimage images; I'd personally just keep them as they are, but if you think they need renaming or something to force ports to transition to new images, that's ok
[13:24] <lool> just need to sync with stgraber on this
[13:24] <lool> we wont break ports because we wont change anything to cdimage images for now, I think that's all we need to worry about for now  :-)
[13:25] <ogra_> no, i think they just dont need publishing once ports can use system images
[13:25] <lool> alright, so summary of plan: didrocks+barry work on new dbus API with goal to finish on thursday?
[13:25] <barry> +1
[13:25] <lool> stgraber + ogra to implement new /current / /proposed mechanism for system-image.u.c tomorrow (wed)
[13:26] <lool> sergiusens to implement new phablet-flash host backup/restore flag for thursday
[13:26] <didrocks> +1
[13:26] <lool> we test the switch on thursday and we announce on friday
[13:26] <ogra_> err, what ?
[13:27] <lool> what what?  :-)
[13:27]  * ogra_ has never seen the code of system-images.u.c ... nor do i have access to it i think
[13:27] <ogra_> (access to the machine i mean)
[13:27] <lool> ogra_: Ok; I thought you were handling the cdimage symlink updates and would be interested in this, but if you think stgraber should tackle it alone, that works too I guess
[13:27] <barry> ogra_: https://code.launchpad.net/~ubuntu-system-image/ubuntu-system-image/server
[13:27] <lool> ogra_: (I don't have access to the machine either)
[13:28] <ogra_> lool, system-image pulls from cdimage /pending (and should go on to do so)
[13:28] <lool> ogra_: I am not sure that's the case
[13:28] <ogra_> i thought it is
[13:28] <lool> in the beginning at least, it was looking for cdimage build numbers and taking the highest one
[13:28] <lool> e.g. 20130820
[13:28] <ogra_> which means /pending :)
[13:29] <lool> there's a subtle difference IMO
[13:29] <lool> anyway
[13:29] <lool> doesn't matter here
[13:29] <ogra_> a published build automatically becomes /pending
[13:29] <lool> one thing I forgot in the plan: I need to keep in sync with slangasek to see when the repartitioning stuff could land
[13:29] <lool> if it could be ready for thursday/friday, we could have it rolled in phablet-flash for the announcement as well
[13:29] <lool> as beta or not
[13:30] <lool> just to avoid one extra host backup + restore effort for users
[13:30] <lool> Ok; does the "plan" sound reasonnable?  anything I'm missing?
[13:30] <didrocks> lool: TBH, I would advise on announcing it officially on Monday
[13:30] <didrocks> like not before a week-end everybody will be away
[13:30] <lool> didrocks: that's a good idea actually, announce on fridays isn't good
[13:30] <didrocks> let's test on Thursday and Friday
[13:30] <lool> fair enough
[13:30] <ogra_> lool, in any case the /current /pending stuff on system-image is also depending on QA to have tests in place and runnning
[13:31] <ogra_> they do a readonly test already, but no click package based ones yet afaik
[13:31] <lool> ogra_: Ack; I have a weekly meeting to check on this either today or tomorrow
[13:31] <ogra_> good
[13:32] <ogra_> i think asac doesnt want us to make the switch until the tests are identical ...
[13:32] <lool> alright; we're overtime, but since I didn't leave any time for status, I'd like to open the floor to any other topic for today
[13:32] <ogra_> or at least close
[13:33] <lool> barry, didrocks, ogra_, seb128: Any other important topic that you guys would like to raise?
[13:33] <seb128> nothing from me
[13:33] <barry> i'm good
[13:33] <ogra_> nope
[13:34] <lool> rock on
[13:34] <didrocks> (nothing as well)
[13:34] <lool> feel free to update https://blueprints.launchpad.net/ubuntu/+spec/foundations-1308-os-updates to list things you'd like to discuss at vUDS for next iterations of OS updates!
[13:34] <lool> have a great end of day, happy hacking!
[13:34] <barry> lool: thanks!
[16:00] <smoser> #startmeeting ubuntu-server-team
[16:00] <meetingology> Meeting started Tue Aug 20 16:00:33 2013 UTC.  The chair is smoser. 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] <adam_g> o/
[16:00] <smoser> hello all and welcome to this weeks exciting adventure that we like to call the Ubuntu Server Team Weekly Meeting.
[16:00] <smoser> #topic Review ACTION points from previous meeting
[16:01] <smoser> wow. we had no shortage of actions from last weeks meeting
[16:01] <smoser> arosales to update Juju blueprints
[16:02] <smoser> no arosoles atm, moving on
[16:02] <smoser> roaksoax to clean-up iscsitarget packaging for 12.04.3
[16:02] <smoser> hallyn_ to confirm iscsitarget packaging done
[16:02] <smoser> roaksoax, hallyn_ ?
[16:02] <hallyn_> jamespage did that :)
[16:02] <hallyn_> (did the packaging - i confirm :)
[16:02] <smoser> k. good
[16:02] <smoser> Daviey to review 'dlm' in new queue for Saucy
[16:02] <jamespage> \o/
[16:02] <smoser> Daviey, ?
[16:02] <roaksoax> smoser: seems that jamespage took care of it
[16:03] <smoser> zul to follow up on mariadb/percona making it into Saucy
[16:03] <jamespage> roaksoax, yeah - I was on a roll for dkms updates...
[16:03] <smoser> hallyn_ to coordinate with zul and smb on testing xen 4.3 on nova
[16:03] <hallyn_> that's less stable than i realized.  haven't progressed much
[16:03] <Daviey> smoser: done
[16:03] <smb> I think distracted would be a better word :)
[16:03] <smoser> arosales to update Juju blueprints
[16:03] <hallyn_> (haven't gotten xen 4.3 to work for me at all)
[16:04] <arosales> smoser, in progress for vUDS coming up
[16:04] <Daviey> smoser: dlm reviewed and accepted
[16:04] <smoser> ok. i'll push the xen item to next weke also
[16:04] <smoser> ACTION: hallyn_ to coordinate with zul and smb on testing xen 4.3 on nova
[16:04] <smoser> #action hallyn_ to coordinate with zul and smb on testing xen 4.3 on nova
[16:04] <meetingology> ACTION: hallyn_ to coordinate with zul and smb on testing xen 4.3 on nova
[16:04] <jamespage> smoser, you missed "jamespage to clean-up openvswitch packaging for 12.04.3 "
[16:04] <smoser> status ?
[16:05] <Daviey> jamespage: I started reviewing that for SRU, but not yet complete
[16:05] <jamespage> well as you ask :-)
[16:05] <jamespage> decided to take a different approach
[16:05] <jamespage> its actually only the dkms package thats not compatible
[16:05] <jamespage> and the user-space tools we have in 12.04 should be compatibile with a dkms module from raring
[16:06] <smoser> cool
[16:06] <jamespage> so we are going to backport lts-raring variants of the openvswitch-datapath-* modules to 12.04
[16:06] <jamespage> Daviey is reviewing
[16:06] <smoser> #link https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule
[16:06] <smoser> feature freeze is 29th.
[16:07] <smoser> i personally would like to see a cloud images beta1.
[16:07] <smoser> utlemming, can we just plan on that ?
[16:07] <utlemming> smosser: sure, I think that is a great idea
[16:07] <smoser> as always, please get / have blueprints in order.
[16:07] <utlemming> smoser: I'll plan on that happening
[16:07] <smoser> k.
[16:08] <smoser> anyone have anything else here ? or do we move to release bugs now ?
[16:09] <smoser> #subtopic Release Bugs
[16:09] <smoser> hm..
[16:09] <smoser> #topic Release Bugs
[16:09] <smoser> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html#server
[16:10] <smoser> bug 1175028 seems in fix-committed.
[16:11] <smoser> bug 1208455.
[16:11] <hallyn_> smb: ^
[16:11] <smoser> it looks like smb has some movement on that as recently as 18 hours ago
[16:11] <smb> hallyn_, Working on it
[16:11] <smoser> moving on.
[16:11] <hallyn_> +1
[16:12] <smoser> bug 1213915
[16:12] <smoser> i'm geussing mr jamespage has that under control.
[16:12] <smoser> bug
[16:12] <smoser> 1156932
[16:12] <jamespage> meh - waiting for a archive-admin
[16:12] <smoser> bug 1156932
[16:12] <jamespage> oh -thats a nice one
[16:14] <jamespage> not sure its a 'High' tho
[16:14] <smoser> i guess we should push that a bit upstream.
[16:14] <smoser> there aren't work arounds other than "don't do that"
[16:15] <jamespage> zul, any chance upstream will do something about that - its possible to have a broken nova api call right now
[16:15] <zul> ill look
[16:15] <smoser> ah. you can, Aaron Rosen's comment is quite good.
[16:16] <smoser> i agree, not High.
[16:16] <smoser> bug 1206872
[16:17] <smoser> i'll assume matthias has that.
[16:17] <jamespage> I started looking at the merge for that
[16:17] <smoser> ok. good.
[16:17] <jamespage> but got uncomfortable as slangasek's upstart/init goodness appeared to get dropped
[16:17] <jamespage> so I pinged him then forgot - my bad
[16:17] <smoser> you're syaing its reported fixed in debian ?
[16:18] <smoser> oh. yeah, i see that.
[16:18] <smoser> k. never mind.
[16:18] <smoser> nmoving on.
[16:18] <smoser> jamespage, please do ping slangasek again.
[16:18] <smoser> bug 1199791
[16:18] <jamespage> smoser, will do
[16:19] <smoser> zul you have athat in hand ?
[16:19] <smoser> bug 1203828
[16:21] <smoser> mdeslaur, ^? is that under control
[16:21] <smoser> bug 1203828
[16:21] <smoser> bah
[16:21] <smoser> bug 1170393
[16:21] <smoser> bug 1188069
[16:21] <smoser> that one is fix-committed, so moving on.
[16:22] <smoser> leave that to security team.
[16:22] <smoser> bug 1180397
[16:23] <smb> I need to check with infinity to get those moving one by one
[16:23] <smoser> k. thank you smb.
[16:23] <smb> Oh well actually rather would aboid that for S
[16:23] <smb> And go 4.3
[16:23] <smoser> yeah.
[16:23] <smoser> you can update the bug subject. you're the opener, smb
[16:23] <smoser> bug 1031680
[16:24] <smoser> that one doesn't hae anyone assigned.
[16:24] <smoser> hm..
[16:24] <smoser> rbasak, could youjust take a look at that offline
[16:24] <smoser> make sure its not just getting missed
[16:25] <smoser> #topic Blueprints
[16:25] <smoser> link http://status.ubuntu.com/ubuntu-s/group/topic-s-servercloud-overview.html
[16:26] <mdeslaur> smoser: I'm not currently working on the mysql package...if someone from the server team can take a look, I'd appreciate it, else it will have to wait until I get back from vacation
[16:26] <smoser> hm.. there is a lot of rred there, and we are near feature freeze.
[16:26] <smoser> mdeslaur, thanks for the follow up.
[16:26] <smoser> i think i'm generally just going to ask everyon e(and myself to take a look at your blueprints andensure that they're in a reasonable state)
[16:27] <hallyn_> yup, with ff a week away...
[16:27] <smoser> #topic Weekly Updates & Questions for the QA Team (plars)
[16:27] <plars>  -> psivaa
[16:27] <smoser> plars, anything ?
[16:27] <psivaa> no updates from the qa side
[16:27] <smoser> k.
[16:28] <smoser> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:28] <smb> Currently working on bug 1208455 which jodh reported. But also would really want xen 4.3 to get into Saucy but the window closes. I do not think it would have a real impact on anything but xen-api, xen-api-libs and blktap. All tree look to be parts of the xen cloud platform (open source xen-server) from Citrix. And all three are FTBS even without the xen update. They only exist in the archive as they got pocket-copied over from previous re
[16:28] <smb> leases.
[16:28] <smoser> double nested ?
[16:28] <slangasek> s/double //
[16:29] <smb> smoser, yeah, in the end he uses 3 levels
[16:29] <smb> But the problem actually can be seen in the 2nd level already
[16:29] <smoser> wow.
[16:29] <smb> slangasek, So yeah, probably should remove the double there
[16:30] <slangasek> well, the three levels we care about are host, outer VM, inner VM
[16:30] <smb> smoser, Better do not ask _what_ he does, cause I don't know :)
[16:30] <slangasek> to be clear
[16:30] <jodh> smoser: ftr, all I'm trying to do is create a kvm instance that is controllable from the autopkgtest env. Just so happens that when I create my instance, there are already 2 instances behind me ;)
[16:30] <slangasek> smb: jenkins dispatches vms; integration tests for upstart requires booting under a test harness; thus, nested vms are required
[16:31] <slangasek> or else jenkins needs to dispatch to bare metal instead
[16:31] <rbasak> tbh, I think bug 1031680 will get missed. It's more in depth as it seems, and needs to be dealt with with care.
[16:31] <ogra_> note that this bug seems to hold up an important fix for touch images
[16:31] <slangasek> ogra_: that's a separate discussion that I need to have with rsalveti today
[16:31] <ogra_> (the kvm one)
[16:31] <ogra_> ah, k
[16:31] <rbasak> Fundamentally it's an upstream bug, which tries to understand apt in a broken way, and fixing it is considerable upstream work.
[16:31] <smoser> slangasek, presumably a workaround would be to disable kvm
[16:32] <rbasak> A workaround is available.
[16:32] <rbasak> Not breaking compatibility is the difficult part.
[16:32] <slangasek> smoser: running qemu without paravirt? hmmmm
[16:32] <smoser> other than being painfully slow, that would workaround the bug.
[16:32] <slangasek> hadn't considered that
[16:32] <slangasek> well, "painfully slow" is the status quo
[16:32] <ogra_> speed is overrated :)
[16:32] <slangasek> we need to be able to do fast upstart integration tests
[16:32] <smoser> orders of magnitude performance affected i suspect.
[16:33] <smoser> yeah. its not a fix.
[16:33] <slangasek> if it's too slow, we can bypass it by running them locally instead
[16:33] <smoser> its a workaround
[16:33] <smoser> anyway.
[16:33] <slangasek> it's around, but it doesn't work for us ;)
[16:33] <smb> So far it seems that at least with Q and R as host and not running 64bit qemu on 32 bit guest things are more stable for me
[16:33] <smb> smoser, and that is with kvm enabled
[16:34] <smoser> oh wow. running 64 bit qemu in 32 bit guest ?
[16:34] <slangasek> ermm I hope that's not the way we're doing it
[16:34] <smoser> it just gets better and better :)
[16:34] <slangasek> jodh: ^^ are you really running 64-bit inner guest on a 32-bit outer guest?  If so, don't
[16:34] <ogra_> wow, that means we could also have arm64 under armhf :)
[16:34] <smb> slangasek, That was what jodh  was doing
[16:34] <jodh> smb: do we have a handle yet as to what is causing the kernel crashes? Does this need to be raised on lkml?
[16:34] <jodh> slangasek: no, I am not :)
[16:35] <slangasek> ok
[16:35] <smoser> i'm gonna move on here, and assume that slangasek, smb, and jodh can figure it out.
[16:35] <jodh> slangasek: well, not knowingly. But the distinction between 'qemu', 'kvm' and all the sym link horror of the multiple binaries might be doing stuff...
[16:35] <smb> jodh, You were using qemu-system-x86_64 in the guest that was i386
[16:35] <jodh> smb: I was using what was provided by 'kvm'.
[16:35] <slangasek> should we maybe take this elsewhere and not derail the meeting in progress? :)
[16:36] <jodh> which is what autopkgtest does
[16:36] <smoser> yeah, please take up in #ubuntu-server.
[16:36] <smb> slangasek, agree to take it away
[16:36]  * smoser is interested, but this is a bit long here.
[16:36] <smoser> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:36] <smoser> rbasak, do we have a kernel that we could put in the cloud iamges ? i tihnk we hvae no maas images for ephemerla for saucy at the moment due to lack of sufficent kernel...
[16:37] <smoser> i suppose i should have a bug on that, but i do not.
[16:37] <utlemming> smoser: the saucy ephemeral arm images are back to normal now...it was a qemu bug
[16:37] <rbasak> smoser: we have a generic kernel now
[16:37] <rbasak> That would do.
[16:38] <smoser> utlemming, oh? ok. that is good. well i will raise bug if there is an issue.
[16:38] <rbasak> I'll need to check exact status, but the general plan is to have lpae and non-lpae variants
[16:38] <smoser> what is the 'generic' kernel ?
[16:38] <smoser> just actually 'generic' like on other arch ?
[16:38] <utlemming> I think there is going to be some issues since we are using the OMAP kernel with the OMAP loaders.
[16:38] <rbasak> Yes, but there are a limited number of platforms that support it. Hopefully that number will grow
[16:38] <utlemming> rbasak: we should sync tomorrow morning on this
[16:38] <rbasak> ack
[16:38] <smoser> cool. thanks rbasak utlemming .
[16:38] <smoser> +1 for growing number of platforms
[16:39] <smoser> #topic Ubuntu Server Team Events
[16:39] <smoser> anyone have anything here?
[16:39] <zul> vuds is next week
[16:39] <smoser> oh yeah.
[16:39] <smoser> that
[16:39] <smoser> :)
[16:39] <smoser> and feature freeze too
[16:39] <zul> and  i move at the same time
[16:41] <smoser> so .. if anyone is looking
[16:41] <smoser> http://paste.ubuntu.com/6007053/
[16:41] <smoser> is a list of openstack proposals that ubuntu members have submitted.
[16:41] <smoser> i fyou think those are interested and have openstack voting rights (ie, you are an openstack community member), then vote
[16:42] <smoser> you can generically vote for speakers at http://www.openstack.org/rate/Presentation/how-to-monetise-your-openstack-cloud-service
[16:42] <smoser> gah
[16:42] <smoser> click VOTE HERE at http://www.openstack.org/summit/openstack-summit-hong-kong-2013/
[16:42] <smoser> http://www.openstack.org/summit/openstack-summit-hong-kong-2013/
[16:43]  * smoser cut and paste fail
[16:43] <smoser> #topic Open Discussion
[16:43] <smoser> anyone have anything her e?
[16:43] <smoser> k
[16:43] <smoser> #topic Announce next meeting date and time
[16:44] <smoser> tune in next week at Tuesday 2013-08-27 at 1600 UTC for the continuing saga of ubuntu server development.
[16:44] <arosales> smoser, thanks for chairing
[16:44] <smoser> #endmeeting
[16:44] <meetingology> Meeting ended Tue Aug 20 16:44:51 2013 UTC.
[16:44] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-08-20-16.00.moin.txt
[16:44] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-08-20-16.00.html
[16:49] <jamespage> thanks smoser
[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 Aug 20 17:01:07 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:01] <jsalisbury> #       'o/' indicates you have something to add (please wait until you are recognized)
[17:01] <jsalisbury> Roll Call for Ubuntu Kernel Weekly Status Meeting
[17:01] <kamal> o/
[17:01] <sconklin> o/
[17:01] <henrix> o/
[17:01]  * smb hastes in
[17:01] <ogasawara> o/
[17:01] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:01] <jsalisbury> No new update this week.
[17:01] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:02] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:02] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:02] <jsalisbury> ..
[17:02] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:02] <ogasawara> [LINK] https://launchpad.net/~canonical-kernel-distro-team/+upcomingwork
[17:02] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-s/canonical-kernel-distro-team.html
[17:02] <ogasawara> || apw       || foundations-1305-arm64-bringup || 2 work items ||
[17:02] <ogasawara> || ppisati   || foundations-1305-kernel        || 1 work item  ||
[17:02] <ogasawara> || sforshee  || pm-system-policy               || 2 work items ||
[17:02] <ogasawara> || smb       || servercloud-s-virtstack        || 1 work item  ||
[17:02] <ogasawara> ..
[17:02] <rtg> o/
[17:02] <jsalisbury> [TOPIC] Status: Saucy Development Kernel (ogasawara)
[17:02] <ogasawara> We have uploaded a new Saucy kerel based on the v3.11-rc6 upstream kernel.
[17:02] <ogasawara> We'll continue tracking the v3.11 kernel for the remainder of the Saucy
[17:02] <ogasawara> 13.10 release.
[17:02] <ogasawara> -----
[17:02] <ogasawara> The 12.04.3 point release is set to release this Thurs, Aug 22.  I am
[17:02] <ogasawara> hearing rumors there may be a small slip, ie 1 day slip, but it should
[17:02] <ogasawara> be going out this week.  We are not aware of any critical issues at this
[17:02] <ogasawara> time that would warrant any respins.
[17:02] <ogasawara> -----
[17:02] <ogasawara> Lastly, Virtual UDS is next week, Tues-Thurs Aug 27-29.  I've gone ahead
[17:02] <ogasawara> and opened a generic kernel catch-all blueprint.  Feel free to add any
[17:03] <ogasawara> topics which you would like to discuss.
[17:03] <ogasawara> https://blueprints.launchpad.net/ubuntu/+spec/foundations-1308-kernel
[17:03] <ogasawara> -----
[17:03] <ogasawara> Important upcoming dates:
[17:03] <ogasawara> [LINK] https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule
[17:03] <ogasawara> Thurs Aug 22 - 12.04.3 (~2 days away)
[17:03] <ogasawara> Thurs Aug 29 - Beta 1 freeze (~1 week away)
[17:03] <ogasawara> Thurs Sep 05 - Beta 1 (~2 weeks away)
[17:03] <ogasawara> ..
[17:03] <jsalisbury> [TOPIC] Status: CVE's
[17:03] <jsalisbury> == 2013-08-20 ==
[17:03] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:03] <jsalisbury> http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:03] <jsalisbury> ..
[17:03] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Raring/Quantal/Precise/Lucid (bjf/henrix/sconklin)
[17:03] <bjf> Status for the main kernels, until today (July 23):
[17:03] <bjf>   *   Lucid - Prep'ing
[17:03] <bjf>   * Precise - Prep'ing
[17:03] <bjf>   * Quantal - Prep'ing
[17:03] <bjf>   * Raring  - Prep'ing
[17:03] <bjf> Current opened tracking bugs details:
[17:03] <bjf>   * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:03] <bjf> For SRUs, SRU report is a good source of information:
[17:03] <bjf>   * http://people.canonical.com/~kernel/reports/sru-report.html
[17:03] <bjf> ..
[17:04] <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 Aug 20 17:04:51 2013 UTC.
[17:04] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-08-20-17.01.moin.txt
[17:04] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-08-20-17.01.html
[17:04] <kamal> thanks jsalisbury
[17:05] <sconklin> thanks
[22:29]  * slickymaster is away: I'm busy
[22:30]  * slickymaster is away: [Got to work]
[22:30]  * slickymaster is away: Got to work>
[22:31]  * slickymaster is away: <Got to work>
[22:32]  * slickymaster is away: Got to work
[22:32] <genii> Hm.
[22:33] <genii> !away