[00:08] <lifeless> do we still use Pygpgme ?
[00:09] <lifeless> wgrant: https://bugs.launchpad.net/launchpad/+bug/184835
[00:09] <_mup_> Bug #184835: Add status '9' (which equates to WONTFIX) to the Roundup external bug tracker <bugwatch> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/184835 >
[00:09] <lifeless> wgrant: is that fixed incidentally?
[00:09] <wgrant> lifeless: No, but it's no longer an OOPS, so it's Low.
[00:13] <lifeless> wgrant: what about https://bugs.launchpad.net/launchpad/+bug/125068 ?
[00:13] <_mup_> Bug #125068: Bugzilla bug watch updater crashes on POSTs that return a HTTP error <bugwatch> <lp-bugs> <oops> <story-reliable-bug-syncing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/125068 >
[00:13] <wgrant> lifeless: Some of those are fixed, others are not.
[00:13] <lifeless> I wonder if leonardr's work has fixed https://bugs.launchpad.net/launchpad/+bug/106338 ?
[00:13] <_mup_> Bug #106338: Editing a bug targeted to a release crashes if you directly edit the untargeted task  <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/106338 >
[00:13] <wgrant> I need to check waht still shows up.
[00:14] <lifeless> he says it hasn't fixed it
[00:14] <lifeless> but I wonder if we're lucky
[00:14] <wgrant> Indeed.
[00:14] <wgrant> He tested it.
[00:14] <wgrant> And said it wasn't fixed.
[00:25] <lifeless> wgrant: hey - https://bugs.launchpad.net/launchpad-buildd/+bug/497772 - would love to get bm crashes oopsing
[00:25] <_mup_> Bug #497772: exceptions.AttributeError: 'DebianBuildManager' object has no attribute '_subprocess' <oops> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/497772 >
[00:35] <wgrant> lifeless: So, roughly, "fuck no"
[00:36] <wgrant> Generating OOPSes from user-controlled code == bad
[00:37] <wgrant> It's also really hard, since there is no access to the slaves except through lp-buildd, and that's what's broken here.
[00:39] <lifeless> wgrant: uhm, thats not what I was saying
[00:39] <lifeless> wgrant: if the build manager blows up, it should write an oops.
[00:39] <lifeless> ditto lp-buildd
[00:39] <wgrant> Where should lp-buildd write an OOPS to?
[00:39] <lifeless> if the *build* fails, thats not lp-buildd or the build manager blowing up
[00:40] <lifeless> wgrant: hand it off to the bm
[00:40] <wgrant> And how do we know a user isn't going to run their own lp-buildd and generate millions of OOPSes?
[00:40] <lifeless> wgrant: can they talk to the build master?
[00:40] <wgrant> lifeless: I can easily hijack a buildd and get my own lp-buildd to run there.
[00:40] <lifeless> wgrant: on the host os?
[00:41] <wgrant> lifeless: Outside the chroot, but inside the VM.
[00:41] <lifeless> wgrant: isn't that on a different IP ?
[00:41] <wgrant> lifeless: lp-buildd runs inside the VM.
[00:41] <wgrant> We don't talk to the host at all.
[00:41] <lifeless> *blink*
[00:41] <wgrant> We don't know that the host exists.
[00:41] <lifeless> ok
[00:41] <lifeless> uhm
[00:41] <wgrant> We just know that there is a command that we can run to reset the VM.
[00:41] <wgrant> (because we will need to use alternative virt solutions in the future *cough* ARM *cough*, where there is no Linux on the host)
[00:42] <lifeless> you have a good scary story there
[00:42] <lifeless> but
[00:43] <lifeless> if we get an oops from lp-buildd, its time to kill the build
[00:43] <lifeless> that prevents millions of oopses from one instance
[00:43] <wgrant> What does killing the build mean?
[00:43] <wgrant> Killing the build does not kill lp-buildd.
[00:44] <lifeless> wgrant: AIUI we restart the buildd per build because of precisely the trust issues you allude to
[00:44] <lifeless> wgrant: so I mean that
[00:44] <wgrant> lifeless: At the moment we only restart it when the next build starts. But that is itself a security issue, so we should probably fix that.
[01:02] <wgrant> There seem to be three different ways an externalbugtracker can indicate that the importance is unable to be converted :(
[01:03] <lifeless> \o/
[01:04] <wgrant> lifeless: Bug #422960 is cheating.
[01:04] <_mup_> Bug #422960: appear to be failing to record oops for all +translate HTTP 503 errors <canonical-losa-lp> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/422960 >
[01:04] <lifeless> wgrant: I disagree :)
[01:06] <lifeless> wgrant: it falls into the bucket of a bunch of operational improvements that we should do, IMO
[01:07] <wgrant> Maybe.
[01:08] <wgrant> Almost OOPS report time.
[01:08] <lifeless> yeah
[01:08] <lifeless> almost 11 second timeout time
[01:08] <wgrant> Exactly.
[01:09] <wgrant> What did we start at?
[01:09] <wgrant> 16?
[01:09] <lifeless> 20
[01:09] <lifeless> 17 on edge
[01:09] <lifeless> step 1 was making both 17
[01:10] <wgrant> I was going to say 17, but I thought that seemed a bit odd.
[01:10] <lifeless> since then we've ratched as we fixed things
[01:10] <lifeless> edge was lower 'to catch slow pages' - but has a different user population, so not very effective at that
[01:11] <StevenK> And edge still isn't dead. :-(
[01:11] <lifeless> its in the queue
[01:12] <wgrant> But at least it no longer has a shorter queue.
[01:15] <wgrant> lifeless: Your gardening has nearly been successful.
[01:15] <wgrant> But not quite :(
[01:15] <StevenK> I'd like to rewrite my Firefox URL suggestions, since most of those tend to be edge URLs
[01:17] <lifeless> wgrant: thats just the first 75
[01:17] <lifeless> StevenK: sqlite3
[01:17] <lifeless> StevenK: update ...
[01:17] <lifeless> where ...
[01:20] <StevenK> lifeless: Er, which of the 4,000,000 sqlite databases? :-)
[01:22] <wgrant> places
[01:23] <wallyworld> thumper: got a sec on mumble?
[01:23] <thumper> sure
[01:27] <StevenK> sqlite> select count(*) from moz_places where url like '%edge%';
[01:27] <StevenK> 163
[01:27] <StevenK> :-(
[01:34] <wgrant> gnarrrrgh
[01:35] <wgrant> If I "accidentally" break bug searching and manage to globally corrupt the history so the old code is irretrievable, does writing an implementation does not UTTERLY SUCK become critical?
[01:35] <wgrant> s/implementation/implementation that/
[01:37] <StevenK> How do you plan to globally corrupt the history? :-)
[01:37] <wgrant> That's one part of the plan that is not yet entirely defined.
[01:38] <StevenK> wgrant: To quote Penny Arcade: Stay Good!
[01:40] <wgrant> lifeless: Is bug #558585 valid?
[01:40] <_mup_> Bug #558585: librarian outages cause OOPSes on pages showing BranchMergeProposal diffs <code-review> <lp-code> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/558585 >
[01:40] <wgrant> That's like complaining that Launchpad doesn't work when the DB is down.
[01:40] <wgrant> Except that mizuho is shit and a SPOF.
[01:42] <StevenK> Next p-s-c run will hit SPR 98000
[01:43] <lifeless> wgrant: its arguable
[01:43] <lifeless> I'm not sure if we should say 'yes, yes it does'
[01:44] <lifeless> or 'we should degrade gracefully'
[01:48] <wgrant> StevenK: Isn't the much faster than we thought?
[01:48] <wgrant> Or are lots of early SPRs missing?
[01:49] <StevenK> Lots of early SPRs are missing changelogs
[01:49] <wgrant> I mean missing in general.
[01:49] <wgrant> I don't know what evil was done before the first import.
[01:49] <StevenK> Ah. The first SPR id run across was 59510
[01:49] <wgrant> Right.
[01:49] <lifeless> wgrant: are you still hacking on https://bugs.launchpad.net/launchpad/+bug/575450?
[01:49] <_mup_> Bug #575450: Archive:+copy-packages nearly unusable due to timeouts <lp-soyuz> <ppa> <timeout> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/575450 >
[01:50] <wgrant> lifeless: The next piece of work in that is bug #733071.
[01:50] <_mup_> Bug #733071: Archive:+copy-packages slow when potential conflicts detected <timeout> <Launchpad itself:Triaged by wgrant> < https://launchpad.net/bugs/733071 >
[01:50] <wgrant> But there is also work needed to speed up the UI, but I haven't analysed that yet.
[01:50] <lifeless> wgrant: there is a stall condition here
[01:50] <wgrant> Yes.
[01:51] <lifeless> wgrant: if you split out a bug like this, please assign yourself to all components, or only leaf components
[01:51] <lifeless> wgrant: you see why ?
[01:51] <wgrant> Yeah, sorry.
[01:51] <lifeless> no worries
[01:51] <lifeless> bigjools pinged me about this morning when discussing the drop to 11 seconds
[01:53] <lifeless> hes concerned about usability during release
[01:53] <wgrant> That's +queue.
[01:53] <wgrant> Not +copy-packages
[01:54] <StevenK> wgrant: If my one-liner of evilness is right, we've processed 38k SPRs since the 15th.
[01:54] <wgrant> StevenK: Sounds reasonably plausible.
[01:54] <StevenK> Pity there is another 500+ k
[01:55] <lifeless> wgrant: bah, emybrain
[01:55] <wgrant> Speaking of 11 seconds.
[01:56] <wgrant> 424 Time Outs
[01:56] <wgrant> :(
[01:57] <StevenK> You didn't want 424?
[01:57] <wgrant> We had 252 yesterday.
[01:57] <wgrant> So, no.
[01:57] <StevenK> wgrant: The BUILDMASTER oops concerns me
[01:57] <StevenK> Since the same thing happened yesterday too
[01:57] <wgrant> StevenK: That normally just means the source has been superseded.
[01:57] <wgrant> It often happens.
[01:58] <wgrant> I thought jelmer had fixed that, but maybe not complete.
[02:02] <StevenK> I guess EB and ED are also appservers?
[02:02] <wgrant> EB and ED are edge appservers.
[02:02] <StevenK> Ahh
[02:02] <StevenK> They need more fire.
[02:03] <wgrant> We need to get rid of potassium and gandwana.
[02:03] <wgrant> Now.
[02:03] <wgrant> The +copy-packages GET timeouts are all high non-SQL on gandwana and potassium.
[02:04] <wgrant> lifeless: When are the new appservers happening?
[02:05] <lifeless> wgrant: probably not till mthaddon is back
[02:05] <wgrant> :(
[02:05] <lifeless> elmo was checking with charlies/nafallo about the memory
[02:06] <wgrant> Is the session queue normally sitting at 0?
[02:06] <wgrant> ie. would it help to deprioritise gandwana/potassium instances?
[02:06] <lifeless> cve:+index spiked
[02:06] <lifeless> jcsackett: has a fix for that
[02:06] <wgrant> He does.
[02:06] <lifeless> is it landed?
[02:06] <wgrant> No.
[02:06] <lifeless> ><
[02:06] <wgrant> Kanban says it's in review.
[02:06] <wgrant> Checking it.
[02:06] <lifeless> dropping the timeout
[02:07] <wgrant> Excellent.
[02:33] <StevenK> Wow, apparently windmill is fixed
[02:34] <lifeless> rm?
[02:39] <lifeless> have we done anyting to improve https://launchpad.net/ubuntu/+source/kde4libs/+publishinghistory ?
[02:47] <jtv> StevenK: did they use the great "rm -rf" debugger?
[03:06] <wgrant> StevenK: Windmill is not fixed, but wallyworld fixed the broken test.
[03:07] <wgrant> lifeless: My SPR.copyright fix will have improved that.
[03:07] <wgrant> It still times out occasionally, though.
[03:13] <thumper> https://code.launchpad.net/~thumper/launchpad/blueprint-linked-bug-tasks/+merge/53734 anyone?
[03:14] <thumper> I have three other reviews which are the start of the pipeline
[03:14] <thumper> but they are trivial
[03:14] <thumper> and I'm tempted to self review
[03:14] <thumper> but if someone wants to look at them
[03:14] <thumper> here they are:
[03:14] <thumper> https://code.launchpad.net/~thumper/launchpad/bugtask-repr/+merge/53731
[03:14] <thumper> https://code.launchpad.net/~thumper/launchpad/bugtask-tales-addition/+merge/53732
[03:14] <thumper> https://code.launchpad.net/~thumper/launchpad/add-publishing-for-factory-distro-sourcepackage-bug-tasks/+merge/53733
[03:15] <wgrant> In bugtask-tales-addition you seem to be trying to reimplement structuredstring.
[03:16] <thumper> wgrant: what do you mean?
[03:16] <wgrant> _make_title escapes stuff.
[03:17] <thumper> wgrant: I implemented it in the same way that the main link is generated
[03:17] <thumper> wgrant: I didn't think too hard about the implementation
[03:17] <wgrant> Yes, and most of our code is buggy :(
[03:17] <thumper> is that bit buggy?
[03:18] <wgrant> It's not buggy, but it's not a pattern that we want to perpetuate.
[03:18] <wgrant> If you are calling cgi.escape, you are probably doing it wrong.
[03:18] <thumper> where is structuredstring?
[03:19] <wgrant> canonical.launchpad.webapp.menu, or somewhere stupid like that.
[03:19] <wgrant> Yeah, canonical.launchpad.webapp.menu.structured is the constructor.
[03:22] <thumper> hmm...
[03:22] <StevenK> wgrant: Hm, do you know the diff?
[03:22] <wgrant> StevenK: Which diff?
[03:23] <StevenK> wgrant: wallyworld's that fixed the failing windmill test
[03:24] <wgrant> StevenK: r12593
[03:25] <thumper> wgrant: can you think of a better place than lp.services.utils for structured?
[03:26] <StevenK> lp.app.utils
[03:27] <thumper> StevenK: it isn't really LP specific
[03:27] <wgrant> I think lp.app is probably more appropriate.
[03:27] <wgrant> But I'm not really sure.
[03:27] <lifeless> SpamapS: ping
[03:27] <lifeless> https://bugs.launchpad.net/launchpad/+bug/627974 - the url I got from you, did you get that from launchpadlib, or were you url hacking ?
[03:27] <_mup_> Bug #627974: MaloneApplication:CollectionResource is slow/times out <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/627974 >
[03:29] <thumper> wgrant: lp.app.browser.string ?
[03:30] <thumper> or lp.app.browser.structured
[03:30] <wgrant> thumper: string, I think.
[03:30] <wgrant> Mm.
[03:30] <wgrant> I don't know.
[03:31] <thumper> it needs an interface module too
[03:31] <thumper> I'd not be happy putting it in lp.app.interfaces.launchapd
[03:31] <thumper> or launchpad even
[03:31] <thumper> I'd be happy to have the interface and implementation in a single file in lp.services.string
[03:31] <wgrant> Indeed not.
[03:32] <thumper> and include escape and structured
[03:32] <wgrant> But lp.services is not webapp-specific, so lp.services.string is wrong.
[03:32] <wgrant> lp.services.escaping, maybe.
[03:32] <lifeless> l.c.l.w.string then
[03:32] <wgrant> But I'd prefer lp.app somewhere.
[03:33] <thumper> lifeless: we are trying to remove things from c.l.w
[03:33] <thumper> wgrant: lp.app with two files?
[03:34] <lifeless> thumper: I know, but that seems pointless to me, the angst about it is dwarfed by the number production and deployment issues spent fixing moves
[03:34] <lifeless> I can't bring myself to care about labels
[03:35] <lifeless> the arguments for moving are that the old structure impeded splitting the tree, but the analysis for splitting the tree was wrong
[03:35]  * lifeless shrugs
[03:36] <thumper> perhaps we should just move canonical.launchpad.webapp to lp.app.webapp
[03:36] <thumper> :)
[03:36] <wgrant> thumper: I am not sure if bugtask-repr is safe.
[03:36] <thumper> wgrant: why?
[03:37] <wgrant> thumper: It potentially exposes the bug ID and target, if you manage to get hold of a BugTask through the webservice.
[03:38] <thumper> wgrant: the webservice handles launchpad.View
[03:38] <thumper> wgrant: and a bugtask view permissions filter to the bugs
[03:38] <thumper> wgrant: so not a valid concern I believe
[03:38] <wgrant> thumper: The webservice handles launchpad.View for collections, sometimes.
[03:38] <thumper> having that repr certainly helped my debugging
[03:43] <wgrant> 8 of todays top 10 OOPSes are fixed. Yay.
[03:43] <wgrant> The next few are codehosting.
[03:43] <wgrant> Blue squad sounds like a good one to take those :P
[03:47] <StevenK> wgrant: I'm having a such a brain fade -- can you remind how to get the latest version of an SPR in a distroseries.
[03:48] <wgrant> StevenK: That doesn't really make sense. But getCurrentSourceReleases might do what you want.
[03:48] <wgrant> Depending on what you actually mean.
[03:48] <wgrant> It is ambiguous in a couple of ways.
[03:49] <StevenK> wgrant: So, Julian would like to delete the DSD is the derived series and parent series have the same version published. This makes sense to me, but I'm having a brain fade looking for the method to help me.
[03:50] <wgrant> That's deleting the comment history.
[03:50] <wgrant> Bad idea to do that so early.
[03:50] <wgrant> You can possibly justify doing that once a series is done.
[03:50] <wgrant> But not before.
[03:51] <StevenK> Why? If something has been synced, the comments are now irrelevant/
[03:51] <StevenK> s/\//./
[03:52] <wgrant> StevenK: I want to know why it was synced.
[03:52] <StevenK> Then you can look up the bug.
[03:52] <wgrant> There wasn't a bug, because we are no longer in the dark ages.
[03:52] <wgrant> The sync button has been implemented.
[03:53] <StevenK> Good point.
[03:58] <thumper> how do we avoid the ValidPersonCache queries?
[03:58] <thumper> can we precache it?
[04:01] <wgrant> thumper: list(getUtility(IPersonSet).getPrecachedPersonsFromIds(ids, need_validity=True))
[04:02] <thumper> wgrant: I have the people already from a different join
[04:04] <thumper> although looking at this method, I may change it
[04:06] <lifeless> thumper: are you filtering on person ?
[04:07] <thumper> lifeless: I'm looking at two timeouts
[04:07] <thumper> for spritns
[04:07] <lifeless> Sprint:+huge-vocabulary?
[04:07] <thumper> one on +index seems to be getting valid persons
[04:07] <thumper> and +attendees-csv is just shite
[04:07] <lifeless> ok
[04:07] <lifeless> bug #'s ?
[04:07] <thumper> the attendees-csv could be trivially fixed
[04:07] <thumper> except for the ircnicknames
[04:08] <thumper> bug 735996
[04:08] <_mup_> Bug #735996: Sprint:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735996 >
[04:08] <thumper> there isn't a bug for +attendees-cvs db counts
[04:09] <thumper> ircnicknames is a SQLMultipleJoin
[04:09] <thumper> so not sure how to precache the names for all the people :-(
[04:09] <wgrant> You'll have to make it a cachedproperty returning a list.
[04:10] <thumper> wgrant: but that doesn't mean we can get them all at once
[04:10] <wgrant> thumper: It does...
[04:10] <thumper> how
[04:10] <wgrant> store.find(IRCNick, IRCNick.personID.is_in(personIDs)
[04:10] <wgrant> grep around for pre_iter_hook
[04:11] <thumper> hmm...
[04:11] <thumper> I'll look around
[04:28] <lifeless> jtv: perhaps you could comment on https://bugs.launchpad.net/launchpad/+bug/708875
[04:28] <_mup_> Bug #708875: AssertionError: More than 6 plural forms were submitted <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/708875 >
[04:28] <jtv> lifeless: should be an unexpectedformdata if it happens from the web UI.
[04:29] <jtv> Seems a far-out guess that this is coming from the web UI, but I'm pretty sure I made the importer check for this condition way back when.
[04:30] <wgrant> I think the check is wrong.
[04:30] <wgrant> I looked at it yesterday and ran away.
[04:30] <wgrant> There are only forms 0-5
[04:30] <wgrant> Which is 6.
[04:30] <wgrant> Not more than 6.
[04:36] <jtv> The check doesn't even make sense to me.  It's an "else" attached to a "for" loop AFAICS
[04:36] <wgrant> Right.
[04:36] <wgrant> That does make sense.
[04:36] <wgrant> But it's not right here.
[04:37] <wgrant> (the else block is executed if the loop runs to completion, without a break)
[04:37] <jtv> Gawd
[04:37] <wgrant> Pretty much.
[04:37] <jtv> So yes, that explains the off-by-one
[04:37] <lifeless> which is the absolute opposite of what *everyone* reads it as
[04:37] <jtv> The loop breaks when it hits the first plural form that is supported but is not in the form.
[04:37] <jtv> And when you submit exactly the maximum number of forms, it never does.
[04:37] <jtv> FFS.
[04:38] <wgrant> Exactly.
[04:38] <wgrant> But I thought this must have come up often.
[04:38] <wgrant> Does it not?
[04:39] <lifeless> wgrant: still working on bug 714414 ?
[04:39] <_mup_> Bug #714414: unstack debian sid branches <code-hosting> <stacking> <Launchpad itself:Triaged by wgrant> <Ubuntu Distributed Development:Fix Released by mbp> < https://launchpad.net/bugs/714414 >
[04:39] <jtv> Probably, yes, but plural forms are relatively rare, and only Arabic uses 6.
[04:39] <wgrant> jtv: Right, but wouldn't it occur on every plural arabic translation, then?
[04:40] <wgrant> Or is the last one uncommon?
[04:40] <jtv> Every complete plural arabic translation made in the UI, yes.
[04:40] <wgrant> Given the debate around ubuntu-l10n-ar, I guess we don't have many arabic translators.
[04:40] <wgrant> lifeless: Not really.
[04:41] <jtv> An upstream translation. or one uploaded by a translation team member, wouldn't have this problem.
[04:41] <jtv> I'm expounding on the bug.
[04:44] <lifeless> wgrant: unassign?
[04:46] <lifeless> is https://bugs.launchpad.net/launchpad-buildd/+bug/719162 deployed?
[04:46] <_mup_> Bug #719162: [Natty] check-implicit-pointer-functions fails on natty, resulting possibly broken packages <qa-ok> <Launchpad Auto Build System:Fix Committed by julian-edwards> < https://launchpad.net/bugs/719162 >
[04:48] <wgrant> lamont was looking at that earlier this week. We need an amd64 builder on staging before we can QA it.
[04:48] <wgrant> So no, it's not yet deployed.
[04:52] <lifeless> stub: hey
[04:53] <lifeless> can you see how long the very big query in bug 722787 takes now on prod?
[04:53] <_mup_> Bug #722787: Product:+filebug timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/722787 >
[04:53] <lifeless> I suspect the index repack fixed it
[04:59]  * stub tries to find a real query
[05:01] <lifeless> wgrant: and are you doing 729064 ?
[05:08] <wgrant> lifeless: Yes.
[05:08] <stub> I can't even cut and paste the query without making terminal explode :-P
[05:08] <stub> https://lp-oops.canonical.com/oops.py/?oopsid=1875O1575 has bigger problems than just timing out
[05:08] <lifeless> stub: :P
[05:09] <lifeless> love our ui
[05:09] <lifeless> There are currently no open bugs.
[05:09] <lifeless> https://bugs.launchpad.net/launchpad-project/+bugs?field.importance=Critical&start=225
[05:11] <stub> lifeless: So the insane query in that oops runs in 3 seconds atm. on one of the slaves.
[05:12] <lifeless> stub: great,thanks
[05:13]  * lifeless closes
[05:13] <lifeless> 224 critical bugs
[05:13] <lifeless> tada
[05:13] <lifeless> including 6 5-digit ones
[05:14] <lifeless> stub: going to cook dinner; catchup after that?
[05:14] <stub> sure
[05:23] <poolie> hi
[05:24] <poolie> re bug 719271, are there multiple threads per scanner process?
[05:24] <_mup_> Bug #719271: Branch scanner jobs failing in bzrlib <branch-scanner> <bzr> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/719271 >
[06:20] <lifeless> stub: ping
[06:24] <stub> lifeless: pong
[06:24] <lifeless> skype?
[06:28] <wgrant> https://staging.launchpad.net/successful-updates.txt is odd.
[06:30] <lifeless> stub: https://dev.launchpad.net/LEP/ReliableDBDeploys
[06:37] <wgrant> Can we move to Python 3 please?
[06:37] <StevenK> How do you suggest we move Zope and Storm to Python 3?
[06:37] <wgrant> Shh
[06:38] <StevenK> Oh, you don't want problems, you want solutions?
[06:39] <wgrant> I want non-awful Unicode.
[06:39] <wgrant> I also want lucid_db_lp to fail sensibly.
[06:39] <wgrant> Because its current failure is not sensible.
[07:16] <stub> lifeless: tasque
[07:30] <lifeless> wgrant: happier with the bug count now ?
[07:35] <wgrant> lifeless: Mostly.
[07:47] <wallyworld> wgrant: there's a question about getting increased space for a ppa. who do i assign that to?
[07:51] <wgrant> wallyworld: A LOSA, or poke a commercial admin
[07:52] <spm> that doesn't sound right. we haven't been doing space increases for ages. can you guys already do that?
[07:52] <spm> yourselves as in. ?
[07:53] <wallyworld> spm: if we can do it, i don't know how :-)
[07:53] <spm> it's an admin option off the ppa itself. or was.
[07:53] <wgrant> It needs a commercial admin or a LOSA, and there is approximately one active commercial admin.
[07:54] <wallyworld> i also have a question about a confirmation code being rejected when someone tried to create an account. assignee?
[07:54] <wgrant> wallyworld: Ask them to file a ticket at the SSO support site.
[07:54] <spm> that needs a level of sanity filtering first
[07:54] <wgrant> Or reassign the question to canonical-identity-provider
[07:55] <wallyworld> wgrant: thanks. will reassign to cip. what's the sso support site?
[07:56] <wgrant> https://forms.canonical.com/lp-login-support/
[07:56] <wallyworld> thanks
[08:01] <wallyworld> spm: if it is an admin option on the ppa i can't see it. can i ask you to increase the space for the user?
[08:01] <stub> wgrant: You were correct about Bug #736613
[08:02] <stub> (The ℃ bug since mup seems to have run out of blow)
[08:03] <wgrant> Aha
[08:03]  * wallyworld has soccer training. back later
[08:48] <bigjools> morning hackers
[08:56] <adeuring> good morning
[09:02] <jtv1> hi adeuring
[09:03] <adeuring> hi jtv1!
[09:04] <jtv1> StevenK: I realize it's late for you, so you may want to ignore this.  I have minimal tests running for cron.publish-ftpmaster, but basically without any packages.  Next on my wishlist is to make it produce meaningful data so I can test that I don't break it.
[09:05] <wgrant> You managed to get it to run locally?
[09:05] <jtv1> Yes
[09:05] <jtv> In /tmp, not /srv/launchpad.net
[09:06] <jtv> The test should be able to reproduce it without any system changes.
[09:07] <jtv> Also, I changed it so it'll run against ubuntutest.  Not sure yet if that's particularly useful.
[09:07] <wgrant> Knowing the state of the sampledata, it's probably best to run against a completely new distro.
[09:07] <wgrant> Or you are going to have fun when you start trying to publish stuff.
[09:07] <jtv> Yes, that's what I was hoping to do.
[09:08] <jtv> Problem is, I'm lost in the dark.
[09:08] <lifeless> in a completely temp dir
[09:09] <jtv> all alone
[09:09] <jtv> and it's freezing
[09:09] <wgrant> Don't pollute my terminal with your wide characters again.
[09:10] <jtv> my… what?
[09:10] <wgrant> Oh wait, that was stub.
[09:10] <jtv> ah—nasty stub
[09:10] <jtv> Is ญ a wide character?
[09:11] <jtv> Anyway, wgrant, what would I have to set up?  I'm guessing distro, distroseries, sourcepackagename, sourcepackagerelease, sourcepackagepublishinghistory… anything else?
[09:11] <wgrant> Yes, but not as wide as the ℃  I was terrorised with earlier.
[09:12] <jtv> Wait, there's a single character for °C?
[09:12] <stub> I can whine in ℉ if you would rather
[09:12] <jtv> How do I type those?
[09:13] <stub> And if you think I'm bitching about the cold, you should hear my maid.
[09:13] <wgrant> jtv: Distribution, DistroSeries, DistroArchSeries to start. Then you can create some stuff to publish... SPPHs (you may have to add files manually) to test publish-distro, and PackageUploads with PackageUploadCustoms to run through process-accepted to test dist-upgrader signing.
[09:13] <jtv> Holy cow, it's 18°!   Insane!
[09:13] <stub> You mean 18℃
[09:13] <jtv> wgrant: quite a shopping list already… thanks
[09:14] <wgrant> stub: At least there was no exclamation mark that time.
[09:14] <jtv> stub: yes, but I only know how to type that as °C
[09:14] <jtv> Is there a problem with an exclamation mark after ℃?
[09:14] <wgrant> Aaaaaaaa
[09:15] <jtv> Or as the Danes would say, Åååå.
[09:16]  * jtv is beginning to wonder whether wgrant's terminal is perhaps not entirely prepared for some non-ASCII characters somehow.
[09:16] <stub> Bug #736613 is the "℃" problem
[09:16] <wgrant> http://people.canonical.com/~wgrant/bad-kerning.png
[09:17] <jtv> wgrant: thanks, that gives me something to aim for
[09:17] <bigjools> if you use an irc client developed this century, it would probably work
[09:17] <lifeless> it works in irssi
[09:17] <wgrant> This irssi.
[09:18] <wgrant> It depends on your terminal emulator and font.
[09:18] <wgrant> +is
[09:18] <lifeless> ok, irssi with real terminal and font :P
[09:19] <wgrant> :(
[09:19] <stub> ꒴
[09:20] <jtv> wgrant: the files I may have to add manually are changelogs for the SPRs?  Or something else?
[09:20] <wgrant> jtv: SPRFs
[09:20] <jtv> Isn't that a view?
[09:20] <wgrant> The view is SPFP
[09:20] <jtv> Oh
[09:20] <jtv> How could I have been so stupid?
[09:20] <wgrant> I know, right.
[09:22] <bigjools> I knew that would provoke a reaction :)
[09:23] <jtv> hi bigjools :)
[09:25] <bigjools> helleau jtv
[10:28] <sidnei> anyone around for a review?
[10:30] <poolie> o/
[10:31] <poolie> (just waving, not volunteering :)
[10:34] <LPCIBot> Project devel build #547: FAILURE in 4 hr 38 min: https://hudson.wedontsleep.org/job/devel/547/
[10:37] <wgrant> lp.services.job.tests.test_runner.TestTwistedJobRunner.test_timeout as usual.
[10:37] <sidnei> oh, hi poolie :)
[10:38] <gmb> The Kanban board should pop a message when I move a card into the review lane that says "Are you sure, little man?"
[10:41] <sidnei> gmb, with a picture of clippy?
[10:41] <gmb> Yeah :)
[11:25] <lifeless> jml: ping
[11:26] <jml> lifeless: pong
[11:26] <lifeless> jml: https://dev.launchpad.net/LEP/ReliableDBDeploys
[11:26] <jml> lifeless: yeah, I saw your earlier IRC comment about it. It's on the list.
[11:26] <lifeless> jml: thanks
[11:27] <lifeless> jml: also, I just replied to bug 655385 - with some ideas about solving a few of our bug challenges all at once
[11:27] <_mup_> Bug #655385: Allow bug status change from Triaged only for bug supervisor <accesscontrol> <acl> <bugs> <easy> <lp-bugs> <Launchpad itself:Opinion> < https://launchpad.net/bugs/655385 >
[11:27] <lifeless> jml: I'd be interested in your thoughts on my comment (which was mailed in so possibly not visible yet
[11:28] <jml> lifeless: ok
[11:28] <lifeless> its a little adlib, but I felt the pieces going 'click' as I wrote
[11:32] <lifeless> man, its *really* hard to enter a tag that is a prefix of an official bug tag
[11:40] <lifeless> jml: its there - https://bugs.launchpad.net/launchpad/+bug/655385/comments/14
[11:40] <_mup_> Bug #655385: Allow bug status change from Triaged only for bug supervisor <accesscontrol> <acl> <bugs> <easy> <lp-bugs> <Launchpad itself:Opinion> < https://launchpad.net/bugs/655385 >
[11:51] <lifeless> hmm, night all
[11:51] <lifeless> bigjools: if you think some of the things I changed should still be critical, please just change them back: I was doing a big sweep as I said, and 100% accuracy is hard to achieve
[11:52] <bigjools> lifeless: ok, I didn't want to be too presumptuous :)
[11:52] <lifeless> bigjools: long as you include a reason (so that in 3 months I don't toggle again, blindly :)) it will be fine
[11:53] <wallyworld> jtv: there's a translation question i have no clue about. can i assign it to you?
[11:54] <jml> lifeless: !!!
[11:55] <lifeless> jml: ?
[11:56] <lifeless> jml: you caught me just as I was about to walk away from the keyboard... whats up?
[11:56] <jml> lifeless: oh, just that at least one of the bugs that were marked down had been previously marked Critical without comment.
[11:56] <jml> lifeless: it's no big deal
[11:57] <lifeless> jml: presumably by me? I do try to comment consistently, though I will admit I rarely bother when the bug is tagged oops or timeout from the start
[11:59] <jml> lifeless: yeah. it was one or two out of about thirty, and not bugs I care about personally.
[12:00] <lifeless> jml: if it was the getBranches on sourcepackage one, there was a comment already on the bug saying it no longer oopsed; I was lazy there ;)
[12:01] <lifeless> http://webnumbr.com/.join(launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all)
[12:57] <jml> hmm.
[12:58] <jml> I've got some PPA stats
[12:58] <jml> questions
[12:59] <jml> - how many PPAs are there?
[12:59] <jml> - how many packages are being uploaded to PPAs?
[12:59] <bigjools> https://launchpad.net/ubuntu/+ppas
[13:00] <jml> bigjools: awesome :)
[13:00] <wgrant> There are also a few graphs on lpstats.
[13:00] <bigjools> yeah w3as just searching for some good ones for jml
[13:00] <bigjools> like https://lpstats.canonical.com/graphs/NewPPAsWithUploads/
[13:00] <wgrant> There aren't really any good ones.
[13:01] <wgrant> That's the only interesting one.
[13:01] <bigjools> https://lpstats.canonical.com/graphs/PPASourcePackages/
[13:01] <jml> do those "published sources" and "published binaries" numbers collapse versions?
[13:01] <bigjools> published implies collapsed
[13:02] <bigjools> PPAs don't let you publish more than one version
[13:02] <bigjools> of the same package, I mean
[13:02] <wgrant> If you mean distinct source versions? No.
[13:02] <wgrant> If I have the same package in multiple series or PPAs, it will show up a few times in that number.
[13:02] <jml> I guess what I mean is COUNT(DISTINCT (archive, sourcepackagename))
[13:02] <bigjools> ah, no idea
[13:02] <bigjools> anyway I am desperately hungry
[13:02] <jml> ok, thanks.
[13:26] <jml> I'm getting a failure in stable running ./bin/test -cvv lp.services.job.tests.test_runner test_timeout
[13:26] <wgrant> jml: Yes, that test fails on its own.
[13:26] <wgrant> And sometimes in the full test suite.
[13:26] <jml> it's consistent, and it's not like either of the failures mentioned on bug #505913
[13:26] <_mup_> Bug #505913: TestTwistedJobRunner.test_timeout fails intermittently <lp-foundations> <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/505913 >
[13:26] <wgrant> jml: Is it a failure to import _pythonpath?
[13:26] <jml> wgrant: yeah.
[13:27] <jml> wgrant: you also get this failure when running the test standalone?
[13:27] <wgrant> It needs someone who knows that code to look at it.
[13:27] <wgrant> I spent a couple of hours on it and made very little progress.
[13:28] <jml> wgrant: I'm keen to have a try today, if I can deal with prior obligations.
[13:29] <jml> wgrant: just to be crystal clear, you get the _pythonpath import failure when you run the test by itself locally?
[13:29] <wgrant> jml: Yes.
[13:30] <wgrant> jml: Working around that in ways that I no longer recall (possibly hacking site.py in the custom PYTHONPATH it uses) gets the same message as the spurious failure, but I was unable to work out how to get the output of the subprocess.
[13:30] <wgrant> So I made the failure spurious again and ran away.
[13:57] <wgrant> jml: I initially suggested doing what you considered, but could not think of a reasonable name for the method.
[13:57] <wgrant> Er.
[13:57] <wgrant> Swap suggested and considered.
[13:58] <jml> wgrant: ahh, yeah. I can see how that would be a problem.
[14:04]  * bigjools waves at jcsackett
[14:05] <jcsackett> bigjools: publisher config schema review? :-)
[14:05] <bigjools> jcsackett: yarp :)
[14:05] <jcsackett> looking now.
[14:17] <sinzui> jcsackett: will you have time to review https://code.launchpad.net/~sinzui/launchpad/person-merge-job-0/+merge/53706
[14:17] <wgrant> deryck: I've tried running it 30 times. It doesn't hang :/
[14:17] <deryck> wgrant: *sigh*
[14:18] <wgrant> deryck: Yes.
[14:18] <jcsackett> sinzui: i'll do it next. already had it marked for looking at today.
[14:18] <deryck> wgrant: I was afraid of that.
[14:18] <wgrant> deryck: It's also only died a couple of times on Jenkins.
[14:18] <deryck> wgrant: can you point me at those builds?
[14:18] <wgrant> And it doesn't die often on ec2 when only running WindmillLayer.
[14:19] <deryck> wgrant: also, I'm going to try it in a vm with lower resources and see if that helps cause it.
[14:19]  * deryck is grasping at straws
[14:19] <wgrant> That's a good plan.
[14:19] <wgrant> I ran out of straws a week or two ago.
[14:21] <deryck> I'm spending today on it and if I get no hangs, then will look at other options -- decoupling from Zope test runner or moving to Selenium.
[14:22] <deryck> abentley: I'm good for a js chat now.
[14:22] <abentley> deryck: cool.
[14:22] <wgrant> https://hudson.wedontsleep.org/job/windmill/2/ https://hudson.wedontsleep.org/job/windmill/5/ https://hudson.wedontsleep.org/job/windmill/35/ https://hudson.wedontsleep.org/job/windmill/41/ https://hudson.wedontsleep.org/job/windmill/43/ are isolated spurious test failures. The build I thought was Windmill breakage was in fact the UEC slave going away.
[14:23] <gmb> leonardr: Is it possible to pass versioned annotations to export_write_operation (for example, if I want to export a write operation in devel but nothing else)?
[14:23] <wgrant> deryck: So we have had 62 builds without a failure.
[14:23] <wgrant> Yay.
[14:23] <wgrant> Is it something about being in a full test run? Low resources? A race? Who knows...
[14:24] <leonardr> gmb: yes, but you can't do it in export_write_operation, because the definition of a named operation takes place over multiple annotations
[14:24] <leonardr> you need to use @operation_for_version()
[14:24] <gmb> Ah.
[14:25] <gmb> leonardr: So, do I do something like:
[14:25] <leonardr> to publish an operation in devel and nothing else, at the bottom of the annotation stack you would have @operation_for_version('devel')
[14:25] <gmb> ... right.
[14:25] <gmb> :)
[14:25] <gmb> Cool.
[14:25] <gmb> THanks.
[14:25] <leonardr> np
[14:29] <jcsackett> bigjools: so, this branch is just adding these fields, not refactoring anything to make use of them yet?
[14:29] <jcsackett> i only see addition, and setting/changing of the fields, not anything using them.
[14:29] <bigjools> jcsackett: yep, just doing a small focused branch
[14:29] <jcsackett> bigjools: cool.
[14:30] <bigjools> because I know that the code change to use this stuff will be pain ridden :)
[14:30] <jcsackett> bigjools: in the factory, since those are optional fields, is it entirely appropriate that they're always set?
[14:31] <bigjools> jcsackett: interesting point
[14:31] <jcsackett> i don't know that it's actually a problem...just raising a possible different take on how it should work.
[14:31] <bigjools> it would be impossible to set them to None
[14:31] <bigjools> with that code
[14:32] <bigjools> I'll change that, thanks for spotting
[14:32] <jcsackett> bigjools: r=me, with that. :-)
[14:32] <bigjools> cheers!
[14:34] <jcsackett> sinzui: looking at your MP now.
[14:34] <bigjools> Our reviews rock lately
[14:37] <jcsackett> i think moving to the "just use the review page as the queue" is a big win.
[14:39] <bigjools> you weren't around in the old days when we used a wiki page ...
[14:39]  * bigjools shudders
[14:40] <jcsackett> that sounds like it would be problematic, yes. :-P
[14:42] <sinzui> problematic was an understatement
[14:43] <bigjools> and a review team of about 5 people
[14:43] <sinzui> We had to locate a reviewer and prod each over several days to get approval
[14:43] <bigjools> r=trivial was great for that :)
[14:44] <sinzui> except when something broken and kiko looked at the branch and ask how anyone could claim the changes were trivial
[14:50] <LPCIBot> Yippie, build fixed!
[14:50] <LPCIBot> Project devel build #548: FIXED in 4 hr 15 min: https://hudson.wedontsleep.org/job/devel/548/
[14:52] <deryck> wgrant: sorry, was on call.  thanks for the build links.  And I'm not sure honestly what it is about the entire run that causes it.
[14:52] <deryck> if the Jenkins build is just WindmillLayer, then perhaps it could be changed to run the entire suite + windmill.
[14:55] <jcsackett> sinzui: is there a need for a test on mergeAsync in the failure case?
[14:55] <jcsackett> i.e. when it returns None instead of a job?
[14:55] <jcsackett> ah, nevermind. that test exists, just in a different test file.
[14:55] <sinzui> jcsackett: That is handled by the base runner and tests. the base defines an empty set of addresses.
[14:56] <jcsackett> sinzui: yes; i saw test_mergeAsync_success on test_person and so nothing corresponding, but it's handled elsewhere. :-)
[14:58] <bac> hi sinzui -- can you look at this paste as a mid-imp sanity check for the menu problem we discussed yesterday?  https://dev.launchpad.net/JavascriptUnitTesting
[15:01] <jcsackett> sinzui: r=me.
[15:02] <sinzui> bac: thank you for updated the docs
[15:03] <gmb> jcsackett: I have an MP for you to review, if you'd be so kind: https://code.launchpad.net/~gmb/launchpad/make-+subscribe-play-nice-bug-735397/+merge/53839
[15:03] <bac> sinzui: oops, that was the wrong paste.  :)
[15:04] <bac> sinzui: i meant for you to look at http://pastebin.ubuntu.com/581613/
[15:04] <bac> but, yes, i was happy to update those testing docs
[15:06] <jcsackett> gmb: looking now.
[15:07] <gmb> Thankee kindly
[15:09] <sinzui> bac: ugh. I do not think we should be injecting line-height into styles. The anchor is making a bad guess. Only <h3>s have a line-height of 20px. Maybe this is why firefox still shows the icons misaligned in pages
[15:09] <bac> sinzui: perhaps, but that isn't part of my change.
[15:09] <sinzui> you cargo-culted it
[15:09] <bac> sinzui: i'm happy to fix it at the same time, though
[15:10] <bac> sinzui: i replicated the existing code, assuming it was correct, for the case i was adding
[15:10] <bac> thanks TAL
[15:10] <bac> sinzui: the gist of my change to the page template is the conditional addition of "display:none"
[15:11] <sinzui> bac: why do you use style instead of the invisible-link class. I think I would toggle between two classes <invisible-link|visible-linl>
[15:11] <bac> sinzui: good idea
[15:11] <sinzui> we have supported invisible link since 2006 to make link testing easy. I think we can really use it for something else now
[15:12] <bac> sinzui: otherwise a reasonable way to go?
[15:12] <sinzui> yes. your implementation is what I would have done
[15:12] <sinzui> I am worried about spurious line-heights now
[15:12] <sinzui> damn
[15:14] <sinzui> sweet. bac. there is only one occurrence. bac. try removing it and look at the page in firefox and safari. I think they will look the same now
[15:14] <SpamapS> lifeless: pong (no packet loss, but latency is close to interplanetary ;)
[15:14] <bac> sinzui: thanks.  i'll switch to use invisble-link.  and i'll make the line-height fix
[15:15] <sinzui> bac: firefox is still showing the sprites offset from where we intended them. I did not check that there was something overriding the line-height in the markup :(
[15:16] <bac> sinzui: these would be for links such as in the global-actions portlet?
[15:17] <deryck> henninge: we're all sorted out for feature flag now?
[15:18] <henninge> deryck: the request is on LPS
[15:18] <deryck> henninge: ok, thanks.
[15:19] <sinzui> bac: this template is used by "fmt:link", which is most links
[15:21] <deryck> henninge: the number in the feature flag has to be incremented above whatever the current highest number is.
[15:21] <gmb> jcsackett: I need to go and run some errands; I'll respond to your review comments and questions when I get back.
[15:21] <deryck> henninge: so the 1 is probably something like 20 now?
[15:21] <jcsackett> gmb: righto.
[15:25] <deryck> jml: ping
[15:25] <jml> deryck: hi
[15:25] <henninge> deryck: hm?
[15:25] <deryck> henninge: I forgot what that attribute is called, but it has to be current value + 1.
[15:26] <henninge> deryck: oh, I did not know that. I think it's the priority.
[15:26] <deryck> yeah, that's it.  priority.
[15:27] <deryck> henninge: rather, it has to be some value that isn't taken yet. ;)  So everyone does current + 1.
[15:27] <henninge> deryck: I thought that was only relevant when you have multiple rules for the same flag.
[15:28] <henninge> it's to solve those ambiguities, I thought
[15:29] <deryck> henninge: yes, but there's a db constraint it has to be unique across all flags.  the update will fail if not.  it did in the past anyway.
[15:29] <henninge> deryck: hm, there are multiple rules with "1" and also with "0" in the current rule set.
[15:29] <henninge> https://launchpad.net/+feature-rules
[15:30] <deryck> henninge: ah, ok.  So guess I'm wrong then. sorry for the noise.
[15:31] <bac> sinzui: that line-height styling doesn't seem to have any effect.  i've removed it and bumped it up to very high and see no difference in rendering
[15:31] <sinzui> bac: in firefox?
[15:32] <sinzui> Well regardless, we need to remove it. I was hoping that firefox would be fixed
[15:33] <bac> sinzui: actually, i was only looking at the global-actions portlet, which uses the same styling
[15:33] <bac> sinzui: it *does* have an effect on those in the involvement portlet
[15:36] <bac> sinzui: on firefox, in the involvment portlet removing the 'line-height' styling does change the spacing between the lines (yay) but it does not appear to affect the vertical spacing of the sprite relative to the text.
[15:38] <sinzui> bac: I do not see a style attribute in the involvement portlet links on https://launchpad.net/gdp
[15:40] <sinzui> oh, no icon
[15:41] <sinzui> bac: set this aside. I will look into it later
[15:41] <sinzui> sorry for the diversion
[15:42] <bac> sinzui: np.  i'm easily diverted
[15:59] <sinzui> jcsackett: I really like your TestTeamParticipationMesh test. I was able to add two new tests, one using setMembershipData on each member, and the other using deactivateAllMembers. The second test fails as I expect. I will know my refactoring is done when both agree
[16:00] <jcsackett> sinzui: fantastic.
[16:12] <jcsackett> gmb: r=me. left a few questions in a comment, but those are strictly for my education, not issues with the branch.
[16:13] <gmb> jcsackett: Thanks. I'll respond to your questions in the MP now.
[17:19] <deryck> I may have a Windmill hang now!
[17:32] <jelmer> deryck: Is that really something to get excited over ? ;-)
[17:32] <deryck> jelmer: it's the little things that make me happy :-)
[17:37] <sinzui> jcsackett: ping
[17:37] <jcsackett> sinzui: pong.
[17:37] <sinzui> jcsackett: I have a fix for team participation. Do you have a few minutes to mumble about it?
[17:38] <jcsackett> give me just a few moments to grab a drink, and i will be on mumble.
[17:42] <deryck> ah.  stuck in a sleep.
[17:43] <deryck> I told you all sleep was evil.
[17:47] <bigjools> just ask lifeless
[17:48] <deryck> oh wow
[17:48] <deryck> windmill imports time.sleep and uses it inside a while statement
[17:59] <jml> deryck: that sucks
[18:00] <deryck> jml: yes, that's a terrible, scary thing to do, IMHO. But turns out it's unrelated.  Just frightening, but not causing the hang.
[18:00] <jml> deryck: huh
[18:00] <jml> deryck: very glad you're working on this, btw.
[18:01] <deryck> jml: looks like were stuck in client.open.  still digging to know for sure. lot of backtrace to get through
[18:01] <deryck> and thanks!  glad to be working on it myself
[18:02] <bigjools> night folks
[18:03] <deryck> crap.  lost my hung process.
[18:03] <deryck> night bigjools
[18:35] <lifeless> moin
[18:38] <jml> g'night
[18:39] <deryck> Morning, lifeless
[18:44] <lifeless> hi deryck
[19:00] <lifeless> wgrant: jelmer: can either of you loook at  https://rt.admin.canonical.com/Ticket/Display.html?id=42954 and answer toms debugging question?
[19:02] <lifeless> abentley: hey, do you know - do the LP code import slaves need access to the librarian ?
[19:02] <abentley> lifeless: I don't know.
[19:04] <jelmer> lifeless: looking...
[19:04] <lifeless> jelmer: thanks
[19:05] <lifeless> jml: if you haven't actually gone - did I make any sense in that bug post I pointed you at?
[19:29] <sinzui> jcsackett: Can you review https://code.launchpad.net/~sinzui/launchpad/deactivate-all-members-fix-0/+merge/53885 today?
[19:29] <jcsackett> sinzui: sure. i'll take a look in just a bit.
[19:30] <jcsackett> sinzui: 458 lines? that's much smaller than i was expecting from your earlier concerns. :-)
[19:34] <sinzui> jcsackett: Deleting lots of code is often small then editing it
[19:34] <lifeless> jcsackett: hey, how is your cve:+index fix going
[19:35] <jcsackett> lifeless: made the changes you pointed out and it's out to land.
[19:35] <jcsackett> ec2 instance died without output on first try, second try seems to be going alright.
[19:35] <lifeless> jcsackett: cool - third highest oops yesterday
[19:36] <jcsackett> lifeless: well, let's hope i got everything then. :-)
[19:37] <lifeless> jcsackett: if you didn't, we can iterate
[20:07] <jcsackett> sinzui: r=me, and thanks for that branch. i feel that it's a pretty big win.
[20:07] <sinzui> jcsackett: thank you.
[20:10] <jcsackett> thumper: you around yet?
[20:26] <thumper> morning
[20:26] <thumper> jcsackett: am now, with coffee even
[20:26] <jcsackett> thumper: cool. i am looking at https://code.launchpad.net/~thumper/launchpad/bugtask-tales-addition/+merge/53732
[20:26] <thumper> ok
[20:27] <jcsackett> i think it looks pretty good, but i wonder if now all Formatters will need to define _title_values? it looks like calling it is baked into the base class, but the base class has it as NotImplemented.
[20:29] <jcsackett> thumper: it might be better for the base form to just return None on _title_values instead, since that's handled gracefully.
[20:29] <thumper> jcsackett: that seems reasonable
[20:29] <thumper> can easily fix
[20:30] <jcsackett> thumper: with that change, r=me.
[20:30] <thumper> wgrant yesterday also suggested replacing the cgi.escape rubbish with "structured"
[20:30] <jcsackett> thumper: yeah, that might be better too.
[20:30] <thumper> jcsackett: that branch is one of a pipeline :)
[20:30] <jcsackett> thumper: dig. :-)
[20:30] <thumper> jcsackett: I only want to land the top
[20:30] <thumper> I just broke it up for review
[20:30] <thumper> it was getting kinda big
[20:31] <jcsackett> thumper: dig.
[20:31] <jcsackett> so, r=me on that little bit. :-)
[20:31] <thumper> thanks
[20:43] <lifeless> ugh, checkwatches passwords are in lp-prod-configs :(
[20:55] <lifeless> abentley: are translation sharing jobs actually running yet ?
[20:55] <abentley> lifeless: no.
[20:56] <lifeless> abentley: I'm thinking of marking https://bugs.launchpad.net/launchpad/+bug/735954 qa-untestable then
[20:56] <_mup_> Bug #735954: Translation merge job display <qa-needstesting> <Launchpad itself:Fix Committed by henninge> < https://launchpad.net/bugs/735954 >
[20:57] <abentley> lifeless: I don't think "untestable" is strictly accurate.
[20:58] <abentley> lifeless: too-painful-to-test, perhaps :-)
[20:58] <lifeless> abentley: indeed, and too little risk; I think we should check the page renders on qastaging
[21:03] <lifeless> abentley: what url should I look at to see the sharing stuff ?
[21:03] <abentley> lifeless: translations.*/$SOURCEPACKAGE/+sharing-details.
[21:05] <lifeless> abentley: I get a 404 on https://translations.qastaging.launchpad.net/ubuntu/+source/bzr/+sharing-details
[21:06] <lifeless> ah, distro series source package
[21:06] <abentley> lifeless: yes, sorry.
[21:07] <lifeless> https://translations.qastaging.launchpad.net/ubuntu/natty/+source/bzr/+sharing-details
[21:07] <lifeless> seems to render ok
[21:07] <lifeless> and i've clicked around and turned everything I could find on
[21:08] <lifeless> abentley: that seems sufficient to suggest production won't be broken by the change
[21:10] <abentley> lifeless: does it show that a job's pending?
[21:11] <lifeless> abentley: it says No upstream templates have been found yet
[21:11] <lifeless> I guess that that is impeding it
[21:12] <abentley> lifeless: doesn't sound right.
[21:12] <lifeless> abentley: darn, I'll undo my tag change then
[21:13] <lifeless> abentley: what should we do to be confident this is deployable
[21:13] <lifeless> [that is, that it won't regress or break anything]
[21:15] <bac> sinzui: would you have the time and interest to review the branch for the menu links that we discussed this morning?
[21:15] <abentley> lifeless: it should say something like this: http://pastebin.ubuntu.com/581807/
[21:15] <abentley> lifeless: the fact that it doesn't suggests that we may not have the correct revno on qastaging.
[21:16] <lifeless> abentley: 12617
[21:17] <lifeless> I'll have a poke at unity instead
[21:17] <lifeless> it should have strings
[21:19] <abentley> lifeless: I don't know what's going on.  Perhaps the job has not been created.  Perhaps the browser message is being suppressed somewhere.
[21:19] <lifeless> abentley: I think its because there are no templates for upstream
[21:19] <abentley> lifeless: Oh, did you actually create a packaging link?
[21:20] <lifeless> yes, but the upstream hasn't been imported
[21:20] <abentley> I don't recall making job creation conditional on that.
[21:20] <abentley> It requires the package to be an Ubuntu package, but I think that's all.
[21:21] <wallyworld> sinzui: you still there?
[21:21] <lifeless> abentley: have a look here - https://translations.qastaging.launchpad.net/ubuntu/natty/+source/gtk+2.0/+sharing-details
[21:22] <lifeless> abentley: tell me what you think
[21:22] <sinzui> I am
[21:23] <abentley> lifeless: it looks as though this was an already-existing packaging link.  If you just linked it now, then it should have the message.
[21:23] <wallyworld> sinzui: i have lost an email you may have sent about dealing with spam. there's a few open questions about removing spam links or accounts sending spam etc. if there a wiki page or email you can flick me which describes sop for that?
[21:23] <wallyworld> s/an email/any email
[21:23] <lifeless> abentley: oh, ok.
[21:23] <sinzui> Not yet. I may write it tomorrow
[21:23] <lifeless> uhm, will look on needs-packaging
[21:24] <abentley> lifeless: look now.
[21:24] <lifeless> abentley: what did you do?
[21:25] <wallyworld> sinzui: ok. so with accounts sending spam, i assume i should try and see if it's a one off (in case they have been hacked) or if it's an ongoing issue and hence disable that account?
[21:25] <abentley> lifeless: I deleted the packaging link and then re-created it.
[21:25] <sinzui> wallyworld: I can find the email I sent. I believe we can see suspended users now so the process is simpler. suspend the user, then send an email to the user's preferred email address asking the him to confirm he has control of his computer, browser, and isp
[21:25] <lifeless> abentley: ok, cool
[21:25] <lifeless> so it looks ok to you?
[21:25] <abentley> lifeless: yes.
[21:25] <wallyworld> sinzui: will do. thanks.
[21:26] <lifeless> abentley: thanks for the help
[21:26] <abentley> lifeless: you're welcome.
[21:27] <sinzui> wallyworld: I just sent the email I think you remember. It has the text of the messages I send
[21:28] <wallyworld> sinzui: thanks. much appreciated. i need a better email filing system. there's sooooo much of it :-)
[21:28] <sinzui> wallyworld: no you do not. I need to document what I have been doing for the last 15 months
[21:29] <wallyworld> sinzui: wow 15 months of dealing with spam! you poor soul. get it document so we all can help out better :-)
[21:31] <bac> sinzui: did you see my request ^^?
[21:31] <sinzui> bac: sorry I did not. I can review it now
[21:32] <bac> thanks, sinzui!  https://code.launchpad.net/~bac/launchpad/hidden_links/+merge/53911
[21:32] <lifeless> rockstar: whats jsoops?
[21:35] <abentley> lifeless: it's what Brendan Eich says when he reviews his life's accomplishments.
[21:44] <rockstar> lifeless, it's our way of logging js errors.
[21:45] <lifeless> rockstar: they get passed back to the server?
[21:45] <rockstar> It's not really defined right now, but we're in the process of doing that.
[21:45] <rockstar> lifeless, *kinda*  It's still being defined.
[21:45] <lifeless> rockstar: you might like to add anything constraints wise you come up with to dev.launchpad.net/LEP/OopsDisplay
[21:45] <rockstar> The very basics of it is "have javascript write a img with the src="/jsoops?<oops-contents>"
[21:46] <lifeless> rockstar: I'm putting together a redo of the entire oops stack to be more agile and reusable across teams
[21:50] <mwhudson> rockstar: does this work of Y.on('error') or something?
[21:51] <rockstar> mwhudson, well, we had a global event called one:error that has some extra handling (like providing feedback to the user).
[21:52] <mwhudson> ah ok
[21:52] <wgrant> lifeless: Did you get the code import worker sorted out?
[21:52] <rockstar> We don't yet have error handling inside YUI just yet, simply because it steps on our current jsoops infrastructure.
[21:52] <lifeless> wgrant: the librarian usage question? its for the librarian uploader ha rt ticket
[21:54] <beuno> mwhudson, the idea is that if *anything* fails, even YUI, it's silently reported to our servers
[21:54] <beuno> I picked that up after talking to one of the gmail devs
[21:54] <rockstar> beuno, unfortunately, YUI kills our existing jsoops stuff.
[21:54] <beuno> said that's how they managed to roll out so much crack to so many browsers
[21:54] <beuno> rockstar, yeah, need to give it some love again
[21:54] <rockstar> beuno, already on it.
[21:54] <rockstar> (well, kinda)
[21:55]  * beuno pretends to not have read that
[21:55] <lifeless> beuno: lp will want that real badly
[21:55] <thumper> lifeless: can you mentor wgrant's review https://code.launchpad.net/~thumper/launchpad/add-publishing-for-factory-distro-sourcepackage-bug-tasks/+merge/53733 ?
[21:55] <lifeless> beuno: I suspect my oops stuff will be highly relevant
[21:55]  * thumper waves at beuno and rockstar
[21:55] <thumper> splitters!
[21:55]  * rockstar waves at thumper
[21:56] <beuno> heh
[21:56] <beuno> hi thumper!
[21:56] <beuno> lifeless, yeah, I only spent a few days on it like 5 months ago, it needs some love and documentation to be able to be used company-wide
[21:57] <lifeless> beuno: json format ?
[21:57] <beuno> lifeless, well, it sends it back as a url, so we don't need js to do any mangling (it did fail, so it can't be depended on)
[21:58] <beuno> once we finish making it play nice with yui, we need something in the backend to parse it
[21:58] <lifeless> beuno: ok
[22:01] <leonardr> thumper: https://code.launchpad.net/~leonardr/lazr.restful/forbid-reference-to-entry-not-published-in-this-version/+merge/53918
[22:01] <leonardr> not 100% happy with the implementation, but see what you think
[22:02] <thumper> leonardr: ok...
[22:03] <thumper> leonardr: with the VersionedObject addition, will this mean any locations in LP will need to be fixed?
[22:03] <thumper> leonardr: or is that wrapped in the entry code?
[22:15] <sinzui> huwshimi: http://people.canonical.com/~curtis/out-4.ogv demonstrate call-to-action links create by an :after pseudo class
[22:16] <huwshimi> sinzui: Very nice!
[22:16] <huwshimi> sinzui: How do you make the arrows?
[22:16] <huwshimi> sinzui: Are they an ascii character?
[22:19] <sinzui> huwshimi: http://pastebin.ubuntu.com/581829/
[22:20] <huwshimi> sinzui: Nice work
[22:22] <sinzui> huwshimi: I wanted to use something more semantic and implicit <em><a>test..., but the pseudo class has to be on the parent element to hover correctly. So I used an explicit class
[22:28] <thumper> is LP on python 2.6 or python 2.7 ?
[22:29] <wgrant> 2.6
[22:29] <wgrant> Lucid doesn't have 2.7.
[22:29] <wgrant> :(
[22:29] <huwshimi> sinzui: I can hear you
[22:36] <thumper> https://code.launchpad.net/~thumper/launchpad/blueprint-linked-bug-tasks/+merge/53734 needs a mentor review :)
[22:41] <LPCIBot> Project db-devel build #463: FAILURE in 4 hr 56 min: https://hudson.wedontsleep.org/job/db-devel/463/
[22:46] <lifeless> wgrant: did you look at the rt I mentioned? - the buildmaster xmlrpc thing
[22:47] <wgrant> lifeless: The code import worker thing?
[22:47] <wgrant> lifeless: That I asked you about an hour ago?
[22:47] <lifeless> wgrant: I referenced two things
[22:47] <lifeless> 08:00 < lifeless> wgrant: jelmer: can either of you loook at  https://rt.admin.canonical.com/Ticket/Display.html?id=42954 and answer toms debugging question?
[22:48] <lifeless> and
[22:48] <lifeless> do the LP code import slaves need access to the librarian ?
[22:48] <thumper> yes, I think sop
[22:48] <wgrant> lifeless: 42954 is code imports, not buildmaster.
[22:48] <thumper> we store the logs there
[22:48] <wgrant> But yes, I think the import slaves need librarian access.
[22:48] <lifeless> oh bah, it is
[23:01] <lifeless> and no, not sorted
[23:13]  * thumper has to get out of the house
[23:36] <wgrant> lifeless: What is blocking the HA librarian? Complete identification of all the required firewall holes?
[23:42] <lifeless> yes
[23:43] <lifeless> there is an rt for it, don't have the number offhand but you should be able to see it