[13:00]  * stgraber waves
[13:00]  * lool o/
[13:00]  * barry yawns
[13:01]  * rsalveti waves
[13:02] <lool> fishing notes from last week
[13:02] <lool> 15: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:03] <ogra_> oh
[13:03] <lool> ogra_: well, let's start with this then  :-)  how are we looking bugs-wise?
[13:03] <lool> (for the flipped images)
[13:03] <ogra_> yeah, i just noticed that i missed the notification for this meeting, thanks for the ping
[13:03] <lool> I've read Chicken was confident we could switch early this week
[13:04] <ogra_> we are just about to do it
[13:04] <ogra_> last tests are running
[13:04] <ogra_> bug wise we still have a few races more than unflipped but these will be sorted over time
[13:04] <ogra_> booting is still pretty slow but we wont work on this until MIr and lightdm actually are in the boot
[13:05] <ogra_> (else it is pointless)
[13:05] <sergiusens> it just needs a push
[13:05] <ogra_> and i think mako had some extra issues
[13:05] <ogra_> err
[13:05] <ogra_> manta
[13:05] <rsalveti> the main race now is with maguro
[13:05] <ogra_> all in all it ia good enough to switch imho
[13:05] <lool> ogra_: Hmm I don't think we had xnox in the meeting last week; I guess the cross-compiler item was about building the android bits as a package; it's not heavily related to OS updates though, so maybe we can skip the update on in-archive android cross-toolchain (unless I'm missing a link to the OS update / image format stuff)
[13:05] <rsalveti> yesterday's image got me a broken camera and broken media-player
[13:05] <sergiusens> +1 on switching
[13:06] <rsalveti> which also breaks input, when you try to open the media-player
[13:06] <ogra_> lool, yeah, i guess we can
[13:06] <rsalveti> but it's looking decent enough with the other devices
[13:06]  * ogra_ doesnt have any issues on maguro here, weird
[13:06] <lool> The sooner we can kill the non-flipped images...  :-)
[13:06] <rsalveti> hopefully today :-)
[13:07] <ogra_> yeah
[13:07] <lool> Sounds like it would be less confusing to have one set of images and better to have everyone test the flipped ones at this point
[13:07] <lool> perhaps with a "Known bugs" in the announcement
[13:07] <ogra_> lool, all the code to support loop mounted setups is also in
[13:07] <xnox> lool: well, our cross-toolchain doesn't build dynalically linked binaries that execute under android's linker. The added bonus of $ adb shell /system/bin/linker seg faulting adds additional complications in troubleshooting this.
[13:07] <lool> xnox: eh
[13:08] <ogra_> theoretically you should eb able to dump stgraber's images into the right place on disk and it would use them
[13:08] <lool> ogra_: oh that's cool
[13:08] <lool> are there devices where we're using these?
[13:08] <xnox> lool: so still working on getting a working toolchain
[13:08] <ogra_> not yet
[13:08] <ogra_> switching to flipped was more in focus
[13:08] <lool> ogra_: what's the interface to set these up?
[13:08] <ogra_> but switching to loop should be a breeze now
[13:08] <lool> xnox: ack
[13:09] <stgraber> lool: my plan is to start publishing images to system-image later this week that'll use loop+read-only
[13:09] <ogra_> lool, interface ?
[13:09] <lool> ogra_: I mean, how do you set these up in the boot path?  also do we have a flag to generate corresponding images?
[13:09] <ogra_> you just have to have them in place on disk ... the initrd will prefer them to normal flipped boot
[13:10] <stgraber> though we discussed on a recent call that we shouldn't switch to that until we have click pages landed and working as otherwise everyone would just switch to developer mode which kind of defeats the purpose
[13:10] <lool> ogra_: Ok, so there's a convention that one names filesystem images /data/userdata.img or something like that?
[13:10] <ogra_> right
[13:11] <ogra_> the initrd looks for the files in their respective locations and will boot them if they are there
[13:11] <lool> stgraber: Hmm I see the argument but I'm not sure it's great delaying testing on such core functionality; perhaps we should have a mean to have a manual chroot in userdata or something?
[13:11] <stgraber> lool: it looks for /data/system.img if it finds it, it switches to read-only+loop mode, if it doesn't and /data/ubuntu exists it boots in normal flipped if it doesn't it prints a message and panics (there's a comment in the code saying that this is where the repartitioned-read-only code should go)
[13:11] <lool> ogra_: is there a wiki page capturing this perhaps?
[13:12] <ogra_> lool, that would only be a one liner :)
[13:12] <stgraber> lool: well, people will be able to test it soon (once I get that stuff on system-image.u.c), it just won't be the default
[13:12] <lool> maybe this could be added to the porting guide
[13:12] <ogra_> put a combined ubuntu+android rootfs image into /data/system.img
[13:12] <ogra_> lool, we dont even support flipped with ports yet
[13:12] <ogra_> so no
[13:13] <ogra_> not before we have that :)
[13:13] <lool> "flipped with ports"?
[13:13]  * ogra_ thinks stgraber should blog about it or write a mail to the ML
[13:13] <lool> android bits built as a package?
[13:13] <sergiusens> I need to move the boot/ramdisk stuff to the android build
[13:13] <ogra_> but it shouldnt be in the porting guide yet
[13:13] <lool> yeah a blog post would go a long way to capture this in a way we can refer to
[13:14] <lool> or email to $ML really
[13:14] <ogra_> lool, ports still build unflipped images atm
[13:14] <stgraber> ogra_: I'll blog about that whole thing once I can get the upgrader to work (hopefully this week)
[13:14] <lool> ogra_: oh ok
[13:14] <ogra_> we havent integrated the generic ubuntu initrd in their builds yet
[13:14] <lool> ogra_: sorry was confused with ports.u.c for a couple of minutes
[13:14] <ogra_> heh
[13:15] <lool> stgraber: great, thanks
[13:15] <lool> stgraber: next in the list from last week were scripts to apply updates in the recovery ROM
[13:15] <lool> stgraber: with new tar.xz support and gpg support in the recovery ROM
[13:15] <lool> (No ondra around?)
[13:15] <stgraber> ondra isn't around but he sent his status update to you and I by e-mail
[13:16] <sergiusens> lool: I have a patch from ondra but did not apply it
[13:16] <lool> oh indeed, odd that I just got it
[13:16] <stgraber> we got our first working recovery image yesterday evening (3am London time)
[13:16] <sergiusens> I was weary to apply it since it has a binary blob for tar
[13:16] <stgraber> so I haven't had time to work on an upgrade script using that yet (just started my day here)
[13:16] <sergiusens> and we are making way to remove blobs, adding one didn't seem right
[13:16] <lool> sergiusens: is that the one with gpg?
[13:17] <stgraber> sergiusens: hmm, we should only be adding a single blob for gpg (until ondra figures out how to build it without the NDK)
[13:17] <ogra_> sergiusens, i think we agreed in this meeting to do it as a temp. solution
[13:17] <sergiusens> lool: hmmm, no, one for tar with xz support
[13:17] <ogra_> though i dont get why busybox tar isnt ok to use
[13:17] <sergiusens> ogra_: stgraber I might be wrong though and it might be gpg
[13:17] <lool> sergiusens: I completely agree that we should go towards less blobs; is there something reasonnably easy that can be done to include tar + xz + gpg support from source in our images?
[13:17] <stgraber> tar and xz from busybox are fine, we shouldn't be adding those
[13:18] <ogra_> yeah, gpg has to be binary atm
[13:18] <sergiusens> ogra_: are you ok with me applying that?
[13:18] <lool> BTW, Ondra's status email mentions: 1/ recovery change to look for ubuntu_command file and execute updater script: done  2/ gpg static build as part of the Android image build: done
[13:18] <ogra_> sergiusens, as long as we remove it again :)
[13:19] <ogra_> sergiusens, which was the initial plan ...
[13:19] <sergiusens> ok, must of missed it... I'll apply it right after this meeting
[13:19] <ogra_> ondra is aware that it cant stay that way
[13:19] <sergiusens> but someone would need to track it's removal
[13:20] <lool> I'm going to make a really really native hypothesis, I hope I don't get mocked for this one: is there a reason we can't copy our eglibc + tar + gz + gpg into the recovery rom initrd?
[13:20] <lool> like, that would be too big?
[13:20] <rsalveti> probably
[13:20] <ogra_> it would surely grow it a lot
[13:20] <ogra_> but recovery is usually quite big
[13:20] <ogra_> (compared to boot for example)
[13:20] <rsalveti> sergiusens: sorry, which patches?
[13:20] <lool> do we have an idea of budget for recovery ROM size (across devices)?
[13:20] <ogra_> rsalveti, binary gpg blob
[13:21] <rsalveti> got it
[13:21]  * ogra_ only knows that 8M is a typical boot size 
[13:21] <lool> cause I'm not sure adding static binaries is that much worse than adding glibc + tar
[13:21] <ogra_> usually safe to assume as lowes size
[13:21] <rsalveti> do we have support for gpg in busybox?
[13:21] <stgraber> lool: 10MB total is what we discussed in the recovery partition last week, the kernel takes almost 5MB
[13:21] <lool> (or really glibc + gpg instead of just static gpg)
[13:21] <stgraber> rsalveti: no, gpg has to be a separate binary
[13:21] <ogra_> rsalveti, no, thus the blob
[13:22] <rsalveti> someone get an action to check the size of a static gpg then (with glibc)
[13:22] <rsalveti> hard to say without numbers
[13:22] <lool> well, with compression I guess
[13:22] <lool> yeah
[13:22] <lool> I'm all for trying to fit it in an initrd
[13:22] <stgraber> rsalveti: the GPG ondra worked on is built against the NDK so it's likely smaller than a static build against glibc
[13:23] <sergiusens> rsalveti: fyi, this is the patch https://chinstrap.canonical.com/~okubik/phablet-bootable-recovery-gpg.patch
[13:23] <rsalveti> stgraber: right
[13:23] <stgraber> IIRC it's around 5MB (uncompressed) here, just checking now
[13:23] <ogra_> lool, wrie an ubuntu initrd hook, build a new initrd with -v
[13:24] <stgraber> ah no, 2.7MB but that's not the final version, the latest one may be a bit bigger (ondra said he had to static link more stuff in)
[13:24] <ogra_> *write
[13:24] <ogra_> and then count the sizes
[13:24] <rsalveti> sergiusens: but why is this a binary instead of a source based project that gets built for recovery?
[13:25] <lool> well, maybe we ought to defer this on #ubuntu-phone
[13:25]  * ogra_ guesses we need ondra to answer these questions
[13:25] <rsalveti> right, indeed, we can check this offline
[13:25] <lool> maybe we can dive into building gpg from source as part of the recovery build, or try including shared or static gpg in recovery and see how much bigger it becomes
[13:25] <stgraber> anyway, we clearly intend on having it built from source, the result will likely be static anyway as recovery doesn't contain much libs at all
[13:25] <rsalveti> yeah
[13:25] <stgraber> the current plan is to get the binary in ASAP so that my work isn't blocked on this
[13:25] <sergiusens> rsalveti: because it was easier to use the ndk I think
[13:26] <rsalveti> we can build it as part of recovery, from the android sources side atm, until we move to something else (for recovery)
[13:26] <stgraber> then ondra will spend the time to move from building using NDK+patched-makefiles to building cleanly for recovery
[13:26] <rsalveti> right, sounds fine
[13:26] <lool> right; ondra mentioned as TODO: 1/ polish recovery change so it shows animation during update process, at the moment it shows black screen  2/ get gpg branch to state it can be push to git and added to phablet repository, just cleaning process so it can be pushed.
[13:27] <stgraber> rsalveti: we currently use Android's recovery code and have no plan to ditch it (as we need it for roll-back), our change to the code just makes it call our upgrader if it spots and Ubuntu update in /cache
[13:27] <lool> so that sounds like his 2/, albeit a bit more clearly specified
[13:27] <lool> we can keep discussing this after this meeting
[13:27] <ogra_> rsalveti, if we want to support android rollback, we cant move to somethign else
[13:27] <ogra_> bah, stgraber was faster
[13:27] <ogra_> :P
[13:28] <lool> stgraber: outside of the binaries not currently in the recovery rom, were you able to develop the unpacking scripts with ondra?
[13:28] <rsalveti> right, that's fine, just saying that we could later on have our own, built separately and such, which could still be compatible
[13:28] <ogra_> yeah
[13:28] <rsalveti> ogra_: do you know if grouper supports neon?
[13:28] <ogra_> tegra3 should
[13:28] <lool> it should, it's tegra3
[13:28] <rsalveti> don't remember which device we had issues with the updater-binary in the past
[13:28] <ogra_> 2 definitely doesnt ...
[13:28] <lool> tegra2 was one of the rare armv7 which didn't, but they realized the mistake with tegra3
[13:28] <rsalveti> but anyway, we need to make sure this gpg binary is not built with neon by default
[13:29] <lool> rsalveti: good point
[13:29] <lool> well, it ought to autodetect neon at runtime really
[13:29] <ogra_> (teh ac100 community is just freaking out about the last chromium SRU that blindly enabled NEON in raring
[13:29] <stgraber> lool: I ran a test script yesterday on my N4 to check that the interface works and it did. I now need to make a fully working version of that though but I have higher priority items on my list (get working images published, fix a couple of issues with loop-mount, publish scripts for LXC testing, ...)
[13:29] <stgraber> lool: I've spent most of yesterday fixing LXC/mount related issues for ogra_ and then fixing an upstart bug that's currently affecting ofono on Touch, so didn't have much time for my stuff :)
[13:30] <lool> yeah, seen the upload, damn ogra!  ;-)
[13:30] <ogra_> lool, wasnt me ... blame chad !
[13:30] <ogra_> i just get all the heat from the users :P
[13:30] <lool> stgraber: Ok; I was hoping we'd have images for testing this week, does that sound feasible?
[13:31] <lool> barry: Looking at remaining things from last week (sorry, we're overrunning): did you discuss reboot interface with ondra?
[13:31] <stgraber> lool: not giving up hope ;) though tomorrow is packed with meetings, so I'll see how much of the work I can do today and Thursday/Friday
[13:31] <lool> stgraber: Ok; cool
[13:32] <ogra_> at least you can test the local setup by putting the img manually in place
[13:32] <lool> I'm away next week, would someone like to run this meeting next week, or I could ask slangasek but it's earlyish for him
[13:32] <barry> lool: mostly discussed w/stgraber.  we spec'd it out and the upgrader should be compliant now.  the last little bit is plumbing through the reboot command (the reboot framework is there, but the actual reboot command is waiting for the lxc container test environment - it's probably a 2 line change).
[13:32] <stgraber> lool: I can do that
[13:33] <lool> barry: also, would you like to share latest updates on download service?  ISTR you wanted minor tweaks to the download service to set UA
[13:33] <lool> stgraber: cool, thanks
[13:34] <lool> barry: Hmm that sounds like it should work with flipped images though
[13:34] <lool> Unless I'm missing something
[13:34] <lool> barry: (I mean reboot should work in flipped images)
[13:34] <barry> lool: correct.  we've had some good discussions with mandel and others about the download service.  he's moved the code to our project, and he was going to extract those bits from the google doc to our wiki.  i have to ping him about that part.  anyway, we needed a few changes to the dbus api to support what we need, but it all seemed doable.  haven't looked at mandel's code yet.
[13:35] <barry> lool: it should.  i could probably just mock it out (obviously don't want the test suite to try to reboot :)
[13:35] <lool> barry: Ok; would be good to check the plan for landing this in the images with him too, and we also need to land your code in the images
[13:35] <lool> barry: did the design discussion settle on UI from settings app or standalone?
[13:35] <barry> lool: right.  client code is now packaged and uploaded.  i think stgraber was working on getting that into the images (if it's not already there)
[13:35] <stgraber> lool: he means the CI LXC test environment so he can test the reboot call without rebooting his laptop :)
[13:36] <stgraber> barry: yeah, I still need to seed/add it to the meta package
[13:36] <barry> lool: i haven't heard anything about ui
[13:36] <lool> barry: Hmm would you want to ping the thread?  it's from 10 days ago or so at least
[13:37] <barry> lool: yep, will do
[13:37] <lool> stgraber: ahh  :-)
[13:37] <lool> alright, I think we covered all things from last week
[13:37] <lool> anything else?
[13:37] <lool> if not I'll try to sum up ongoing work for this week
[13:39] <lool> ok, what I have is: stgraber trying to get image update code completed this week; ogra/sergiusens/rsalveti flipping images today; ondra/rsalveti/sergiusens/stgraber looking at including static gpg build w/o NEON in the recovery initrd; barry pinging design team on update UI; barry wrapping up download service API with mandel
[13:39] <lool> I hope this didn't get cut
[13:39] <lool> Did I miss anything?
[13:39] <rsalveti> sounds fine
[13:40] <rsalveti> and you getting some vacation
[13:40] <rsalveti> ;-)
[13:40] <ogra_> :)
[13:40] <barry> lool: it's a short week here in the usa, but i am also working on the dbus api for the client
[13:40] <lool> he yeah, and stgraber running the meeting  ;-)
[13:40] <lool> alright, you guys rock!  let's close this meeting and keep chatting about gpg builds on #ubuntu-phone
[13:40] <lool> thanks all!
[13:41] <barry> thanks!
[13:41] <stgraber> thanks!
[13:42] <ogra_> thanks
[13:43] <rsalveti> thanks!
[14:37] <kokoye2007> hello Sarvatt
[14:37] <kokoye2007> sorry
[14:38] <yeminn> just testing
[15:00] <Daviey> o/
[15:00] <Daviey> doh, i'm too keen.
[16:00] <jamespage> o/
[16:00] <smb> o/ (this time)
[16:01] <Daviey> o/
[16:01] <matsubara> o/
[16:01] <Daviey> rbasak: I believe you to be the chair today?
[16:02] <rbasak> I am?
[16:02] <arosales> rbasak, yes sorry for the late notify
[16:02] <arosales> rbasak, are you ok with chairing today?
[16:02] <rbasak> OK
[16:03] <rbasak> #startmeeting ubuntu-server-team
[16:03] <meetingology> Meeting started Tue Jul  2 16:03:09 2013 UTC.  The chair is rbasak. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:03] <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:03] <rbasak> #topic Review ACTION points from previous meeting
[16:03] <arosales> Daviey set priority on s-cycle BPs
[16:03] <arosales> Daviey follow up on missing BPs from overview s-topic
[16:04] <rbasak> I don't see last week's meeting logs
[16:04] <arosales> rbasak, I just updated the wiki page with those two actions
[16:05] <rbasak> https://wiki.ubuntu.com/MeetingLogs/Server/20130625 doesn't exist.
[16:05] <Daviey> arosales: Broadsided me :-)
[16:05] <rbasak> I'll look at the IRC logs.
[16:05] <Daviey> I believe the priorities are all good NOW.. I need to double check they are all on the status tracker.
[16:05] <arosales> rbasak, yes sorry I didn't add that there
[16:05] <Daviey> Mark it done, will double check following this.
[16:05] <arosales> the moin logs are at http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-06-25-16.00.moin.txt
[16:05] <arosales> rbasak, I'll get those added to the wiki
[16:06] <rbasak> Thanks
[16:06] <rbasak> #action arosales to carry out post-meeting procedure (minutes, etc) documented at https://wiki.ubuntu.com/ServerTeam/KnowledgeBase for meeting of 25 June
[16:06] <meetingology> ACTION: arosales to carry out post-meeting procedure (minutes, etc) documented at https://wiki.ubuntu.com/ServerTeam/KnowledgeBase for meeting of 25 June
[16:07] <rbasak> Sorry I'm just catching up.
[16:07] <arosales> rbasak, thank you
[16:07] <rbasak> Daviey follow up on missing BPs from overview s-topic
[16:07] <rbasak> Did you just cover that?
[16:08] <Daviey> Yes
[16:08] <rbasak> OK
[16:08] <rbasak> #topic Saucy Development
[16:08] <rbasak> #subtopic Release Tracking Bug Tasks
[16:08] <rbasak> #link http://reports.qa.ubuntu.com/reports/rls-mgr/rls-s-tracking-bug-tasks.html#server
[16:09] <rbasak> Shall I go through these?
[16:09] <Daviey> rbasak: Please do
[16:09] <rbasak> Would it be an idea to make sure someone is assigned to each of them?
[16:09] <rbasak> bug 1124384
[16:10] <rbasak> utlemming: any comment? Do you want to follow that through?
[16:10] <rbasak> bug 1196921
[16:10] <rbasak> Nobody is assigned at the moment. Any volunteers?
[16:11] <Daviey> Looks like 1124384 has become a hard problem, but smoser and utlemming are tracking it.  Not worried it will be resolved
[16:11] <Daviey> 1196921 looks like a transition that could be painful.. As it's not a blocking package, i think we can leave it for this week
[16:11] <rbasak> bug 1183634
[16:12] <rbasak> Looks like it's waiting on the MIR team.
[16:12] <Daviey> adam_g is tracking that
[16:12] <rbasak> bug 1170393
[16:12] <Daviey> I think 1183634 needs an upload to make it show on c-m list
[16:13] <Daviey> jamespage: what am i looking at on that bug?  Shows Won't Fix?
[16:13] <jamespage> I'll take that quantum one
[16:14] <rbasak> May I assign it, so that we remember for next week?
[16:14] <Daviey> jamespage: Why does the recent change show Won't Fix?
[16:14] <jamespage> not a clue - rbasak - I've already done that
[16:14]  * jamespage shrugs
[16:14] <rbasak> Thanks!
[16:15] <Daviey> Ah, i see.. the development series was thrown away, with a dedicated saucy task
[16:15] <rbasak> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1188069 is security and the security team are tracking it.
[16:15] <rbasak> https://bugs.launchpad.net/ubuntu/+source/libasm4-java/+bug/1196979
[16:15] <jamespage> anyone want to help with something java-ish
[16:15] <jamespage> ?
[16:15] <jamespage> ^^
[16:15] <jamespage> two packages to transition to asm4 in main
[16:15] <jamespage> so we can get rid of asm3
[16:16] <Daviey> jamespage: Happen to know why jarjar is in main?
[16:16] <jamespage> cglib
[16:16] <jamespage> which is one of the things that needs to be transitioned
[16:16] <jamespage> I suspect its actually broken right now
[16:16] <jamespage> as asm upstream don't version their package namespaces and they are not backwards compat
[16:16] <Daviey> ugh!
[16:16] <rbasak> https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/1031680
[16:17] <Daviey> jamespage: Do you have capacity to triage that?
[16:17] <jamespage> nagios or asm4?
[16:17] <Daviey> (java one)
[16:17] <jamespage> yeah - sure
[16:17] <Daviey> ta
[16:17] <jamespage> (I discussed with doko earlier in -devel anyways)
[16:18] <rbasak> I've been looking at this one. It's a complex issue and there's a workaround (use a different, much simpler plugin). I'm not sure it can be fixed in _this package_ for Saucy without introducing a horrible delta.
[16:18] <Daviey> rsome good triage there
[16:18] <rbasak> xnox: any comment on that? You targetted it for Saucy.
[16:18] <Daviey> rbasak: seems xnox raised it with upstream?
[16:18] <rbasak> I raised it.
[16:19] <Daviey> Oh sorry.
[16:19] <rbasak> The only comment is that we need to provide input since upstream need help. But the only sane way of fixing it is to ditch the plugin and use update-notifier directly, for Ubuntu.
[16:19] <Daviey> rbasak: lets wait to see if upstream respond?
[16:19] <rbasak> They sort of have.
[16:19] <xnox> rbasak: looking... trying to remember.
[16:19] <rbasak> " I'm less keen on having
[16:19] <rbasak> the behaviour depend on whether or not some tool is available, though; as
[16:20] <rbasak> that's problematic with respect to maintenance and support. And I guess
[16:20] <rbasak> update-notifier is a bit too Ubuntu-ish to add a hard dependency on
[16:20] <rbasak> apt-check ...
[16:20] <rbasak> Sorry I thought that'd paste on one line.
[16:20] <Daviey> So do we simply recommend using the other tool?
[16:20] <rbasak> IMHO, yes.
[16:20] <Daviey> WFM
[16:20] <rbasak> The alternative isn't packaged, though.
[16:20] <Daviey> if it's a drop in feature compatible
[16:20] <rbasak> It's not.
[16:20] <Daviey> Pah
[16:20] <rbasak> But it'll do for 99% of use cases IMHO.
[16:21] <rbasak> The existing plugin's interface is very much based on the way it works. It's not really a clean interface.
[16:21] <rbasak> How about I take this to the ML?
[16:21] <rbasak> https://bugs.launchpad.net/ubuntu/+source/virtinst/+bug/1192290
[16:22] <Daviey> mdeslaur seems to be working on it
[16:22] <rbasak> OK that's all the bugs on that report for us.
[16:22] <Daviey> \o/
[16:22] <rbasak> #subtopic Blueprints
[16:22] <rbasak> #link http://status.ubuntu.com/ubuntu-saucy/group/topic-saucy-servercloud-overview.html
[16:23] <rbasak> That link appears to be broken.
[16:23] <jamespage> http://status.ubuntu.com/ubuntu-s/group/topic-s-servercloud-overview.html
[16:23] <rbasak> Thanks!
[16:23] <rbasak> #link http://status.ubuntu.com/ubuntu-s/group/topic-s-servercloud-overview.html
[16:23] <rbasak> I'll amend the agenda for next time.
[16:24] <Daviey> Ta
[16:24] <xnox> rbasak: yeah, i only mangled bug statuses to have this bug bubble up for saucy cycle. Ideally it should be resolved one way or the other, but could be regretfully postponed.
[16:24] <Daviey> arosales: Are you able to adjust the trend line?
[16:24] <arosales> Daviey, unfortunately no
[16:24] <arosales> Daviey, a bug report should get the right folks looking at it though
[16:25] <arosales> https://bugs.launchpad.net/launchpad-work-items-tracker/+filebug
[16:25] <rbasak> xnox: OK, thanks. I'll email the ML with what I think we should do and copy you in.
[16:25] <Daviey> utlemming / ivoks: What is servercloud-s-webscale MIR's blocked on?
[16:25] <jamespage> that topic is stilling missing bp's btw
[16:25] <xnox> rbasak: cool =) back in the day I used to do a lot of nagios/check_mk large scale monitoring.... =)
[16:26] <jamespage> Daviey, the MIR's are dependent on the other work items happening first
[16:26] <Daviey> jamespage: Will sweep up after this, but we  have enough to track development of what is there for now
[16:26] <arosales> jamespage, I think Daviey has an action out to follow up on missing BPs
[16:26] <Daviey> jamespage: OIC
[16:26] <utlemming> Daviey: er, I am not sure...I'll look into that today. I've been out on vacation
[16:27] <Daviey> jamespage: Would you be able to work with zul to help with the direction of servercloud-s-openstack-hypervisor ?
[16:27] <jamespage> Daviey, can do
[16:27] <Daviey> jamespage: I suspect you are well placed to have some good guidance, based on last Friday
[16:27] <jamespage> ack
[16:28] <rbasak> Any more on Blueprints?
[16:28] <Daviey> roaksoax: What is our zeromq story right now?
[16:28] <Daviey> (servercloud-s-openstack-charms-ha-v2)
[16:28] <roaksoax> Daviey: have not look at it yet (been busy with charms mainly)
[16:28] <Daviey> ok
[16:29] <Daviey> Any more news on MariaDB/Percona ?
[16:29] <roaksoax> i'll have more information next week
[16:29] <zul> Daviey:  they have gone silent
[16:29] <Daviey> I saw the ITP in Debian for xtrabackup
[16:29] <roaksoax> zul: didn't jcastro mentioned they were going to provide their own charm too?
[16:29] <Daviey> Okay, i'll reach out to them this week.
[16:29] <zul> roaksoax:  they did but i havent heard anything else
[16:30] <Daviey> ACTION: Daviey to speak to Percona about Saucy inclusion
[16:30] <Daviey> #ACTION Daviey to speak to Percona about Saucy inclusion
[16:30] <meetingology> ACTION: Daviey to speak to Percona about Saucy inclusion
[16:30] <rbasak> I'd really like to see the alternatives in this cycle. Otherwise we'll end up not even being able to consider doing anything but supporting mysql for another LTS cycle.
[16:31] <Daviey> jamespage: Any news on juju-core snapshot in saucy ?
[16:31] <Daviey> rbasak: right
[16:31] <jamespage> Daviey, the juju-core team hit some issues end of last week
[16:31] <jamespage> should be resolved ~2 days ish
[16:32] <Daviey> super
[16:32] <Daviey> The rest looks ok, thanks.
[16:33] <rbasak> Thanks Daviey!
[16:33] <rbasak> #topic Ubuntu Server Team Events
[16:33] <rbasak> Linaro Connect is in Dublin next week.
[16:33] <rbasak> (I'll be there)
[16:33] <rbasak> Any other upcoming events?
[16:33] <Daviey> Hmm
[16:34] <Daviey> 19th London, Openstack Meetup
[16:34] <Daviey> Openstack's 3rd birthday event
[16:34] <Daviey> EOF
[16:34] <rbasak> #topic Weekly Updates & Questions for the QA Team (plars)
[16:34] <rbasak> plars: hello!
[16:34] <plars> Hi
[16:34] <zul> it seems i am in the wrong part of the world for events
[16:34] <plars> Not much to report, except that the server images had some problems today
[16:34] <plars> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1196981
[16:35] <plars> I believe the release team is looking into it
[16:35] <rbasak> Thanks plars! Does anyone have any questions for plars?
[16:35] <rbasak> OK.
[16:35] <rbasak> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:35] <smb> Hi
[16:35] <smb> Not much to report. Currently working on a pre-release-pre-debian version of xen 4.3 to have the pieces together when the release happens. Any issues from server after kernel v3.10 hit the block?
[16:36] <rbasak> I still appear to be using a 3.9 based cloud image as of today.
[16:36] <rbasak> Any questions for smb?
[16:36] <Daviey> jamespage fixed openvswitch, iscisitarget is still broke
[16:37] <jamespage> next on my list
[16:37] <Daviey> jamespage: is there a bug for iscsi-target?
[16:37] <jamespage> yes
[16:37] <rbasak> Should we target that for Saucy?
[16:37] <jamespage> bug 1195607
[16:37] <jamespage> it already is
[16:37] <Daviey> Thanks
[16:37]  * jamespage wonders about the release bugs list again
[16:37] <rbasak> It didn't come up on the tracking page though?
[16:38] <Daviey> it's not tagged
[16:38] <Daviey> Tags are useless. :-)
[16:38] <jamespage> it should not need to be tagged
[16:38] <jamespage> it has a release task and its subbed by ubuntu-server
[16:38] <rbasak> Other bugs in the report are not tagged.
[16:38] <jamespage> that should be sufficient IMHO
[16:39] <rbasak> It dosen't look like it's subbed by ubuntu-server to me.
[16:39] <rbasak> It doesn't appear in the "May be notified" list
[16:40] <rbasak> Can an ~ubuntu-server admin fix that please?
[16:41] <rbasak> Daviey? jamespage?
[16:41] <jamespage> ack
[16:41] <rbasak> Thanks!
[16:41] <rbasak> (and to smb!)
[16:41] <rbasak> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:41] <rbasak> Nothing new to report. Any questions for me?
[16:41] <Daviey> rbasak: Any news on mongo?
[16:42] <rbasak> I've not looked at it, sorry.
[16:42] <Daviey> no problem
[16:42] <Daviey> EOF
[16:42] <rbasak> #topic Open Discussion
[16:43] <rbasak> Is there anything anybody wants to bring up?
[16:43] <rbasak> I do, actually, related to the next item.
[16:44] <jamespage> rbasak, congrats btw
[16:44] <rbasak> I have a proposal that I hope is constructive. Instead of rotating the chair weekly, how about we rotate the chair once the chair completes the post-meeting procedure?
[16:44] <rbasak> Thanks jamespage!
[16:44] <jamespage> for those that don't know rbasak is now a MOTU and member of ubuntu-server-dev
[16:45] <yolanda> congrats
[16:45] <Daviey> +1!
[16:45] <rbasak> Thanks :)
[16:46] <rbasak> If we do that, then the previous chair will have his notes, and there won't be a delay at the start with confusion over who's chairing. And it's an incentive to get it done :)
[16:46] <rbasak> I propose it starts with me, so I might as well volunteer to chair next week unless I get it done.
[16:46] <rbasak> #topic Announce next meeting date, time and chair
[16:47] <rbasak> The next meeting will be on 9 July at 1600 UTC as usual. I may be absent as I'll be at Linaro Connect. So I hope I'll get it done and yolanda will chair :)
[16:47] <rbasak> #endmeeting
[16:47] <meetingology> Meeting ended Tue Jul  2 16:47:50 2013 UTC.
[16:47] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-02-16.03.moin.txt
[16:47] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-02-16.03.html
[16:47] <yolanda> ok
[16:55] <arosales> rbasak, thanks for chairing
[16:55] <rbasak> No problem
[17:00] <jsalisbury> #startmeeting
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Jul  2 17:00:03 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> ## This is the Ubuntu Kernel Team weekly status meeting.
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/Meeting
[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] <cking> \o
[17:00] <ppisati> o/
[17:00] <henrix> o/
[17:00] <sforshee> o/
[17:00] <apw> o/
[17:00] <jsalisbury> [TOPIC] ARM Status (ppisati)
[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> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:01] <ogasawara> [LINK] https://launchpad.net/~canonical-kernel-distro-team/+upcomingwork
[17:01] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-s/canonical-kernel-distro-team.html
[17:01] <ogasawara> || apw       || foundations-1305-arm64-bringup || 1 work item ||
[17:01] <ogasawara> || ogasawara || foundations-1305-kernel        || 1 work item ||
[17:01] <ogasawara> ||           || mobile-power-management        || 1 work item ||
[17:01] <ogasawara> || sforshee  || foundations-1303-phablet-kernel-maintenance || 1 work item ||
[17:01] <ogasawara> ||           || pm-system-policy               || 2 work items ||
[17:01] <ogasawara> || smb       || servercloud-s-virtstack        || 1 work item  ||
[17:01] <ogasawara> ..
[17:01] <jsalisbury> [TOPIC] Status: Saucy Development Kernel (ogasawara)
[17:01] <ogasawara> We've recently rebased our Saucy kernel to v3.10 final and uploaded.
[17:01] <ogasawara> We'll continue to track the latest v3.10.x upstream stable while we
[17:01] <ogasawara> evaluate moving to a v3.11 based kernel for Saucy.
[17:01] <ogasawara> Important upcoming dates:
[17:01] <ogasawara> Thurs July 25 - Alpha 2 (opt in)
[17:01] <ogasawara> Thurs Aug 22 - 12.04.3
[17:01] <ogasawara> ..
[17:02] <jsalisbury> [TOPIC] Status: CVE's (bjf)
[17:03] <bjf> The current CVE status can be reviewed at the following link:
[17:03] <bjf>   * http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:03] <bjf> ..
[17:04] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Raring/Quantal/Precise/Lucid/Hardy (bjf/henrix/sconklin)
[17:04] <bjf> Status for the main kernels, until today (July 2):
[17:04] <bjf>   *   Lucid - Regression testing
[17:04] <bjf>   * Precise - Regression testing
[17:04] <bjf>   * Quantal - Regression testing
[17:04] <bjf>   * Raring  - Regression testing
[17:04] <bjf> Current opened tracking bugs details:
[17:04] <bjf>   * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:04] <bjf> For SRUs, SRU report is a good source of information:
[17:04] <bjf>   * http://people.canonical.com/~kernel/reports/sru-report.html
[17:04] <bjf> Future stable cadence cycles:
[17:04] <bjf>   * https://wiki.ubuntu.com/RaringRingtail/ReleaseInterlock
[17:04] <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 Jul  2 17:04:58 2013 UTC.
[17:04] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-02-17.00.moin.txt
[17:04] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-07-02-17.00.html
[17:05] <kamal> thanks jsalisbury