[12:35] <jenda> nevermind, fixed
[12:53] <mpt> (From the "meanwhile in other bugtrackers" department: RESOLVED LATER and RESOLVED REMIND have just been removed from Bugzilla CVS.)
[12:55] <Ubugtu> New bug: #58776 in malone "clicking on 'file a bug against foo' link leads to 'foo does not exist in Dapper' error message" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58776
[01:01] <mpt> Goooooooooooooooood morning Launchpadders!
[01:47] <jelmer> mpt: It's starting to feel like Ground Hog Day now you're doing that daily ;-)
[01:49] <LarstiQ> gooooood night! ;)
[01:56] <mpt> ~ They say that love won't pay the rent ~ Before it's earned, our money's always spent ... ~
[02:00] <Ubugtu> New bug: #58784 in blueprint "Spec page refers to non-existent "Specifications in grey"" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58784
[03:26] <jamesh> mpt: have you seen this spec? https://features.launchpad.net/distros/ubuntu/+spec/internet-sharing
[03:33] <mpt> jamesh, no I hadn't. That looks pretty ... interesting.
[03:33] <jamesh> mpt: I wonder if the person thought "this isn't a bug, but rather a feature request ..."
[03:34] <mpt> I wasn't the one who thought the spec tracker should be a separate application :-P
[03:35] <Ubugtu> New bug: #58791 in malone "+subscribe page contains non-useful radiobutton" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58791
[03:38] <mpt> jamesh, see also https://launchpad.canonical.com/MaloneAndBlueprintIntegration
[03:40] <Cogito_ergo_sum> hi good night
[03:45] <mpt> ... and good luck
[05:05] <mpt> jamesh: ping
[05:05] <jamesh> mpt: pong
[05:07] <mpt> jamesh: https://devpad.canonical.com/~andrew/paste/fileRYXA42.html
[05:07] <mpt> Any idea what's going on here?
[05:08] <jamesh> mpt: you are using the most recent pqm-submit plugin?
[05:10] <mpt> revno 22
[05:10] <mpt> parent branch: http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/bzr-0.8/
[05:11] <mpt> hmm, is that bad when trying to use it with bzr 1.0ish?
[05:11] <jamesh> yes
[05:11] <jamesh> try this:
[05:11] <jamesh> cd ~/.bazaar/plugins/pqm-submit
[05:11] <jamesh> bzr pull --overwrite http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel
[05:12] <jamesh> to get the updated version
[05:12] <jamesh> (this version also has smtp auth support, btw)
[05:12] <mpt> great!
[05:12] <jamesh> you can set smtp_username and smtp_password in ~/.bazaar/bazaar.conf and it'll do the right thing
[05:12] <mpt> aha, I have a conflict from my manual ayuth change
[05:13] <jamesh> bzr revert then.
[05:13] <mpt> yeah
[05:14] <mpt> ok, now bzr pull --overwrite http://bazaar.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel says "0 revision(s) pulled"
[05:14] <jamesh> there are 22 revisions on both the bzr-0.8 and devel branches
[05:15] <mpt> but bzr info is still pointing at the wrong parent branch
[05:15] <jamesh> so the difference in length of revision history is 0
[05:15] <jamesh> ah.
[05:15] <jamesh> "bzr pull --remember http://..." should fix that
[05:16] <mpt> 0 revision(s) pulled...
[05:17] <mpt> but now it has the correct parent
[05:17] <jamesh> configure your SMTP username/password in ~/.bazaar/bazaar.conf and retry the pqm-submit command
[05:18] <mpt> bzr: ERROR: No PQM submission address specified in configuration
[05:18] <jamesh> argh.  That's the shadowing problem again ;(
[05:18] <mpt> the what? :-)
[05:20] <jamesh> one section of ~/.bazaar/locations.conf shadowing settings from another section
[05:22] <mpt> The second line of locations.conf is "pqm_email = Canonical PQM <pqm@pqm.ubuntu.com>"
[05:22] <mpt> There are no other pqm_email lines
[05:23] <mpt> just various branches with push_location lines, and one branch with both a push_location and a pqm_branch
[05:26] <mpt> pqm-submit doesn't seem to let me specify the address explicitly
[05:29] <mpt> Removing the section for this branch from locations.conf seems to work (though it's going so slowly, it hasn't gotten up to asking for my password yet)
[05:30] <mpt> ok, it didn't work after all. It tried to mail mpt@canonical.com instead of mailing pqm@pqm.ubuntu.com
[05:31] <mpt> (Host or domain name not found. Name service error for name=canonical.com type=MX: Host not found, try again)
[05:39] <mpt> hurrah, copying all the config stuff from the global section to that branch's section worked
[06:40] <SteveA> morning
[07:08] <jamesh> stub: ping?
[07:12] <stub> jamesh: pong
[07:13] <jamesh> stub: last week I put together a script to clean up the [https://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/NNNN]  text that was inserted into the comments of bugs imported from bugzilla.ubuntu.com
[07:13] <jamesh> stub: I was wondering if you could look over it and maybe run it in production this week if it looks okay
[07:14] <jamesh> I did a test run on demo.launchpad.net which seemed to go okay
[07:14] <stub> ok. Still going through my email from last week so haven't got to that one yet.
[07:15] <Ubugtu> New bug: #58806 in blueprint "Specification page contains unexplained "(n days)" text" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58806
[07:16] <jamesh> stub: the code is here: https://devpad.canonical.com/~jamesh/fixup-bug-references -- it needs to be run as a user that can update the MessageChunk table
[07:17] <stub> jamesh: Please email me the details if you haven't already so I don't forget by the time I've cleaned out my pile
[07:19] <jamesh> stub: done.  the thread is "Rewriting bug numbers and dupe comments"
[07:19] <stub> k
[07:20] <stub> (302 in inbox to go, then the mailing lists :-( )
[07:21] <jamesh> stub: second thing: would it be possible to get another product-release-finder run done on staging?  I believe the problem we ran into last time has been fixed.
[07:21] <stub> Last I left it it was scheduled to run daily
[07:22] <jamesh> hmm
[07:23] <jamesh> stub: the product-release-finder code keeps a cache of URLs that it has previously processed in /var/tmp/productreleasefinder, which is probably why it didn't look like it was doing anything
[07:24] <jamesh> stub: would it be possible to blow that cache away so we can see how it runs now?
[07:24] <stub> jamesh: It died last night with an ftp error
[07:25] <jamesh> I've got a branch in the review queue to get rid of the cache code, but for now it would prevent the releases from being created after a DB refresh
[07:25] <stub> jamesh: https://devpad.canonical.com/~andrew/paste/fileRtP8Iz.html
[07:26] <stub> Yer - only turned on ftp_proxy on production
[07:26] <jamesh> stub: that indicates that ftp_proxy wasn'
[07:26] <jamesh> t set
[07:27] <SteveA> stub: morning
[07:28] <SteveA> stub: in the launchpad meeting, in the "production and staging" section, people listed things they particularly want to get into production this week
[07:29] <stub> jamesh: it is rerunning now anyway
[07:29] <jamesh> stub: with the cache blown away?
[07:29] <stub> jamesh: yes
[07:29] <jamesh> thanks
[07:31] <cbx33> Is it possible to send a mail to everyone in a LP group?
[07:31] <stub> jamesh: I suspect we should be storing this cache in the Librarian, as we don't really want to download a few gb of data every time the server is rebooted, or /var/tmp otherwise cleaned.
[07:32] <jamesh> stub: I'm getting rid of the cache completely
[07:32] <stub> excellent
[07:32] <jamesh> stub: the database contains all the state needed to handle repeated runs, so the cache just adds a point of failure
[07:32] <SteveA> stub: are you planning to do a rollout this week?  if so, please mail the launchpad list to say what will happen.
[07:32] <stub> SteveA: I have no idea yet. I'm still going through my backlog, and probably will be for few hours
[07:32] <SteveA> stub: okay
[07:33] <SteveA> mpt: have you looked at the meeting summary for thursday yet?
[07:33] <jamesh> it'd be nice to get a rollout done this week -- there's been lots of fixes since the last one
[07:38] <lifeless> stub: welcome back
[07:38] <stub> :-)
[08:14] <stub> Lunch
[09:06] <SteveA> jamesh: hi, around?
[09:06] <jamesh> SteveA: yeah
[09:06] <SteveA> jamesh: got a few minutes for a chat with me and mpool about some bzr infrastructure work?
[09:06] <jamesh> SteveA: sure.
[09:32] <mpt> SteveA, looked at it? I wrote it. Or are you referring to a different meeting?
[09:32] <SteveA> mpt: if you wrote it, that's great.  I want to point stub at the production/staging section, so that he can know what was discussed, and what code people want to get landed
[09:33] <mpt> ah, but I forgot to update MeetingAgenda
[09:33] <mpt> I'll do that now
[09:34] <SteveA> thanks
[09:34] <SteveA> and please mail stub too
[09:36] <mpt> ok
[09:38] <mpt> done
[09:39] <mpt> and done
[09:51] <jamesh> stub: how's the product-release-finder run going?
[09:52] <stub> Hmm.... go boom
[09:52] <lifeless> :(
[09:53] <stub> https://devpad.canonical.com/~andrew/paste/file35Ccxs.html
[09:54] <lifeless> blech
[09:54] <lifeless> encoding
[09:54] <lifeless> and on a 503 error ? wtf
[09:55] <lifeless> there seem to be two errors mentions
[09:56] <Burgundavia> SteveA: can we get a user to change his wiki name if it is possibly misleading? (ubuntupr)
[09:56] <carlos> morning
[09:58] <jamesh> lifeless: the 503 error is probably an earlier request.
[09:58] <stub> I agree with James
[09:58] <jordi> hi carlos
[09:59] <lifeless> kk
[09:59] <stub> There are other 503's earlier in the output handled just fine (although we really shouldn't be logging them as tracebacks since they are expected)
[09:59] <jamesh> the walker class should be generating log messages
[09:59] <jamesh> I wonder why it isn't.
[09:59] <stub> DEBUG level? I didn't run it with -v
[10:00] <jamesh> it should be generating info level messages
[10:00] <jamesh> looks like it isn't passing the log object down that far.
[10:02] <stub> There is a global that can be used (although it was naughty to do it that way)
[10:02] <stub> (Made unit tests a pita)
[10:02] <jamesh> I'll look at getting the walker logging working
[10:03] <jamesh> and I suppose we should handle BeautifulSoup parse failures better too
[10:03] <stub> I thought BeautifulSoup was supposed to handle badly formatted soup
[10:04] <jamesh> I wonder if we can get at the squid logs to get an idea of what it accessed last?
[10:05] <stub> Looks like encoded strings are leaking into it rather than Unicode (or whatever encoding BS is expecting?)
[10:05] <jamesh> given that the log doesn't include that info
[10:06] <lifeless> oh now thats a cute idea
[10:06] <stub> #canonical-sysadmin might be able to help here
[10:06] <stub> c/here/there/
[10:06] <lifeless> create a function dynamically called the name of the thing it is about to try
[10:06] <lifeless> then you dont need log barf to read the traceback usefully ;)
[10:07] <lifeless> more sensibly, how about a top level catch-all try:except: print; raise
[10:07] <lifeless> around or in handleProduct
[10:07] <jamesh> lifeless: the traceback formatter from zope takes a different approach: if any frame has a local called __traceback_info__, it is pretty printed along wiht the frame in the traceback
[10:07] <lifeless> jamesh: thats nice
[10:08] <lifeless> back in 1 hr
[10:08] <jamesh> stub: what machine was the script running on?
[10:08] <stub> gangotri
[10:16] <stub> mpt: Your bug queries on the mailing list (in the preventing duplicates thread) - do you want results for open bugs or all bugs?
[10:17] <stub> Actually, needs to be all bugs or else the later ones regarding duplicates won't make sense (since duplicate bugs are never closed atm)
[10:28] <SteveA> hi ddaa 
[10:28] <SteveA> do we have a meeting today?
[10:28] <ddaa> hi SteveA
[10:28] <ddaa> Meeting in 92 mins
[10:28] <SteveA> thanks
[10:29] <ddaa> SteveA: got a very detailed agenda on BazaarMeetingAgenda if you care to look
[10:29] <SteveA> yes
[10:29] <SteveA> i do
[10:29] <SteveA> Burgundavia: hi
[10:30] <Burgundavia> SteveA: did you see my comment?
[10:30] <SteveA> Burgundavia: I'm sure we *can* change someone's wiki name.  I think it would be better to ask them to change it themselves first.
[10:31] <SteveA> there's also the issue of who says we *ought* to change it.  the ubuntu wiki is governed by the CoC and the CC, I think
[10:31] <SteveA> so, while I have technical power, I don't have the "right" to do anything so long as it isn't causing a technical problem.
[10:32] <SteveA> is there someone beneath the CC who is responsible for encouraging good conduct on the wikis?
[10:34] <SteveA> ddaa: where can I read the agenda?
[10:34] <SteveA> stub: ever looked at xapian?  I was talking with alan runyan about it at the weekend.
[10:35] <ddaa> https://launchpad.canonical.com/BazaarMeetingAgenda
[10:35] <stub> SteveA: Nope. I don't even know what it is
[10:35] <ddaa> "Meeting plan" section is the outline for the meeting
[10:35] <ddaa> that is all the bit I plan to copy-paste
[10:35] <SteveA> stub: some kind of hot shit free software text searching system.
[10:35] <SteveA> http://www.xapian.org/
[10:36] <ddaa> and I will use that as template for the summary, I'll try to keep doing it that way in the future, as that will force me to keep the agenda up to date
[10:36] <SteveA> stub: alan does various work with the developers, so if this is at all interesting for us, we can talk with people.
[10:36] <SteveA> ddaa: reading
[10:37] <SteveA> stub: alan says the tech is great.  the bindings are gross.
[10:37] <Burgundavia> SteveA: apparently, it is nobody that is listed as his real name in LP
[10:37] <ddaa> stub: welcome back
[10:38] <SteveA> Burgundavia: what's the launchpad page for this person?
[10:39] <Burgundavia> SteveA: I cannot find it, because none of the LP pages for  Carlos Rivera has a wikiname of UbuntuPR
[10:39] <ddaa> stub: is rollout planned for today?
[10:39] <Burgundavia> and there are 6 hits for Carlos Rivera
[10:43] <SteveA> Burgundavia: I see no wikiname of UbuntuPR in the database.
[10:44] <Burgundavia> https://wiki.ubuntu.com/UbuntuPR
[10:45] <SteveA> there are lots of names containing the text "ubuntu"
[10:45] <Burgundavia> indeed
[10:46] <SteveA> Burgundavia: https://launchpad.net/people/crrivera
[10:46] <SteveA> aha
[10:47] <Burgundavia> hmm, I will email him
[10:47] <Burgundavia> thanks for the find
[10:47] <Burgundavia> I wish launchpad.net/foo would do a search for foo
[10:47] <Burgundavia> much like packages.d.o or .u.c does
[10:47] <SteveA> on the staging database, his wiki name is Crrivera
[10:47] <SteveA> so, this must be a recent change
[10:48] <Burgundavia> the page for his name just go created
[10:49] <SteveA> there is a search form on launchpad.net/people/
[10:49] <SteveA> it doesn't search wikinames right now
[10:49] <SteveA> it could do though.  file a bug if you want such a feature.
[10:52] <stub> SteveA: I think I remember this now - Richard Jones was using it with Roundup and he seemed to like it.
[10:52] <stub> SteveA: Not yet suitable for us though as we need to glue it into PostgreSQL
[10:54] <stub> SteveA: Seems to offer the same feature set as tsearch2, with the addition of wildcard searches. No idea if they use some magic index for fast wildcard searching or if it would be with similar restrictions to PostgreSQL LIKE
[10:56] <ddaa> stub: is rollout planned for today?
[10:56] <stub> ddaa: No. And I'm not sure about tomorrow yet (still clearing intrays)
[11:12] <sivang> morning
[11:26] <jamesh> stub/lifeless: I've got the problem page that tripped up product-release-finder will see if I can reproduce it
[11:42] <ddaa> whaaaa! gimme my crack of the week! gimme! gimme!
[11:43] <jamesh> I blame Norman Walsh
[11:43] <ddaa> jamesh: how snob, why don't you blame Daniel Bernstein like everybody else?
[11:44] <jamesh> ddaa: the page was http://www.docbook.org/xml/
[11:44] <jamesh> (although the real problem was BeautifulSoup not handling the UTF-8 on that page)
[11:45] <Ubugtu> New bug: #58835 in soyuz "Debian Installer garbage collection not working?" [High,Confirmed]  http://launchpad.net/bugs/58835
[11:46] <jamesh> hmm looks like the problem is the way PRF is using BeautifulSoup
[11:47] <ddaa> PRF, you mean URTF?
[11:47] <ddaa> unless you mean Dyson maybe?
[11:47] <jamesh> product-release-finder
[11:48] <ddaa> thanks for demonstrating that anything longer than two words ends up as an obscure acronym :)
[11:49] <stub> Indeed. Dyson is much easier to remember, and its name need not change as the scope of its tasks changes over time ;)
[11:52] <carlos> jamesh: hi, how's going my code review? I would like to get it cherrypicked this week so we approve a bunch of entries automatically as soon as possible...
[11:57] <jamesh> carlos: not yet done.  I'll make sure it is done by tomorrow
[11:57] <carlos> jamesh: thank you
[11:57] <carlos> did you started it?
[11:58] <carlos> I have a small trivial change related to automatic approvals and if you didn't start I would prefer to add it there instead of using [trivial] 
[11:58] <carlos> it doesn't affect directly to the changes already done ther
[11:58] <carlos> there
[11:58] <ddaa> lifeless: -> #launcphad-meeting
[11:58] <jamesh> carlos: just add it to the branch.  I haven't done that much on the branch yet.
[11:58] <carlos> ok
[11:59] <carlos> jamesh: thanks
[12:07] <stub> What does PAS stand for again?
[12:08] <lifeless> piece a shit
[12:08] <stub> That makes sense in this context, but I don't think it is correct
[12:09] <malcc> Packages arch-specific
[12:09] <stub> ta
[12:38] <lifeless> review meeting in 22
[12:45] <lifeless> review meeting in 15
[12:53] <SteveA> it's so nice our RCS isnt' called "arch" anymore, as "PAS" would be doubly confusing
[12:55] <lifeless> review meeting in 5
[01:01] <SteveA> hmm... massive rain shower
[01:01] <lifeless> review meeting time
[01:01] <lifeless> whos here ?
[01:01] <SteveA> hello.  iamhere
[01:02] <BjornT> me
[01:02] <jamesh> me
[01:02] <lifeless> hi guys
[01:02] <lifeless> next meeting time - sept 11
[01:03] <lifeless> this time
[01:03] <SteveA> +1
[01:03] <lifeless> ok
[01:04] <lifeless>  * queue size
[01:04] <lifeless>  * other items
[01:04] <lifeless> queue has 5 items in it - oldest is salgado & 9 days
[01:04] <lifeless> all the rest are 3 or less, which is inside our service level
[01:05] <lifeless> BjornT: can you nag salgado, 9 days for a 77 line review is - excessive - and your time zones should cross
[01:05] <BjornT> lifeless: yeah, i'll send an email to him, reminding him that he should check his queue daily
[01:06] <lifeless> BjornT: hmm, was hoping more personal ;)
[01:06] <lifeless> BjornT: I'll send such a mail after this meeting
[01:06] <lifeless> if you see him on IRC though, please nag in person
[01:06] <BjornT> ok
[01:07] <lifeless> andrew put up a proposal
[01:07] <lifeless>  * what to do about merges that aren't properly reviewed?  (AndrewBennetts)
[01:07] <lifeless>    Seeing as I'm on leave this week, here's my thoughts for discussion, ready for pasting into the channel: {{{
 Some recent merges concerned me a little:
 r3995 was merged without review by the review team [r=cprov,malcc] 
 r4001 was merged with [rs=elmo]  (and built on the changes in r3995).
 I did an unsolicited post-merge review of 4001 (and some of 3995), and found a bunch of issues.  Nothing terrible, but certainly the quality was less than I'd approve as-is.  I'd rate it about merge-conditional.
 I propose that someone (Robert?) checks the commit list daily, and assigns "trivial", rubber-stamped, and other anomalous merges to reviewers for post-merge review, much like the pre-merge review queue.  It's easy to run "bzr diff -r 1000..1001 | less", so we wouldn't need to pre-generate diffs.
 In theory, these should be rare enough and/or small enough that it shouldn't add much to the review load, but it might help keep quality from slipping.
 What do people think?
[01:07] <lifeless> }}}
[01:08] <jamesh> Sounds like a good idea (and something we've discussed in the past)
[01:08] <SteveA> i'm in favour of it.  i'd also like to see some progress on getting diffstats and links in the mails from pqm
[01:08] <SteveA> and i'm glad spiv has been doing such reviews
[01:09] <lifeless> I think its a good idea
[01:09] <BjornT> sounds good to me as well.
[01:09] <lifeless> I'm not sure how much overhead it will take
[01:09] <SteveA> malcc: would you comment on this?  was there a particular reason that r3995 was not reviewed by the review team?
[01:09] <lifeless> both on reviewers for the additional reviews, and for the assigner to ensure they catch everything
[01:09] <jamesh> does the fact that people are putting these large changes through as trivial (or not reviewed by a review team member) indicate problems with our process?
[01:10] <malcc> SteveA: kiko asked me and Celso for our thoughts on the patch, which we provided, then he went ahead and merged with that r=
[01:10] <SteveA> hi cprov 
[01:10] <cprov> SteveA: hi
[01:10] <malcc> SteveA: I wasn't sure exactly what the procedure was, so I didn't know if I should be objecting or not
[01:10] <Ubugtu> New bug: #58842 in soyuz "sync-source doesn't understand pockets (eg. -proposed)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58842
[01:10] <lifeless> malcc: you should start with PreMergeReviews and read from there
[01:10] <SteveA> so, the code was by kiko, with some review from malcc and cprov?
[01:11] <lifeless> malcc: the whole process is documented :)
[01:11] <malcc> lifeless: Thanks
[01:11] <malcc> SteveA: Yes
[01:11] <SteveA> was there a reason that this code needed to land in a hurry?
[01:11] <SteveA> like, urgent fixes to get cherrypicked?
[01:12] <jamesh> seems a bit weird given we didn't have a rollout scheduled last wek
[01:12] <jamesh> week
[01:12] <malcc> SteveA: No. In fact the landings during the sprint have led to a situation where rocketfuel is effectively undeployable for Soyuz on drescher at the moment, until we finish the testing we've started since the sprint
[01:12] <malcc> SteveA: As far as I could tell, kiko was just in a hurry and being kiko
[01:12] <SteveA> you mean, you're running non RF stuff in production?
[01:12] <lifeless> heres what I propose - we try spics suggestion for 1 week. At the end of it, we gather reviewers feelings on those reviews, and mine on the overhead of generating the reviews to do
[01:13] <lifeless> *spivs* 
[01:13] <malcc> SteveA: We're running an older rocketfuel in production, with some (also rocketfuel) cherrypicks
[01:13] <lifeless> theres some statistical principle that suggests the unreviewed merges spiv looked like are more likely to be typical than atypical
[01:14] <SteveA> I see.  so, careful soyuz updates until you finish the testing and associated code.
[01:14] <lifeless> SteveA: soyuz gets special treatment on rollouts 
[01:14] <SteveA> I think in this case, kiko considered himself the representation from the review team on that branch
[01:15] <SteveA> but, I think seeing as kiko also wrote the code, that that's not sufficient oversight to get consistent quality in the code
[01:15] <lifeless> SteveA: as he wrote the patch, our current protocol excludes him from that role
[01:15] <SteveA> but, let's ask kiko about it later
[01:15] <lifeless> and the results that spiv found correlate to the oversight thing you are saying there
[01:15] <lifeless> anyhow, I dont think that this one patch is exceptional
[01:16] <lifeless> which is my point - understanding this one matters, but trialling post-merge-reviews of trivial and rs merges is worth doing
[01:16] <SteveA> +1 to your proposal of trying spiv's proposal for 1 week
[01:16] <lifeless> *regardless* of the genesis of the soyuz patch
[01:17] <lifeless> jamesh: I dont know if our process has problems
[01:17] <lifeless> jamesh: but I think anything other than mandatory reviews will get occasional abuses
[01:17] <malcc> Incidentally, would someone be kind enough to tell me off for allowing my name in r= when I'm not a reviewer? This way, if I'm asked to do this again, I'll be being honest when I say I got slapped for it last time :)
[01:17] <BjornT> lifeless: +1 to trying spiv's suggestion
[01:17] <SteveA> malcc: there are situations where a domain expert will review, and that can be noted.
[01:17] <lifeless> malcc: I dont think you need telling off
[01:18] <jamesh> lifeless: occasionally the queue gets overloaded leading to longer review times, which'd encourage some people to try and bypass it
[01:18] <SteveA> the point is, there was no member of the code review team in there
[01:18] <lifeless> malcc: you *did* a review.
[01:18] <lifeless> malcc: but what we would have wanted there was [r=spiv, r=malcc, vc=bjorn]  ...
[01:18] <lifeless> or some such
[01:18] <SteveA> vc?
[01:18] <lifeless> voice call, cant remember the abbreviation
[01:19] <SteveA> very cool?
[01:19] <SteveA> p=
[01:19] <jamesh> p=
[01:19] <lifeless> sucks to be me eh?
[01:19] <lifeless>  * other business
[01:20] <jamesh> spiv has a few very old branches in merge-conditional.  I guess that's not really a review team problem though
[01:21] <lifeless> its worth us putting some pressure on folk, but no, its definately those peoples problem, according to the process documentation
[01:21] <lifeless> 'you are responsible for getting your branch through the review process'
[01:22] <lifeless> we seem to be idling, so
[01:22] <lifeless>  * other business ?
[01:22] <BjornT> nothing from me
[01:22] <SteveA> no
[01:22] <jamesh> no
[01:22] <lifeless> meeting over, kthx
[01:33] <sivang> any idea someone how I can reach Kinnison ?
[01:34] <sivang> if anybody has his phone number, could you please PM me?
[01:45] <Ubugtu> New bug: #58847 in launchpad "product-release-finder HTTPWalker " [Untriaged,Confirmed]  http://launchpad.net/bugs/58847
[02:48] <stub> malcc: Should I update drescher's code during tomorrows roll out? Or leave it with you and cprov?
[02:48] <cprov> stub: we will need to do it later
[02:49] <stub> ok. I'll leave it with you too
[02:49] <stub> (bit early for you cprov, isn't it?)
[02:49] <cprov> stub: nop, almost 10 AM here 
[02:49] <stub> Bit late for me then ;)
[02:50] <cprov> stub: I guess so ;)
[03:03] <carlos> see you!
[03:31] <Ubugtu> New bug: #58766 in ubiquity "Ubuntu Installer Crash" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58766
[05:00] <SteveA> hi kiko
[05:00] <SteveA> how's it going?
[05:19] <kiko> SteveA, going super. how's it going up north?
[05:32] <kiko> hey malcc how's it going?
[05:33] <malcc> kiko: Going well, I was just preparing an email to the launchpad list updating the status of the soyuz system test stuff
[05:33] <kiko> ah, mind-reader
[05:35] <Keybuk> ddaa: ping?
[05:37] <Keybuk> ddaa: unping
[05:37] <ddaa> Keybuk: you're welcome
[05:38] <Keybuk> ddaa: no worries
[05:48] <kiko> ddaa, Keybuk: what is product-release-finder [going to be]  used for?
[05:49] <ddaa> It will automatically create Release objects with associated tarball by looking into the tarball locations specified in series/+source
[05:49] <jamesh> kiko: it is all part of the master plan
[05:50] <Keybuk> what's product-release-filnder ?
[05:50] <ddaa> it is related to things like NoSourcePackage, and 
[05:50] <ddaa> Keybuk: the new name for Dyson
[05:50] <Ubug2> New bug: #58881 in launchpad-cal "Accessing /+calendar/+subscriptions without logging in crashes" [Low,Confirmed]  http://launchpad.net/bugs/58881
[05:50] <ddaa> ... and relating vcs-imports to package imports (sourcerer)
[05:50] <Keybuk> oh right
[05:51] <Keybuk> so yes, it scans FTP sites and downloads tarballs
[05:51] <ddaa> kiko: old stuff which was first talked about two years ago
[05:51] <jamesh> Keybuk: we've almost got it working too ...
[05:51] <Keybuk> registers the ProductRelease records and the tarballs in the Librarian
[05:51] <Keybuk> so they can be later imported into bzr
[05:53] <kiko> salgado, can you explain the change in r3957 in layman's terms?
[05:54] <kiko> gotcha.
[05:54] <kiko> thanks jamesh, Keybuk, daa
[05:54] <kiko> ddaa.
[05:57] <salgado> kiko, ProberFactory had a deferred attribute and one callsite was poking with it, causing the callbacks to be called in the wrong order, in some cases.  I fixed the bug, renamed deferred to _deferred and left a comment explaining why it needs to be private
[05:57] <kiko> salgado, what does it do in practice though?
[05:59] <salgado> in practice it suppresses the AlreadyCalledErrors you've seen on the output of nighly.sh. :)
[05:59] <kiko> so... "A bug that caused mirror probes to be issued in an inconsistent order was fixed."?
[06:00] <salgado> not the probes themselves, as they don't need to happen in a specific order
[06:01] <kiko> what then? the probe handlers?
[06:01] <salgado> a bug that caused the callback chain of the mirror prober to be in the wrong order
[06:01] <kiko> right.
[06:15] <Ubug2> New bug: #58887 in launchpad-bazaar "Rank branches by heat" [Wishlist,Confirmed]  http://launchpad.net/bugs/58887
[06:24] <kiko> BjornT, ping?
[06:24] <ddaa> Seeking feedback on https://launchpad.net/products/launchpad-bazaar/+bug/58889
[06:24] <Ubugtu> Malone bug 58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [Medium,Confirmed]  
[06:25] <Ubugtu> New bug: #58888 in soyuz "Death row processing needs to be added to cron.daily" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58888
[06:29] <kiko> malcc, filed that bug ^^^
[06:29] <kiko> ddaa, that doesn't sound bad at all
[06:30] <Ubugtu> New bug: #58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [Medium,Confirmed]  http://launchpad.net/bugs/58889
[06:33] <BjornT> kiko: pong?
[06:33] <kiko> BjornT, I sent you email, fine to reply there
[06:33] <BjornT> ok
[07:57] <kiko-fud> is staging bonked? carlos?
[07:58] <carlos> kiko-fud: let me check
[08:00] <carlos> hmmm
[08:01] <carlos> kiko-fud: it's the language pack export... a full Edgy export takes a lot of time...
[08:01] <kiko-fud> carlos, can you please request a box for you?
[08:01] <kiko-fud> we can't have language packs halt systems for other people all the time.
[08:01] <carlos> as a workaround, yes
[08:01] <carlos> I should schedule some time to improve its performance
[08:02] <carlos> stub told me about using production server
[08:02] <carlos> with a mirror
[08:03] <carlos> kiko-fud: I will talk with Stuart tomorrow again about it
[08:03] <kiko-fud> carlos, thanks.
[08:04] <carlos> np
[08:43] <kiko> ddaa, do branches now have whiteboards?
[08:55] <kiko> BjornT, did you make any progress on attaching-files-to-bugs-through-email?
[08:57] <BjornT> kiko: no, other things came up. i can do it this week, though. you were ok with attaching files via unsigned emails, right?
[08:58] <kiko> I just wanted to catch up with you on that.
[08:58] <kiko> I don't know if it's more a priority than the bugtracker improvements we discussed
[08:58] <kiko> what do you think?
[09:03] <kristog> hello :)
[09:03] <BjornT> i think it is. it should take only one day, and i think it's quite common for people to try attaching files via email. there has been complains about that before, that triager asks for extra information, and the reporter attaches it to the email.
[09:03] <kristog> i wonder if *normal* launchpad users can close $main-package bugs.
[09:04] <kristog> yesteday i tried to close a dbus bug but i didn't find the usual combo_box
[09:10] <kiko> kristog, were you logged in?
[09:11] <kristog> yes.
[09:12] <kiko> then it's odd. 
[09:12] <kiko> do you have a URL?
[09:12] <ddaa> kiko: they had whiteboards since forever
[09:12] <kiko> oh. you can now edit one when adding branches then.
[09:12] <kristog> kiko: forgot it...now it works
[09:12] <ddaa> kiko: yup
[09:12] <kristog> kiko: https://launchpad.net/distros/ubuntu/+source/dbus/+bug/47354
[09:12] <Ubugtu> Malone bug 47354 in dbus "dbus won't upgrade without current lsb-base" [Medium,Needs info]  
[09:12] <kiko> thanks ddaa 
[09:13] <kiko> kristog, that's usually a symptom of not being logged in.
[09:13] <kristog> nono, i was logged in,
[09:13] <kristog> but * dbus (Ubuntu) * was not clickable.
[09:14] <kristog> kiko: btw, forget it, now it works :)
[09:16] <kristog> thank you
[11:00] <mpt> Goooooooooooooooooooooooooooooooooooood morning Launchpadders!
[11:03] <ddaa> hey mpt, I'd like your opinion on https://launchpad.net/products/launchpad-bazaar/+bug/58889
[11:03] <Ubugtu> Malone bug 58889 in launchpad-bazaar "Merged and abandoned branch should not appear in main branch listings" [Medium,Confirmed]  
[11:09] <mpt> ddaa, +1 on all that, except I suggest making the link "Show n merged/abandoned branches", and putting it under the list instead of above it (and making it a grey "No merged/abandoned branches" non-link if there aren't any)
[11:11] <ddaa> So you suggest "[Show|Hide]  n merged/abandoned branches", and if there are None "No merged/abandoned branches" on both the normall and the show=all page?
[11:11] <ddaa> At the bottom of the page.
[11:16] <mpt> ddaa, exactly so.
[11:16] <ddaa> mpt: Thank you, would you be kind enough to take credit and put that in a comment to that bug :)
[11:35] <mpt> ddaa, done
[11:35] <ddaa> mpt: thank yoiu
[11:44] <mpt> "sabes un favor dime como puedo insicribirme en ubuntu y asi poder acceder a los discos que ofrecen"
[11:44] <mpt> Anyone able to tell me what that means?
[11:45] <mpt> Are they wanting Ubuntu CDs?
[11:48] <matsubara> mpt: yes
[11:48] <matsubara> mpt: but I don't speak spanish
[11:49] <ddaa> yup
[11:50] <ddaa> Rustily: "Please tell me how to sign up on Ubuntu to access to the discs you are offering"
[11:50] <matsubara> that's exactly the meaning I got from my portuol :)
[11:50] <ddaa> which is a remarkably polite way to ask it if you compare to what we get from some other countries
[11:53] <mpt> cool, thanks
[11:55] <ddaa> Good night.