[00:00] <StevenK> wgrant: I was going to do my own QA first.
[00:00] <lifeless> wgrant: one per person in the team
[00:01] <wgrant> lifeless: No.
[00:01] <wgrant> lifeless: TeamParticipation.person is constrained to me. And Person is contrained to TeamParticipation.team
[00:01] <wgrant> So it's finding all of my teams that have subscriptions
[00:02] <lifeless> to bug 1234
[00:02] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[00:02] <wgrant> Right.
[00:02] <lifeless> nested loop on TP though, which is a nuisance
[00:02] <lifeless> if we're right
[00:06] <lifeless> can teams have multiple subscriptions ?
[00:07] <lifeless> ah it sthe order by
[00:10] <lifeless> wgrant: will 8ms do ?
[00:11] <wgrant> lifeless: Nah.
[00:11] <wgrant> What'd you change?
[00:11] <lifeless> couple of things
[00:11] <lifeless> CTE
[00:11] <wgrant> srsly?
[00:11] <lifeless> plus narrower distinct by nested tables
[00:11] <wgrant> For TP again?
[00:11] <lifeless> https://pastebin.canonical.com/55155/
[00:11] <lifeless> just checking on wildcherry
[00:12] <lifeless> 28 and 11
[00:12] <lifeless> checking old query
[00:12] <lifeless> old query is 130ms on wildcherry consistently
[00:13] <lifeless> 11ms new
[00:13] <lifeless> consistently
[00:16] <lifeless> wgrant: anyhow, context switching if you're finished with me ?
[00:16] <wgrant> That indeed looks better. Odd.
[00:16] <wgrant> Thanks.
[00:17] <lifeless> https://pastebin.canonical.com/55156/
[00:17] <lifeless> is the new plan
[00:18] <lifeless> wgrant: I'm not sure the distinct is needed
[00:19] <lifeless> wgrant: unless teams can have multiple subscriptions to a bug
[00:20] <wgrant> I'm not sure.
[00:20] <lifeless> wgrant: the reason for the CTE is the 105 teams all did table walks on TP
[00:20] <wgrant> Hah
[00:20] <lifeless> if you look at the original plan
[00:26] <wgrant> But we have to guess at what's expensive. And I can't test fixes :(
[00:26] <wgrant> Because
[00:26] <wgrant>  Total runtime: 0.693 ms
[02:12] <lifeless> who is reviewin today ?
[02:15] <lifeless> StevenK: could you spare time to do a review?
[02:16] <lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/less-rsync/+merge/80861
[03:01] <StevenK> lifeless: Can do -- I was noming, sorry
[03:01] <lifeless> StevenK: food? zomg NOOOOOOO
[03:01] <lifeless> [thanks]
[03:03] <StevenK> lifeless: r=me
[03:04] <lifeless> thanks
[03:04] <lifeless> I have another in a sec :)
[03:04] <StevenK> lifeless: And wgrant is OCR today, but there is some silly horse race on.
[03:04] <lifeless> yeah, wiki was down when I asked
[03:08] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-tools/amqp-polish/+merge/80864 in a minute or two
[03:08] <lifeless> StevenK: and thanks!
[03:12] <lifeless> StevenK: diff is up
[03:13] <StevenK> I've already read it, just thinking
[03:17] <lifeless> I can do a test for the upper if you want
[03:17] <lifeless> though its one of those things that isn't going to break once its done
[03:17] <StevenK> That's not my concern
[03:17] <lifeless> :)
[03:18] <StevenK> My concern is if there is a neater way to do it
[03:18] <lifeless> we could reindex the 27M oops ids in the db with a functional index on upper()
[03:19] <StevenK> Ew
[03:19] <StevenK> Approvinated
[03:19] <lifeless> thanks!
[03:20] <lifeless> have you had an instant-oops yet ?
[03:20] <StevenK> I've seen the new ids
[03:20] <lifeless> heh, close :)
[03:21] <StevenK> Personally, I think lp-oops.c.c needs to be better before I stop ssh'ing into carob to see OOPSes
[03:21] <lifeless> its pleasant to hack on now
[03:21] <lifeless> 6s test suite
[03:21] <lifeless> etc
[03:22] <StevenK> lifeless: Can I take output from subunit-ls and say to bin/test please run those
[03:22] <lifeless> StevenK: yes
[03:22] <lifeless> thats what testr run --failing does
[03:22] <lifeless> the machinery is:
[03:22] <lifeless> subunit-ls > list-file
[03:22] <lifeless> bin/test --load-list list-file
[03:22] <StevenK> I wonder if bin/test will like /dev/stdin as a list file
[03:23] <lifeless> StevenK: it might, but ewww ;)
[03:23] <lifeless> StevenK: you know you're reinventing testr by hand, right (AFAICT)
[03:23]  * StevenK tries it, just to make lifeless a little greener
[03:23] <StevenK> Yeah, maybe I should just testr init, testr load, etc
[03:33] <lifeless> ok, so thats deployed out; next thing, the workarounds for oops-amqp
[03:33] <lifeless> almost need a fixed-amqplib
[03:33] <lifeless> but I'm not quite there yet
[03:40] <StevenK> Argh, model code updated by triggers
[03:40]  * StevenK claws his eyes out
[03:40] <lifeless> StevenK: bug heat ?
[03:40] <StevenK> lifeless: Branch.unique_name
[03:41]  * StevenK waits for his branch to stop WADLing
[03:42] <lifeless> quack quack
[03:56]  * StevenK grumbles.
[03:56] <StevenK> I suspect this branch is impossible with FDT.
[03:57] <StevenK> jtv: O hai, can you QA r14202?
[03:57] <jtv> Hi StevenK
[03:58] <jtv> I'll get to it in a moment
[04:00] <wgrant> StevenK: Are you still trying to rename +junk without talking to mrevell and others?
[04:09] <poolie> StevenK: i would like to be involved in planning what happens there
[04:09] <wgrant> Renaming it is technically trivial.
[04:09] <wgrant> Every other aspect of it is not trivial.
[04:09] <lifeless> mostly trivial
[04:09] <lifeless> depending on the new name +  backward compat desires
[04:10] <poolie> i think we ought to at least think about the larger story of how projects get started and grow
[04:10] <poolie> some things in junk are purely personal
[04:10] <lifeless> poolie: I think that hinders the local improvement
[04:10] <lifeless> poolie: of just having a better na,e
[04:10] <poolie> others are nascent larger projects
[04:10] <wgrant> A local improvement should be hindered.
[04:10] <nigelb> Hey, can SSO grab from lp if a person is remote or not?
[04:11] <wgrant> Because it is a large backwards-compatibility burden.
[04:11] <nigelb> (for a sprint)
[04:11] <lifeless> wgrant: only if it breaks +junk
[04:11] <poolie> lifeless: thinking about it does not hinder it
[04:11] <lifeless> wgrant: which isn't presumed
[04:11] <wgrant> lifeless: We now have to support +junk forever.
[04:11] <poolie> it's been like this for ~5 years
[04:11] <wgrant> lifeless: Adding a new name means we have to support the new name forever too.
[04:11] <lifeless> I shouldn't have said anything. I have work to do :)
[04:12] <poolie> congratulations on getting realtime oopses done
[04:12] <poolie> btw
[04:13] <lifeless> thanks
[04:13] <lifeless> StevenK: care to do https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.4/+merge/80865 as well ?
[04:16] <lifeless> StevenK: diff is there
[04:20] <StevenK> wgrant: So its apparently pointless to do, then?
[04:20] <StevenK> poolie: Involved how?
[04:22] <poolie> StevenK: when lp changes things like this that affect bzr, i'd appreciate being told beforehand
[04:24] <nigelb> +junk is going away?
[04:24] <StevenK> It is not.
[04:24] <lifeless> no
[04:24] <nigelb> Or going to be called something "better"
[04:24] <lifeless> but there is broad consensus that its a horrible name
[04:24] <poolie> i'm heartily in favour of improving it and of looking for a small change that will improve it
[04:24] <poolie> what are you planning to do?
[04:24] <nigelb> heh, agreed.
[04:24] <StevenK> poolie: I'm planning on changing the code to return +personal by default, but accepting both +junk and +personal.
[04:24] <poolie> StevenK, we write documentation about launchpad and we answer a lot of questions about how to use it
[04:25] <poolie> and we make design decisions that work with launchpad
[04:25] <StevenK> However, I'm not even sure if it's landable
[04:25] <poolie> so i think it's reasonable not to be surprised by changes there
[04:25] <StevenK> Since there is a trigger involved.
[04:25] <poolie> ok
[04:26] <poolie> is this in an mp? i don't see any mail about it
[04:26] <lifeless> StevenK: some care needed to check interactions with e.g. the apache rewrite map
[04:26] <lifeless> StevenK: I think that uses that column
[04:26] <StevenK> It's local only at this point.
[04:26] <poolie> that sounds like a good step though
[04:26] <poolie> a great step in fact
[04:27] <lifeless> I think we should have a brief discussion with mrevell about the new url component
[04:27] <lifeless> I'm in favour of something like 'p'
[04:27] <lifeless> may as well make it not fugly
[04:27] <StevenK> +p ?
[04:27] <lifeless> no
[04:27] <lifeless> p
[04:28] <StevenK> We don't allow single character projects, do we?
[04:28] <lifeless> exactly.
[04:28] <StevenK> I'm not sure about p, TBH
[04:28] <lifeless> p might be better reserved for project branches or something, but you get the idea
[04:28] <lifeless> real-short-and-simple
[04:29] <lifeless> I don't think + makes for a nice UI, never have.
[04:30] <poolie> i think according to https://dev.launchpad.net/LaunchpadEnhancementProposalProcess you need to write a lep for it
[04:30] <lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-amqp/0.0.4/+merge/80865
[04:30] <StevenK> So sinzui said on the call that +personal seems to be the prefered name, and that I can have a free rs=sinzui so he copes the flak and I don't. :-P
[04:30] <StevenK> lifeless: Shall I just wait on IRC for your next MP?
[04:30] <lifeless> StevenK: please
[04:30] <lifeless> StevenK: that would be awesome
[04:31] <StevenK> lifeless: Your timing the last two times has been impeccable
[04:31] <lifeless> StevenK: blame your squadmate :)
[04:31] <StevenK> I just swap my own work back in and I get pinged again.
[04:31] <StevenK> I think I'll blame Melbourne.
[04:31] <lifeless> StevenK: hey, I pinged this one 17 m back, but you were distracted :)
[04:32] <StevenK> Oh, that one.
[04:32] <StevenK> I already had it open, I was thinking.
[04:34] <StevenK> lifeless: Approved, with a comment.
[04:34] <poolie> :/
[04:34] <StevenK> poolie?
[04:34] <lifeless> poolie: I think you're asking for more from LP devs than they ask from bzr here, and I don't understand why.
[04:35] <lifeless> poolie: both project cooperate, have a reasonable understanding of the other (at least at team mgmt levels) so they ask when they see impact, and don't when they don't.
[04:36] <poolie> yeah my unhappiness is basically that they don't ask when they see an impact
[04:36] <poolie> or perhaps they don't see an impact
[04:36] <StevenK> poolie: How does the personal namespace impact on bzr?
[04:37] <poolie> for instance, we have documentation that refers to +junk
[04:37] <lifeless> So, imagine that we accept +personal and +junk, and advertise +personal. That obviously needs to be socialised amongst everyone doing support, and all our useres.
[04:37] <lifeless> but its compatible; any docs won't be invalidated, they will keep working.
[04:37] <poolie> yeah
[04:37] <StevenK> Exactly
[04:37] <poolie> i guess that seems a bit pedantic to me
[04:37] <poolie> and it would be easy and more courteous to just say 'we're going to change this' in advance
[04:38] <StevenK> poolie: Er, so I didn't even know if it was *possible* to change it until 4pm yesterday.
[04:38] <StevenK> To be brutually honest, what I have is a play branch
[04:38] <lifeless> would you tell LP if you added a new verb with no particularly surprising semantics in it, that was backwards compatible with old clients etc?
[04:39]  * StevenK throws his Dell laptop out the window
[04:39] <lifeless> StevenK: how will you play WoW ? Oh right ...
[04:39]  * StevenK has removed that from his machines
[04:40] <StevenK> Besides, I hated playing WoW with a trackpad
[04:40] <poolie> lifeless: i guess that example means "that had no changes that are likely to impact lp"
[04:40] <poolie> the difference is that changes to lp's ui/user model do impact us, because we document and support it
[04:41] <poolie> StevenK: np, i don't really mind this case (and again, i'm happy to see it improved) it just seemed like a bit of a pattern
[04:42] <lifeless> poolie: what data points are on this pattern? Last time we spoke about this feeling you were hard put to pin it down.
[04:42] <lifeless> poolie: it *seemed*, as I remember it, to be mainly feeling that LP did stuff without talking about it : but when we compared notes team bzr wasn't communicating (in advance) any more fully
[04:43] <poolie> i don't think it's about who's doing better or worse
[04:43] <lifeless> poolie: I don't mean to frame this as what you do vs what lp does, though it seems I'm taking it that way
[04:43] <poolie> but rather, which things are useful to communicate about
[04:43] <poolie> if lp changes the namespace for branches that is the kind of thing i'd like to hear about
[04:44] <StevenK> lifeless: Can we have a quick skype?
[04:44] <lifeless> StevenK: sure
[04:45] <poolie> if there's any thing we're changing that you wish you'd heard about earlier, let me know
[04:46] <lifeless> poolie: I trust that (I track what you are doing enough, and that you make good decisions) to the extent that whatever falls through the cracks, falls through the cracks.
[04:48] <poolie> yeah i normally do too
[04:48] <poolie> i was surprised by this because i didn't see anything about it on a bug or mp
[04:51] <nigelb> Hi, so +temp-meeting-export will not give a subscription information if someone is not registered for a sprint. Is there a chance I can remove that check?
[04:51] <jtv> StevenK: I need to make dogfood or staging go through the motions of notifying about a package sync or upload…  I can't sync Ubuntu packages on dogfood any more; what would I need to do to elicit an email notification from an upload?
[04:52] <StevenK> jtv: OTP
[04:52] <jtv> ok
[04:52] <lifeless> nigelb: I believe summit is the only user, so sure, though the data size can be pretty big on popular blueprints
[04:53] <nigelb> lifeless: It has always been big. we hit issues with the 2 sprints thing this time.
[04:54] <nigelb> Some BPs were only registered to LDS.
[04:54] <nigelb> I'll change it after UDS, lest people murder me.
[04:56] <lifeless> StevenK:         result = store.find(
[04:56] <lifeless>             (Branch.id, Branch.unique_name),
[04:56] <lifeless>             Branch.unique_name.is_in(prefixes),
[04:56] <lifeless>             Branch.transitively_private == False).one()
[04:59] <nigelb> Oh.
[05:01] <nigelb> I just noticed rf-* is symblinked to the binary in devel.
[05:04] <jtv> StevenK, wgrant: mind if I upgrade dogfood?
[05:09] <poolie> when are builds deleted? like https://code.launchpad.net/~neon/+recipe/project-neon-kdesdk/+build/12437
[05:09] <poolie> are they gc'd a while after they complete?
[05:11] <wgrant> jtv: No.
[05:11] <jtv> Thanks.
[05:11] <wgrant> poolie: they're meant to never be deleted.
[05:12] <wgrant> And I think I convinced code that deleting them was not going to work.
[05:12] <poolie> so the user must have deleted them?
[05:12] <wgrant> So IIRC they shouldn't ever be deleted.
[05:12] <poolie> or the urls are just wrong
[05:12] <wgrant> What linked to that?
[05:12] <poolie> https://bugs.launchpad.net/launchpad-buildd/+bug/693524
[05:12] <_mup_> Bug #693524: Daily builds fail because of insufficient memory <escalated> <linaro> <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
[05:13] <wgrant> Perhaps they renamed the recipe?
[05:13] <wgrant> D:
[05:13] <wgrant> SPRB.destroySelf exists.
[05:13]  * wgrant goes stabbity stab.
[05:13] <wgrant>         for release in releases:
[05:13] <wgrant>             release.source_package_recipe_build = None
[05:13] <wgrant> tergjkeriogjeroigteriogjioergioernjegkl
[05:13] <wgrant> 23FTRWE89HGN A9PRGHERIUHGER
[05:14] <wgrant> Yes that's right let's just erase the auditing information
[05:14] <wgrant> WHY NOT
[05:16] <poolie> :)
[05:19] <poolie> wgrant: what would be the most practical way for me to get the versions of bzr and bzr-builder in to the build log file
[05:19] <poolie> to make bzr-builder print them?
[05:20] <wgrant> I'm not sure.
[05:20] <wgrant> I would hesitate to suggest that a bzr-builder upgrade would be the easiest thing.
[05:24] <poolie> meaning "it probably is, but only slightly" or "it's probably not?"
[05:24] <wgrant> I would have said it was, until we ran into this recent trouble.
[05:24] <wgrant> Now it's possibly easier and safer to fix lp-buildd.
[05:41] <lifeless> ftr this is the bug - https://bugs.launchpad.net/launchpad/+bug/147407
[05:41] <_mup_> Bug #147407: Junk sounds too harsh <lp-code> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/147407 >
[05:51] <poolie> ftr my bit is https://bugs.launchpad.net/launchpad/+bug/884092
[05:51] <_mup_> Bug #884092: source recipe build logs should mention versions used <Launchpad itself:Triaged> < https://launchpad.net/bugs/884092 >
[07:08] <jtv> StevenK: not having much luck testing that revision.  Can't even upload a deb to dogfood.  :(  Since my branch doesn't change any functionality, I think I'll go with "qa-untestable."
[07:09] <jtv> (The upload failure is something I've seen before — worth chasing down, but probably not worth holding up landings for)
[07:13] <poolie> so does buildd/buildrecipe somehow get copied to buildrecipe.py, which seemsto be the name that isactually run?
[07:21] <poolie> ok https://code.launchpad.net/~mbp/launchpad/884092-buildd-versions/+merge/80870
[07:22] <poolie> stevenk, wrgant, how could i usefully locally test a change to buildrecipe?
[07:24] <lifeless> poolie: there is a makefile in buildd, or a debian.rules - something
[07:24] <poolie> yeah, even some documentation
[07:36] <nigelb> wgrant: OCR-ing today?
[07:36] <wgrant> nigelb: Public holiday.
[07:36] <wgrant> So I'm mostly not here.
[07:36] <nigelb> wgrant: HA, what's the holiday for? (its holiday for us too)
[07:37] <wgrant> Melbourne Cup
[07:37] <wgrant> Because horse races are awesome, apparently.
[07:37] <nigelb> Horse race?
[07:37] <nigelb> lol
[07:37] <nigelb> Ours is slightly more reasonable. State formation anniversary thingie.
[07:41] <nigelb> wgrant: Do you get holidays for cricket matches as well? ;)
[07:41] <wgrant> Nope.
[07:41] <nigelb> Sad.
[07:41] <nigelb> That obviously meant more hlidays.
[07:42] <nigelb> No more make lint?
[07:43]  * nigelb moves to right folder.
[07:51] <nigelb> Ugh, http://paste.ubuntu.com/725049/
[07:51] <nigelb> Tried out +temp-meeting-export locally.
[07:52] <nigelb> Ah, that was my fail :)
[07:57]  * wallyworld_ off to see Cold Chisel :-)
[08:05] <nigelb> Ew. This was done very badly.
[08:05] <nigelb> For the meeting export, it gets all the sprint attendees and then gets people from it.
[08:21] <nigelb> Could someone give some guidance on potential perfomance?
[08:21] <nigelb> Currently, the meeting export fetches all the attendees for a summit and filters the people attending from that.
[08:21] <lifeless> yup
[08:22] <nigelb> so, the meeting export page is sort of fast.
[08:22] <lifeless> this is an important characteristic
[08:22] <nigelb> But the chnage I want kinda screws it up.
[08:22] <nigelb> And I'm hesitant to do that :)
[08:23] <lifeless> fair enough too :)
[08:23] <nigelb> I wondering if we could add people to list as I find them
[08:23] <nigelb> with the details I want
[08:23] <lifeless> whats the big picture here
[08:23] <nigelb> and build the list of people based on the people subscribed to the BPs in the sprint.
[08:23] <nigelb> The big picture is we want all the people subscribed to a blueprint.
[08:24] <lifeless> so the export should be 3 queries
[08:24] <lifeless> -> sprint
[08:24] <lifeless> -> blueprints
[08:24] <lifeless> -> people
[08:24] <lifeless> and then some glue
[08:24] <nigelb> heh
[08:24] <nigelb> Yeah
[08:24] <nigelb> My idea is this
[08:24] <nigelb> We do this currently
[08:24] <nigelb>         people_by_id = dict((person.id, person) for person in
[08:24] <nigelb>             getUtility(IPersonSet).getPrecachedPersonsFromIDs(attendee_set))
[08:25] <nigelb> and then we look into that dict to find a person's ID and whether they are required.
[08:25] <lifeless> and \o/ instant oopses on staging as well
[08:25] <nigelb> heh
[08:25] <nigelb> I'm running it locally :)
[08:25] <rvba> lifeless: congrats!
[08:25] <lifeless> rvba: thanks :)
[08:26] <nigelb> lifeless: \o/ Nice :)
[08:26] <lifeless> rvba: allenap: btw - you might like the last commit on oops-amqp - more errors amqplib throws up when rabbits are restsarted
[08:26]  * rvba looks.
[08:27] <nigelb> lifeless: Ideally, I'd like to look if a person exists in a dict I create as I go, if not lookup each person I find on a BP, and find their ID, name, required status and put into that dict.  I'll be quering more on launchpad, but only once person.  Is that too much of a perf drop?
[08:28] <lifeless> nigelb: thats about as bad as it gets
[08:28] <nigelb> I was afraid of that :)
[08:28] <nigelb> Alternatively, can I look up subscribers to a BP instead?
[08:28] <lifeless> nigelb: step back
[08:29] <lifeless> nigelb: you need three queries:
[08:29] <lifeless> sprint
[08:29] <lifeless> blueprints
[08:29] <lifeless> peple
[08:29] <lifeless> and then glue
[08:29] <lifeless> the glue is mostly done - jus tneeds shuffling
[08:29] <nigelb> I get all the people in launchpad?
[08:29] <lifeless> you can't work with the object model for doing queries though: the object model is intrinsically hostile to performance
[08:29] <lifeless> nigelb: no, you get all the people relevant to the blueprints
[08:30] <lifeless> one query.
[08:30] <nigelb> I can do that?
[08:30]  * nigelb didn't know.
[08:30] <lifeless> well, you'll need to put the bits in the right order, but yes.
[08:30] <lifeless> thats what the current code does (but it selects all attendees, not all subscribers-or-attendees)
[08:31] <lifeless> [caveat, I haven' tlooked at that code in ~ 9 months, bzr annotate will tell you precisely when)
[08:31] <nigelb> Is there code to do that or do you suggest I write it? :)
[08:31] <lifeless> I don't know how much will need assembling and how much is pre canned
[08:32] <lifeless> this is bread-and-butter to changing something in LP though, its not at all unordinary
[08:32] <nigelb> Excellent. I'll look at the model and see if I can figure something out :)
[08:32] <nigelb> I may need lots of help.
[08:34] <lifeless> is this desirable? Won't the summit UI explode ?
[08:34] <nigelb> No.
[08:34] <nigelb> Summit was always doing this.
[08:34] <nigelb> Showing all the subscribers to a BP.
[08:34] <nigelb> It helps people hide the ones they aer not subscribed to.
[08:35] <nigelb> And setup personal icals.
[08:35] <lifeless> ok
[08:35] <lifeless> so how is that data not present ?
[08:35] <nigelb> all those break since some subscriptions don't get sycned thanks to two summits.
[08:35] <lifeless> I don't understand the failure mode
[08:35] <nigelb> We're using 2 launchpad sprints.
[08:35] <nigelb> some Bps proposed to uds-p, some to lds
[08:35] <nigelb> (Eventually, all blame goes to linaro :P)
[08:35] <lifeless> but if you're using temp-meeting-export, that means you're not getting all subscriptions
[08:36] <nigelb> we query both
[08:36] <nigelb> so we get all subscriptions
[08:36] <nigelb> But we don't get all the people
[08:36] <nigelb> some people are registered for uds, some for lds.
[08:36] <lifeless> I don't understand
[08:36] <lifeless> neither export includes non-attendees
[08:36] <lifeless> how are you getting 'all subscriberes to a BP'
[08:37] <nigelb> Its from the export
[08:37] <nigelb> I need to find out how james set this up.
[08:37] <lifeless> so the export includes all subscribers irrespective of attendees ?
[08:37] <nigelb> (at the summit end)
[08:37] <nigelb> export does not.
[08:37] <lifeless> then how is summit showing all subscribers ?
[08:37] <nigelb> export includes only subscribers who are attendees.
[08:38] <nigelb> Summit isn't showing all subscribers, which is what I'm digging for.
[08:38] <lifeless> but you said 'summit was always doing this'
[08:38] <nigelb> We always had one sprint.
[08:38] <lifeless> 21:34 < lifeless> is this desirable? Won't the summit UI explode ?
[08:38] <lifeless> 21:34 < nigelb> No.
[08:38] <lifeless> 21:34 < nigelb> Summit was always doing this.
[08:38] <lifeless> 21:34 < nigelb> Showing all the subscribers to a BP.
[08:38] <nigelb> so, this was never a problem.
[08:38] <lifeless> nigelb: one sprint doesn't mean showing all subscriberes
[08:38] <lifeless> nigelb: the statements are not at all equivalent
[08:38] <nigelb> lifeless: I'll rephrase.
[08:39] <nigelb> Until now, we never noticed the impact.
[08:39] <nigelb> Most Ubuntu folks were attendees.
[08:39] <lifeless> right, and thats why I'm asking.
[08:39] <lifeless> Won't the summit UI explode ?
[08:39] <nigelb> explode in what sense?
[08:41] <lifeless> 600 attendees
[08:41] <nigelb> we don't show all attendees in one place.
[08:41] <nigelb> But we show all subscribers to a BP.
[08:41] <lifeless> bear with me
[08:41] <nigelb> Yeah, I'm misunderstanding soething :)
[08:42] <nigelb> Would skyping help?
[08:47] <lifeless> ok, 597 subscribers across all bp;s
[08:48] <lifeless> peaks is 46
[08:48] <lifeless> thats probably tolerable
[08:48] <lifeless> (on a single spec)
[08:48] <nigelb> hah, that.
[08:48] <nigelb> Yeah.
[08:48] <nigelb> We do occasionally have UI explosion for big and famous sessions
[08:49] <nigelb> But its only if you mouse over.
[08:52] <nigelb> lifeless: You just made me realize I need to dig deeper into summit for this.
[08:52] <nigelb> Because with both the meetings, we should get all the subscriberes, but we're not.
[08:52] <lifeless> nigelb: consider the more permanent solution :)
[08:53] <nigelb> lifeless: I like what's currently there for its performance :)
[08:53] <nigelb> I probably only wold add a warning when subscribing that "You aren't markd as attending for this sprint" or osmething.
[09:20] <allenap> lifeless: Yes, tip top, thanks.
[09:21] <lifeless> allenap: also the current catch IOError in LP is too broad
[09:21] <lifeless> allenap: (again, see oops-amqp for better handling of that)
[09:22] <allenap> lifeless: rvba has been working on that, but is suffering badly from a Heisenbug around OOPSes. I suspect the big OOPS landing yesterday might help.
[09:23] <rvba> allenap: I tried to use the new oops thing yesterday and land it again, but I've been suffering from the perf problem lifeless mentioned in his email and I killed it after 6 hours in ec2.
[09:24] <lifeless> rvba: its fixed now :)
[09:24] <rvba> lifeless: \o/.  I shall try to land it again then. Thanks for the heads up.
[09:24] <lifeless> if it takes that long its your change :P
[09:25]  * rvba tries to land it again.
[11:32] <bigjools> gmb: can I bother thee for a review please
[11:32] <gmb> bigjools: Sure. I'll take a look as soon as I've done with rvba's.
[11:32] <bigjools> thanks
[12:28] <bigjools> gmb: heh, good point with the comments
[12:28] <gmb> :)
[12:28] <bigjools> I only even added those ones as an afterthought - never a good idea
[12:58] <deryck> Morning, all.
[13:16] <danhg> Hi Everyone, if you're a Launchpad user, please get in touch if you'd like to do some usability testing today.
[13:19] <lifeless> danhg: I suggest trying in #ubuntu-uds
[13:19] <danhg> thanks lifeless
[13:19] <lifeless> danhg: folk here probably don't qualify for such tests :P
[13:20] <danhg> I've posted there too
[13:20] <lifeless> danhg: I don't see you in that channel ?
[13:20] <danhg> I'm in it now
[13:21] <danhg> I'm on Colloquy. It likes to mess around.
[13:21] <lifeless> indeed, you are too
[14:24] <rvba> lifeless: Your new oopses code fixed my Heisenbug.  Thank you for that!
[14:25] <lifeless> \o/
[14:25] <lifeless> how?
[14:26] <rvba> I don't know (hence the Heisenbug), but I was able to land my code without a problem once I've refactored it to use the new oops code.
[14:26] <rvba> I had this weird 'test hung' failure.
[14:26] <rvba> That I could not reproduce locally.
[14:32] <rvba> lifeless: If you're really interested, you have all the details about the Heisenbug in my email "Help with a hung test" to the mailing list.
[14:33] <Beret> lifeless, thought you were going to bed? :)
[14:34] <lifeless> I was
[14:34] <lifeless> I am too :P
[14:34] <lifeless> rvba: were you using getLastOops ?
[14:34] <rvba> lifeless: yes.
[14:34] <lifeless> then you were seeing an oops from the test before, in all probability
[14:35] <lifeless> because it was a terrrrrible API (though probably not obviously so at the time it was written)
[14:35] <lifeless> rvba: I'm glad its working for you
[14:35] <lifeless> and with that, I really am halt()ing state
[14:35] <rvba> Good night lifeless!
[14:42] <rvba> gmb: I've got a tiny review for you if you're up for it ;). https://code.launchpad.net/~rvb/launchpad/combinator-bug-881144/+merge/80911
[14:42] <gmb> rvba: I'm OTP and then am going to be grabbing a late lunch, but I'll come to it soon thereafter.
[14:43] <rvba> gmb: sure. Thank you!
[15:04] <deryck> abentley, should we do a late standup now, while I wait on staging update?
[15:04] <abentley> deryck: sure.
[15:08] <deryck> abentley, http://pastebin.ubuntu.com/725330/
[15:25] <deryck> abentley, we will need to get a loading spinner of some sort working when changing the ordering.
[15:25] <deryck> abentley, but I think we'll need to rethink our current spinner approach since a whole section of the page changes.
[15:25] <abentley> deryck: We haven't implemented precaching yet :-)  Well, I guess we should add a spinner anyhow.
[15:26] <deryck> abentley, yeah, just to be safe.
[15:26] <deryck> mrevell, staging is working now.  https://bugs.staging.launchpad.net/launchpad/+bugs
[15:26] <mrevell> Woooo! Thanks deryck
[15:26] <deryck> mrevell, np.
[15:27] <deryck> mrevell, some minor issues still, like needing a loading symbol to indicate we're getting results, but overall, the resorting is pretty darn cool.
[15:27] <deryck> but after the initial load, it's super fast.
[15:27] <mrevell> deryck, Cool :) What team do I need to be in the thing?
[15:28] <mrevell> Sorry, that made little sense.
[15:28] <deryck> mrevell, I think matsubara added the product team to the feature flag rule.
[15:28] <mrevell> I'm not seeing the new listings so I'll hunt him down and ask him to pop me in the relevant team. Cheers.
[15:29] <deryck> mrevell, cool.  cheers.
[15:29] <abentley> deryck: very nice.
[15:30] <deryck> thanks, abentley!
[15:57] <jml> mrevell: in this ask ubuntu session, you'd be amazed at how much people are talking about 'reputation' (their karma equiv.) as a desirable commodity and a motivator for actions.
[16:45] <gmb> rvba: I haven't had chance to review your branch yet, but I will do before I EoD.
[16:46] <rvba> gmb: Great, it's not urgent so if you don't have the time today that's fine, I'll get it reviewed tomorrow.
[16:47] <gmb> rvba: Okay, thanks. I'll do my best though. Interviews are sucking up a lot of time for team Yellow this week.
[21:18] <mrevell> hey huwshimi
[21:18] <thumper> hi mrevell
[21:18] <huwshimi> mrevell: Morning!
[21:18] <thumper> mrevell: you in orlando?
[21:20] <thumper> mrevell: is sinzui there with you?
[21:21] <thumper> I'd like to talk privacy with him
[21:21] <mrevell> thumper, sinzui is here, he arrived today
[21:21] <mrevell> thumper, and "hello" :)
[21:21] <mrevell> huwshimi, Hey, do you want to have a catch-up call?
[21:22] <mrevell> thumper, I'm not sure where he is right now but I can let him know you want to talk.
[21:22] <thumper> mrevell: that'd be cool
[21:22] <huwshimi> mrevell: Sure
[21:22] <thumper> mrevell: I'm back home now though, so it would have to be afternoon for him
[21:22] <huwshimi> mrevell: 5 mins?
[21:23] <mrevell> thumper, Okeydoke. I'll let him know to contact you when I see him.
[21:23] <mrevell> huwshimi, Sure.
[21:23] <lifeless> mrevell: allo
[21:23] <mrevell> hello lifeless
[21:25] <jelmer> hi launchpadders
[21:27] <lifeless> mrevell: have you seen the new LessJunk LEP? I haven't read it yet but given that the implementation is pretty shallow it would be worth us working through the questions I expect it raises.
[21:29] <huwshimi> mrevell: Ready when you are
[21:29] <mrevell> lifeless, I've seen that it exists but not yet read it; it's been pretty full on today and yesterday. I'll take a look tonight or tomorrow morning and perhaps we can have a call tomorrow.
[21:30] <mrevell> huwshimi, Cool. Is Skype okay?
[21:30] <huwshimi> mrevell: yup
[21:30] <lifeless> mrevell: sweet
[21:33] <huwshimi> mrevell: I'm getting nothing
[21:34] <mrevell> huwshimi, Oh, weird. It was ringing for me. I'll try again
[21:34] <huwshimi> mrevell: It rang and I answered, but no sound
[21:34] <huwshimi> mrevell: Oh, looks like skype crashed
[21:36] <huwshimi> mrevell: Try again?
[21:41] <lifeless> flacoste: dunno if you saw, but wgrant shaved a second off of ubuntu bug searches
[21:42] <lifeless> flacoste: maybe more in fact - poor behaviour on the TeamParticipation table
[21:42] <lifeless> flacoste: I going to ask stub to look into some pg innards relating to this
[21:42] <flacoste> lifeless: i saw mention of a performance related feature flag earlier
[21:42] <flacoste> didn't know the details
[21:42] <flacoste> but that's excellent
[21:42] <lifeless> its a bit worrying, but good we have a workaround - I suspect table and index bloat on the table
[21:44] <lifeless> flacoste: also \o/ \o/ \o/ I'm so happy the major part of the oops arc is complete.
[21:48] <flacoste> yes, this is also awesome news!
[21:48] <lifeless> I know I mentioned it yesterday, but I'm still bouncy from it ;)
[21:54] <poolie> flacoste, all
[21:54] <flacoste> hi poolie
[22:59] <poolie> hi huwshimi?
[23:37] <poolie> lifeless, huw, i wonder if there should be some kind of systematic answer to whether to provide counts of objects from the thing that links to them
[23:37] <poolie> like rvb's recent bug 827935
[23:37] <_mup_> Bug #827935: Person:+branches timeouts <regression> <timeout> <Launchpad itself:In Progress by rvb> < https://launchpad.net/bugs/827935 >
[23:37] <poolie> perhaps it's just simply: do it if it's useful but not if it's too expensive
[23:43] <lifeless> I think it depends a lot on context
[23:43] <lifeless> for instance, a dashboard telling you what things need doing it much more useful if you don't need to click through
[23:44] <lifeless> the portlet showing high/critical/untriaged/my bugs for instance - the first three tell you things you need to action, the last one is more 'canned search' - if you see what I mean
[23:48] <wgrant> lifeless: Is lp-oops missing its 500.html again?
[23:48] <lifeless> wgrant: it hasn't been added ever
[23:48] <lifeless> wgrant: its barfing on the index page?
[23:48] <wgrant> Yes.
[23:48] <wgrant> And all other pages.
[23:48] <wgrant> Ah, no, some OOPSes work.
[23:49] <lifeless> should wire it up with oops reporting
[23:49] <wgrant> Heh
[23:50] <lifeless> ./src/oopstools/settings.py:INDEX_TEMPLATE = "index-launchpad.html"
[23:50] <poolie> lifeless: yeah i like the new/high/critical things
[23:50] <StevenK> And then if the OOPS reporting causes an OOPS while reporting an OOPS, we reboot Launchpad.
[23:58] <lifeless> wgrant: should be fixed


[01:56] <mpt> holy crap the Launchpad wiki disappeared
[02:01] <lifeless> or has it
[02:02] <mpt> elmo fixed it
[02:32] <poningru> err showstopper I guess
[02:33] <poningru> Typing Launchpad into firefox url bar
[02:33] <poningru> current result: I'm feeling lucky search of google does not have Launchpad.net for a launchpad search
[02:34] <poningru> wanted result: typing launchpad into firefox url bar will take me to launchpad.net
[02:34] <poningru> possible patch: googlebomb!!!
[02:35] <poningru> well the legal kind
[02:35] <poningru> have everyone put a link to launchpad on their blogs
[08:04] <Mez> anyone here?
[08:04] <Mez> I have a suggestion for malone
[08:05] <Mez> kiko 0 you here or just auto-reconnect ?
[08:23] <ajmitch> Mez: file a bug on malone
[08:35] <Mez> ajmitch: can never find the right place ;)
[08:39] <ajmitch> against the product malone
[10:46] <mpt__> poningru, we're working on that, see https://wiki.launchpad.canonical.com/LaunchpadGooglification#head-6e208a405b33f70198bc9efcd866a6217b22a17a
[10:46] <poningru> ?
[10:46] <poningru> regarding my question in Ubuntu-offtopic?
[10:46] <poningru> or my earlier question?
[10:47] <poningru> thanks mpt_
[10:47] <poningru> oh the googlebombing idea
[10:47] <poningru> err googlification idea ;)
[10:50] <mpt__> linking from OSNews three days ago should help
[10:50] <poningru> yeah true
[10:51] <poningru> but still if everyone on planet ubuntu just had a link to launchpad on their homepage
[10:52] <mpt__> Why would they want to? :-)
[10:52] <poningru> because launchpad is used for a major distro they work on :)
[10:52] <poningru> sorry had to try
[10:52] <poningru> I mean like just ask people to
[10:53] <mpt__> I don't imagine many of them had links to Bugzilla from their Weblogs before now
[10:53] <mpt__> but, don't let me stop you :-)
[10:53] <poningru> hehe
[10:55] <mpt__> anyway, Planet Ubuntu right now seems to be entirely news from 2005
[10:55] <poningru> hehe yeah
[10:55] <poningru> also can we add it to planet ubuntu?
[10:56] <mpt__> It has nothing to do with Planet Ubuntu...
[10:58] <poningru> ok well I have to go to sleep
[10:59] <poningru> night dude, thanks for lending me your ear
[11:13] <ajmitch> mpt__: planet ubuntu is broken due to livejournal screwing up its rss feeds :)
[11:28] <mpt__> ajmitch, every time I look at Planet Ubuntu it's broken for *some* reason
[11:44] <mdke> yes
[11:45] <mdke> but this time it's not planet's fault :)
[11:48] <jblack> mpt: Yeah. I gave up on planet last week after I caught it duplicating blog entries.
[11:49] <ajmitch> hey jblack
[11:50] <jblack> Hey buddy.
[11:51] <lifeless> jblack: that was livejournals fault
[11:52] <jblack> It was? I was referring to a blog posted on a drupal.
[11:52] <mpt__> "launchpad, rosetta, and malone are not proprietary, just unfinished and unreleased. the release milestones and features are available https://wiki.launchpad.canonical.com/ they are targeting a july 6th 1.0 release." -- someone on OSNews
[11:53] <mpt__> Just as well we don't mention what year that July 6th refers to, eh :-)
[11:53] <lifeless> jblack: hmm, I thought you had livejournal feeds
[11:53] <jblack> I think I tried just about everywhere but there. :)
[11:53] <jblack> I went from advogato to something to blogspot to finally drupal.
[11:56] <jblack> I'm happy with what I setup on the site with drupal.
[11:57] <jblack> Now there's entries by developer, by rcs, and all.
[11:57] <jblack> Tough I don't think there's feeds for all of them.
[12:37] <kiko> mpt__, that's an interesting quote right there
[12:37] <kiko> Mez, what was up?
[12:40] <jblack> kiko: Can I tell you a secret?
[12:40] <kiko> it depends
[12:40] <kiko> do I have to keep it a secret? :)
 don't tell anyone, but this super-silent super-mirror is creeping me out a little.
[12:41] <kiko> super-silent?
[12:41] <kiko> it could play the latest white stripes album every time a patch landed?
[12:42] <jblack> I think I might put in logging just to keep a closer eye on it.
[12:42] <kiko> oh
[12:42] <kiko> you updated the script
[12:42] <kiko> :)
[12:42] <kiko> I'm okay with you having it output information
[12:42] <kiko> just not tracebacks :)
[12:43] <jblack> How much output?
[12:44] <jblack> You don't mind plenty of output, as long as you know what it means?
[12:44] <jblack> kiko: Yeah, last week, while I was on vacation. :)
[12:44] <jblack> and then more when I got back from vacation, when I realized that it was quiet because postfix on my lappy was broken
 You don't mind plenty of output, as long as you know what it means?
[12:50] <kiko> right.
[12:50] <kiko> it can't be tracebacks.
[12:51] <jblack> So.. even if somebody made a bzr branch of the linux kernel, and the supermirror reported once every ten minutes for six hours that it couldn't get a lock because the previous version was still running....
[12:52] <jblack> (thats 60 emails, btw)
[01:15] <kiko> that's a lot of email indeed
[01:15] <kiko> maybe failed to acquire lock could be silent.. then again, a stale lock..
[01:15] <kiko> are you using contrib/glock.py
[01:15] <kiko> -- ?
[01:16] <jblack> No. I'm still using lockfile.
[01:17] <jblack> They're not stale locks. They're valied locks
[01:17] <jblack> The supermirror in this iteration doesn't support concurrancy in any form.
[01:17] <kiko> that's okay
[01:17] <jblack> Something that I'm keen to resolve, but don't have the time to do at the moment.
[01:18] <kiko> but if you have a stale lock and no email notifications...
[01:18] <kiko> I dunno. you should probably use contrib/glock.py
[01:18] <jblack> I don't imagine a situation in which I could.
[01:19] <jblack> The code looks something like  lock(); try: domirrorstuff(); finally: unlock()
[01:19] <kiko> locks stay around, you know?
[01:19] <kiko> if a -KILL is issued to that process, what happens?
[01:19] <jblack> It could if the machine went down, or if python segfaulted, or if it were killed, sure.
[01:19] <kiko> right.
[01:19] <kiko> which WILL happen in the lifetime of the SM a few times at least
[01:20] <jblack> Yup.
[01:20] <jblack> The new lockfile deals with staleness.
[01:20] <kiko> really now?
[01:20] <jblack> well, that's what I'm told by my boss.
[01:20] <kiko> you mean god?
[01:21] <jblack> well, bosses aren't infallible. They're just right until proven otherwise. :)
[01:23] <jblack> Either you're thinking really hard, wandered off, or are trying to come up with a nice way to tell me I'm dissillusioned. :)
[01:25] <kiko> neither
[01:25] <kiko> I am acquiring cocaine
[01:26] <jblack> Is that legal there?
[01:26] <jblack> I so need to move to brazil.
[01:30] <mpt_> Cocaine is the name of a babe, apparently
[01:31] <jblack> I still need to move to brazil. :)
[01:48] <kiko> what is this babe conversation
[01:49] <kiko> anyway
[01:49] <kiko> time for suicide bike ride
[02:10] <uws> jblack, kiko_suicide: jfyi, some applications store the current PID in the lockfile to check for staleness
[05:05] <jordi> kiko_suicide: DUDE
[05:05] <jordi> don't die just now.
[05:05] <jordi> you wanted m
[10:17] <jb-home> Bugzilla appears to not be read only: http://bugzilla.ubuntu.com/show_bug.cgi?id=18157
[10:17] <Ubugtu> Ubuntu bug 18157: "Make linux/agpgart.h usable from userspace" Product: Ubuntu, Component: linux-kernel-headers, Severity: normal, Assigned to<EMAIL_ADDRESS>Status: RESOLVED, Resolution: FIXED


[06:33] <darkxst> ricotz, does mutter need a soname bump to go along with mozjs bump?
[06:36] <ricotz> darkxst, no, it doesnt depend on mozjs in anyway
[06:37] <ricotz> afaics pitti pushed the needed rebuilds of gjs and gnome-shell
[06:37] <darkxst> yeh just saw that
[06:38] <ricotz> so this wily-proposed mess should get be sorted soon hopefully :)
[06:39] <ricotz> (at least for the most common subset of packages)
[06:48] <darkxst> ricotz, have you test theed mutter gl sync patches? I don't have an affected card here
[06:50] <ricotz> darkxst, sorry, no
[06:51] <ricotz> I mean I havent tested them, but I have a affected system
[06:58] <ricotz> darkxst, let's see how this goes https://launchpad.net/~ricotz/+archive/ubuntu/testing/+sourcepub/5292782/+listing-archive-extra
[14:53] <ricotz> darkxst, the nvidia fixes in mutter seems to work :)


[13:26] <BluesKaj> Hi all
 what is the difference between kubuntu and regular ubuntu to have a different support server apart from KDE?
[14:35] <Paavel_Daemon> Yo Guys!
[14:36] <Paavel_Daemon> Anybody there?
[14:44] <BluesKaj> Paavel_Daemon, yup :-)
[16:24] <gabriel_> hg
[17:33] <lijun> plugin
[17:33] <lijun> Sorry. Mistyped. Just testing Konversation. First time use it.


[15:56] <beisner> o/
[15:56]  * beisner prepares the chair
[15:59] <smoser> o/
[16:00] <coreycb> o/
[16:00] <gnuoy> o/
[16:00] <beisner> #startmeeting ubuntu-server-team
[16:00] <meetingology> Meeting started Tue Sep 30 16:00:42 2014 UTC.  The chair is beisner. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:00] <meetingology> Available commands: action commands idea info link nick
[16:01] <beisner> hello!
[16:01] <gnuoy> hi!
[16:01] <arges> o/
[16:01] <beisner> ok, all set.
[16:01] <beisner> #topic Review ACTION points from previous meeting
[16:02] <matsubara> o/
[16:03] <jamespage> o/
[16:03] <beisner> no action points from last wk
[16:03] <caribou> o/
[16:03] <smb> o/
[16:03] <beisner> other than the usual bp update reminders
[16:04] <beisner> #topic Utopic Development
[16:04] <beisner> #link https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule
[16:04] <beisner> so final beta & final beta freeze was last wk
[16:05] <beisner> next milestone in U release:  Oct 9  kernel freeze
[16:05] <beisner> any other points re: release schedule?
[16:05] <smoser> and we released beta of cloud images.  (http://cloud-images.ubuntu.com/releases/utopic/beta-2/)
[16:06] <smoser> well, we're in crunch time now.
[16:06] <beisner> great!  thanks smoser.
[16:06] <smoser> if you're aware of issues in ubuntu, now is the time to raise them to someone.
[16:06] <beisner> down to the wire indeed
[16:06] <beisner> speaking of...
[16:06] <beisner> #subtopic Release Bugs
[16:07] <beisner> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-u-tracking-bug-tasks.html#ubuntu-server
[16:07] <kickinz1> confirm pb with bcache needing a reboot to discard the caching device
[16:07] <beisner> kickinz1, is there a bug?
[16:08] <beisner> no critical bugs atm, woot.
[16:08] <beisner> several bugs unassigned, do we need to pin that down?
[16:09] <kickinz1> yes if you do a mistake when creating a bcache device (ie swapping backing and caching, wrong backing) it still creats a bad bcache device, but you cannnot control it unti you poweroff the machine, to re-create it...
[16:10] <kickinz1> I'll chat with rbasak to know who to send this to
[16:10] <beisner> ok let's make sure we get a big filed
[16:10] <beisner> rewinding a sec...  there was an action item.  "rbasak to review mysql-5.6 transition plans with ABI breaks with infinity"
[16:11] <beisner> rbasak appears to be offline
[16:11] <rbasak> o/
[16:12] <beisner> hi !
[16:12] <beisner> rbasak, anything to note on review mysql-5.6 transition / abi infinity action?
[16:12] <rbasak> We decided to defer the 5.6 move for this cycle.
[16:12] <beisner> ok thank you
[16:13] <rbasak> We felt it was too late given the ABI concerns.
[16:13] <beisner> any other bug issues to raise or discuss?
[16:13] <beisner> moving on then
[16:13] <beisner> #subtopic Blueprints
[16:13] <beisner> #link http://status.ubuntu.com/ubuntu-u/group/topic-u-server.html
[16:15] <beisner> as mentioned, it's crunch time.  please be sure your blueprints are updated.
[16:16] <beisner> #action all to review blueprint work items before next weeks meeting
[16:16] <meetingology> ACTION: all to review blueprint work items before next weeks meeting
[16:16] <beisner> #topic Server & Cloud Bugs (caribou)
[16:16] <caribou> Hi, everything is good on my side, thanks
[16:16] <beisner> hi caribou
[16:16] <beisner> ack thank you
[16:17] <beisner> #topic Weekly Updates & Questions for the QA Team (psivaa)
[16:18] <beisner> I see a lot of activity in qa iso tracker, looks like test cases are getting the usual late-cycle manual runs.
[16:18] <beisner> psivaa, anything else to note?
[16:18] <beisner> on to kernel...
[16:18] <beisner> #topic Weekly Updates & Questions for the Kernel Team (smb, sforshee, arges)
[16:18] <smb> Hi. One thing I seem to hit in Utopic is that libvirt and xen init seem to be more affected to race against each other on boot up. Though I need to get more data there.  Those attack my senses for a nice login on vt1...  :-P That's all. Questions?
[16:19] <beisner> smb is always sooo fast to respond!
[16:19]  * smb tries to be prepared
[16:19] <hallyn> he has an expect script
[16:19] <smb> oh yeah, should write a chat bot for myself
[16:19] <smb> :)
[16:20] <beisner> is this the real smb? [-.-]
[16:20] <smb> how do you think about the real smb?
[16:21] <beisner> does this smb bot have #vote?
[16:21] <beisner> ok anyway, any discussion re: libvirt xen init issue?
[16:21] <smb> beisner, no just for info
[16:22] <smb> I look into it
[16:22] <beisner> thanks smb
[16:22] <beisner> #topic Ubuntu Server Team Events
[16:22] <beisner> i don't think there are any to announce.
[16:22] <beisner> #topic Open Discussion
[16:23] <beisner> (quiet in here)
[16:23]  * beisner checks network connection
[16:23] <beisner> ok, i think we can all go back to crunch time.
[16:23] <beisner> #topic Announce next meeting date and time
[16:23] <beisner> +1 week, same place, same time.
[16:24] <beisner> thank you all
[16:24] <beisner> #endmeeting
[16:24] <meetingology> Meeting ended Tue Sep 30 16:24:13 2014 UTC.
[16:24] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-09-30-16.00.moin.txt
[16:24] <caribou> beisner: thanks
[16:24] <kickinz1> thanks beisner
[16:24] <beisner> lutostag is up next week
[16:27] <coreycb> thanks beisner !
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Sep 30 17:00:39 2014 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: action commands idea info link nick
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Utopic
[17:00] <ppisati> o/
[17:00] <arges> o/
[17:00] <kamal> o/
[17:01] <sforshee> o/
[17:01] <smb> o/
[17:01] <bjf> o/
[17:01] <chiluk> o/
[17:01] <henrix> o/
[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] Status: Utopic Development Kernel (ogasawara)
[17:02] <jsalisbury> The Utopic kernel remainds rebased on the v3.16.3 upstream stable
[17:02] <jsalisbury> kernel.  The latest uploaded to the archive is 3.16.0-19.26.  Please
[17:02] <jsalisbury> test and let us know your results.
[17:02] <jsalisbury> Also, Utopic Kernel Freeze is next week on Thurs Oct 9.  Any patches
[17:02] <jsalisbury> submitted after kernel freeze are subject to our Ubuntu kernel SRU
[17:02] <jsalisbury> policy.
[17:02] <jsalisbury> -----
[17:02] <jsalisbury> Important upcoming dates:
[17:02] <jsalisbury> [LINK] https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule
[17:02] <jsalisbury> Thurs Oct  9 - Utopic Kernel Freeze (~1 week away)
[17:02] <jsalisbury> Thurs Oct 16 - Utopic Final Freeze (~2 weeks away)
[17:03] <jsalisbury> Thurs Oct 23 - Utopic 14.10 Release (~3 weeks away)
[17:03] <jsalisbury> ..
[17:03] <jsalisbury> [TOPIC] Status: CVE's
[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 - Trusty/Precise/Lucid (bjf/henrix/kamal/arges)
[17:03] <bjf> Status for the main kernels, until today (Sept. 30):
[17:03] <bjf>   *   Lucid - Verification and Testing
[17:03] <bjf>   * Precise - Verification and Testing
[17:03] <bjf>   *  Trusty - Verification and Testing
[17:03] <bjf>
[17:03] <bjf> Current opened tracking bugs details:
[17:03] <bjf>   * http://kernel.ubuntu.com/sru/kernel-sru-workflow.html
[17:03] <bjf> For SRUs, SRU report is a good source of information:
[17:03] <bjf>   * http://kernel.ubuntu.com/sru/sru-report.html
[17:03] <bjf>
[17:03] <bjf>
[17:03] <bjf> Schedule:
[17:03] <bjf>
[17:03] <bjf> cycle: 19-Sep through 11-Oct
[17:03] <bjf> [17:03] <bjf>          19-Sep   Last day for kernel commits for this cycle
[17:03] <bjf> 21-Sep - 27-Sep   Kernel prep week.
[17:03] <bjf> 28-Sep - 04-Oct   Bug verification & Regression testing.
[17:03] <bjf> 05-Oct - 11-Oct   Regression testing & Release to -updates.
[17:03] <bjf>
[17:03] <bjf> ..
[17:04] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:05] <jsalisbury> Thanks everyone
[17:05] <jsalisbury> #endmeeting
[17:05] <meetingology> Meeting ended Tue Sep 30 17:05:09 2014 UTC.
[17:05] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-09-30-17.00.moin.txt
[17:05] <kamal> thanks jsalisbury
[17:05] <arges> good job joe