[00:27] <wgrant> sinzui: How close is the merge QA?
[00:34] <lifeless> wgrant: thanks for backing out the batchnav landing
[00:34] <wgrant> lifeless: I see you've fixed p-r-f. Thanks.
[00:34] <wgrant> I'll be looking at the API timeout regression this morning.
[00:35] <wgrant> Once I do a bit more QA.
[00:37] <poolie> hi all
[00:45] <lifeless> wgrant: awesome, thanks.
[00:45] <lifeless> poolie: morning
[01:23] <LPCIBot> Project devel build #632: FAILURE in 4 hr 46 min: https://lpci.wedontsleep.org/job/devel/632/
=== StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews
[02:34] <wgrant> poolie: OOPS-1929D68 (from bug #736421) doesn't sound like a qastaging OOPS...
[02:34] <_mup_> Bug #736421: Person:+delete timeouts : Connect the UI the merge jobs <merge-deactivate> <qa-needstesting> <timeout> <Launchpad itself:Fix Committed by sinzui> < https://launchpad.net/bugs/736421 >
[02:35] <poolie> maybe i used the wrong domain?
[02:36] <wgrant> poolie: Could you test on qastaging again?
[02:36] <poolie> i will
[02:36] <wgrant> We need to get this QA'd ASAP.
[02:36] <wgrant> Thankks.
[02:36] <poolie> i blame url completion
[02:37] <wgrant> Heh.
[02:37] <poolie> either that or sunspots
[02:37] <poolie> hm so qastaging still thinks it has a ppa, even though i deleted the ppa from lpnet yesterday?
[02:38] <wgrant> poolie: qastaging updates manually, every month or so.
[02:38] <wgrant> staging updates once a week.
[02:38] <wgrant> s/updates/restores/g
[02:39] <wgrant> You might need DB hacking to get the PPA deleted :(
[02:40] <wgrant> But that is easily done.
[02:41] <wgrant> poolie: So, request deletion of the PPA, and we'll SQL it.
[02:41] <poolie> ppa deletion is broken only on qas?
[02:41] <wgrant> Since the publisher doesn't run on qas, so it will stay DELETING forever.
[02:42] <wgrant> The UI sets the status to DELETING, and then the publisher comes along, deletes it from disk, and sets it to DELETED.
[02:42] <wgrant> qas doesn't have a publisher.
[02:42] <poolie> right
[03:17] <wallyworld_> lifeless: is this one ok now? https://code.edge.launchpad.net/~wallyworld/launchpad/disabled-project-bugs-shown/+merge/57265
[03:20] <lifeless> wgrant: rereview ^ and I will mentor
[03:21] <wgrant> lifeless: I'm rereviewing another of wallyworld_'s branches at the moment, but I'll get to it soonish.
[03:23] <lifeless> wgrant: no panic
[03:23] <wgrant> Not for this, at least...
[03:23] <StevenK> wgrant: Would you accept http://pastebin.ubuntu.com/593393/ , or is it still dangeous?
[03:24] <StevenK> *dangerous
[03:24] <wgrant> StevenK: Still dangerous.
[03:24] <StevenK> :-(
[03:24] <StevenK> wgrant: Even though they don't share an archive?
[03:25] <wgrant> StevenK: The initialisation and the builds it creates will work, but will live you in a bad state.'
[03:25] <wgrant> We need to either decided that that bad state is OK, or fix it.
[03:27] <StevenK> wgrant: What sort of bad state?
[03:27] <wgrant> StevenK: The source has some binaries identical, some different.
[03:28] <StevenK> wgrant: But we can even get that behavior with Ubuntu.
[03:30] <wgrant> StevenK: Oh?
[03:30] <wgrant> You can't have two different binaries with the same name in the same archive.
[03:30] <wgrant> So no, you can't.
[03:30] <StevenK> wgrant: Say 'libuser' is uploaded to Maverick, and it builds successfully on amd64, and i386, and fails on powerpc. The powerpc build isn't given back during Maverick's cycle. Natty opens, and the libuser amd64 and i386 binaries are copied in, and the powerpc build is re-created and is successful. So now we have some binaries identical and one different.
[03:31] <wgrant> StevenK: Not different: unique.
[03:31] <wgrant> The source is still copiable. There is no binary conflict.
[03:32] <StevenK> Your concern is that if a series is derived while say, libuser is building we won't be able to copy the source?
[03:33] <wgrant> Something like that.
[03:33] <wgrant> This may be acceptable, but we need to think very carefully.
[03:33] <wgrant> And see if there is a way we can fix it, because it's a problem for PPAs too.
[03:34] <StevenK> wgrant: So even with that change, it's -1?
[03:35] <wgrant> StevenK: Until I see discussion of the potential damage, yes.
[03:35] <wgrant> Primary archive corruption is not something to be taken lightly.
[03:35] <StevenK> I'm still failing to see how two seperate archives can impact each other.
[03:36] <wgrant> They will not directly.
[03:37] <StevenK> wgrant: Okay, would you mind explaining how this damage could occur? I'm afraid I don't see it yet.
[03:39] <wgrant> StevenK: I can't think of a common case in this immediate feature that would be broken by the differing binary sets. But it is going to be very confusing, has potential to break future workflows, and is a problem that already plagues PPAs.
[03:40] <wgrant> It is possible that the confusion is acceptable. We could declare that it is fine.
[03:40] <wgrant> But we need to solve this at some point, and now is a good time to do that.
[03:40] <wgrant> Until we've had this discussion it should not be permitted.
[03:41] <wgrant> Copies will not work unless the copied source and series has a superset of the binaries that are in the target archive.
[03:41] <wgrant> So creating conflicting sets makes some copies impossible.
[03:45] <StevenK> wgrant: So, my current thought is this: I have a bug that states that derivation is impossible while builds are pending. The change I'm proposing helps with that, but I'm happy to open a new bug echoing your concerns and you, Julian and I can discuss it and come up with a solution?
[03:45] <wgrant> StevenK: It helps with that by potentially creating bad state. The correct solution should be discussed in the bug.
[03:46] <StevenK> Right, I can see that I'm only going to please you by having a fully correct solution.
[03:47] <StevenK> wgrant: I've reverted to the __nonzero__ call that was the other push-back, do I need to fix that properly too?
[03:47] <wgrant> StevenK: I will not let potential breakage in without a discussion of the potential breakage!
[03:47] <wgrant> Particularly when it comes to primary archives.
[03:48] <wgrant> Primary archives are serious business.
[03:48] <StevenK> wgrant: I'm just frustrated, we've been arguing about this for hours!
[03:53] <StevenK> wgrant: So, yes __nonzero__, or no __nonzero__?
[03:53] <wgrant> StevenK: I do not strictly forbid it, but I suspect lifeless will.
[03:54] <StevenK> lifeless: ^
[03:54] <lifeless> hi guys
[03:54] <StevenK> wgrant: The reason I ask was we saw that SQLObject doesn't provide .is_empty()
[03:54] <lifeless> whats up
[03:54] <lifeless> StevenK: it provides it
[03:54] <lifeless> StevenK: the interface declaration is bogus
[03:55] <lifeless> I looked this up yesterday
[03:55] <StevenK> lifeless: I couldn't do it with methodcaller() yesterday when I tried?
[03:56] <lifeless> StevenK: thats correct, because the security proxy is stopping you calling the method
[03:56] <StevenK> Oh, sigh
[03:56] <lifeless> StevenK: your options are:
[03:56] <lifeless>  - removeSecurityProxy
[03:56] <lifeless>  - allow the attribute in a lp config.zcml
[03:56] <lifeless>  - fix the interface declaration in storm/zope/interfaces.py
[03:57] <StevenK> The last one sounds like the proper solution
[03:57] <StevenK> But likely requires a new storm
[03:57] <lifeless> StormResultSet does not have __nonzero__, and I think its likely it won't ever, given the overhead of accidental evaluation.
[03:57] <lifeless> I'm having one of those days
[03:57] <StevenK> lifeless: lp:storm is fine to fix?
[03:58] <lifeless> I'll put a new storm together for you after I enicreamenate
[03:58] <StevenK> After you ... what?
[03:58] <lifeless> StevenK: lp:storm will break lp on two counts: datetime marshalling has changed, and we're running with a WITH patch that is still under review.
[03:58] <lifeless> enicecreaminate
[03:58] <StevenK> Oh
[03:58] <StevenK> No wonder dict(1) didn't know the word
[04:01] <wallyworld_> poolie: 740338 (dup of 513591) doesn't seem to be an issue anymore. but 735290 still is. you last commented on the first bug mentioned on 2011-04-10. did you see that is was broken at that time?
[04:01] <wallyworld_> just trying to see if something has been fixed in the past few days
[04:02]  * poolie looks
[04:03] <poolie> wallyworld_: hi
[04:04] <wallyworld_> yello
[04:04] <poolie> so jools was hitting bug 513591, and because of that he then hits bug 735290
[04:04] <_mup_> Bug #513591: Assignee selector on +filebug trashes form input due to missing javascript <dhrb> <lp-bugs> <regression> <story-ajaxify-dupe-finder> <Launchpad itself:Triaged by wallyworld> < https://launchpad.net/bugs/513591 >
[04:04] <_mup_> Bug #735290: changing Project drop down in project group +filebug loses all your work <ajax> <bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735290 >
[04:04] <wallyworld_> poolie: there around 9 dups of that bug
[04:04] <poolie> right
[04:04] <wallyworld_> poolie: the assignee selector is not blue anymore - the ajax link works
[04:04] <poolie> i think it's the 735290 part that makes it super annoying
[04:04] <poolie> right
[04:04] <wallyworld_> on qastaging and lp.net
[04:05] <poolie> but 735 can still be hit in other cases, as described on that bug
[04:05] <poolie> there are several other things that are very nearly dupes of it
[04:05] <wallyworld_> poolie: yes, so i'll fix the project drop down
[04:05] <wgrant> wallyworld_: Still blue for me.
[04:05] <wallyworld_> and others that i can see
[04:05] <wallyworld_> wgrant: ??
[04:05] <poolie> well, really https://bugs.launchpad.net/launchpad/+bug/553946 is the key thing
[04:05] <_mup_> Bug #553946: JavaScript breaks ability to recover +filebug form data <bugjam2010> <lp-bugs> <story-ajaxify-dupe-finder> <Launchpad itself:Triaged> < https://launchpad.net/bugs/553946 >
[04:05] <poolie> https://bugs.launchpad.net/launchpad/+bug/553946/comments/4
[04:05] <_mup_> Bug #553946: JavaScript breaks ability to recover +filebug form data <bugjam2010> <lp-bugs> <story-ajaxify-dupe-finder> <Launchpad itself:Triaged> < https://launchpad.net/bugs/553946 >
[04:05] <wallyworld_> wgrant: works fine for me. wonder what gives?
[04:05] <wgrant> wallyworld_: The assignee selector on +filebug?
[04:06] <wallyworld_> wgrant: yes
[04:06] <wgrant> Which browser?
[04:06] <wallyworld_> wgrant: ff4
[04:06]  * wallyworld_ think he will have to open ff3
[04:06] <wgrant> Intriguing! FF works.
[04:06] <wgrant> Only broken in Chromium.
[04:06] <wallyworld_> zh
[04:06] <wallyworld_> ah
[04:07] <wgrant> I didn't realise that.
[04:07] <poolie> i would be thrilled if that is fixed
[04:07] <wallyworld_> wgrant: still, even with js off or whatever, it's bad that people lose their work
[04:07] <wgrant> Definitely.
[04:07] <wallyworld_> wgrant: not sure how to solve it though in the non js case
[04:08] <poolie> what happens in the non jscase?
[04:08] <poolie> a separate form?
[04:08] <wallyworld_> poolie: try ff :-)
[04:08] <wallyworld_> poolie: i think a separate page, yes
[04:08] <wallyworld_> poolie: haven't tried without js recently
[04:08] <wgrant> wallyworld_: The link should be hidden without JS.
[04:09] <poolie> anyhow imbw but i think the key thing there is not to dynamically add the textarea
[04:09] <wallyworld_> wgrant: forcing people to type directly into the assignee text field?
[04:10] <wgrant> wallyworld_: Yes.
[04:11] <wallyworld_> poolie: i haven't looked yet at the implementation, but you're talking about the deleting of people's work when the project changes when you refer to the textarea?
[04:11] <thumper> poolie: want a catch up chat?
[04:11] <wgrant> No other way to do it, really...
[04:11] <wallyworld_> wgrant: yeah, agreed
[04:11]  * wallyworld_ wonders why it broke on chrome. will look into that
[04:12]  * wallyworld_ needs food first
[04:12] <poolie> thumper: sure
[04:13] <poolie> want to try voip?
[04:13] <thumper> poolie: sure
[04:13] <thumper> poolie: mumble or sip?
[04:13] <poolie> what's my name again?
[04:13] <thumper> poolie: Martin
[04:13] <poolie> 7806
[04:13] <poolie> on sip
[04:13] <poolie> can you try calling me?
[04:14] <thumper> I can tru
[04:14] <thumper> try
[04:21] <lifeless> StevenK: https://code.launchpad.net/~lifeless/storm/bug-759384 - am merging it up to our storm now
[04:24] <StevenK> lifeless: Are you self-reviewing, or are you looking for a +1?
[04:26] <lifeless> StevenK: neither, just letting you know
[04:26] <lifeless> StevenK: you can apply that locally to your unpacked storm egg to do your testing without waiting for me
[04:26] <lifeless> wgrant: what was that egg-info chicken
[04:27] <lifeless> nvm
[04:27] <StevenK> lifeless: Love the docstring error that you corrected for __nonzero__.
[04:28] <lifeless> StevenK: yah. c&p FTW
[04:28] <lifeless> dist/storm-0.18.0.99-lpwithnodatetime-r392.tar.bz2 is in the download cache
[04:29] <lifeless> StevenK: do a bzr update there, and update the version in versions.cfg; then bin/buildout and you are good to go.
[04:30] <StevenK> I shall, after lunch
[04:50] <lifeless>  https://bugs.launchpad.net/launchpad-project/+bugs?search=Search&field.status=New triage is falling behind
[04:53] <wgrant> It would help if my bookmark was launchpad-project instead of just launchpad.
[04:53]  * wgrant fixes.
[04:55] <wgrant> I guess bug #758758 wants to be moved to bzr?
[04:55] <_mup_> Bug #758758: bzr out of memory during auto-build <Launchpad itself:New> < https://launchpad.net/bugs/758758 >
[04:56] <wgrant> poolie: ^^
[05:02] <lifeless> iz dupe I think
[05:02] <wgrant> Of a fix-released bug.
[05:02] <wgrant> So not really.
[05:11] <wgrant> wallyworld_: Rereviewed your picker branch. Sorry about the delay.
[05:12] <wallyworld_> wgrant: np. i've had other stuff to keep me busy
[05:13] <wgrant> Looking at your disabled projects one now.
[05:22] <StevenK> lifeless: Your storm stuff has landed?
[05:23] <lifeless> StevenK: no
[05:23] <lifeless> StevenK: I've added an egg with it to the downloadcache
[05:24] <lifeless> you just need to update your versions.cfg to use it
[05:24] <lifeless> I've proposed a branch to storm
[05:24] <lifeless> but we're running a fork anyway
[05:30] <StevenK> Oh, you have to got to be kidding me.
[05:31] <StevenK> IDistroSeries.section is a SQLObjectResultSet, but IDistroSeries.components is a list.
[05:31] <StevenK> s/\(section\)/\1s/
[05:33] <StevenK> And the XXX in IDistroSeries.components makes me sob.
[05:40] <lifeless> oh grah
[05:40] <lifeless> 'incomplete bugs' links to 'expirable bugs'
[05:40] <lifeless> THESE ARE NOT THE SAME
[05:41] <wgrant> StevenK: components is a list for cachability.
[05:46] <lifeless> wgrant: so, in cases like this - task on bzr [core work happens there], task on lp [have to deploy the resulting work]
[05:46] <StevenK> wgrant: But then I can't just call is_empty() on it :-(
[05:47] <wgrant> StevenK: Yeah :(
[05:47] <wgrant> lifeless: I guess.
[05:52] <StevenK> wgrant: When IDistroSeries get Stormified, that point is moot, isn't it, since ResultSets can be easily cached?
[05:53] <lifeless> wgrant: its what we do elsewhere
[05:53] <lifeless> StevenK: ResultSet doesn't cache
[05:53] <lifeless> StevenK: and you can use storm queries on sqlobject base classes
[05:54] <lifeless> StevenK: so I'm confused about what you're saying/the problem you're facing
[05:54] <StevenK> lifeless: I'm just wondering if we can drop the list() in IDistroSeries.components
[05:54] <wgrant> No.
[05:55] <lifeless> StevenK: only if we stop using it
[05:55] <StevenK> Sorry, I wasn't being clear, I don't mean now, I mean 'at some point'
[05:55] <lifeless> StevenK: thats what I mean
[05:56] <lifeless> StevenK: if we do a persistence layer like I'm threatening, we'll get rid of all query objects in model code
[05:56] <lifeless> StevenK: (so it wouldn't need listifying, it would /be/ a list)
[05:56] <lifeless> StevenK: alternatively, if we setifiy all our logic, we don't need the attribute
[05:56] <lifeless> StevenK: (but this makes quick-small hacks harder to write)
[06:01] <poolie> hi wgrant
[06:04] <wgrant> Hi poolie.
[06:10] <StevenK> wgrant: +localpackagediffs on staging makes me sad
[06:13] <StevenK> Bleh, more import policy violations
[06:13] <StevenK> wgrant: Can you look over https://code.launchpad.net/~stevenk/launchpad/ids-bugfixes/+merge/57270 again?
[06:14] <wgrant> StevenK: The lack of base versions?
[06:14] <wgrant> bigjools and I were looking at that last night.
[06:16] <StevenK> wgrant: That, but mostly the large number of DSDs with the same version in both Natty and Sid.
[06:16] <wgrant> Ah, yes.
[06:16] <wgrant> Has that fix landed yet?
[06:16] <StevenK> jtv: ^
[06:16] <wgrant> He's EOWed.
[06:17] <StevenK> Ah, bah
[06:17]  * StevenK checks kanban, then
[06:17] <wgrant> Ahh.
[06:17] <wgrant> He ec2'd it 10 minutes before my testfix.
[06:17] <wgrant> So it probably just missed.
[06:17] <wgrant> I might throw it through again.
[06:18] <wgrant> Or you could. We probably don't want to wait until Monday.
[06:18] <StevenK> Yeah, I'm happy to.
[06:18] <StevenK> It's tiny
[06:18] <wgrant> Thanks.
[06:19] <wgrant> lifeless: https://code.launchpad.net/~wallyworld/launchpad/disabled-project-bugs-shown/+merge/57265 and https://code.launchpad.net/~wallyworld/launchpad/assign-non-contributor/+merge/55869 would both like to be mentored.
[06:20] <lifeless> 1.4 second tag summaries so far - with visibility but doublecounting on redundant subscriptions
[06:20] <wallyworld_> wgrant: poolie: that assignee link on the bug page works fine for me in Chrome :-/ wonder why it's broken for you?
[06:20] <poolie> which one?
[06:20] <poolie> on filebug?
[06:21] <wallyworld_> poolie: yes. the one that says "Find..." in blue. except for me it doesn't. it says "Choose..." in green :-)
[06:21] <wallyworld_> so, so far i'm unable to see the reported problem
[06:22] <poolie> it is blue for me and sends me to /people
[06:22] <poolie> which seems kind of weird for a non-js fallback
[06:22] <poolie> but i think i've never wanted to click that
[06:22] <poolie> i know the ids of every person i want to assign bugs to
[06:22] <wgrant> wallyworld_: Let me see.
[06:23] <poolie> my complaint with this page is just the more general issue that it breaks history
[06:23] <wallyworld_> poolie: agreed. i'm just curious as to why we're seeing different behaviour. but i think i need to add an option to not show the Find... if there's no javascript
[06:24] <wgrant> wallyworld_: Which URL?
[06:24] <poolie> that would be fine
[06:24] <wallyworld_> wgrant: lp.net/someproject/+filebug
[06:24] <wallyworld_> lp.dev even
[06:24] <StevenK> wgrant: Right, after fighting with utilties/ec2, I've tossed it successfully.
[06:25] <wgrant> wallyworld_: Which domain? launchpad.dev, or bugs.launchpad.dev?
[06:25] <wallyworld_> wgrant: sorry, bugs
[06:25] <lifeless> +            qs = Y.lp.client.append_qs(qs, 'name', vocabulary);
[06:25] <lifeless> 300	+            qs = Y.lp.client.append_qs(qs, 'search_text', search_text);
[06:25] <wgrant> Although neither work for me, we've had cross-domain JS problems like this before.
[06:25] <lifeless> 301	+            qs = Y.lp.client.append_qs(qs, 'batch', BATCH_SIZE);
[06:25] <lifeless> 302	+            qs = Y.lp.client.append_qs(qs, 'start', start);
[06:25] <lifeless> does the javascript client manually track the batching implementation ?!
[06:25] <wgrant> lifeless: Yes, pickers have their own batchnav UI.
[06:26] <wgrant> I didn't realise they did it like that, though :/
[06:26]  * lifeless deadhesks
[06:26] <StevenK> Haha
[06:26] <jtv> wgrant: a db-devel merge caused some trouble, so it's back into EC2
[06:26] <wgrant> jtv: It's a race!
[06:26] <poolie> wallyworld_: oh btw i like the assignee thing a lot
[06:26] <wallyworld_> wgrant: poolie: actually, it works for me using bugs.lp.dev but fails on bugs.lp.net. so something must have been fixed
[06:26] <StevenK> jtv: Ah, should I stop mine? :-)
[06:26] <wallyworld_> poolie: me too :-)
[06:26] <poolie> (i realize there are details to sort out but thumbs up anyhow)
[06:27] <wgrant> wallyworld_: What about qas? Which version Chromium?
[06:27] <jtv> StevenK, wgrant: did you try to land it as well?
[06:27] <wallyworld_> poolie: yeah, it's a first cut. it certainly can be improved but good to get something out there
[06:27] <wgrant> jtv: I asked StevenK to.
[06:27] <wgrant> jtv: Since you're not here.
[06:27] <jtv> Which I'm not.
[06:27] <StevenK> jtv: I *just* threw it at ec2, so I'm happy to kill it.
[06:27] <jtv> Kill.
[06:28] <wallyworld_> wgrant: broken on qas too. 11.0.696.43 beta
[06:28] <wgrant> poolie: Oh dear, that whole form is constructed in JS?
[06:28] <wgrant> poolie: This is revolting.
[06:28] <poolie> yus
[06:28] <lifeless> pop quiz
[06:29] <lifeless> is subsecond tag / count aggregates acceptable ?
[06:29] <poolie> cunningly designed to disable browser history mechanisms
[06:29] <wgrant> No, needs to be <1µs
[06:29] <wgrant> poolie: Indeed!
[06:29] <wgrant> Let's see.
[06:29] <poolie> i spent probably 20m typing into it the other week
[06:29] <poolie> was very sad
[06:29] <wgrant> I think we've all done that :(
[06:30] <lifeless> wgrant: Time: 17.281 ms
[06:30] <lifeless> wgrant: for bzr
[06:30] <lifeless> wgrant: Time: 743.434 ms
[06:30] <wgrant> lifeless: µs, not ms.
[06:30] <lifeless> wgrant: for ubuntu
[06:30] <wgrant> Insufficient.
[06:30] <wgrant> What :/
[06:30] <StevenK> wgrant: I get a Unicode error, you mean microsecond?
[06:30] <lifeless> wgrant: Time: 135.709 ms
[06:31] <lifeless> wgrant: ubuntu anonymous
[06:31] <wgrant> Why is activateConstrainBugExpiration called on *every* page?
[06:31] <wgrant> When it's only used on Product:+configure-bugtracker?
[06:31] <wallyworld_> wgrant: since it works on lp.dev and not qas or lp.net, must be some issue with how we run prod vs local?
[06:31]  * StevenK manages to get ec2 list to hang, so checks AWS by hand
[06:31] <wgrant> wallyworld_: Yeah... I'm trying to work out where we actually hook it up.
[06:32] <wallyworld_> wgrant: a lot of it uses the lp formk infrastructure
[06:32] <wallyworld_> the assignee is a IPersonChoice and there's a standard widget for that
[06:32] <wgrant> We need a new creation form system.
[06:32] <wallyworld_> wgrant: vocabulary-picker.js.template is used and has some pararameters wired in
[06:33] <wallyworld_> wgrant: lp.app.widgets.popup.py is also part of it
[06:33] <wallyworld_> wgrant: it provides VocabularyPickerWidget
[06:34] <wgrant> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[06:34] <lifeless> https://bugs.launchpad.net/launchpad/+bug/758587/comments/10 for folk interested in the summary table
[06:34] <_mup_> Bug #758587: summarising bugs is expensive <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/758587 >
[06:34] <StevenK> "You should not import PrefixFilter from lp.services.log.logger" -- but it's in __all__? I'm confused
[06:34] <wgrant> StevenK: Not here it's not.
[06:35] <StevenK> wgrant: Here, r12811 of devel it is.
[06:36] <wgrant> StevenK: Erm.
[06:36] <wgrant>     'Nullhandler'
[06:36] <wgrant>     'PrefixFilter',
[06:36] <wgrant> Wrong caps, and missing comma.
[06:36] <StevenK> Ah ha
[06:36] <wgrant> So we now have a NullhandlerPrefixFilter
[06:36] <StevenK> wgrant: Right, fixing. Thanks.
[06:38] <wallyworld_> wgrant: <tal:chooseLink replace="structure view/chooseLink" /> in form-picker.pt inserts the javascript from the vocabulary-picker.js.template into the page
[06:39] <wallyworld_> wgrant: but i'm not sure why it all works locally on lp.dev and not elsewhere
[06:39] <wgrant> wallyworld_: Maybe a race?
[06:39] <wgrant> wallyworld_: The form is loaded in a separate request.
[06:40] <wallyworld_> wgrant: maybe. looking into it as we speak.
[06:40] <wallyworld_> wgrant: you mentioned something though about setting cross domain issues?
[06:41] <wallyworld_> seeing
[06:41] <wgrant> wallyworld_: That's not the problem here.
[06:41] <wgrant> Just something we've seen elsewhere.
[06:41] <wgrant> So thought it was best to be exactly sure about where you were seeing it.
[06:41] <wallyworld_> np. didn't think so but just wanted to double check in case i was being stpuid again
[06:42] <wgrant> Ah hm.
[06:45] <wgrant> I wonder if what we're doing is actually legal.
[06:45] <wgrant> I saw some similar strange JS-ignoring behaviour in your branch yesterday.
[06:45] <wgrant> An XSS attempt failed.
[06:45] <lifeless> SpamapS: oh btw
[06:45] <wgrant> <b>, <i> etc worked fine, but <script> didn't.
[06:46] <wgrant> Perhaps Chromium doesn't like inserting JS like this.
[06:46] <lifeless> SpamapS: that api thing you had that was slow
[06:46]  * StevenK waits for 90 second PQM
[06:46] <lifeless> SpamapS: was because you were querying 'related bugs'
[06:46] <lifeless> SpamapS: thats partly fixed in our 'next' schema
[06:46] <SpamapS> lifeless: OOH haha
[06:46] <SpamapS> lifeless: so "please show me all bugs and all their related bugs" ?
[06:46] <wgrant> StevenK: 90s? You mean 45s?
[06:47] <lifeless> SpamapS: show me all bugs I (filed, commented on, assigned to me, subscribed to)
[06:47] <lifeless> SpamapS: the commented-on clause required filtering across both ends of a 4 table join.
[06:47] <StevenK> wgrant: I've not seen that quick, it tends to take a bit to actually get the mail
[06:47] <lifeless> SpamapS: bug table seqscan is 4 seconds on its own.
[06:49] <wgrant> wallyworld_: http://poeticcode.wordpress.com/2007/10/03/innerhtml-and-script-tags/
[06:50]  * wallyworld_ looks
[06:52]  * wallyworld_ hates IE even more if that's possible
[06:52] <wgrant> wallyworld_: It's not just IE, though.
[06:53] <wallyworld_> wgrant: ok. but it's still fun to hate IE :-)
[06:53] <wgrant> Yeah.
[07:03] <StevenK> lifeless: Can haz mentor on https://code.launchpad.net/~stevenk/launchpad/ids-bugfixes/+merge/57270 ?
[07:03] <wgrant> Ah, sorry, forgot about that one.
[07:08] <wallyworld_> huwshimi: are you able to +1 on a ui review?
[07:08] <huwshimi> wallyworld_: Sure.
[07:09] <wallyworld_> huwshimi: it's that picker confirmation one you help me with https://code.edge.launchpad.net/~wallyworld/launchpad/assign-non-contributor/+merge/55869
[07:13] <lifeless> StevenK: whats source_interface: lp.soyuz.interfaces.distributionjob.IInitialiseDistroSeriesJobSource for ?
[07:13] <StevenK> lifeless: It's so the IDSJs can be run using cronscripts/run_jobs.py, and allows me to remove cronscripts/initialise_distro_series.py
[07:14] <lifeless> when would it have a different value ?
[07:14] <StevenK> When the interfaces moves, if ever
[07:14] <StevenK> lifeless: Keep in mind, run_jobs is generic, multiple job runners make use of it.
[07:14] <lifeless> this seems cracked
[07:14] <lifeless> yes, i get that
[07:15] <StevenK> TBBH, the entire job system is crack
[07:15] <lifeless> we should not have things in the config system that are other than knobs-we-want-admins-to-change.
[07:15] <lifeless> thats not config. its code.
[07:16] <StevenK> lifeless: I like being able to drop the cronscript, I've had to kill everything else I liked about that branch due to wgrant. :-(
[07:16] <lifeless> StevenK: I like that too
[07:16] <lifeless> but for 'non end user config' we have zcml
[07:16] <wgrant> lifeless: The generic job runner takes a config section name. So the interface has to be specified there. Yes, this is crap, like DB users.
[07:17] <wgrant> It can be fixed in the post-critical world.
[07:17] <wgrant> Which may happen this year.
[07:17] <lifeless> not saying I like - or dislike - zcml, but we definitely should not be putting non admin knobs into the the lazr.config.
[07:17] <lifeless> right
[07:17] <lifeless> not blocking this on it
[07:17] <lifeless> but - tag, you're it - please file a bug
[07:17] <StevenK> Er, which one of us?
[07:17] <lifeless> StevenK: you
[07:18] <StevenK> Bah
[07:18] <StevenK> lifeless: High? Low?
[07:19] <wgrant> Low tech-debt, IMO
[07:20] <StevenK> Done, bug 759476
[07:20] <_mup_> Bug #759476: run_jobs shouldn't require source interfaces in the schema <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/759476 >
[07:24] <lifeless> thanks
[07:31] <huwshimi> wallyworld_: Reviewed. Sorry for my comment in advance :)
[07:33] <wallyworld_> huwshimi: thanks. actually the lack of space was bothering me too :-) so i'll fix it for  sure before landing. i'd rather out in the effort to get it as right as we can
[07:33] <wallyworld_> put
[07:34] <huwshimi> wallyworld_: Yeah, thanks a lot. I don't like giving such trivial reviews, especially if there's been a bunch of back and forwards already.
[07:34] <wallyworld_> huwshimi: i don't see it as trivial per se. if something needs fixing, it should be fixed. much easier to do it now before landing :-)
=== almaisan-away is now known as al-maisan
[07:35] <huwshimi> wallyworld_: Yeah I agree, it's not a full stop in a comment or something, but it was just once space that I was complaining about :)
[07:36] <wallyworld_> huwshimi: one space that made the buttons look too squashed up and would annoy users :-)
[07:37] <huwshimi> wallyworld_: I know, I know. It's worth doing. I still feel bad though :)
[07:38] <wallyworld_> huwshimi: actually, do you know off hand what css i need to say "every element inside this containing div should have some right padding"?
[07:38] <wallyworld_> i'm thinking i'll use that in the extra-form-buttons class to add the padding to the buttons
[07:39] <wgrant> Is a normal space not sufficient?
[07:39] <wgrant> I guess it might not be wide enough.
[07:39] <wallyworld_> wgrant: i thought nbsp was verbotten?
[07:39] <LPCIBot> Yippie, build fixed!
[07:39] <LPCIBot> Project devel build #633: FIXED in 5 hr 22 min: https://lpci.wedontsleep.org/job/devel/633/
[07:39] <wallyworld_> and that it is best to use css for layout
[07:39] <wgrant> wallyworld_: Doesn't even need to be nbsp
[07:39] <wgrant> A plain old ' ' would do fine.
[07:39] <huwshimi> wallyworld_: You can reference them by their type e.g. button or input or input[type="submit"] depending on what they are and what else is in the div
[07:40] <huwshimi> wallyworld_: For this, if a space is wide enough then I don't think it's bad
[07:41] <wallyworld_> huwshimi: wgrant: ok. i'll use a ' '.  much simpler :-) i just didn't want to the css style nazis to get mad at me :-)
[07:42] <huwshimi> wallyworld_: You will be gotten
[07:43] <wallyworld_> using css is actually cleaner cause then you can just add in other buttons and not worry about also adding in the ' ' each time
[07:43] <wallyworld_> and there's more control and flexibility to adjust it in one spot
[07:43] <wgrant> wallyworld_: Did you have the misfortune to come across subscribe_form_body in lib/lp/bugs/javascript/filebug_dupefinder.js during your investigations earlier?
[07:44] <wallyworld_> wgrant: not in detail. but i know it's there waiting for me :-(
[07:44] <wgrant> This, here, is a good example of why I am pedantic about JavaScript now.'
[07:44] <wgrant> To prevent people from doing... that.
[07:44] <wallyworld_> wgrant: dogfood also shows the issue on chrome so i may need to money patch some stuff for diagnosis perhaps. i'll see how i go.
[07:45] <wgrant> wallyworld_: Interesting.
[07:45] <wallyworld_> monkey. gof i can't type today
[07:45] <wallyworld_> god aaaahhh
[07:46] <wallyworld_> gotta put in a stupid ' ' for huwshimi first though :-P
[07:46] <wgrant> Heh.
=== Ursinha is now known as Ursinha-afk
[08:23] <StevenK> rvba: Shoot
[08:24] <rvba> StevenK: https://code.launchpad.net/~rvb/launchpad/dds-stats-portlet/+merge/57280
[08:24] <rvba> StevenK: I think you're the right person for this ;).
[08:28] <wgrant> StevenK: Any ideas on the lack of base version?
[08:28] <StevenK> wgrant: I've not investigated
[08:28] <wgrant> Ah.
[08:38] <StevenK> rvba: Reviewed
[08:39] <StevenK> wgrant: The script appears to do the right thing
[08:39] <StevenK> wgrant: Which saddens me
[08:40] <rvba> StevenK: thank you.
[08:41] <rvba> StevenK: do you have a suggestion to avoid adding the two booleans to IDistroSeries?
[08:43] <StevenK> rvba: I suspect we don't have a way to get around it -- I suspect the information has to live *somewhere*, I'm just concerned that IDistroSeries is already bloated.
[08:43] <StevenK> rvba: So ignore that bit for now, and fix up the rest. :-)
[08:43] <rvba> StevenK: all right ... so I guess I'll have to leave them where they are. I'll fix the rest.
[08:44] <wgrant> StevenK: Why's it the right thing? Unparsable changelogs?
[08:46] <StevenK> wgrant: What I mean is that the code in the script appears to do the right thing
[08:46] <wgrant> StevenK: Right.
[08:46] <StevenK> More logging would be awesome
[08:46] <wgrant> That's what I Thought.
[08:46] <wgrant> I'll attack mawson once I've finished with this lazr.restful business.
[08:47] <lifeless> actually we can just ignore dupes
[08:47] <lifeless> no point counting them towards closed etc
[08:48] <StevenK> rvba: Anyway, I want to remove that horrible webservice doctest, no fair adding to it.
[08:48] <lifeless> grrrrrr
[08:48] <lifeless>    944 |     22
[08:48] <wgrant> Oh?
[08:48] <lifeless> 949 In-progress bugs
[08:48] <lifeless> out by 5
[08:48] <rvba> StevenK: ok.
[08:48] <StevenK> In fact, I'm working on that now.
[08:49] <StevenK> Since lazr.restful seems to have set out to annoy me.
[08:49] <rvba> StevenK: I was about to propose to do it as part of the fixing I'm doing now ... but since you're on it, I'll just convert my new doctest to a unitest.
[08:50] <lifeless> wgrant: if you want to bend your mind a little
[08:50] <lifeless>  https://bugs.launchpad.net/launchpad/+bug/758587/comments/14
[08:50] <_mup_> Bug #758587: summarising bugs is expensive <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/758587 >
[08:50] <lifeless> OTOH this queries Ubuntu bugs in 235ms
[08:50] <lifeless> which I'm kinda happy about
[08:50] <wgrant> Heh.
[08:50] <lifeless> including privacy
[08:50] <wgrant> Do you have temp table privs on qas?
[08:50] <lifeless> yes
[08:50] <wgrant> Handy.
[08:51] <lifeless> yes.
[08:51] <wgrant> I didn't know that.
[08:51] <lifeless> 22MB of data.
[08:52] <lifeless> about 100MB with indices
[08:52] <wgrant> Not bad.
[08:52] <lifeless> biggest is the unique index @ 35MB
[08:53] <wgrant> lifeless: So, I know you're not really Zopey, but have a look at RequestExpiredView in lib/canonical/launchpad/webapp/error.py
[08:53] <wgrant> lifeless: It clears the request data in __init__.
[08:53] <wgrant> This seems fairly crackful.
[08:53] <wgrant> I've moved it to initialize(), and everything still works.
[08:55] <lifeless> just cooking dinner; I will come look at it in ~ 15-20
[08:55] <wgrant> k'
[08:56] <wgrant> Could also *possibly* fix lazr.restful to use queryMultiAdapter instead of getMultiAdapter to look up the view, but then it's not obvious how to replace the IWebServiceExceptionView adaption check, except perhaps by forcing the view to implement it directly.
[08:56] <wgrant> But I think dangerous view __init__s should probably be avoided.
[08:56] <adeuring> good morning
[08:56] <wgrant> Morning adeuring.
[08:56] <adeuring> hi wgrant!
[08:59] <StevenK> Didn't we have a better way to call the webservice in tests rather than webservice_for_person() ?
[08:59] <wgrant> StevenK: Interesting. DF has 7209 natty base_versions set, 8054 not set. That's more set than staging has, and staging should have more changelogs..
[08:59] <StevenK> Staging looks to have close to zero set
[08:59] <rvba> StevenK: I've tried to find a way to do what DistributionJob.getJobs does without having to had a new method but no luck ... could you take a look for me?
[09:00] <wgrant> StevenK: bigjools said it had 19000 (yes, exactly 19000) unset when I asked him last night. But the script wasn't done yet.
[09:01] <wgrant> And staging is down, yay staging.
[09:02] <StevenK> rvba: getUtility(IInitialiseDistroSeriesJobSource).iterReady(),
=== StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
[09:03] <StevenK> wgrant: I wonder if it completed.
[09:04] <wgrant> StevenK: It probably did. This was a second run after the first run did the same thing.
[09:04] <wgrant> But we should check with the Julian.
[09:04] <StevenK> Right
[09:04] <StevenK> And do it again after jtv's fix lands
[09:04] <StevenK> Or just update dogfood
[09:05] <StevenK> (The database, not the code)
[09:05] <StevenK> Julian seems to be velemently against that, though
[09:06] <wgrant> DF needs to update in two weeks anyway.
[09:06] <wgrant> We can do it then.
[09:06] <StevenK> Perhaps we should cowboy more logging onto staging, so we can get some idea
[09:07] <wgrant> Well, we should check if the script finished first.
[09:07] <lifeless> wgrant: that seems appropriate, *IFF* lazr.restful is creating such a view *before* the oops is written
[09:07] <rvba> StevenK: I did not consider iterReady because it does not look to allow to get the jobs for one distro.
[09:08] <lifeless> wgrant: wgrant the regular publishing machinery does this:
[09:08] <lifeless>  - log the oops
[09:08] <lifeless>  - figure out how to show the error
[09:08] <StevenK> rvba: I doubt there are going to be many IDSJs
[09:08] <lifeless> wgrant: why doesn't the api stuff do that [not to mention, why does the api have its own publisher]
[09:08] <wgrant> lifeless: The lazr.restful exception handler is a bit special, since it needs to handle errors that should be returned as 400s, for example.
[09:09] <wgrant> lifeless: So it looks up the view for the exception, and checks if it can be adapted to IWebServiceExceptionView
[09:09] <wgrant> lifeless: If not, it reraises.
[09:09] <wgrant> lifeless: I'm not sure how avoidable this duplication is.
[09:09] <lifeless> wgrant: I understand its special; I don't understand why it needs to be different to the main publisher
[09:09] <lifeless> e.g.
[09:09] <rvba> StevenK: ok ... so I guess you mean I should get the right job in python.
[09:09] <wgrant> lifeless: Neither.
[09:09] <lifeless> more code to delete.
[09:09] <lifeless> after criticals.
[09:10] <rvba> StevenK: I'll do that but I don't like it.
[09:10] <wgrant> Yeah.
=== Ursinha-afk is now known as Ursinha
[09:19] <rvba> StevenK: iterReady fetches only jobs with status Job.ready_jobs and I think I really need all jobs with a status in PENDING_STATUSES (WAITING, RUNNING, SUSPENDED)
[09:27] <StevenK> rvba: Then I suggest a better name than a generic getJobs
[09:27] <rvba> StevenK: all right ... getPendingJobsForDistribution ;-)
[09:59] <bigjools> wgrant: hello
[10:04] <wgrant> bigjools: Hi.
[10:05] <bigjools> wgrant: I'm interested to hear about your discussion with StevenK regarding initialising from distros with builds in progress
[10:05] <wgrant> bigjools: Well, for initialisations within an archive you will never be able to copy that source in that archive ever again.
[10:06] <bigjools> wgrant: what do you mean by within?
[10:06] <wgrant> bigjools: For inter-archive initialisations you end up with confusion and binaries that are mostly copiable between archives, except not quite.
[10:06] <wgrant> bigjools: eg. a new series of Ubuntu.
[10:06] <wgrant> Doesn't cross archives.
[10:07] <bigjools> so firstly, we're never going to allow intra-archive copies with builds in progress
[10:07] <wgrant> Well, that original code did.
[10:07] <bigjools> StevenK wasn't listening to me the other week then :)
[10:07] <bigjools> secondly, can you expand on the inter-archive problem?
[10:08] <bigjools> the plan was to reset BUILDING to NEEDSBUILD
[10:08] <wgrant> bigjools: A source has built on i386 and amd64 in Ubuntu, but is still pending on armel.
[10:08] <wgrant> bigjools: We initialise a new distribution from this Ubuntu series.
[10:09] <wgrant> The series eventually have identical i386 and amd64 binaries, but the two armel builds produce different binaries.
[10:09] <bigjools> how?
[10:09] <wgrant> There are two builds... they will produce different binaries.
[10:10] <bigjools> they are using the same dependencies, I don't see how
[10:10] <bigjools> but anyway, so what?
[10:11] <wgrant> The functional differences may not be significant, true. But regardless those two sources become incompatible, as each has a subset of the other's binaries. This is a problem we see fairly often in PPAs already, and is going to become far worse the next time we add another PPA architecture.
[10:11] <wgrant> It is probable that none of the derivation workflows at the moment have a problem with this situation.
[10:12] <bigjools> I still don't see why that's a problem
[10:13] <wgrant> bigjools: For PPAs it breaks copies... Upload to a series with (i386, amd64, lpia), copy to a series with (i386, amd64, armel) which creates a new armel binary, and you can never copy that source again.
[10:14] <wgrant> I can't see where that is going to come up immediately in the derivation case.
[10:14] <bigjools> how does it create a new armel binary?
[10:14] <wgrant> bigjools: Because there is no existing armel binary, a new build will be created.
[10:14] <wgrant> (the upload series did not have armel)
[10:15] <bigjools> I can't remember if we do that automatically or not
[10:15] <wgrant> We don't have the pending build issue in PPAs because we forbid such copies.
[10:15] <wgrant> We do.
[10:15] <wgrant> All source copies run createMissingBuilds.
[10:15] <wgrant> Similar things happen when copying between PPAs with incompatible sets of architectures.
[10:15] <bigjools> what part of the copy checker prevents copying the source again?
[10:15] <wgrant> The whole of it.
[10:15] <wgrant> That's what CopyChecker does.
[10:15] <bigjools> specifically which check?
[10:15] <wgrant> Oh, you mean the build thing?
[10:15] <bigjools> yes
[10:15] <wgrant> It's crackful and broken and wrong, but let me find it...
[10:17] <wgrant> Hmm. It looks like it relies on the destination archive having the pending builds, which only works for intra-archive copies.
[10:17] <wgrant>             if build_summary['status'] in building_states:
[10:17] <wgrant> Around line 315.
[10:18] <wgrant> So, I can be convinced to allow inter-archive copies of pending builds if we acknowledge the issue, but the fact that the check was removed unconditionally strongly suggested that it had not been discussed.
[10:18] <wgrant> And I will not permit undiscussed corruption of primary archives :)
[10:19] <bigjools> yes sir
[10:19] <wgrant> (I was the reviewer)
[10:20] <bigjools> can you explain in English why the copy is prevented? :)
[10:20] <lifeless> [no]
[10:20] <lifeless> :P
[10:21] <wgrant> bigjools: For the inter-archive case? Not directly, no. It has definite undesirable consequences, but none are fatal.
[10:21] <StevenK> wgrant: The check was removed unconditionally was because I thought it was fine. I'm happy to admit I'm wrong
[10:21] <wgrant> None are *obviously* fatal.
[10:21] <wgrant> In present workflows.
[10:22] <bigjools> wgrant: let me re-phrase this so I get the answer I am looking for.  What check, in English, prevents re-copying the same source in a PPA after the above situation?
[10:22] <wgrant> Oh.
[10:22] <wgrant> That check.
[10:22] <wgrant>             if not copied_binaries.issuperset(published_binaries):
[10:22] <wgrant>                 raise CannotCopy(
[10:22] <wgrant>                     "binaries conflicting with the existing ones")
[10:24] <wgrant> (is that broken? possibly. the whole binary copying system is a bit iffy :/)
[10:24] <bigjools> what part of "in English" passed you by? :)
[10:25] <bigjools> in any case, I'm trying to work out why that check is in place
[10:25] <wgrant> bigjools: The check exists to prevent copying in duplicate binaries.
[10:25] <wgrant> You can end up with some archs' binaries matching, and others differing.
[10:26] <wgrant> If you permitted the copy then you would have multiple binaries with identical names.
[10:26] <bigjools> so if we have the extra armel in the target PPA and we copy again,  why is that bad?
[10:27] <wgrant> If there is only one set of armel binaries, nothing.
[10:27] <wgrant> s/nothing/it's not/
[10:28]  * bigjools has to run off for 10 mins
[10:28] <bigjools> bbr
[10:28] <bigjools> brb
[10:30] <lifeless> headdesk
[10:30] <lifeless> select count(*) from (select distinct bugtask.bug from bug,bugtask where bug.id=bugtask.bug and bugtask.distribution=1 and (not bug.private or exists (select true from teamparticipation,bugsubscription where bugsubscription.bug=bug.id and teamparticipation.person=2 and teamparticipation.team=bugsubscription.person)) and bugtask.status=22 and bug.duplicateof is NULL) as _tmp;
[10:30] <lifeless>  count
[10:30] <lifeless>    944 |     22
[10:30] <lifeless> -------
[10:30] <lifeless> -so close-
[10:31] <lifeless>    943
[10:31] <lifeless> but I think this is the duplicate subscription miscounting
[10:32] <lifeless> which I can live with.
[10:40] <bigjools> wgrant: sorry, back
[10:42] <bigjools> wgrant: considering we'll never copy binaries when syncing from the parent distro, I don't think that check will ever trigger will it?
[10:42] <bigjools> the binary copy will only happen on init
[10:42] <wgrant> bigjools: At the moment we won't, no.
[10:42] <wgrant> But it's possible in OEM's insane structure that they'll want to.
[10:43] <bigjools> wgrant: it's not possible to do in the current design
[10:43] <wgrant> Say you have a hierarchy, and add a new arch in the top shared project, and copy down a layer.
[10:43] <bigjools> I also think each project is single arch
[10:43] <wgrant> You probably don't want to rebuild stuff in the second layer unless necessary.
[10:44] <wgrant> bigjools: Well, an OEM could conceivably have common branding and utilities on i386 and ARM projects.
[10:44] <wgrant> It's not *too* contrived a situation.
[10:44] <wgrant> But it's not immediately applicable.
[10:44] <bigjools> wgrant: I still don't really grok why that check is written like it is
[10:44] <wgrant> But it needs to be considered.
[10:44] <wgrant> bigjools: It's a cheap way of checking that the files aren't duplicated, I guess.
[10:44] <bigjools> too cheap it seems
[10:45] <wgrant> Indeed, although some of the issues would still fall afoul of a duplicate file check.
[10:45] <wgrant> It gets really messy when you can have partial copies :/
[10:45] <bigjools> wgrant: are you happy with the workflow we have now?
[10:46] <bigjools> I need to get this resolved.  Not being able to init with builds in progress is a blocker, I can't see anyone ever being able to initialise otherwise.
[10:46] <wgrant> bigjools: As long as the issue is recognised I am happy enough with inter-archive copies.
[10:46] <wgrant> It is not a non-issue, and it's certainly never OK to permit it intra-archive, but it's probably acceptable for inter-archive for now.
[10:47] <bigjools> wgrant: and do you think resetting BUILDING to NEEDSBUILD for the binary copies will suffice?
[10:47] <wgrant> bigjools: Resetting? New NEEDSBUILD builds will be created.
[10:47] <bigjools> that's what I mean
[10:47] <wgrant> Right.
[10:48] <wgrant> It's the right way to go. It will result in bad things happening, but we can resolve that when it becomes a problem as long as we acknowledge the issue now.
[10:50] <bigjools> ok thanks for raising the point
[10:50] <bigjools> StevenK, got all that?
[10:52] <wgrant> bigjools: I gather that the DSD population script failed again :(
[10:52] <bigjools> wgrant: yes.
[10:52] <bigjools> wgrant: missing changelogs I expect, but I need to investigate more
[10:52] <bigjools> and jtv's branch didn't land apparently.  Darn
[10:54] <wgrant> bigjools: He sent it off to ec2 again this afternoon.
[10:54] <bigjools> ah good lad
[10:54] <wgrant> Should be landing in half an hour ago.
[10:54] <wgrant> :/
[10:54] <bigjools> e_timewarp_error
[10:55]  * bigjools needs caffeine to cope with this
[11:07] <wgrant> bigjools: It just landed.
[11:07] <bigjools> \o/
[11:07] <wgrant> Half an hour later than I expected, but it's there.
[11:11] <StevenK> wgrant: So, with the issue discussed, the change I mentioned this morning with only checking builds for the same distribution is fine?
[11:15] <wgrant> StevenK: Not "fine", but "OK".
[11:20] <jtv1> bigjools: the fix for bug 757483 has landed on devel.
[11:21] <jtv1> My other branch still needs a bit of nursing, evidently.  Merging in a fresh db-devel broke some things.
[11:21] <bigjools> jtv1: cheers
[11:23] <jtv1> I honestly don't think librarian.txt has any right to fail on that branch.
[11:23] <wgrant> jtv1: That's spurious.
[11:23] <wgrant> jtv1: If it's returning the wrong status code.
[11:23] <jtv1> Oh…  the "this is some data" failure?
=== danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews
[11:24] <jtv1>     UploadFailed: Server said: 200
[11:24]  * danilos is always bad at updating the topic with his OCR info :(
[11:24] <jtv1> excuses
[11:24] <jtv1> Why can't you be more like me—just accept that you can't be bothered
[11:25] <wgrant> jtv1: That's the one.
[11:25] <wgrant> jtv1: If that was the only failure, lp-land!
[11:25] <jtv1> wgrant: no, but it looks like the fixes for the merge-induced problems were simply never pushed
[11:25] <wgrant> Heh.
[11:30] <jtv1> re-ec2'ing now
[11:36] <jtv1> wgrant: it's detached.  I'm off.
[11:39] <lifeless> jkakar: thanks for merging my fix
[11:39] <jkakar> lifeless: Thanks for providing it. :)
[11:39] <lifeless> de nada
[11:40] <jkakar> Que beuno!
[11:40] <jkakar> bueno, even.
[11:40] <lifeless> :)
=== henninge is now known as henninge-lunch
=== al-maisan is now known as almaisan-away
[13:00] <danilos> anyone knows of good examples of collapsible divs in LP UI?
[13:05] <danilos> ah right, PPA page is a good one
[13:05] <bigjools> danilos: ....
[13:05] <bigjools> beat me to it :)
[13:06] <danilos> bigjools, heh :)
[13:06] <bigjools> we're doing the same thing on the derived distros pages
[13:06] <bigjools> wgrant: turns out a load of packages in natty don't have changelogs. Grar.
[13:07] <wgrant> bigjools: Or a lot of recent ones in debian?
[13:07] <wgrant> bigjools: Do you have an example?
[13:08] <bigjools> not looked at debian yet, the script is still running
[13:08] <wgrant> Again? :(
[13:08] <bigjools> StevenK tells me so
[13:08] <bigjools> aalib (which handily has a SPN id of 1) has no changelog in natty for version  1.4p5-38build1
[13:09] <wgrant> When was that uploaded?
[13:09] <wgrant> I guess I could check.
[13:09] <bigjools> checking
[13:09] <wgrant> But that would mean not being lazy.
[13:09] <bigjools> "26 weeks ago"
[13:09] <wgrant> Hmm.
[13:10] <wgrant> And its changelog is null?
[13:10] <bigjools> apparently
[13:10] <wgrant> Can you verify that in the DB?
[13:10] <bigjools> looking at the query output right now
[13:11] <bigjools> http://pastebin.ubuntu.com/593544/
[13:11] <wgrant> datecreated
[13:11] <StevenK> On *dogfood* the SPR's changelog is None
[13:11] <bigjools> this is staging
[13:12] <bigjools> there are 2994 packages in natty that don't have it set, compared to 15042 that do
[13:12] <StevenK> Yes, but when I checked for you on the call, I was prodding dogfood
[13:12] <bigjools> sure
[13:12] <wgrant> bigjools: Oh, so most have it set, OK.
[13:12] <bigjools> I am checking staging too
[13:12] <bigjools> yeah, most
[13:12] <bigjools> trying to work out the remaining ones
[13:12] <wgrant> We started setting it in April last year, except for gina which was Nov/Dec.
[13:12] <bigjools> ah
[13:13] <bigjools> aalib was uploaded 2010-03-05
[13:13] <bigjools> the sid version does have one BTW
[13:14] <wgrant> It may be one of the last few, then.
[13:14] <bigjools> I guess we could just say there's no diff until it's updated for those few
[13:14] <wgrant> Which should be some time this week, right StevenK?
=== henninge-lunch is now known as henninge
[13:14] <bigjools> not for old natty versions?
[13:15] <StevenK> I am going to check on the progress tomorrow afternoon
[13:15] <StevenK> It should be done by Friday, hopefully
[13:16] <wgrant> bigjools: It should be importing everything without a changelog, AIUI.
[13:16] <wgrant> bigjools: Except for expired things.
[13:16] <bigjools> ah cool
[13:16] <bigjools> let's wait until it's finished then
[13:17] <StevenK> And staging is updated
[13:17] <StevenK> So Monday or Tuesday, I guess
[13:19] <bigjools> the thought makes me hungry
[13:35] <maxb> Um.... is it just me, or is the AJAX bug "Subscribe" link broken on production?  (Spins briefly and does nothing)
[13:38] <wgrant> maxb: Are you in the malone alpha team?
[13:38] <maxb> yes
[13:38] <maxb> mute_link is null
[13:38] <wgrant> Yeah.
[13:38] <wgrant> Broken for the alpha team for now.
[13:38] <wgrant> I thought that fix had been deployed, but maybe I was wrong.
[13:40] <wgrant> Bug 753387?
[13:40] <_mup_> Bug #753387: Can't subscribe to bug: Uncaught TypeError: Cannot call method 'get' of null <Launchpad itself:Triaged> < https://launchpad.net/bugs/753387 >
[14:17] <maxb> Sounds like the same thing, just reported differently by firefox
[14:30] <bac> danilos: would you have a moment to do a review?  should be quick.
[14:32] <danilos> bac, sure thing
[14:32] <bac> https://code.launchpad.net/~bac/launchpad/lptestrequest/+merge/57484
[14:34] <bigjools> for the love of .... Google chose *TCL* as a scripting language for Chrome?!
[14:36] <danilos> bac, r=me
[14:36] <danilos> bigjools, isn't it already the 13th? :)
[14:36] <bigjools> danilos: which century?
[14:37] <danilos> bigjools, well, not that far off, but I think April 1st is gone by already :)
[14:37] <bigjools> which is a shame
[14:42] <jcsackett> danilos: do you have time to review https://code.launchpad.net/~jcsackett/launchpad/private-bugs-404/+merge/57244, by any chance?
[14:42] <danilos> jcsackett, sure thing, let me take a look
[14:42] <jcsackett> thanks!
[14:44] <bac> bigjools: really?  oh that is awful.  i had to do a lot of tcl/tk back in the day and it was painful
[14:45] <bigjools> bac: me too.  It's abominable.
[14:45] <bigjools> bac: although I may have misread slightly, I think the TCL folks are the first to produce an interface that works with the Chrome script API
[14:46] <bigjools> I'd love to use Python instead of JS
[14:46] <bac> oh
[14:46] <bac> i'd love to use X instead of JS where X not in [TCL, perl]
[14:50] <danilos> bigjools, unfortunately, world is turning towards JS :( even epiphany, which you could write plugins for in python before, now only supports either natively compiled or JS
[14:50] <bigjools> danilos: it makes me sad to hear that
[14:52] <danilos> bigjools, yeah, me too
[14:53] <abentley> danilos: on the plus side, PyPy seems to be doing well, and it has a JS backend :-)
[14:54] <danilos> jcsackett, r=me
[14:54] <jcsackett> danilos: thanks!
[14:54] <danilos> jcsackett, you are welcome
=== danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
[15:02] <bac> danilos: in one of your yuitests i get a failure
=== abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
[15:03] <danilos> bac, which one is it? node construction ones with waits?
[15:03] <bac> danilos: test_escaping_url
[15:03] <danilos> bac, hum, let me try it out in different browsers
[15:03] <bac> i used ff3
[15:04] <danilos> bac, right, I can see it failing... damn YUI "compatibility" layer... it's probably blindly using browser's implementation of escape() function which seem to differ between browsers
[15:05] <danilos> bac, I don't see a good way around it other than asserting that the text is *not* unescaped (i.e. as-is)
[15:05] <danilos> bac, what do you think?
[15:05] <bac> danilos: i haven't looked at the details of the test yet
[15:06] <danilos> bac, oh, this just makes sure that node.set('url', '...') escapes the URL properly; it's not even a big deal because it's all URLs we produce, but I just wanted to be extra safe
[15:07] <danilos> bac, fwiw, the test passes in webkit browsers like epiphany
[15:08] <bac> danilos: you have other escaping tests.  why do those pass and this one fails?
[15:10] <danilos> bac, the only thing I can think of is that others are for node content, and this one is for node attribute value (ff seems to transform stuff into URL encoding vs. HTML character entities)
[15:10] <danilos> (that might be YUI and not FF, of course)
[15:11] <danilos> bac, basically, what I am doing in the test is reading node.get('innerHTML') and that behaves differently
[15:11] <danilos> (at least)
[15:13] <renata> Hello everybody, I am starting to work with launchpad api, and without launchpadlib, I would like to obtain a list of packages from a specific ubuntu release.
[15:13] <renata> I know that source_package_publishing_history shows me a package based on a package ID. But I would like to get a direct link with a list of all packages, without knowing their IDS.
[15:13] <renata> is it possible?
[15:13] <renata> thanks in advance :)
[15:16] <abentley> renata: there's no central list of what sourcepackages are present in a release.  In our model, sourcepackages are arbitrary combinations of a sourcepackagename and a distroseries.
[15:18] <abentley> renata: You could try archive.getPublishedSources.  Doesn't look like sourcepackagename is required.
[15:19] <renata> abentley ahhh ok!! so I'll try to see getPublishedSources.. if that doens't work I figure something out. thank you very much for the help :)
[15:19] <danilos> bac, I've fixed the test case, fwiw, I am asserting that it's not equal to the originating string now
[15:20] <bac> danilos: ok, that seems reasonable
=== salgado is now known as salgado-lunch
[15:31] <danilos> bac, do you perhaps want to go through the branch on the phone?
[15:31] <bac> danilos: sorry, i know you're in a rush.  i don't think that would help right now.
[15:31] <danilos> bac, np, just checking :) I am not in a big rush, I just want to help as much as I can
[15:46] <BjornT> i've gotten a lot of oopses today while reviewing merge proposals. well, not a lot maybe, but 2  out of 5 or so page loads have oopsed (e.g. OOPS-1929AW110)
[15:46] <adeuring> abentley: could you have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/bug-758902/+merge/57502 ?
[15:47] <gary_poster> I was about to say the same thing, BjornT.  Looks like a librarian might be down.
[15:47] <abentley> adeuring: sure.
[15:49] <gary_poster> abentley, here's another one when you have a chance.  https://code.launchpad.net/~gary/launchpad/bug744888/+merge/57499
[15:50] <abentley> adeuring: r=me
[15:50] <adeuring> abentley: thanks!
[15:51] <abentley> gary_poster: What's the effect of doNotSnapshot?
[15:52] <gary_poster> abentley, it means that Snapshots, which are temporary objects we use typically to send out modify events to show what an object looked like before a webservice change, will not include that particular attribute.
[15:54] <abentley> gary_poster: so that's server-side event handling, not directly related to the web service?
[15:55] <gary_poster> abentley, yes, except that AFAIK, only the webservice changes use them.  I could be wrong on that, but that's certainly where they are used the most consistently.
[15:56] <gary_poster> BjornT, there might have been some misconfiguration for the new LP appservers.  We think it's fixed.  Could you let us know if things seem better?
[15:57] <abentley> gary_poster: Cool.  I think we also use snapshots to generate attribute change emails, e.g. for branches and merge proposals.
[15:57] <gary_poster> ah, cool abentley.
[15:59] <abentley> gary_poster: would StormStatementRecorder work for your test?
[15:59] <gary_poster> abentley, me looks for it.
[15:59] <BjornT> gary_poster: second page load: OOPS-1929AR131
[16:00] <gary_poster> BjornT: :-( ok thanks
[16:00] <abentley> gary_poster: testing/__init__.py
[16:03] <gary_poster> abentley, yeah, that looks simpler, thanks.  I'll switch to that
[16:07] <abentley> gary_poster: I wonder whether there's risk of your SQL check hitting false negatives?  Would it be crazy to just look for the string 'message' in the entire statement?
[16:08] <abentley> gary_poster: I think PEP8 requires an extra blank line at 55.
[16:12] <gary_poster> abentley: looking for message: well...there are also "bugmessage"s in theory...it's obviously a balance between possible false negatives and false positives.
[16:12] <gary_poster> I guess we could try being a bit more aggressive.  I'd be OK with simply splitting on whitespace and making sure there are no strings that start with "message" (which would include tables).  If people find that too restrictive in the future they can adjust the test.  You good with that variation?
[16:12] <gary_poster> abentley: line 55 of test_bug.py?
[16:12] <abentley> gary_poster: line 55 of the diff.
[16:12] <gary_poster> oh sorry
[16:13] <gary_poster> looking
[16:13] <abentley> gary_poster: line 25 or so of test_bug.
[16:13] <abentley> gary_poster: immediately after metaclass = __type__
[16:13] <gary_poster> gotcha.  huh, I'm not familiar with that, and lint didn't complain, but I'm fine with it.  I'll make the change.
[16:13] <gary_poster> And review at PEP 8 later :-)
[16:14] <gary_poster> Oh, line 25 of test_bug?
[16:14] <gary_poster> that has two returns now
[16:14] <gary_poster> though I changed that after the initial MP
[16:15] <gary_poster> maybe you are looking at the email version?
[16:15] <gary_poster> of the diff?
[16:16] <abentley> gary_poster: My apologies, PEP8 says "Separate top-level function and class definitions with two blank lines." and is silent on how to separate other top-level items (except imports).
[16:16] <gary_poster> oh ok cool
[16:18] <abentley> gary_poster: So with your proposed change ("splitting on whitespace..."), r=me.
[16:19] <gary_poster> great, thanks very much abentley!  Glad to know about StormStatementRecorder for this purpose especially.
[16:21] <abentley> gary_poster: np.
=== salgado-lunch is now known as salgado
[16:49] <sinzui> jcsackett: do you have time to mumble now?
[16:49] <jcsackett> sinzui: now is excellent.
[16:55] <henninge> no branches on qastaging ... :(
[16:57] <henninge> ah, just no lp: support ;)
=== beuno is now known as beuno-lunch
[17:10] <jelmer> I've filed bug 759928
[17:10] <_mup_> Bug #759928: linked MP is inaccessible <Launchpad itself:New> < https://launchpad.net/bugs/759928 >
[17:10] <sinzui> jelmer: I am still looking for an oops I can read
[17:11] <maxb> It's not OOPSing any more
[17:11] <jelmer> sinzui: you can't access the OOPS id mention in the bug report?
[17:11] <jelmer> I can pastebin the traceback if that would help
[17:12] <sinzui> jelmer: no, nor the others I have been given. I think oopes are not syncing
[17:14] <sinzui> jelmer: a TB would be very helpful
[17:14] <jelmer> sinzui: I've pasted one in the bug report as a comment
[17:14] <sinzui> thanks
[17:15] <jelmer> sinzui: you can't reproduce the issue with the first URL?
[17:15] <sinzui> ah yes! I followed the wrong link the first time.
[17:15] <sinzui> I am an idiot
[17:18] <sinzui> jelmer: I am a different kind of idiot than I supposed. I did click on the right link.
[17:19] <sinzui> jelmer: The access to the librarian is intermittent. I believe we have a connectivity issue with one of more app servers
[17:20] <jelmer> sinzui: ah, that would explain some things
[17:20] <jelmer> I can sometimes get the page if I refresh often enough
[17:20] <sinzui> I am engaging a losa now
[17:21] <maxb> There definitely seems to be some sort of pattern in the oops prefixes
[17:27] <sinzui> jelmer, lets load that mp url 5 times each to see it is now reliably loads
[17:28] <sinzui> not for me
[17:36] <jelmer> sinzui: just refreshing it 5 times here it failed 3 out of 5
[17:37] <sinzui> i get the same
[17:42] <maxb> I have stuck a load of OOPS codes on the bug
[17:42] <maxb> to demonstrate that it looks to have node affinity
[17:49] <sinzui> maxb: I saw. thanks
[17:49] <sinzui> mthaddon: took the new webapp offline. I think the issue is fixed for now
=== beuno-lunch is now known as beuno
=== Ursinha is now known as Ursinha-afk
[18:56] <bac> abentley: i like the changes to 'bzr lp-land', i assume you did them.
[18:57] <abentley> bac: I changed it to prompt before launching an editor, and to not write the commit message to the proposal.  Is that what you like?
[18:57] <bac> abentley: indeed!
[18:57] <abentley> bac: Cool!  You're welcome.
[20:09] <sinzui> I recall we changed out ftp server recently. I think I make related to https://answers.launchpad.net/launchpad/+question/152715
[20:10] <sinzui> Have we blocked passive-ftp
[20:17] <sinzui> lifeless: thumper, abentley ^
[20:18] <abentley> sinzui: I don't know anything about ftp.
[20:19] <lifeless> sinzui: morning
[20:19] <lifeless> sinzui: we did, poppy died and poppy-sftp now listens on ftp as well
[20:19] <lifeless> sinzui: this is the issue - valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] :
[20:20] <lifeless> sinzui: the poppy-sftp service *also* tries to verify gpg sigs while the client is connected
[20:20] <lifeless> sinzui: it uses GPGHandler
[20:20] <lifeless> sinzui: which uses a /tmp dir
[20:20] <lifeless> sinzui: which the /tmp reaper deletes old files from
[20:21] <lifeless> sinzui: so this means that the gpg.conf for the running poppy-sftp on ppa.launchpad.net has been deleted and needs to be recreated.
[20:21] <lifeless> sinzui: I'm looking up the bug
[20:21] <sinzui> yuck
[20:21] <lifeless> its pure win
[20:22] <lifeless> bug 374019 is what was fixed causing the regression
[20:22] <_mup_> Bug #374019: bad keys result in no response on ppa uploads <email> <lp-soyuz> <oops> <poppy> <qa-ok> <soyuz-upload> <Launchpad itself:Fix Released by julian-edwards> < https://launchpad.net/bugs/374019 >
[20:24] <lifeless> bug 760147
[20:24] <_mup_> Bug #760147: poppy-sftp service has its gpg conf reaped <Launchpad itself:New> < https://launchpad.net/bugs/760147 >
[20:24] <sinzui> fab
[20:25] <lifeless> workaround is to contact losa and have them repair
[20:25] <sinzui> I am starting that now.
[20:25] <sinzui> lifeless: Does the fix for this entail preventing reaping or automatic recreation?
[20:26] <lifeless> sinzui: long term is a code change to either stop using one long gpghandler or put it somewhere else
[20:26] <lifeless> the problem isn't that its in /tmp, its that its written at daemon startup and untouched for 5 days
[20:27] <lifeless> or 4 days or whatever the reaper config is
=== Ursinha-afk is now known as Ursinha
[21:11] <Ursinha> http://i.imgur.com/y7Hm9.jpg
[21:11] <benji> news flash from 2024: the "Sassy Grass Green" squad has moved to maintenance rotation
[21:12] <lifeless> benji: thats 'the stoners' right ?
[21:12] <benji> or people who drive Plymouth cars from the 70s
[21:13] <benji> http://www.flickr.com/photos/paddyspig/5434998200/
[21:13] <lifeless> benji: shiny
[21:14] <lifeless> benji: I want the gocart in the background
[21:14] <Ursinha> lifeless, I wonder why that oops wasn't synced to devpad
[21:14] <benji> lifeless: heh, really; I guess once you run out of room for cars you start hanging them on the wall
[21:15] <lifeless> Ursinha: 12 hour cron IIRC
[21:15] <lifeless> Ursinha: should be synced now, I think
[21:16] <Ursinha> lifeless, I thought sync happened like every 10 minutes
[21:16] <lifeless> Ursinha: for some unknown reason, not on codehosting
[21:16] <lifeless> Ursinha: since you are here
[21:16] <lifeless> Ursinha: I have a small qatagger request
[21:17] <lifeless> I was going to put a patch together, but trunk failed tests for me and I got distracted by a tech review for statik
[21:17] <lifeless> Ursinha: can we stop it setting milestones ?
[21:17] <lifeless> Ursinha: per the thread on -dev about releases being decoupled from downtime
[21:17] <jcsackett> i think i have killed my computer. i can't seem to run tests...
[21:17] <lifeless> we don't need milestones anymore
[21:17] <Ursinha> lifeless, I guess, I haven't stopped because I see a few people still setting it even after your email
[21:18] <lifeless> Ursinha: well, qatagger is the driving force
[21:18] <lifeless> Ursinha: if it stops, I think folk will naturally stop
[21:18] <Ursinha> lifeless, ok, so I'll disable it
[21:18] <LPCIBot> Project windmill build #173: FAILURE in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill/173/
[21:18] <lifeless> Ursinha: thanks!
[21:19] <Ursinha> np :)
[21:20] <sinzui> jcsackett: mumble?
[21:21] <jcsackett> sinzui: sure, one moment.
[21:22] <jcsackett> sinzui: can you hear me?
[21:23] <sinzui> jcsackett: me no hear
[21:24] <jcsackett> sinzui: mumble appears to not be working for me. i did not hear you either.
[21:24] <jcsackett> one moment.
[21:24]  * sinzui kills mumble
[21:24] <lifeless> sinzui: is there anything I can do for you guys today ?
[21:25] <jcsackett> lifeless: make mumble work reliably? :-P
[21:25] <lifeless> use ekiga/empathy with the canonical voip system
[21:25] <sinzui> and unity/compiz. I went belly up and it looks like I am ignoring people
[21:26] <lifeless> it works beautifully, even here where mumble is terrible
[21:26]  * jcsackett makes note of that.
[21:26] <lifeless> if you don't have an extension (check your directory page) contact #is and they can allocate one
[21:26] <lifeless> [and get them to put it in the directory so you can find it later :P]
[21:27] <sinzui> lifeless: We do not need anything at the moment. I think we  need to talk about how to improve the velocity of the teal squad and do a on-going maintenance well.
[21:27] <lifeless> sinzui: when would you like to do that ?
[21:27] <sinzui> I may ask for your help later today
[21:27] <lifeless> sinzui: sure thing.
[21:27] <lifeless> I have a little hr adminny stuff to do, and other than that a clean slate
[21:30] <jcsackett> and now my whole system just crashed.
[21:30] <jcsackett> perhaps my problem isn't with mumble...
[21:31] <sinzui> jcsackett: I cannot get mumble to restart :(
[21:31] <jcsackett> sinzui: skype? i have that on my phone, which i'm trusting a bit more this second.
[21:34] <sinzui> jcsackett: I am trying skype
[21:36] <jcsackett> sinzui: okay. i'm online with it now.
[21:37] <jcsackett> sinzui: i can hear you shouting. :-)
[21:38] <jcsackett> sinzui: i take it you could not hear me. and the call died.
[21:38] <jcsackett> ...perhaps i have a crappy network connection today...?
[21:39] <sinzui> I could hear you
[21:39] <sinzui> It was not clear you could hear me
[21:40]  * jcsackett grows angry with technology.
[21:46] <lifeless> rage powered development. win.
=== salgado is now known as salgado-afk
[23:11] <lifeless> flacoste: I've tweaked your edit to the rotation (there are two bug triage searches needed :( - to deep link directly to the them on the bugtriage page)
[23:11] <lifeless> flacoste: if you still prefer them inline on the maintenance page, I'll do that for you and add bidirectional pointers so they don't accidentally get out of syn
[23:11] <lifeless> c
[23:26] <lifeless> grr
[23:26] <lifeless> why isn't bug expiry expiring stuff
[23:26] <lifeless> https://bugs.launchpad.net/launchpad/+bug/121859
[23:26] <_mup_> Bug #121859: RFE: Url for posting private, non-security bugs <lp-bugs> <Launchpad itself:Incomplete> < https://launchpad.net/bugs/121859 >