[00:00] <wgrant> jml: Still around?
[00:03] <leonardr> sinzui, thanks for your review. did you see the follow up? https://code.launchpad.net/~leonardr/lazr.restful/more-tests-for-combined-representations/+merge/50202
[00:03] <jml> wgrant: yes
[00:03] <wgrant> jml: Which version of bzr-pqm do you have installed?
[00:04] <jml> wgrant: 1.4.0dev
[00:04] <jml> why?
[00:04] <wgrant> I want the exact package version. Because your zeca move added [ui=none], but I removed that two weeks ago.
[00:04] <jml> 1.4.0~bzr75-0ubuntu1-launchpad1~maverick1
[00:05] <wgrant> (it ended up with two sets of tags: one without [ui=none] from ec2, and another from presumably lp-land)
[00:05] <jml> oh
[00:05] <wgrant> Hmm. That is old.
[00:05] <wgrant> 1.4.0~bzr77-0ubuntu1-launchpad1~maverick1 is the latest version.
[00:05] <wgrant> You've not upgraded lately?
[00:05] <jml> also, I appear to have something symlinked in my plugins
[00:05] <jml> wgrant: just today
[00:05] <jml> wgrant: maybe when I upgraded to natty I didn't re-enable my sources.list for launchpad?
[00:05] <wgrant> That could do it.
[00:06] <jml> should I use 'natty' or 'maverick' for that PPA?
[00:07] <wgrant> natty
[00:07] <wgrant> We support that now.
[00:07] <wgrant> Although the test suite doesn't entirely work, I don't think.
[00:07] <jml> not surprised.
[00:16] <leonardr> thumper, maybe you want to take the (short) follow-up branch, that's all that's holding back a lazr.restful release
[00:37] <lifeless> wgrant: so
[00:37] <lifeless> let me look
[00:40] <lifeless> wgrant: I'm not entirely happy with the memcache change; it seems ugly to me
[00:40] <lifeless> wgrant: perhaps we should talk about it ?
[01:03] <thumper> leonardr: sure, email me with details
[01:03] <thumper> I'm just moving back home from the shared office space
[01:27] <lifeless> matsubara-afk: I can't access the oops in https://bugs.launchpad.net/launchpad/+bug/636158
[01:27] <_mup_> Bug #636158: BugTask:+index times out with many bug tasks/nominations (eg. Bug #1) <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/636158 >
[01:27] <lifeless> matsubara-afk: spm has updated and reenabled the lp-oops db updater
[01:31] <wallyworld> thumper: you back online?
[01:36] <lifeless> woo
[01:36] <lifeless> http://webnumbr.com/launchpad-timeout-bugs#
[01:56] <thumper> wallyworld: am now, but checking on something
[01:57] <wallyworld> thumper: ok. ping me when you are done
[01:57]  * thumper nods
[02:14] <matsubara-afk> lifeless, spm: thanks. looks like update_db is working fine. instructions on how to update are here: https://dev.launchpad.net/Foundations/QA/OopsToolsSetup
[02:14] <matsubara-afk> lifeless, not sure why OOPS-1716ED446 is not working though
[02:15] <thumper> wallyworld: now?
[02:15] <wallyworld> ok
[02:16] <matsubara-afk> lifeless, only thing in the apache log is: [Fri Feb 18 01:09:25 2011] [error] [client 122.63.10.108] Premature end of script headers: oopstools.wsgi, referer: https://bugs.launchpad.net/launchpad/+bug/636158
[02:16] <lifeless> matsubara-afk: thanks; also there are uncommitted changes in the tree; we should fix that to be automatically deployable (like lp itself)
[02:16] <_mup_> Bug #636158: BugTask:+index times out with many bug tasks/nominations (eg. Bug #1) <lp-bugs> <pg83> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/636158 >
[02:17] <matsubara-afk> lifeless, I reverted some debugging code I had left there. the other uncommitted things are config changes which shouldn't be in the vcs (e.g. passwords) and some minor stuff that I have bugs open for but didn't get to it yet
[02:18] <lifeless> matsubara-afk: so the password can be switched to ident
[02:19] <lifeless> matsubara-afk: and other config stuff should either be a separate tree if confidential, or just committed in some fashion
[02:19] <lifeless> matsubara-afk: I say should because the benefits to automation are immense
[02:21] <matsubara-afk> lifeless, right. I think if we can switch the db password to ident then the rest of it can be committed
[02:22] <matsubara-afk> the basic auth stuff is deprecated and I think I can remove that too
[02:22] <lifeless> cool
[02:25] <wgrant> lifeless: What is particularly ugly about the memcache change?
[02:26] <huwshimi> It appears the difference in URL between viewing a branch in loggerhead and viewing the branch details in LP is just a subdomain change (https://code.launchpad.net/~huwshimi/launchpad/tag-label-687546 and https://bazaar.launchpad.net/~huwshimi/launchpad/tag-label-687546). I can't find a situation where this is not the case. Can anyone verify this or know how I can go about doing so?
[02:26] <wgrant> huwshimi: The branch path is always the same.
[02:26] <huwshimi> wgrant: Awesome. No chance that this ever differs?
[02:27] <wgrant> Obviously the subpaths can be different.
[02:27] <wgrant> No.
[02:27] <wgrant> But lp-loggerhead should already have a link back to code.launchpad.net... can you reuse that?
[02:28] <huwshimi> wgrant: It does?
[02:31] <wgrant> huwshimi: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/changes, click the branch name in the top left.
[02:32] <huwshimi> wgrant: Ah right. I missed that as it does not work locally
[02:32] <huwshimi> wgrant: Thanks for that
[02:35] <wgrant> lifeless: With that BugTask:+index query... isn't it basically just SELECT blah blah FROM Message JOIN BugMessage ON BugMessage.message=message.id WHERE BugMessage.bug = %s AND BugMessage.index = 0"
[02:35] <wgrant> ?
[02:35] <wgrant> The query used there seems hugely excessive.
[02:36] <lifeless> wgrant: its using the indexed_messages property
[02:37] <lifeless> yes it can be made much better
[02:37] <wgrant> Ahh.
[02:37] <wgrant> I noticed it was timing out on that a lot on qastaging last night. But couldn't check the OOPSes to see how bad it really was.
[02:46] <lifeless> its better than it was
[02:46] <lifeless> its not shipping them all over the wire
[02:46] <lifeless> the old one was a 10 second query ;)
[02:48] <wgrant> Yep.
[02:54] <lifeless> should be fixed now, just checking I haven't broken anything
[02:56] <wgrant> Excellent.
[02:57] <wgrant> What are message parents used for, anyway?
[02:57] <lifeless> FIIK
[02:57] <wgrant> Heh.
[02:57] <lifeless> We model full email threading
[02:57] <wgrant> I know.
[02:57] <lifeless> we just don't show it anywhere
[02:57] <wgrant> And MPs used to use it.
[02:57] <wgrant> But not any more.
[02:58] <wgrant> It's also used in bugmail, I guess, but not in the UI anywhere AFAIK.
[02:58] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-721056/+merge/50266
[02:58] <lifeless> thumper: ^
[02:59] <lifeless> (diff generating now)
[02:59] <wgrant> lifeless: Drop about 6 seconds off an already 10 second page?
[02:59] <wgrant> Seriously?
[03:01] <lifeless> yes
[03:01] <wgrant> Wow.
[03:01] <lifeless> 5.7 specifically
[03:04] <wgrant> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html needs a "Do it" button
[03:04] <wgrant> Given that it looks like we are able to manage 1-2 rollouts a day now...
[03:11] <wgrant> lifeless: Do you want to discuss my FF branch?
[03:11] <wgrant> Ah, you replied.
[03:11] <wgrant> That was easier than expected. Thanks.
[03:11] <lifeless> I'd previously said it was fine I think
[03:11] <lifeless> it got sidetracked and confused
[03:12] <lifeless> wgrant: the check for Contains is still weird IMO
[03:12] <lifeless> but I haven't read enough of the rest of the file
[03:12] <wgrant> lifeless: It is weird, but it's the same weird as the two other tests.
[03:12] <wgrant> Consistent weird is better than inconsistent weird.
[03:12] <StevenK> wgrant: I think it would be awesome if the "Do it" button would figure out the current losa and physically tap them on the shoulder.
[03:13] <lifeless> bonus points for greying out about now in the week
[03:13] <lifeless> spm: hi
[03:14] <StevenK> lifeless: Your diff for bug-721056 looks odd
[03:14] <lifeless> spm: last interrupt, I semi-promise.
[03:14] <StevenK> lifeless: You have interface changes, but no model changes.
[03:14] <wgrant> StevenK: That's fine.
[03:14] <lifeless> StevenK: there are no model changes
[03:14] <wgrant> Although I'd reject that MP, I think.
[03:15] <wgrant> Exposing an _method?
[03:15] <StevenK> Haha
[03:15] <lifeless> consenting adults
[03:15] <StevenK> And showing a _ in public? Shameful!
[03:15] <lifeless> what really wants to happen is to push the description changed check into Bug
[03:15] <lifeless> but I want to make the damn thing fast first
[03:15] <lifeless> and then make it pretty
[03:16] <wgrant> lifeless: Nothing uses indexed_messages any more.
[03:16] <wgrant> Apart from one test.
[03:16] <lifeless> wgrant: and the API
[03:16] <wgrant> Bah.
[03:16] <wgrant> Kill it.
[03:16] <wgrant> With screw-compatibility-i-want-performance fire.
[03:16] <lifeless> do you know how I know the API uses it ?
[03:16] <wgrant> Because it times out hundreds of times a day?
[03:16] <lifeless> ... we had timeouts on Bug.messages in the first week I was ta
[03:17] <lifeless> wgrant: not anymore :)
[03:17] <wgrant> Oh, right, I remember that.
[03:17] <lifeless> wgrant: it probably will start timing out when we hit 12 second timeouts
[03:17] <StevenK> lifeless: I do note you've stopped pasting the top 10 timeouts.
[03:17] <lifeless> StevenK: not at all
[03:17] <lifeless> I pasted them yesterday
[03:18] <lifeless> today the oops processor was off overnight so the stats would be meaningless
[03:18] <wgrant> I don't think any got through.
[03:18] <StevenK> Right, but how many lines actually made it to the channel?
[03:18] <lifeless> StevenK: the first 3, which is what I pasted
[03:18] <StevenK> I think Freenode has wised up and disabled paste for you :-P
[03:19] <lifeless> possibly
[03:19] <lifeless> the flood rules are positively fascist
[03:21] <StevenK> The reasoning is clear. Use a pastebin!
[03:21] <wgrant> As fascist as you on OOPSes? :P
[03:21] <StevenK> Haha. Maybe Freenode *are* LP users ...
[03:22] <lifeless> wgrant: not quite; it lets some through after all
[03:22] <wgrant> Haha
[03:31] <wgrant> wallyworld: Bug #720474 looks very similar to bug #687623.
[03:31] <_mup_> Bug #720474: Need "Build now" capability for daily recipe builds <recipe> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/720474 >
[03:31] <_mup_> Bug #687623: No ability to manually trigger a build 'like the daily build system' <lp-code> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/687623 >
[03:31] <wallyworld> wgrant: so it does
[03:31]  * wallyworld has a closer look
[03:33] <wgrant> I think we need to SourcePackageRecipe:+index'ify all of LP.
[03:34] <lifeless> wgrant: what do you mean?
[03:34] <wgrant> lifeless: That's a new verb that means "completely AJAXify"
[03:34] <lifeless> ah
[03:34] <lifeless> that would be nice; we need to decide what to do with commercial/stakeholder ie7 users
[03:36] <wallyworld> wgrant: i'll mark 720474 as a dup of 687623. the wording is slightly different but the intent appears to be the same
[03:36] <wgrant> wallyworld: I'd go the other way, but yes, they have the same intent.
[03:36] <wallyworld> wgrant: i thought we were supposed to mark the higher # and the dup?
[03:36] <wallyworld> s/and/as
[03:37] <wgrant> wallyworld: Some say that.
[03:37] <thumper> bah
[03:37] <wgrant> But the most informative, searchable one should win, IMO.
[03:37] <thumper> damn it
[03:37] <wallyworld> wgrant: yes, i see that point too. but both will be searchable even if one is a dup, no?
[03:37] <wgrant> Hahahah
[03:37] <wgrant> No.
[03:37] <lifeless> yes
[03:37] <wallyworld> thumper: what's wrong
[03:38] <lifeless> wgrant: the dupe finder searches dupes
[03:38] <thumper> making description optional requires a db patch :(
[03:38] <thumper> as there's a NOT NULL constraint
[03:38] <thumper> bah humbig
[03:38] <thumper> bug
[03:38] <wallyworld> thumper: patch away!! i'm not RM anymore :-D
[03:38] <lifeless> we should do that in the main bug search, once its performance is tolerable
[03:38] <wgrant> lifeless: ah, true, for the dupefinder.
[03:38] <wgrant> Indeed.
[03:39] <lifeless> wallyworld: if the older bug is less useful, you can either make the newer a master, or improve the older ones subject
[03:39] <lifeless> if you're not working on a bug, taking the older as master is a good idea because of the slight emphasis on older-first bugfixing within a bucket
[03:39] <wallyworld> lifeless: the older one has more background info but the newer one is more succinct. i'll update the older one and dup the newer
[03:40] <lifeless> sinzui: so, I found a another low hanging fruit for bugtask:index, will reevaluate when that has landed and been deployed
[03:41] <lifeless> huwshimi: sinzui and I talked over bugtask:+index today, like you did the day before. I have a raft of bugs I'm going to file once I have some data on the relative performance impact of the various issues
[03:41] <StevenK> lifeless: I wanted to hear your thoughts on bugmessage vs bugcomment when you have a spare cycle?
[03:41] <lifeless> wallyworld: coolio
[03:41] <lifeless> StevenK: hey, so - what in particular
[03:41] <huwshimi> lifeless: That's great. sinzui did mention it and it sounds like we're thinking along the same lines.
[03:42] <huwshimi> lifeless: Well at least that there's stuff to be dealt with
[03:42] <lifeless> huwshimi: great minds
[03:43] <huwshimi> lifeless: Feel free to subscribe me to those bugs or something once they're created
[03:43] <lifeless> sure
[03:43] <lifeless> probably be tuesday before I file them given latency to gather the needed data
[03:46] <huwshimi> lifeless: In particular the subscribers list is going to get a huge hit once the yellow squad's work gets released
[03:46] <lifeless> thats already out of the performance critical path
[03:46] <wgrant> That's in a separate request, but it's still not good.
[03:47] <lifeless> wgrant: actually
[03:47] <lifeless> check BugTaskView
[03:47] <wgrant> lifeless: It calculates them anyway?
[03:47] <lifeless> yes
[03:47] <wgrant> YAY
[03:47] <lifeless> so there is stuff that needs addressing
[03:47] <lifeless> a lot of detail to cover
[03:47] <lifeless> but things like
[03:47] <lifeless>  - have a deleted bugtask state
[03:47] <lifeless> (don't show those)
[03:47] <lifeless>  - don't show declined nominations
[03:48] <lifeless> accordian the activities as well as messages
[03:48] <lifeless> schema changes to let messages-to-show be queried from the db rather than done in python
[03:59]  * wallyworld wonders why stuff wrapped by <noscript> doesn't show up if i disable javascript using the noscripts extension?
[04:08] <lifeless> wallyworld: try disabling javascript entirely instead
[04:09] <wallyworld> that's the hard way! so much easier to clock an icon in the location bar
[04:13] <pjdc> wallyworld: iirc noscript has an option on whether to show <noscript> elements
[04:14] <wallyworld> pjdc: thanks. i'll have a closer look. first time i've used noscript.
[04:14] <lifeless> wallyworld: so I was basing that on my undesrstanding about what noscript does
[04:14] <pjdc> if this is your first trip into the options window, try not to scream.
[04:14] <lifeless> wallyworld: if you haven't tried /actually/ turning it off, you might want to try that :P
[04:14] <wallyworld> i've never seen a need for noscript apert from testing launchpad :-)
[04:15] <wallyworld> lifeless: jeez, i don;t look that stupid do i? i did turn js off using noscript and i know it's off cause the other ajax links have been disabled
[04:15] <wallyworld> :-)
[04:24] <lifeless> wallyworld: well AIUI it doesn't disable the interpreter
[04:24] <lifeless> wallyworld: it filters the content
[04:25] <lifeless> wallyworld: the result being that as far as the browser is concerned javascript is still enabled
[04:25] <wallyworld> lifeless: yeah, i think you're right. i'll look for the noscript option to display noscript tags
[04:26] <StevenK> wgrant: Is getting buildd-manager and a builder working on a development still a path of pain, misery and suffering?
[04:27] <wgrant> StevenK: Yes. But it is fairly short, well-documented path of pain, misery and suffering.
[04:27] <wgrant> Plus there are scripts to do most of it.
[04:27] <wgrant> Unless jml broke them this morning.
[04:28] <wgrant> Let me just check if the docs are up to date.
[04:29] <wgrant> StevenK: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally looks OK.
[04:30] <wgrant> Although installing launchpad-buildd outside a VM is somewhere between unwise and idiotic.
[04:31] <StevenK> Clearly
[04:31]  * StevenK ponders ec2 demo
[04:31] <wgrant> That works.
[04:31] <wgrant> I've done it there before.  But it's easy enough to run lp-buildd in a VM.
[04:32] <StevenK> You assume much about my setup :-P
[04:32] <wgrant> Hah.
[04:32] <wgrant> Grngggh.
[04:32] <wgrant> login_as(someteam) creates a new member and adds it to the team.
[04:32] <wgrant> Which sends email :(
[04:34] <StevenK> wgrant: The wiki pages references edge :-P
[04:34] <wgrant> StevenK: Yes, but it'll still work, even faster!
[04:34]  * wgrant invokes a lifeless-shield.
[04:35] <StevenK> Haha
[04:35] <poolie> someone asked in dallas about merging #launchpad and -dev
[04:35] <wgrant> Also, soyuz-sampledata-setup in devel doesn't do natty.
[04:35] <poolie> seems like a good idea...
[04:35] <wgrant> poolie: Until you have three dev conversations and three user conversations at once.
[04:35] <wgrant> Which doesn't happen in APAC, but does in AMEU.
[04:38] <spm> lifeless: yo
[04:56] <poolie> i wondered about that
[05:24] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/silence-of-the-prober-ii/+merge/50273?
[05:25] <StevenK> wgrant: I can't see a definition of RedirectToDifferentFile anywhere? Did it already exist?
[05:27] <lifeless> spm: hi
[05:27] <lifeless> spm: uhm, staging is borked
[05:28] <lifeless> spm: I think its the NULL on bugmessage
[05:28] <lifeless> spm: a restore from prod will fix, and its friday so we're due one anyhow
[05:28] <lifeless> StevenK: edit the wiki page
[05:28] <lifeless> (to remove edge !)
[05:28] <wgrant> StevenK: Yes, it already existed.
[05:28] <lifeless> wgrant: did you end up following up the issue with the qastaging restore ?
[05:28] <wgrant> StevenK: It was considered a very strange failure.
[05:28] <wgrant> lifeless: Yes, it just needed the DB swapped. Is done.
[05:29] <wgrant> StevenK: But now some mirrors are showing their love for HTTP by redirecting instead of 404ing, because who needs good response codes?
[05:30] <StevenK> lifeless, thumper: O hai, can one of you can mentor my review of https://code.launchpad.net/~wgrant/launchpad/silence-of-the-prober-ii/+merge/50273?
[05:32] <StevenK> DiscoveryFailure: Error fetching XRDS document: <urlopen error [Errno 1] _ssl.c:480: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol><br />
[05:32]  * StevenK pouts at his ec2 demo
[05:33] <wgrant> StevenK: Restart Apache.
[05:33] <StevenK> wgrant: Graceful or bullet-in-the-head?
[05:33] <wgrant> Alternatively the Apache config mangling may be broken now.
[05:33] <wgrant> StevenK: The latter.
[05:33] <wgrant> You used to need to do that after rf-setup, but it now restarts it itself.
[05:34] <thumper> StevenK: done
[05:34] <wgrant> Thanks.
[05:34] <StevenK> wgrant: Welcome
[05:35] <StevenK> thumper: And thanks
[05:36] <wgrant> lifeless: aaaaaaaa
[05:37] <wgrant> Branches without owners?
[05:37] <thumper> what?
[05:37] <StevenK> wgrant: Restarting apache results in the same traceback.
[05:38] <wgrant> thumper: It has just been suggested that official package branches shouldn't have owners at all.
[05:38] <thumper> no
[05:38] <thumper> no
[05:38] <thumper> no
[05:38] <thumper> no
[05:38] <thumper> and NO
[05:38] <wgrant> StevenK: Config mangling on testopenid.dev:443 is broken.
[05:39] <StevenK> $ grep -c 'testopenid.dev' /etc/apache2/sites-available/local-launchpad
[05:39] <StevenK> 0
[05:39] <StevenK> :-(
[05:41] <StevenK> wgrant: However, I can't find an apache config section locally either.
[05:41] <wgrant> StevenK: It'll fall through to the default *:443 vhost.
[05:41] <wgrant> Which happens to proxy to the appserver anyway.
[05:42] <StevenK> There is no default *:443 vhost
[05:43] <wgrant> It was probably mangled.
[05:44] <poolie> lifeless, hi, still here?
[05:53] <wgrant> Does Zopeless serve any purpose these days?
[05:53] <wgrant> It isn't very Zopeless.
[05:53] <LPCIBot> Yippie, build fixed!
[05:53] <LPCIBot> Project devel build (452): FIXED in 5 hr 40 min: https://hudson.wedontsleep.org/job/devel/452/
[05:53] <lifeless> poolie: kindof
[05:53] <wgrant> And the only difference I know of is that it sometimes has different mail delivery techniques.
[06:11] <huwshimi> Have a good friday/weekend everyone.
[06:15] <wgrant> Night huwshimi.
[06:17] <poolie> night huw
[06:22] <lifeless> wgrant: 'owner', not Owner
[06:55] <poolie> is sending a diff on bug description changes really the most useful thing?
[06:55] <poolie> they often seem pretty unreadable to me
[07:03] <LPCIBot> Project db-devel build (377): FAILURE in 4 hr 56 min: https://hudson.wedontsleep.org/job/db-devel/377/
[07:03] <LPCIBot> Launchpad Patch Queue Manager: [r=abentley,
[07:03] <LPCIBot> stub][bug=164196] makes sure that the omitted notification objects
[07:03] <LPCIBot> left over from duplicate actions are marked as processed so
[07:03] <LPCIBot> that they are not perpetually considered for subsequent
[07:03] <LPCIBot> notification cronscript runs.
[07:07] <wgrant> poolie: I'm pretty sure the diff is buggy.
[07:08] <poolie> a wdiff might be better
[07:08] <poolie> or just sending the whole new thing if the change is substantial
[07:08] <wgrant> Possibly.
[07:08] <lifeless> I think showing the old is pretty useful
[07:09] <lifeless> particularly now we don't mail  ones own changes by default
[07:18] <BjornT_> poolie: showing a diff helps showing what the actual change was. a better diff algorithm would be good, though, since the current one is quite naive.
[07:19] <lifeless> I hear bzr has a good one
[07:19] <poolie> well
[07:19] <poolie> i think i'm more often interested in just knowing what the description is
[07:19] <poolie> perhaps a smarter diff would be better
[07:20] <lifeless> poolie: I think there is an option you can turn on
[07:21] <lifeless> where lp will give you the description on each mail
[07:21] <BjornT_> poolie: i find having to re-read the whole description for small changes is a waste of time, especially if i want to know what got added/changed. i don't want to create a diff manually in my head
[07:22] <poolie> BjornT_, it's a tough tradeoff
[07:22] <poolie> neither feels just right
[07:22] <poolie> lifeless, but that's _every_ mail which is too much
[07:22] <poolie> perhaps html text with redlining would be best
[07:23] <poolie> but that sounds a bit hard
[07:23] <lifeless> difftastic!
[07:26] <poolie> maybe a tweaked version of that
[07:26] <poolie> i feel like ideally it would show the whole new description with highlighted/struck out changes
[07:26] <poolie> there are probably still failure modes for this but it would be better
[07:26] <poolie> it's not really a top priority
[07:26] <poolie> i just got an especially unreadable one
[07:26] <poolie> o/ bjornt btw
[07:27] <lifeless> poolie: the obvious failure mode is 100 line descriptions
[07:28] <lifeless> poolie: like most of my timeout ones :)
[07:28] <poolie> mm
[07:28] <poolie> i think 100 line descriptions aren't inherently a failure mode
[07:28] <poolie> i was thinking more of the 'oh i'll sync on paragraph breaks' type thing
[07:30] <poolie> if you're editing a huge description all the time it may suck
[07:30] <poolie> but i'm not sure it will suck any more than at present
[07:30] <lifeless> we have a general concept that we show deltas
[07:30] <lifeless> I think that works pretty well
[07:31] <BjornT_> poolie: showing highlighted/struck out changes would be good, but quite hard to do with text/plain. maybe an option to get html mail would work for those who don't mind.
[07:31] <lifeless> whatever we do, keeping that seems reasonable to me
[07:35] <poolie> perhaps a wdiff of the relevant paragraphs would be the best of both worlds
[07:36] <lifeless> BjornT_: what do you think of the idea of having a bugtask status 'deleted' which would be hidden from search by default, and not shown in the default bugtask:+index view
[07:37] <lifeless> BjornT_: the difference between it and invalid/wontfix would be the hiding of it in bugtask:+index
[07:37] <lifeless> alternatively, we could hide invalid tasks by default in that view
[07:38] <wgrant> Also Deleted tasks don't count for strucsubs.
[07:38] <BjornT_> lifeless: yeah, i was going to suggest simply hiding invalid tasks. that would make that status more useful, and make it more obvious it's not considered a bug
[07:40] <lifeless> wgrant: same thing can be done for invalid
[07:40] <lifeless> BjornT_: indeed, invalid is pretty unambitious at the momemt
[07:41] <wgrant> lifeless: That is difficult, because then invalidating the single task on a bug would remove all its subscribers, leaving the reporter's protests to go nowhere.
[07:43] <lifeless> wgrant: maybe this makes opinion more useful
[07:43] <lifeless> wontfix -> its a defect but won't be fixed here. Useful for closed source projects and for open source projects with frozen contexts - e.g. old releases of bzr.
[07:44] <lifeless> opinion -> dispute over it being a defect
[07:44] <lifeless> invalid -> truely not a bug and no dispute expected
[07:45] <poolie> that's not quite how i would describe wontfix/invalid, but anyhow
[07:45] <poolie> perhaps you could just not allow deleting the last task?
[07:45] <lifeless> poolie: we're discussing a possible change :) redefinitions R us
[07:45] <poolie> istm the main case for this as i understand it is to delete incorrectly added secondary tasks
[07:46] <lifeless> if a spammer reports a bug
[07:46] <lifeless> you want to get rid of it entirely
[07:46] <lifeless> thats not all that common, but I don't know that we should special case it
[07:46] <BjornT_> poolie: not sure about wdiff. it's not too bad for minor changes, but for bigger changes it seems quite unreadable
[07:47] <StevenK> lifeless: Have you ever seen a spammer report a bug? I've only seen them add comments.
[07:47] <poolie> well, there could be a policy that only ~admin or whatever can delete the last task
[08:48] <adeuring> good morning
[08:59] <mrevell> Hi
=== almaisan-away is now known as al-maisan
[09:37] <stub> jtv: Do you have a branch for the BranchRevision.id dropping that I can pick up? Or where you still following up on that?
=== adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews
[09:47] <jml> man
[09:48] <jml> this _LockWarner thing plaguing anyone else?
[09:55] <danilos> wgrant, thanks for QAing 718809
[09:55] <jml> Has anyone had ec2 failures in the last few hours that mention _LockWarner?
[09:56] <jtv> stub: don't have that done yet, no.  An unbroken series of crises took over.
[09:56] <stub> jtv: Sure. But if you have a branch, I can take it over.
[09:57] <stub> Or I can start a new branch :-)
[09:57] <jtv> stub: the branch I have doesn't have much useful stuff in it… hang on, I'll dig it up.
[09:58] <jtv> stub: https://code.launchpad.net/~jtv/launchpad/drop-branchrevision-id
[09:58] <stub> Ta
[09:58] <jtv> I think the main thing was a view that we can also drop.
[09:59] <jtv> Look how far we've come—loggerhead got me to the file in one go.
[09:59] <jtv> http://bazaar.launchpad.net/~jtv/launchpad/drop-branchrevision-id/view/head:/database/schema/patch-2208-99-0.sql
[09:59] <jtv> Not much to see, sorry.  :/
[10:00] <stub> np
[10:01] <wgrant> jml: I've had two successful ec2 runs today. No _LockWarner.'
[10:02] <jml> wgrant: thanks.
[10:02] <jml> it's happened in two unrelated branches for me.
[10:02] <wgrant> Target: bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ r12404
[10:02] <jml> r12400 for me. I doubt anything has changed.
[10:03] <jml> not sure why the devscripts tests are printed as RemotedTestCases (e.g. ERROR: devscripts.ec2test.tests.test_remote.TestWebTestLogger.test_got_line_no_echo (subunit.RemotedTestCase))
[10:04] <bigjools> jml: another spurious ec2 error I've had is all the devscripts tests failing, did that just happen to you?
[10:05] <jml> bigjools: yes. what was the error?
[10:05] <bigjools> jtv: thought you were off today?
[10:05] <bigjools> jml: LockWarner
[10:06] <jml> bigjools: right. That's exactly what happened to me.
[10:06] <jtv> bigjools: I am, I am
[10:06] <jml> bigjools: did you file a bug?
[10:06] <bigjools> jml: I didn't, sorry.
[10:06] <jml> np
[10:06] <jml> I'll do so now
[10:06] <jml> maybe it'll magically accumulate information and get solved while I make breakfast.
[10:06] <bigjools> I was trying to land an important branch at the time and it totally slipped my mind :(
[10:08] <bigjools> having breakfast solves many problems
[10:14] <wgrant> jml: Your lib/canonical cleanup branch is very nice.
[10:14] <jml> wgrant: thank you.
[10:14] <jml> wgrant: I hope it lands one day.
[10:14] <jml> https://bugs.launchpad.net/launchpad/+bug/721166 filed btw
[10:14] <_mup_> Bug #721166: Tests sometimes fail on EC2 due to _LockWarner garbage <build-infrastructure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721166 >
[10:18] <wgrant> jml: "one day"?
[10:19] <jtv> jcsackett: thanks for the review—updated my MP
[10:19] <jtv> (yes yes bigjools, I _am_ off today)
[10:20] <bigjools> jtv: uh huh :)
[10:23] <wgrant> Can someone explain to me why ZopelessTransactionManager exists, given that everything seems to load the ZCA anyway?
[10:24] <jml> wgrant: it's failed 2 out of 2 ec2 test runs
[10:24] <wgrant> jml: :(
[10:25]  * jml resubmits
[10:25] <bigjools> wgrant: hysterical raisins?
[10:26] <wgrant> bigjools: I am hoping so.
[10:26] <bigjools> wgrant: iirc it has a bug as well
[10:27] <bigjools> can't do multiple commits or something
[10:27] <bigjools> but maybe that was fixed
[10:27] <wgrant> Hah, stub has a kill-zopeless branch.
[10:27] <wgrant> From 2009.
[10:27] <stub> Be my guest
[10:28] <stub> Big steaming pile of techdebt
[10:29] <wgrant> Zopeless scripts also don't keep email within the transaction. Is that unrelated to initZopeless except by name?
[10:29] <bigjools> ah yes that was the other gem
[10:29] <stub> unrelated
[10:29] <wgrant> That's what I've suspected for a while.
[10:29] <wgrant> But I thought I must have been missing something, given the whole name thing...
[10:29] <stub> Does appserver keep them within the transaction?
[10:29] <wgrant> Yes.
[10:30] <wgrant> They use the normal Zope queued delivery utility.
[10:30] <bigjools> I don't see how you can keep emails atomic like that
[10:30] <stub> Cool (although I shouldn't say that since I probably write it...)
[10:30] <wgrant> Whereas scripts use SMTP.
[10:31] <wgrant> Grrr.
[10:31] <wgrant> It is not in fact unrelated :(
[10:32] <wgrant> Zopeless mail delivery happens when canonical.lp.isZopeless() is true, which checks if ZTM is installed. But I guess that's easy enough to untangle.
[10:33] <stub> extra points for tieing it into the transaction machinery :-)
[10:33] <wgrant> No.
[10:33] <wgrant> Soyuz relies on it being untied.
[10:33]  * stub looks for his cluebat
[10:33] <wgrant> Rejection emails work by being sent before the failed transaction is aborted!
[10:33] <wgrant> Because why not.
[10:35] <stub> that can be untangled too. I think email being sent on aborted transactions is a bug in most cases.
[10:35] <wgrant> Definitely.
[10:35] <wgrant> Only a couple of scripts should require the old behaviour.
[10:39] <bigjools> that will be hard to fix
[10:40] <wgrant> Indeed.
[10:42] <stub> jtv, danilos, henninge: About 10% of POTranslation is waste and not linked from translationmessage. Probably not enough to worry about garbage collecting?
[10:42] <stub> (2.5 million out of 29 million)
[10:44] <henninge> stub: although that sounds like low-hanging fruit?
[10:44] <danilos> stub, it'd be great to clean it up some time in the future, but we are generally better off completing message sharing migration, imho
[10:44] <danilos> stub, also, there's other stuff worth cleaning up first, like removing some columns from TranslationMessage table
[10:44] <stub> It is. The query to discover the unlinked records takes 10 minutes to run, so it could go in garbo-daily
[10:45] <henninge> It sounded to me like that could be done in single sql query ..
[10:46] <stub> henninge: It could, but I'd rather not do it in a 20-30 minute transaction
[10:46] <danilos> stub, then JFDI :)
[10:46] <danilos> stub, right, up to you then
[10:46] <stub> k
[10:47] <danilos> stub, if locking happens on entire potranslation table instead of per-row for those 20-30 mins, it will cause issues for several translation processes
[10:47] <danilos> (including web UI)
[10:48] <stub> Nah - stick it in garbo so transactions are short and I don't have to remember to run the job again in 2 years time
[10:55] <bigjools> jml: so I got a bit further with hooking ftp into poppy-sftp.  The problem I have now is allowing anonymous access to write files - I think I might need to write a custom FTPAnonymousShell, do you have any thoughts?
[10:56] <jml> bigjools: not off the top of my head, and I have to go right now, sorry.
[10:56] <jml> back at ~1
[10:56] <bigjools> ok np
[10:56] <bigjools> I shall continue to experiment
[10:59] <wgrant> Also note that
[10:59] <wgrant> # if the host is empty it can be overridden by the standard PostgreSQL
[10:59] <wgrant> # environment variables, this feature currently required by Async's
[10:59] <wgrant> # office environment.
[10:59] <wgrant> D:
[10:59] <bigjools> ha
[11:00] <bigjools> wgrant: dput logs in as "anonymous" right?
[11:00] <wgrant> bigjools: Yes.
[11:03] <bigjools> wgrant: hmmm poppy allows anything!
[11:04] <wgrant> As it probably should.
[11:04] <wgrant> But our default dput.cf uses anonymous.
[11:13] <StevenK> bigjools: What are doing to poor poppy-sftp?
[11:13] <bigjools> StevenK: I'm adding ftp to it
[11:13] <wgrant> And renaming it.
[11:13] <bigjools> heh
[11:13] <StevenK> bigjools: Why?
[11:14] <wgrant> zeca died. poppy can die too.
[11:14] <bigjools> because zope's ftp server is shit
[11:14] <StevenK> bigjools: Why now is a better question :-)
[11:14] <bigjools> because I want to
[11:15] <bigjools> it's been itching too long and I  need to scratch now
[11:15] <StevenK> Note that the SFTP server uses parts of the FTP implementation with gay abandon
=== matsubara-afk is now known as matsubara
[11:19] <StevenK> bigjools: The whole thing needs a serious refactor
[11:19] <bigjools> StevenK: I saw no evidence of it using FTP stuff
[11:19] <bigjools> ftp is quite different
[11:20] <bigjools> when I do this I can also fix a loooooooong standing bug where we want to make sure the changes file is signed during the session
[11:25] <StevenK> from lp.poppy.filesystem import UploadFileSystem
[11:25] <StevenK> from lp.poppy.hooks import Hooks
[11:25] <StevenK> bigjools: ^
[11:25] <bigjools> that's not ftp-specific...
[11:26] <bigjools> I'll need to tweak it a bit to re-use that stuff but it won't be too hard
[11:26] <StevenK> The only thing that used it was poppy, so it's poppy-specific
=== al-maisan is now known as almaisan-away
[11:44] <Ronnie> we discovered in the loco, that the live-database is not the same as the developer and django specifications (at least for the field approval_date in teams). In the live DB its an datetime, while the developer version is a date field. Django does not complain and handle things OK, but now on the webpages, dates are shown as datetimes. I added an migration file, so this should be fixed next release.
[11:44] <Ronnie> But if that field did not migrate, its possible that other fields may be wrong too. can i get the schema of the life database somehow, to compare it with the django-settigns ?
[11:45] <Ronnie> cjohnston, mhall119: ^^ above is interesting for both of you too
[11:45] <wgrant> Ronnie: Wrong channel?
[11:45] <Ronnie> oops yea
[11:46] <Ronnie> wgrant: what was the ISD channel?
[11:46] <wgrant> Ronnie: #canonical-sysadmin, you mean?
[11:47] <Ronnie> yes, i guess those guys can access the DB
[12:04] <bigjools> StevenK: poppy/twistedsftp.py has got zero comments and zero docstrings.  :/
[12:04] <bigjools> correction. one docstring
[12:06] <wgrant> I wish we had a Bugs team.
[12:08] <deryck> Morning, all.
[12:08] <deryck> wgrant, as in the former bugs team, or as in a team to deal with all the bugs? :-)
[12:09] <deryck> stub, ping
[12:09] <bigjools> morning deryck
[12:10] <wgrant> deryck: Users having issues with bugtask conjoining and handling statuses. There may be improvements that could be made on the Launchpad end. And there is no expert team to escalate to.
[12:10] <wgrant> Except for this nebulous "stakeholder escalation process"
[12:10] <wgrant> Which is bordering on completely useless for this sort of thing.
[12:10] <deryck> ah
[12:11] <deryck> wgrant, couldn't a maintenance team look at it?  Or it seems more complex to require feature-level work?
[12:11] <wgrant> deryck: It is unclear what the best solution is.
[12:12] <wgrant> (Apart from deleting task conjoinment)
[12:12] <deryck> right
[12:12] <wgrant> I think this is going to become a significant issue.
[12:12] <wgrant> Previously issues could be escalated to a team of people who knew the domain and what was what.
[12:13] <wgrant> Now there is... what is there?
[12:13] <deryck> wgrant, you're right that it likely won't get dealt with for awhile, but FWIW it had no chance of getting scheduled if you had escalated to the bugs team, too. so...
[12:13] <deryck> wgrant, at least here, once the critical queue is cleared and features are caught up, there is some path to getting it scheduled.
[12:13] <deryck> and it's not like you can't ask one of us former bugs people what to do. ;)
[12:14] <wgrant> deryck: Sure, but the old team could have offered suggestions for working around it, and probably would have been able to work out plausible improvements on the LP side.
[12:14] <deryck> right
[12:14] <wgrant> There is no longer any path for that sort of thing.
[12:14] <wgrant> There is the escalation process to get a random team assigned to implement the feature in a few months.
[12:15] <deryck> wgrant, I'm not sure what you mean "path for that sort of thing" -- if it's just "I need domain knowledge advice or help" why not just ask someone?
[12:15] <deryck> wgrant, I see your point, don't get me wrong.  but maybe you're over process driven here?
[12:16] <wgrant> deryck: Asking the old team people is cheating.
[12:16] <wgrant> Because that will not work for long.
[12:16] <bigjools> ?!
[12:16] <deryck> why?
[12:16] <wgrant> People leave, codebases evolve, knowledge rots.
[12:17] <deryck> sure, but knowledge spreads too. and it starts with asking. ;)
[12:17] <wgrant> There isn't necessarily anybody who knows what is going on in that area.
[12:18] <deryck> in what area?  conjoined bugtasks?
[12:18] <wgrant> Well, that stemmed from an attempt at a workaround for the initial issue.
[12:18] <wgrant> Let me explain.
[12:18] <deryck> ok, yes.  let's start with the real issue :-)
[12:20] <wgrant> apw finds that "Incomplete with response" is fairly useless, since it's not visible anywhere except searches. So he wants to be able to have a script automatically revert Incomplete bugs to their previous status when the reporter replies. He tried to use the date_* attributes, but eg. date_triaged gets unset when moving back to Incomplete. So he tried to parse bugactivity records. Which then runs into the fact that conjoined bugtasks ...
[12:20] <wgrant> ... appear in the API as normal tasks.
[12:21] <wgrant> So we have a whole lot of holes in the Bugs API and/or model.
[12:21] <wgrant> It is unclear what we want to support directly.
[12:22] <deryck> hmmm
[12:22]  * deryck looks at something
[12:22] <wgrant> Previously the relevant team could make a reasonable judgement on what needed to happen.
[12:24] <wgrant> So, I have enough knowledge to offer a workaround.
[12:24] <wgrant> But I am not in a position to suggest ways in which Launchpad should improve.
[12:24] <wgrant> I do not know who is.
[12:26] <wgrant> And offering workarounds without making an effort to remove the obstacles sounds like a pretty bad idea.
[12:26] <deryck> wgrant, bdmurray had a work around which I don't recall now.  But to fix this case, I would make a new IBugTask attribute called is_conjoined and export it and replace the private method BugTask._isConjoinedBugTask with it.
[12:26] <deryck> easy peasy and profit ;) :)
[12:26] <wgrant> Sure. But that is a fix four layers below an issue that should possibly be fixed in LP directly.
[12:27] <deryck> wgrant, sure.  agreed.  but conjoined bugtasks aren't going to be fixed anytime soon, and this question does come up somewhat frequently concerning the api
[12:27] <wgrant> deryck: Sure, but this completely avoids the issue of whether the Incomplete issue is something we need to tackle.
[12:28] <wgrant> If people offer workarounds like this, nobody will realise that the higher-level issues need solving.
[12:28] <deryck> wgrant, ok, I thought you were saying fixing conjoined bugtasks was the issue.  Sorry.  you have so many issues! ;)
[12:29] <deryck> wgrant, so the fix for the incomplete issue is to have the bugtask status revert to what it was previously when the original reporter responds and do away with incomplete with response.
[12:29] <wgrant> deryck: Right, but is that a desired feature?
[12:29] <deryck> wgrant, there's a bug somewhere detailing all the related conversation around this.
[12:30] <deryck> wgrant, I would say so.  let me find the bug.
[12:30] <LPCIBot> Yippie, build fixed!
[12:30] <LPCIBot> Project db-devel build (378): FIXED in 5 hr 26 min: https://hudson.wedontsleep.org/job/db-devel/378/
[12:30] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12401,
[12:30] <LPCIBot> 12402, 12403 included.
[12:30] <LPCIBot> * Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12400
[12:30] <LPCIBot> included.
[12:32] <deryck> wgrant, bug 569298
[12:32] <_mup_> Bug #569298: Toggle from Incomplete/Expired when bug reporter responds <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/569298 >
[12:34] <wgrant> deryck: Thanks.
[12:34] <deryck> wgrant, I think you could sniff for the previous state from the activity log and use that rather than a blanket toggle to new status, and avoid having to do a LEP as I suggest in the bug.
[12:35] <deryck> or activity table, rather
[12:35] <wgrant> It's impossible to reliably interpret BugActivity :(
[12:35] <wgrant> Due to task moves.
[12:38] <StevenK> bigjools: What don't you understand about it? :-)
[12:39] <bigjools> StevenK: the bit in the file
[12:39] <StevenK> bigjools: As in SFTPFile?
[12:39] <bigjools> no, the whole file
[12:39] <bigjools> ooo I spotted another comment.  It's an XXX that doesn't meet our XXX guidelines.
[12:40] <StevenK> bigjools: If you ask me questions about it rather than "I don't get it" I'll answer them
[12:41] <bigjools> StevenK: when I have specific questions I'll ask them, but it's hard to know  where to start because there's no clue as to what does what.  Perhaps a better initial question is, "how does this stuff fit in and work?"
[12:42] <bigjools> which is another way of saying, this stuff needs to be brought up to our coding standards :)
[12:43] <StevenK> bigjools: The .tac is where to start
[12:44] <bigjools> StevenK: that part is ok, I figured it out.  Now I just need to know what's going on inside poppy/twistedsftp.py
[12:44] <StevenK> bigjools: An SFTPServer instance is created per client
[12:45] <StevenK> bigjools: Depending on what the client does, methods are called in it, such as makeDirectory and openFile
[12:45] <bigjools> stating the obvious :)
[12:46] <bigjools> StevenK: I will try and call you next week about this
[12:46] <bigjools> I need higher bandwidth and it's late for you
=== benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, benji* | https://code.launchpad.net/launchpad-project/+activereviews
[13:20] <henninge> Anybody got an idea why the hard_timeout feature for TranslationImportQueueEntry:+index might not be working? https://qastaging.launchpad.net/+feature-rules
[13:20] <henninge> The page still times out after 14 seconds.
[13:21] <henninge> Also, it worked last week or so but the database has been renewed since.
[13:32] <jml> bigjools: hi
[13:32] <bigjools> jml: just going to lunch!  But I am making progress, I've even got an ftp server that can mkdir :)
[13:32] <jml> bigjools: sweet
[13:33] <bigjools> I have probably violated every twisted convention in the book but I'm sure you'll put me right
[13:33] <jml> :)
[13:34] <bigjools> once I get this DTRT I will mercilessly refactor
[13:34] <bigjools> anyway, back in a bit
=== almaisan-away is now known as al-maisan
[14:01] <deryck> henninge_, ping for standup
=== henninge_ is now known as heninge
=== heninge is now known as henninge
[14:01] <henninge> deryck: coming
[14:01] <deryck> ack
=== bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, benji*, bac | https://code.launchpad.net/launchpad-project/+activereviews
[14:27] <benji> to whom it may concern: I plan on doing a review of https://code.launchpad.net/~jameinel/launchpad/twisted-close-on-failure/+merge/50067 in a little while.
[14:29] <abentley> henninge, would it be right to say that 702477 is incomplete, and the other translation credit issues are new bugs?
[14:32] <henninge> abentley: possibly ...
[14:32] <henninge> abentley: although  I think all the issues would and should be fixed in one branch that updates the handling of translation credits to the new model.
[14:33] <henninge> abentley: so maybe the bug should be generalized?
[14:35] <abentley> henninge, No, I think if we generalize something, it should be the card.
[14:36] <henninge> or that
[14:36] <abentley> deryck, henninge: I propose we change my current card to "translation credits need upates for new model", and move it back to the Next column.
[14:36] <abentley> deryck, henninge: because right now, there is nothing I can do about it.
[14:37] <deryck> abentley, I accept that proposal :-)
[14:37] <henninge> abentley: I concur
[14:38] <deryck> abentley, I think the splitting work is more important for you to do anyway
[14:38] <deryck> abentley, henninge -- I think that sort of bug could be pushed to when we leave feature work and do maintenance even. or done while/after jml does review even.
[14:56] <benji> bac: I'm ready any time.
[14:56] <benji> I'm also in the wrong chan.
=== al-maisan is now known as almaisan-away
[15:03] <danilos> stub, hi, still around?
[15:03] <stub> sort of
[15:04] <danilos> stub, I'd just like you to take a very quick look at a DB query I'd like to run on production :)
[15:04] <stub> sure
[15:04] <danilos> stub, https://pastebin.canonical.com/43604/
=== almaisan-away is now known as al-maisan
[15:05] <danilos> stub, it should update 23k rows and in a transaction without a commit it took <4s on staging
[15:05] <abentley> deryck, henninge: the one-time merger script took ~5 hours to run.
[15:08] <jml> bigjools: how's it going?
[15:08] <jml> !!!
[15:08] <jml> more test failures.
[15:09] <bigjools> jml: ok thanks, I've figured out a bunch of stuff.  The twisted FTPShell is roughly equivalent to SFTPServer so I'm cargo-culting that stuff to just get it working before I figure  out what I need to refactor.
[15:09] <jml> *nod*
[15:09] <stub> danilos: looks fine - 23.9k rows on prod
[15:09] <bigjools> jml: I need to work out how to add a disconnection hook into FTPShell though
[15:09] <stub> danilos: Code is in place to keep this maintained in the future?
[15:10] <danilos> stub, well, I'd like to have this run only as a special-rollout-requirement when code gets in place (I am just about to submit a branch up for review)
[15:10] <danilos> stub, (or run it after the rollout)
[15:11] <stub> ok. Do we have structuralsubscription entries that should not have a corresponding bugsubscriptionfilter?
[15:11] <danilos> stub, no, we shouldn't, but we have them today
[15:11] <danilos> stub, I was thinking of introducing a constraint as well, but not sure how to best do it with multiple-tables
[15:11] <stub> You can't sanely
[15:12] <danilos> stub, right, that's what I suspected as well
[15:12] <stub> Is this a 1:1 relationship, or can there be many bugsubscriptionfilters referencing a single structuralsubscription?
[15:12] <danilos> stub, there can be many BSFs referencing a SS
[15:12] <danilos> stub, it's a "at least one" BSF for a SS
[15:12] <stub> All seems fine. Add it to special rollout requirements, or we can land this as a db patch if you prefer.
[15:13] <danilos> stub, my team would prefer to get it up on qastaging to ease further development, which is why I am not going with a patch
[15:13] <stub> k
[15:14] <danilos> stub, thanks for the input
[15:16] <jml> bigjools: logout(), I think.
[15:16] <abentley> adeuring, benji, bac: Could you please review https://code.launchpad.net/~abentley/launchpad/pomessage-sequence/+merge/50344 ?
[15:16] <adeuring> abentley: sure, I'll look
[15:16] <abentley> adeuring, thanks.
[15:16] <bigjools> jml: ha, I found a Twisted bug
[15:17] <jml> bigjools: I don't believe you. Twisted is unique among all software in its perfection.
[15:17] <bigjools> ftp.AnonUserDeniedError inherits from FTPCmdError but doesn't pass it an errorMessage required when formatting the response
[15:18] <jml> bigjools: looks like it passes None
[15:19] <bigjools> jml: which makes RESPONSE[self.errorCode] % self.errorMessage blow
[15:19] <jml> ah
[15:19] <deryck> abentley, that doesn't seem *too* bad :-)
[15:19] <bigjools> bizarrely, the FTPAnonymousShell uses AnonUserDeniedError with no problems :/
[15:19] <jml> well, passing anything would make it blow, right? 'foo' % (anything,) fails
[15:20] <bigjools> oh - huh yes :)
[15:21] <jml> another windmill hang, plus librarian connection refused errors.
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
[15:45] <jml> I was thinking on cleaning up the top-level directory of the tree
=== al-maisan is now known as almaisan-away
[15:45] <jml> does anyone know what the *-includes directories are for?
[15:46] <jml> or parts/
[15:46] <jml> or the many zcml files
[15:46] <jml> or benchmarks/
[15:47] <jml> or version.txt
[15:48] <benji> bac: I've finished my review of https://code.launchpad.net/~jameinel/launchpad/twisted-close-on-failure/+merge/50067 and added you as a requested reviewer.
[15:48] <bac> thanks
=== matsubara is now known as matsubara-lunch
[15:53] <jml> flacoste: you've been around a while, know what any of those things are for?
[15:54] <adeuring> abentley: r=me. must have been boring work ;)
[15:54] <flacoste> parts is a buildout managed directory
[15:54] <abentley> adeuring, thanks.
[15:54] <flacoste> some recipe will put stuff in there
[15:55] <flacoste> jml: benchmarks was for the funkload benchmarks we run in the ShipIt sprint
[15:55] <flacoste> version.txt was used when we included the release number in the footer
[15:55] <flacoste> might still be there, but hidden, not sure
[15:56] <flacoste> but it's not used for use, since it's several number behind
[15:56] <jam> benji: thanks for the review
[15:57] <flacoste> overide-includes and package-includes are convenient way of adding ZCML files to the config without having to edit site.zcml
[15:57] <flacoste> jml: ^^^
[15:57] <jml> flacoste: thanks.
[15:57] <jml> flacoste: is 'benchmarks' worth keeping, do you think?
[15:58] <benji> jam: my pleasure, hopefully it's not too stream of consciousness, I intentionally left in some of my thought process because I think it communicates a bit better
[16:01] <flacoste> jml: nah
[16:02] <henninge> have a good weekend everybody!
[16:09] <jam> Can someone help me land: https://code.launchpad.net/~jameinel/launchpad/lp-forking-serve-cleaner-childre/+merge/50031
[16:10] <jam> I assume the correct way to land it is using 'ec2land', but I haven't ever set up ec2
[16:10] <jml> does zope look for magically named zcml files, or do they have to be specified somewhere?
[16:10] <jml> jam: I can land it for you, if you'd like
[16:10] <jam> jml: thanks.
[16:10] <jml> jam: ec2: ERROR: Branch doesn't have linked bugs and doesn't have no-qa option set. Use --no-qa, or link the related bugs to the branch.
[16:10] <bigjools> jml: AFAIK they have to be specified
[16:11] <jam> jml: no bugs, so --no-qa. It is just code cleanup. It is a bit related to a bug, but not enough to be considered anything like a fix for it.
[16:13] <bigjools> jml: the top level zcml is set in the buildout.cfg
[16:13] <jml> bigjools: thanks.
[16:13] <bigjools> there's some wildcard includes though
[16:13] <jml> jam: ok. ec2 instance starting. I'll let you know when it's detached. You ought to get an email.
=== deryck is now known as deryck[lunch]
[16:16] <jml> I wonder if anyone uses start-gdb much.
[16:19] <jam> benji: responded to your response :) The diff may need to update still
[16:19] <benji> jam: cool, I'll look at it in a bit
[16:35] <jam> benji: diff has been updated
[16:36] <jml> flacoste: do override-includes and package-includes have extra stuff in them on production? i.e. can I move them without a special roll-out request?
[16:37] <flacoste> jml: i'm 99.9% sure they don't
[16:37] <jml> good enough.
[16:37] <jml> flacoste: thanks.
[16:37] <flacoste> if they have, it's before my time
[16:37] <flacoste> i never heard of it
[16:39] <flacoste> jml: site.zcml is the default, the app server one is configured in the config (launchpad.conf)
[16:39] <jml> also, any clue about script.zcml, ftesting.zcml
[16:39] <jml> and script-testing.zcml
[16:39] <flacoste> script.zcml is hardcoded by execute_zcml_from_script
[16:39] <flacoste> ftesting.zcml is hard coded somewhere in the test framework
[16:39] <flacoste> and script-testing.zcml is probably similar
[16:39] <jml> I can't find it when grepping the Launchpad tree
[16:40] <jml> but I'll poke a bit more.
[16:40] <flacoste> ftesting.zcml is in zope iirc
[16:40] <flacoste> script-testing.zcml is LP specific
[16:40] <flacoste> it might also be unused nowadays
[16:40] <jml> do we actually *use* ftesting / ftests concepts any more?
[16:40] <flacoste> FunctionalLayer uses it
[16:40] <flacoste> through the FunctionalSetUp fixture
[16:40] <flacoste> or whatever it's called
[16:40] <jml> hmm.
[16:41] <flacoste> execute_zcml_for_script actually switches between 'script.zcml' and 'script-testing.zcml'
[16:41] <flacoste> based on whether it detects we are running within the test runner or not
[16:43] <flacoste> jml: ftesting.zcml is the default ZCML loaded by FunctionalTestSetUp
[16:43] <flacoste> which is used by all FunctionalLayer tests
[16:44] <jml> flacoste: that's great, thanks. it means I can move them.
[16:44] <flacoste> jml: yes, you can, you'll have some plumbing to do :-)
[16:46] <jml> flacoste: also, do you know if zdaemon.conf is used?
[16:47] <flacoste> jml: die, die, die!
[16:47] <jml> :D
[16:47] <flacoste> iow, it's not
[16:47] <flacoste> at 99.9% confidence level
[16:48] <flacoste> we don't even have the runzope script
=== matsubara-lunch is now known as matsubara
=== deryck[lunch] is now known as deryck
[17:27] <bigjools> abentley_: would you mind investigating this branch scanning problem please?  I've no idea what's up.  https://answers.edge.launchpad.net/launchpad/+question/142589
[17:41] <flacoste> i need a reviewer for https://code.launchpad.net/~flacoste/launchpad/bug-721324/+merge/50365
[17:41] <flacoste> a pretty simple branch
[17:45] <flacoste> benji, bac: want to put your teeth onto that one?
[17:46] <benji> flacoste: absolutely
[17:49] <bigjools> ok I think I'll quit for the day on a good note, having just got ftp finally worked into poppy-sftp.
[18:04] <bigjools> g'night all
[18:04] <bigjools> have great weekends
[18:05] <LPCIBot> Project db-devel build (379): FAILURE in 5 hr 35 min: https://hudson.wedontsleep.org/job/db-devel/379/
[18:05] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12404
[18:05] <LPCIBot> included.
[18:07] <benji> bac: I'm done with https://code.launchpad.net/~flacoste/launchpad/bug-721324/+merge/50365 and I added you as a requested reviewer.
=== abentley_ is now known as abentley
[18:20] <jml> what's the motivation for the optional bzr plugin system?
[18:23] <lifeless> jml: the what?
[18:23] <jml> lifeless: optionalbzrplugins
[18:23] <jml> in Launchpad.
[18:24] <lifeless> https://launchpad.net/optionalbzrplugins ?
[18:24] <jml> in the Launchpad tree
[18:25] <lifeless> I think its so that the importer can add that path and get those plugins but the scanner doesn't and won't get them.
[18:25] <lifeless> ditto puller.
[18:25] <lifeless> and I think the why is because the scanner and puller don't have the same safety net in case someone puts in a pull url that is http but backed by svn not bzr
=== bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: benji, bac | https://code.launchpad.net/launchpad-project/+activereviews
[18:43] <jml> .lifthat sounds plausible.
[18:44] <jml> lifeless, rather.
[18:44] <lifeless> I guessed ;)
[18:45] <lifeless> whoa
[18:45] <lifeless> static websites on s3
[18:46] <lifeless> tiny change and *boom*
[18:46] <bac> benji: i'll take danilos branch.
[18:46] <benji> ok
[18:48] <lifeless> booyah
[18:48] <lifeless> https://bugs.qastaging.launchpad.net/ubuntu/+bug/1
[18:48] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[18:48] <lifeless> down to 7.6 seconds cold
[18:49] <lifeless> 5.34 hot
[18:49] <lifeless> wiiin
[18:59] <jml> https://code.launchpad.net/~jml/launchpad/flush-top-level/+merge/50374
[19:00] <jml> Takes the top level from 54 files & directories down to 31.
[19:03] <lifeless> I find it annoying that to add a recipe I have to go elsewhere than where I go to edit a recipe
[19:04] <cjohnston> Can someone please take a look at the spam: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/588595/comments/22
[19:04] <_mup_> Bug #588595: Ubuntu download button renders inccorrectly in Firefox 3.7 (trunk) <ppa> <Mozilla Firefox:Fix Released> <Ubuntu Mozilla PPA Bugs:Fix Released> <Ubuntu Website:Invalid> <firefox (Ubuntu):Invalid> < https://launchpad.net/bugs/588595 >
[19:07] <lifeless> jml: https://bugs.launchpad.net/launchpad/+bug/721460
[19:07] <_mup_> Bug #721460: Cannot use 'lp:bzr' as a branch in a recipe <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721460 >
[19:07] <lifeless> cjohnston: for operational stuff, #launchpad is better
[19:08] <lifeless> that said, its the end of the week - is this new spam, are they still adding spam?
[19:08] <cjohnston> Just happened today
[19:08] <cjohnston> 1 hour ago according to LP
[19:15] <cjohnston> lifeless: mostly want to see about maybe removing the user
[19:16] <lifeless> cjohnston: do they have karma?
[19:16] <lifeless> usually folk with karma have been hacked
[19:17] <cjohnston> ehh.. I get a page gone when trying to visit the user
[19:17] <lifeless> already suspended then
[19:17] <jml> Got bitten by bug 720998 again.
[19:17] <_mup_> Bug #720998: ec2 test times out <build-infrastructure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/720998 >
[19:31] <lifeless> cjohnston: file a question to get that bit of spam removed
[19:35] <cjohnston> against launchpaditself?
[19:35] <flacoste> congratulations to benji for achieving reviewerhood
[19:35] <lifeless> flacoste: hes still mentored isn't he?
[19:35] <benji> flacoste: thanks
[19:35] <flacoste> lifeless: nope, bac graduated him
[19:36] <lifeless> benji: congrats
[19:36] <lifeless> cjohnston: yes answers.launchpad.net/launchpad
[19:36] <benji> lifeless: thanks
[19:36] <benji> I got a little square hat with a tassel and everything.
[19:36] <cjohnston> ty
[19:38] <cjohnston> lifeless: i guess someone already did it https://answers.launchpad.net/launchpad/+question/145908
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[19:54] <jcsackett> benj: care to use your full reviewerhood to take a look at https://code.launchpad.net/~jcsackett/launchpad/dumb-date-formats/+merge/50385 ?
[19:56] <jcsackett> benji ^
[19:56] <jcsackett> darn nick typos.
[19:56] <benji> jcsackett: sure
[20:02] <jcsackett> thanks!
=== matsubara is now known as matsubara-afk
[20:24] <lifeless> flacoste: btw, I've just overhauled the deployment calendars to be crisper and easier to update .... now is your chance to say 'wtf, put it back', if you disagree with the approach :)
=== salgado is now known as salgado-afk
[20:36] <flacoste> lifeless: looks good, but can you follow-up to my emails with the new link, given that you broke it :-)
[20:38] <lifeless> flacoste: I don't think its broken, renames leave a forward in place
[20:38] <lifeless> oh, but its broken
[20:38] <lifeless> I'll put a redirect in place
[20:39] <lifeless> flacoste: done
[20:40] <flacoste> thx<
[20:40] <lifeless> flacoste: the link works, I won't add noise by noting this on the list
[20:40] <flacoste> fair enough
[20:40] <lifeless> it will be obvious to anyone looking, and the redirect can hang about for a while without trouble
[20:40] <flacoste> like you saw, it was broken
[20:40] <flacoste> that's why i asked
[20:40] <flacoste> but since you repaired it
[20:41] <lifeless> yeah, bad assumption on my part
[20:41] <flacoste> everything is fine
[20:41] <lifeless> sorry!
[20:42] <benji> jcsackett: https://code.launchpad.net/~jcsackett/launchpad/dumb-date-formats/+merge/50385 is approved, I had a few questions/suggestions but it looks good.
[20:43] <jcsackett> benji: thanks, i'll address those concerns.
[20:43] <benji> cool
[20:51] <lifeless> hmm
[20:51] <lifeless> is the scanner down? flacostes new commits haven't shown up
[21:37] <lifeless> flacoste: hi
[21:37] <lifeless> flacoste: still around ?
[21:38] <flacoste> lifeless: i am
[22:00] <LPCIBot> Project devel build (455): FAILURE in 5 hr 28 min: https://hudson.wedontsleep.org/job/devel/455/
[22:00] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][bug=719249] The advanced bug subscription overlay is now
[22:00] <LPCIBot> pre-populated in order to speed it up a bit.
[22:00] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless,
[22:00] <LPCIBot> wallyworld][bug=720503] Use feature flags for recipe enablement and
[22:00] <LPCIBot> beta message showing
[22:00] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][no-qa] Add kubuntu-mobile to list of tasks to be
[22:00] <LPCIBot> generated by cron.germinate.
[22:04] <lifeless> flacoste: man, interrupts. _. privmsg if you're still here
[22:08] <lifeless> flacoste: btw, we're getting traction on bug search and bug display
[22:08] <flacoste> i saw!
[22:08] <flacoste> that's pretty cool
[22:09] <lifeless> I should have an analysis of hotspots for the 'show all comments' case next week
[22:09] <lifeless> once we've hit the 'ok the current definition is as efficient as we can do with current tech
[22:09] <lifeless> we'll need to look at pagination of bug comments and so on
[22:09] <lifeless> loading 1400 for bug one is just nuts.
[22:11] <lifeless> it would be really cool to do a facebook style incremental loader though
[22:11] <lifeless> sinzui suggested an enhanced BatchNavigator which would add more results in a given direction
[22:11] <lifeless> without a page load, for ajax enabled users
=== benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: bac | https://code.launchpad.net/launchpad-project/+activereviews
[22:37] <jcsackett> sinzui: standup? or skipping, since it's just the two of us?
[23:28] <jcsackett> sinzui: well, i guess skipping. :-P
[23:38] <LPCIBot> Project db-devel build (380): STILL FAILING in 5 hr 32 min: https://hudson.wedontsleep.org/job/db-devel/380/
[23:38] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12405,
[23:38] <LPCIBot> 12406, 12407, 12408 included.
[23:49] <maxb> Why would ~registry be subscribed to lp:~debian-bazaar/bzr/unstable ? Is this one of these "Dump stuff on ~registry to allow deleting the associated thing" cases?
[23:49] <wgrant> Right, deleting a team is achieved by merging it into ~registry.
[23:50] <wgrant> This is somewhat insane.
[23:51] <lifeless> unsubscribe it
[23:53] <wgrant> Gone.
[23:58] <jam> lifeless: can you ec2land  --no-qa https://code.launchpad.net/~jameinel/launchpad/twisted-close-on-failure/+merge/50067 ? (You're welcome to add bug #717345 to it, but that won't be complete until the third patch lands)
[23:58] <_mup_> Bug #717345: Updates to SFTP server leak file handles in use_forking_server mode <Launchpad itself:In Progress by jameinel> < https://launchpad.net/bugs/717345 >
[23:58] <jam> (Since you were kind enough to mark it approved.)