[00:00] <thumper> AAArrgggghhh!!!!
[00:00] <thumper> FFS
[00:00] <thumper> factory.makeBugTarget returns a bugtarget which has a bug with two! targets
[00:00] <lifeless> conjoined master?
[00:01]  * thumper shrugs
[00:01] <thumper> I don't even know what that means
[00:03] <leonardr> thumper: sinzui and i just worked on that, let me see if i can understand it for you
[00:03] <lifeless> if you have a bug targeted on the development focus for a pillar, then you have 2 bug tasks
[00:03] <lifeless> one on the pillar, one on the series
[00:03] <lifeless> and this is handled specially.
[00:03] <thumper> lifeless: a bare "makeBugTask" should give the simplest possible, surely
[00:03] <lifeless> I don't know why we do this.
[00:04] <lifeless> thumper: if the target is the default series for the pillar, making a bug on that target will implicitly create one on the pillar
[00:05] <thumper> lifeless: a simple makeBugTask should not target any series
[00:05] <lifeless> thumper: sure
[00:06] <wgrant> lifeless: So, are you looking at the bug search issue? It is just about critical.
[00:06] <thumper> ok, it seems that it has created a bug with two different product targets
[00:07] <thumper> leonardr: what enlightenment can you offer?
[00:07] <lifeless> thumper: ok, thats different
[00:07] <leonardr> lifeless: if you just call makeBugTask() with no arguments, the target is a product, and a product has no need for a prerequisite bugtask, so i'm not sure what's going on
[00:07] <leonardr> er, thumper -^
[00:08] <thumper> I know
[00:08] <thumper> make bug makes a default task
[00:08] <lifeless> it has to
[00:08] <thumper> makeBugTask makes a task
[00:08] <thumper> so when you go makeBugTask with no params
[00:08] <thumper> you get two tasks
[00:08] <lifeless> wgrant: so oopses were still nominal yesterday
[00:08] <thumper> one from the makeBug call
[00:08] <lifeless> wgrant: are you seeing other data ?
[00:08] <thumper> and one added in the makeBugTask
[00:09]  * thumper fixorates
[00:10] <leonardr> thumper: your fix may conflict with the branch i'm trying to land now, though it should be reconcilable
[00:10] <thumper> leonardr: what did you do about it?
[00:10] <leonardr> thumper: i changed something else in makeBugTask
[00:10] <leonardr> let me see...
[00:10] <thumper> which branch is it?
[00:11] <leonardr> lp:~leonardr/launchpad/bug-106338
[00:12] <wgrant> lifeless: bzr bug searches time out, and when they don't they take >10s.
[00:12] <wgrant> lifeless: Didn't this change only get deployed like 7 hours ago?
[00:13] <thumper> hmm...
[00:13] <leonardr> thumper: we made some other changes to makeBugTask
[00:13] <lifeless> wgrant: 12582 was the change
[00:14] <thumper> leonardr: I see that
[00:14] <thumper> leonardr: I'm going to change my approach in my test to not need it
[00:14] <leonardr> ok. fwiw, i think your proposed change is complementary to ours
[00:15] <wgrant> Right, and I see the LPS change for that a little over 7 hours ago.
[00:15] <wgrant> lifeless: So I don't think we've seen any OOPS reports for that yet.
[00:19] <lifeless> wgrant: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=sshd&orderby=-importance&search=Search&field.status:list=NEW&field.status:list=INCOMPLETE_WITH_RESPONSE&field.status:list=INCOMPLETE_WITHOUT_RESPONSE&field.status:list=CONFIRMED&field.status:list=TRIAGED&field.status:list=INPROGRESS&field.status:list=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[00:21] <lifeless> wgrant: what I mean is 'searches on ubuntu seem ok'
[00:27] <huwshimi> If wanted to add another static class to this: <td tal:attributes="class view/scope_css_class"> would it be <td tal:attributes="class view/scope_css_class text-right"> or <td tal:attributes="class view/scope_css_class" class="text-right">?
[00:29] <lifeless> The latter
[00:29] <lifeless> tal is for when you need things evaluated
[00:30] <lifeless> mmm
[00:30] <lifeless> it probably won't combine right
[00:30] <lifeless> you probably need to fix scope_css_class
[00:35] <StevenK> lifeless: Can you run select count(id) from SourcePackageRelease; on qastaging? I'd like to get a feel for the size of the table
[00:36] <huwshimi> lifeless: How do I figure out what object that tal statement is using? There are two classes that define scope_css_class.
[00:37] <huwshimi> lifeless: I guess that's kind of a general question about these templates
[00:37] <lifeless> huwshimi: bug 735196 may interest you
[00:37] <huwshimi> specifically the templates in question are lib/lp/answers/templates/questions-index.pt and lib/lp/blueprints/templates/specifications-index.pt
[00:37] <_mup_> Bug #735196: Text pops out of announcment box <css> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735196 >
[01:35] <wgrant> :(
[01:36] <lifeless> T-20
[01:36] <wgrant> Heh, yes.
[01:37] <wgrant> It is a painful wait.
[01:37] <wgrant> But also not today a terribly interesting one.
[01:37] <wallyworld> wgrant: can you tell me the command to run to tar up an egg. in the past i've just done it manually but i'm sure there's an easier way.
[01:37] <lifeless> setup.py egg_info ...
[01:37] <wgrant> wallyworld: It varies.
[01:37] <lifeless> or setup.py sdist
[01:37] <wgrant> wallyworld: Often python setup.py egg_info sdist
[01:37] <lifeless> or bze export
[01:37] <wgrant> Right.
[01:38] <wgrant> All of what lifeless says is valid.
[01:38] <wgrant> Which egg?
[01:38] <wallyworld> thanks. i'll try one of those. i have proposed a change to lazr-js and want to use it locally while i'm waiting to get it approved
[01:39] <wgrant> setup.py egg_info -b-somesuffix sdist
[01:39] <lifeless> wgrant: egg_info does an sdist AFAICT
[01:39] <wgrant> -b adds a suffix to the version.
[01:39] <wgrant> Hm.
[01:40]  * wallyworld goes to impersonate a chicken
[01:41]  * wgrant deletes code.
[01:41] <lifeless> holy cow
[01:41] <lifeless> that with clause I was working on yesterday -rocks-
[01:42] <lifeless> cold on qastaging:  Total runtime: 151.508 ms
[01:42] <lifeless> (20 rows)
[01:42] <lifeless> Time: 193.425 ms
[01:42] <wgrant> lifeless: POFile:+translate?
[01:42] <lifeless> yeah
[01:42] <wgrant> Wasn't the old one several repitions of >1s?
[01:42] <wgrant> *repetitions
[01:42] <lifeless> so the old one was 1.1s cold, 300ms hot
[01:42] <lifeless> this is
[01:42] <wgrant> Ah.
[01:42] <lifeless> 190ms hot, 9ms cold
[01:43] <wgrant> I doubt that, somehow.
[01:43] <lifeless> stub tested on prob, 70ms cold
[01:43] <lifeless> 190ms cold 9ms hot. doh.
[01:43] <wgrant> Heh.
[01:44] <lifeless> we'll probably find it throws some corner case out and becomes pathological
[01:45] <lifeless> cats are awesome
[01:45] <wgrant> Occasionally.
[01:46] <wgrant> Mine likes to sit next to my computer. This is OK except when the side of the case is off, and tail and CPU fan intersect.
[01:47] <lifeless> lol
[01:47] <wgrant> Unhappy cat.
[01:47] <wgrant> What is yours doing?
[01:47] <lifeless> right now, curled up in the basement of its climber, snoring gently
[01:48] <wgrant> Heh.
[01:50]  * wgrant deletes lots of NullBugTask-related hacks.
[01:58] <lifeless> wgrant: https://pastebin.canonical.com/44718/ may interest you (re search perf)
[02:02] <lifeless> dropping the private-bug query -> 1 second
[02:03] <lifeless> but, 10% of the estimated cost
[02:04] <wgrant> lifeless: :(
[02:04] <wgrant> It's still got a really awful plan, though.
[02:04] <wgrant> mawson goes the other way and is sub-second.
[02:05] <wgrant>  * 307 Time Outs
[02:05] <wgrant> So close :(
[02:06] <lifeless> hard + soft = 1800
[02:06] <lifeless> 300 down from yesterdays report
[02:06] <wgrant> And we only had <8 hours of fixedness in that report.
[02:08] <lifeless> so I think we're good to move ahead
[02:08] <wgrant> To 12s? Or less?
[02:08] <lifeless> 12
[02:08] <wgrant> :(
[02:08] <lifeless> I'm worried about search
[02:08] <wgrant> Yeah.
[02:09] <lifeless> crazy eddie plans
[02:09] <wgrant> Gnrgh.
[02:09] <lifeless> jcsackett: hows cve:+index treating you?
[02:09] <lifeless> Distribution:+bugtarget-portlet-bugfilters-stats will need fixing soon
[02:09] <lifeless> bugtask:+index is looking pretty happy, as such things go
[02:11] <wgrant> Bugs' ZCML is crap.
[02:14] <lifeless> s/[^ ]* //
[02:17] <wgrant> +editstatus is protected from rendering on a NullBugTask in three or four ways.
[02:18] <lifeless> win
[02:19] <wgrant> Why would a task listing ever hit a nullbugtask? :/
[02:19] <lifeless> well
[02:20] <lifeless> what was that bug I was looking at yesterday
[02:20] <lifeless> the one with memcache in it ? it wasn't redirecting
[02:20] <wgrant> I know why it sometimes doesn't redirect.
[02:20] <wgrant> That doesn't explain how one would have *ever* shown up in a listing.
[02:20] <lifeless> oh
[02:20] <lifeless> thats because the current context has to show
[02:21] <wgrant> Hm?
[02:21] <lifeless> in the past anyhow
[02:34] <wgrant> Our tests are slow.
[02:36] <StevenK> lifeless: Did you miss my ping?
[02:37] <lifeless> StevenK: presumably
[02:37] <lifeless> whats uo ?
[02:37] <lifeless> ah
[02:37] <lifeless> yes, i did it
[02:38] <lifeless> 822218
[02:38] <StevenK> Ouch, thanks
[02:38] <thumper> lifeless: your with_ statement seems to have a bug in __contains__
[02:39] <thumper> lifeless: possibly worth making a test for
[02:39] <StevenK> lifeless: I think the fastest way to fix the job on loganberry is to run a memcached on it until the job is done. But I think you might want to investigate why we have one memcached per appserver anyway.
[02:40] <StevenK> wgrant: http://pastebin.ubuntu.com/580404/
[02:40] <wgrant> StevenK: Looks good.
[02:41] <StevenK> wgrant: Shouldn't you be the OCR, anyway?
[02:41] <wgrant> StevenK: A reasonable point.
[02:43] <wgrant> lp.bugs.tests.test_bugtask_search.TestNoPreloadBugtaskTargets* is SLOW.
[02:43] <StevenK> How slow?
[02:43] <lifeless> thumper: what happens?
[02:43] <wgrant> StevenK: Many minutes.
[02:43] <lifeless> StevenK: we have a cluster
[02:43] <thumper> lifeless: the with statement isn't used
[02:43] <StevenK> wgrant: Kill it!
[02:44] <lifeless> StevenK: and deterministic routing to them
[02:44] <thumper> lifeless: and you get:     ProgrammingError: relation "blocked" does not exist
[02:44] <thumper>     LINE 1: ....id != 14 AND (Specification.id in (select id from blocked))
[02:44] <lifeless> StevenK: so the fastest way is to make sure the memcaches are configured correctly and have gsa open firewalls if needed.
[02:44] <lifeless> thumper: thanks
[02:44] <lifeless> thumper: probably shallow
[02:44] <thumper> lifeless: probably
[02:45] <StevenK> lifeless: So the way forward is an RT?
[02:45] <lifeless> StevenK: in either scenario yes
[02:46] <StevenK> RT's make me sad.
[02:51] <StevenK> wgrant: If I'm reading these numbers right, we have processed over 4,500 SPRs with 6 failures.
[02:52] <wgrant> StevenK: Excellent.
[02:52] <StevenK> But since memcache doesn't work, we keep looking at the 6 failures.
[02:52] <wgrant> Right.
[02:59] <lifeless> heh
[02:59] <lifeless> doing bzr pull --overwrite lp:~lifeless/storm/with-without-datetime in my lp tree -- bad
[02:59] <wgrant> Haha
[03:06] <lifeless> thumper: lp:~lifeless/storm/with-without-datetime contains the fix
[03:07] <lifeless> thumper: I'll let you make a new egg from the branch, because you'll need that to include it in your branch
[03:07] <thumper> lifeless: I don't need it
[03:07] <thumper> just bumped into it
[03:07] <lifeless> ah
[03:08] <lifeless> ok
[03:08] <lifeless> I might bump the egg shortly, thanks for letting me know
[03:16] <StevenK> wgrant, lifeless: Back of envolope maths: We're looking at ~ 2 months
[03:16] <wgrant> Really?
[03:17] <wgrant> How many need to be processed?
[03:17] <wgrant> That's almost twice my prediction.
[03:17] <StevenK> My maths was assuming all of them, which I've just realised is dead wong
[03:18] <lifeless> so, you can make this faster
[03:19] <lifeless> change garbo so that rather than a 15 minute per loop limit
[03:19] <wgrant> This runs last, dying only on the hour?
[03:19] <lifeless> it sets a 50 minute budget for all loops
[03:19] <lifeless> and per loop allows $remaining_budget as a limit
[03:20] <StevenK> lifeless: No, let me fix my maths first
[03:21] <mwhudson> thumper: the ajax love for blueprints is very nice
[03:21] <lifeless> StevenK: fixing this would be a good idea anyway
[03:22] <thumper> mwhudson: yay, it is noticed :)
[03:22] <lifeless> the 15 minute per loop is bong because if 5 loops take max time we'll exceed one hour
[03:22]  * StevenK looks for the query lifeless wrote
[03:22] <mwhudson> thumper: you should be coming to UDS, i bet all the ubuntu devs would buy you beer
[03:23] <StevenK> thumper: I think you should blog about the blueprint changes and link to the screencast
[03:23] <wgrant> Let's not advertise blueprints.…
[03:23] <StevenK> That may involve jcastro and dholbach flying down to hug you
[03:23] <thumper> StevenK: I did blog about it
[03:24] <lifeless> wgrant: its good to tell people about things we're improving
[03:26] <StevenK> lifeless: select changelog is null, count(*) from sourcepackagerelease group by changelog is null; on qas, plz
[03:26] <lifeless>  f        | 270845
[03:26] <lifeless>  t        | 551373
[03:27] <StevenK> So we are missing 551k changelogs?
[03:27] <lifeless> on qas
[03:27] <StevenK> Right
[03:27] <StevenK> On prod it is likely 547k
[03:28] <StevenK> Still 48 days, give or take
[03:29] <lifeless> so, do the change I propose to garbo (and put this job at the end)
[03:29] <lifeless> its a general win and will give you 3-4 times the throughput
[03:29] <wgrant> 14:19:52 < lifeless> and per loop allows $remaining_budget as a limit
[03:29] <wgrant> How is that going to work?
[03:29] <wgrant> That will allow even the first loop to exhaust the full window.
[03:29] <StevenK> lifeless: Yes, I was just about to look at that
[03:29] <wgrant> Preventing the subsequent ones from running at sll.
[03:30] <StevenK> wgrant: So, garbo-hourly has a budget of 50 minutes. Allow the loops to have a budget of whatever is left of the 50, rather than 15 minutes.
[03:30] <wgrant> StevenK: Right. So loop 1 has 50 minutes to run it, and does so.
[03:31] <StevenK> wgrant: Can haz review of https://code.launchpad.net/~stevenk/launchpad/dsd-base_source_pub-archive/+merge/53357
[03:31] <wgrant> Goodbye loops >=2
[03:31] <StevenK> lifeless: wgrant has a good point
[03:31] <wgrant> StevenK: I shouldn't, but since I'm mentored...
[03:31] <wgrant> lifeless: Could you mentor StevenK's?
[03:31] <StevenK> wgrant: Well, then I'll ask lifeless for a review, then
[03:32] <StevenK> wgrant: You don't need to feel obligated to review
[03:32] <wgrant> StevenK: I am happy to, but I think it's not really appropriate in this case. But this case is pretty trivial, so meh.
[03:34] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/unuse-nullbugtask/+merge/53363?
[03:35] <lifeless> wgrant: it would, but only one of them ever uses its full budget atm - the spr changelog one
[03:35] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-734642/+merge/53365
[03:36] <StevenK> lifeless: That is false, read the logs
[03:36] <lifeless> StevenK: what else is using its full budget ?
[03:38] <StevenK> 2011-03-15 02:13:16 INFO    Running OAuthNoncePruner
[03:38] <StevenK> 2011-03-15 02:28:08 DEBUG   Done. 1 items in 1 iterations, 891.136 seconds, average size 1.000000 (0.00112216283655/s)
[03:38] <StevenK> That isn't every run, but it does happen.
[03:38] <lifeless> that looks like a bug
[03:38] <lifeless> table contention perhaps
[03:38] <StevenK> It is table contention
[03:39] <lifeless> not at 15 minutes its not
[03:39] <StevenK> It blocks on two transactions and sleeps
[03:39] <StevenK> But I don't want to paste 6 lines to the channel
[03:43] <StevenK> thumper: https://code.launchpad.net/~wgrant/launchpad/unuse-nullbugtask/+merge/53363?
[03:43]  * thumper looks
[03:44] <lifeless> StevenK: the backoff algorithm needs fixing I guess
[03:45] <thumper> StevenK: done
[03:45]  * thumper graduates StevenK
[03:45] <thumper> StevenK: I'll send an email to the list
[03:46] <LPCIBot> Project windmill build #49: STILL FAILING in 1 hr 7 min: https://hudson.wedontsleep.org/job/windmill/49/
[03:47] <wgrant> thumper: Thanks. Could you now mentor https://code.launchpad.net/~lifeless/launchpad/bug-734642/+merge/53365?
[03:47] <StevenK> thumper: !!!!
[03:47] <wgrant> (congrats StevenK)
[03:49] <StevenK> thumper: Let me edit ReviewerSchedule
[03:52] <poolie> yes, congrats
[03:52] <poolie> wgrant i filed bug 735260 for the problem i mentioned before
[03:52] <_mup_> Bug #735260: multiple timeouts in bug search <oops> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735260 >
[03:52] <poolie> it seems still broken
[03:52] <wgrant> poolie: You probably want to convince lifeless that it has regressed.
[03:52] <wgrant> I am convinced.
[03:53] <lifeless> yes, the tradeoffs have altered
[03:53] <lifeless> ubuntu bug search is faster than it was
[03:53] <lifeless> and we have more of those
[03:54] <poolie> seriously
[03:54] <lifeless> yes, seriously
[03:55] <lifeless> we had 300 oopses from ~ 8 hours of the new search query
[03:55] <lifeless> (total timeouts)
[03:55] <poolie> ah, i wasn't questioning your assertion, just expressing frustration at not being able to search
[03:55] <lifeless> thats down day on day from monday and from the weekend
[03:55] <poolie> good thing i have email i guess
[03:58] <lifeless> https://lpstats.canonical.com/graphs/OopsLpnetHourly/
[03:59] <lifeless> there is certainly a spike
[03:59] <poolie> i'm glad it's progressing
[04:00] <lifeless> thumper: https://code.launchpad.net/~lifeless/launchpad/bug-734642/+merge/53365
[04:00] <lifeless> thumper: oh you have already - thanks
[04:13] <StevenK> lifeless: Did you want to reping about the LPS feature flags?
[04:14] <lifeless> poolie: try searching at bugs.launchpad.net/bugs
[04:14] <lifeless> poolie: its performing fine - 5 seconds to query sshd
[04:14] <lifeless> StevenK: econtext
[04:15] <StevenK> lifeless: Removal of the recipe beta feature flag
[04:15] <poolie> lifeless, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1900G239
[04:15] <poolie> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1900J237
[04:15] <poolie> is not 'fine'
[04:16] <lifeless> poolie: thats very odd
[04:16] <lifeless> because I tried right before commenting
[04:16] <lifeless> poolie: what query did you use?
[04:16] <wgrant> Also right after commenting?
[04:16] <wgrant> Master vs. slave, maybe?
[04:16] <lifeless> wgrant: possibly
[04:16] <lifeless> 98 queries/external actions issued in 4.67 seconds
[04:17] <poolie> i typed 'shortreadverror' in the search field there, both with 'bzr' in the project field and without
[04:17] <lifeless> 29 queries/external actions issued in 6.53 seconds
[04:17] <lifeless> bug 413430 bug 402857 bug 673439
[04:18] <_mup_> Bug #413430: ShortReadvError on index file <data-integrity> <ui> <Bazaar:Confirmed> < https://launchpad.net/bugs/413430 >
[04:18] <_mup_> Bug #402857: ShortReadvError in pack file: bzr check should check pack file hashes and recover from problems <check> <packs> <Bazaar:Confirmed> < https://launchpad.net/bugs/402857 >
[04:18] <poolie> just curious, why did you untag it 'oops' and 'regression'?
[04:18] <lifeless> we use oops and timeout tags as partitions
[04:18] <poolie> 'oops' means 'non-timeout oops'?
[04:18] <poolie> ok
[04:19] <lifeless> search performance is being a problem but we haven't figured out what is up yet
[04:19] <lifeless> it may well be a coincidence
[04:19] <lifeless> particularly given that right now the same searches are working for me an dbreaking for you
[04:19] <poolie> this used to work reliably, and now it doesn't --> regression, is it not?
[04:19] <lifeless> poolie: it didn't work reliably
[04:19] <wgrant> For !Ubuntu it did...
[04:20] <lifeless> wgrant: poolie is searching in ubuntu still - the bug he filed was an ubuntu bug search
[04:20] <poolie> for me, it's gone from working >95% of the time to working <10% of the time
[04:20] <poolie> no, it wasn't
[04:20] <wgrant> Wasn't it in the bzr product?
[04:20] <poolie> wgrant, yes
[04:20] <lifeless> https://bugs.launchpad.net/ubuntu/+bugs?field ...
[04:20] <lifeless> poolie: ^ thats the url in your bug description, which I have not altered
[04:22] <lifeless> the other two oopses you've reported here I have asked for a sync of, to look at
[04:22] <poolie> ok
[04:22] <poolie> it is also failing in plain bzr searches, i'm pretty sure
[04:22] <wgrant> It is, I saw some earlier.
[04:22] <poolie> i'm confused, i thought i posted several oopses in the description
[04:23] <poolie> for instance https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1900J237
[04:23] <lifeless> you pasted that here, its syncing at the moment
[04:23] <lifeless> after my suggestion to search on the root context
[04:24] <lifeless> the J oops is on bzr
[04:25] <lifeless> 9 second count cold; 2 second count hot
 i'm getting a 'please try again' page talking to lp
[04:25] <poolie>  in fact https://bugs.launchpad.net/bzr/+bugs?field.searchtext=winsshd&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= is pe
[04:25] <poolie> rsistently timing out
[04:25] <poolie> anyhow
[04:25] <poolie> does 'regression' mean 'used to work and now doesn't' or is it more subtle?
[04:25] <lifeless>          ->  Index Scan using bug_fti on bug  (cost=0.00..2306.35 rows=42 width=4) (actual time=43.873..1929.329 rows=7 loops=1)
[04:25] <lifeless>                Index Cond: ((fti)::tsvector @@ '''shortreadverror'''::tsquery)
[04:25] <poolie> i don't care what tags it has, i just want to understand what they mean
[04:25] <lifeless>                Filter: ((duplicateof IS NULL) AND ((NOT private) OR (SubPlan 1)))
[04:26] <lifeless> poolie: regression isn't strictly defined; I may add it back to the bug once we have a handle on whats up
[04:26] <lifeless> poolie: regressions and timeouts and oopses all fall in the same priority bucket (and escalated bugs)
[04:27] <poolie> anyhow, to be clear
[04:27] <poolie> searching just in bzr was working and now isn't
[04:27] <poolie> i might have accidentally been in the package context for one search that i pasted into the bug, but it's also failed several times in the project
[04:28] <lifeless> sure
[04:28] <lifeless> so, we're looking at it
[04:28] <poolie> thanks
[04:28] <lifeless> have been all day in fact
[04:30] <poolie> i'll let you get on with it
[04:30] <poolie> just wanted to be sure the bug was accurate
[04:33] <lifeless> poolie: regression is really about code changes that break things horribly. There is some evidence that this isn't a code change issue per se
[04:33] <lifeless> *even though* a code change was landed
[04:37] <wgrant> StevenK: Want to use your new superpowers on https://code.launchpad.net/~wgrant/launchpad/delete-nullbugtask/+merge/53367?
[04:37] <wgrant> Ugh, forgot prereq.
[04:40] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/delete-nullbugtask/+merge/53369
[04:42] <StevenK> wgrant: Done.
[04:42] <StevenK> It's going to hard to get out of the habit of code* everything
[04:42] <wgrant> Thanks.
[04:43] <StevenK> wgrant: I fully support your plan to kill NullBugTask, and wish to subscribe to your newsletter.
[04:43] <wgrant> StevenK: you should also set the MP status, probably.
[04:43] <StevenK> Also done
[04:43] <wgrant> You overwrote mine :(
[04:43] <wgrant> But thanks.
[05:13] <jtv> StevenK: I need some help with Q/A for generating the DSDJs.
[05:13] <jtv> I need to turn soyuz.derived_series_jobs.enabled on, which I'm not privileged to do, and then I need to make sure that everything that will create SPPHs still works which I don't know how to do.
[05:14] <StevenK> Turn it on *where*
[05:14] <lifeless> poolie: mostly fixed
[05:19] <jtv> StevenK: on qastaging, I guess—depends on where we can do whatever generates SPPHs.
[05:19] <StevenK> gina can't run on qastaging, you can upload and copy, though
[05:20] <jtv> Does that mean one place will get exercised but another won't?
[05:20] <StevenK> Obviously.
[05:20] <StevenK> gina can run on DF, but carefully
[05:21] <jtv> So if I can get someone to enable the flag on qastaging, I can test uploading to PPAs and copying between PPAs there?
[05:21] <StevenK> Indeed
[05:22] <jtv> lifeless: could you enable soyuz.derived_series_jobs.enabled for me on qastaging?
[05:24] <lifeless> jtv: I don't have the admin bit
[05:24] <lifeless> jtv: stub does; stub^
[05:25] <stub> How do I do that? Is this a feature flag or something?
[05:26] <lifeless> visit qastaging.launchpad.net/+feature-rules
[05:26] <wgrant> It's a boolean feature flag. Set it default true.
[05:26] <lifeless> add a line like
[05:26] <lifeless> soyuz.derived_series_jobs.enabled default 0 on
[05:26] <lifeless> (flag, scope, sequence, value)
[05:29] <lifeless> poolie: all sorted now AFAWCT
[05:30] <wgrant> It's still not great, but it's <2s now.
[05:30] <poolie> super
[05:35] <stub> That ff is on now.
[05:35] <stub> On qastaging
[05:35] <stub> jtv: ^^^
[05:35] <jtv> thanks stub
[05:55] <jtv> StevenK: how do I make dput upload to qastaging?
[05:55] <StevenK> Ugh, I can never remember.
[05:55] <wgrant> Erm.
[05:55] <wgrant> Does asuka run poppy?
[05:56] <wgrant> I didn't think it did.
[05:56] <wgrant> You can do recipes and copies there, but not uploads AFAIK.
[05:58] <StevenK> Doesn't look like it does.
[05:58] <jtv> So I can't test uploads?
[05:58] <wgrant> Only on mawson.
[05:59] <jtv> So I can't.
[05:59] <wgrant> Not without our assistance.
[06:00] <jtv> Then could you help out with this?
[06:00] <wgrant> Yes.
[06:00] <jtv> Thanks.  We'll need to enable the feature flag first.
[06:00] <wgrant> No, first we need to update the codebase :(
[06:00] <wgrant> Will take a few minutes.
[06:01] <wgrant> jtv: Your change is in db-devel?
[06:01] <jtv> wgrant: I believe so, but let me check
[06:03] <jtv> wgrant: it is, as of r10296
[06:03] <wgrant> Great, thanks.
[06:04] <jtv> The feature flag is soyuz.derived_series_jobs.enabled
[06:05] <jtv> (Note underscores; the documentation says whosoever useth dashes in feature-flag names shall suffer eternal, er, suffering
[06:05] <wgrant> Yes.
[06:05] <wgrant> I think we all agreed on that.
[06:05] <wgrant> Still waiting for mawson to update.
[06:07] <jtv> Meanwhile I'm waiting for my copied package to be published on qastaging… how long should that take?
[06:07] <wgrant> Eternity.
[06:07] <wgrant> The publisher does not run.
[06:07] <wgrant> Why do you need a publisher?
[06:08] <jtv> I need to test whether I broke SPPH generation or not.
[06:08] <wgrant> SPPHs are done in the webapp transaction.
[06:08] <wgrant> You can check through the API, or even the web UI.
[06:08] <jtv> How do I do that?
[06:09] <wgrant> https://qastaging.launchpad.net/api/devel/~PERSON/+archive/PPA?ws.op=getPublishedSources&status=Pending
[06:09] <wgrant> That should do it.
[06:09] <jtv> 404
[06:09] <StevenK> Note the PERSON
[06:09] <jtv> Ah
[06:10] <StevenK> jtv: Why did you create a new interfaces file for DSDJs when the two current DistributionJobs use interfaces/distributionjob?
[06:10] <StevenK> jtv: And it's bugging me, so can I move it?
[06:10] <jtv> StevenK: you can if you like, but I wanted to avoid the mindless piling-on that has plagued parts of our codebase for so long.
[06:11] <StevenK> They're tiny interfaces, so meh
[06:11] <jtv> wgrant: I suppose I need to replace the PPA with something as well?
[06:11] <wgrant> jtv: Yes.
[06:11] <jtv> But with what?
[06:11] <lifeless> only if you want it to work
[06:11] <wgrant> Whichever PPA you copied it into...
[06:12] <jtv> I copied into ~jtv/+archive/ppa/… nothing in there strikes me as a PPA name.
[06:12] <wgrant> The format of the URL might give you a hint :)
[06:14] <jtv> What, the name is https?
[06:14] <wgrant> s@~PERSON/+archive/PPA@~jtv/+archive/ppa@
[06:15] <jtv> Ah
[06:15] <jtv> So I'm back where I started.
[06:15] <wgrant> jtv: https://dogfood.launchpad.net/+feature-changelog
[06:17] <jtv> Yes, that would be it.
[06:18] <jtv> As for the pending packages, that URL just ended up getting me to the page I was already looking at.  I don't get the impression that the status=Pending is doing much; packages that I thought were published years ago are still in there.
[06:19] <wgrant> "total_size": 1
[06:19] <jtv> The word "total" doesn't appear on the page
[06:19] <wgrant> It's not a page.
[06:19] <wgrant> It's a JSON document...
[06:19] <jtv> I think I got redirected at some point.
[06:20] <jtv> Getting JSON now.
[06:21] <jtv> So… where does the SPPH get created?
[06:21] <wgrant> Code-wise?
[06:21] <jtv> Interaction-wise.  What would fail if that went wrong?
[06:21] <lifeless> thumper: leonard might be the best possible person to look at https://bugs.launchpad.net/launchpad/+bug/735202
[06:22] <wgrant> Your +copy-packages POST would OOPS, or it wouldn't show up with status=Pending.
[06:22] <jtv> Ah, ok, so it was fine all this time!  Thanks.
[06:22] <wgrant> Now, you wanted to test an upload on DF?
[06:23] <jtv> Sure
[06:23] <wgrant> FTP to upload.dogfood.launchpad.net
[06:24] <jtv> OK, I logged in anonymously.
[06:25] <wgrant> You should be using dput to do that for you.
[06:26] <jtv> Ah, so reconfigure dput, then dput, then configure back?
[06:26] <wgrant> Right. Add a stanza to ~/.dput.cf, modelled on the existing ppa one in /etc/dput.cf.
[06:26] <jtv> Except fqdn = dogfood.launchpad.net?
[06:27] <wgrant> Right.
[06:27] <jtv> And then make dput use that stanza somehow.
[06:27] <wgrant> dput dfppa:jtv/ppa blah_source.changes.
[06:28] <jtv> And I guess the dfppa is the name of the new stanza?
[06:28] <jtv> It's uploading, so I guess that's good.
[06:29] <jtv> …and it's uploaded.
[06:29] <jtv> I'm not seeing it show up on my dogfood PPA page though.
[06:29] <StevenK> It needs to be processed
[06:30] <StevenK> Which needs to be run by hand
[06:30] <wgrant> I'm just clearing out incoming/
[06:30] <jtv> So any moment now?
[06:31] <wgrant> Processing.
[06:32] <wgrant> 2011-03-15 06:31:19 DEBUG   Rejected:
[06:32] <wgrant> 2011-03-15 06:31:19 DEBUG   Unable to find distroseries: unstable
[06:32] <jtv> Grrr
[06:33] <jtv> Uploading again with that changed to "natty."
[06:35] <jtv> wgrant: could you run it again?
[06:35] <wgrant> 2011-03-15 06:34:40 DEBUG   Rejected:
[06:35] <wgrant> 2011-03-15 06:34:40 DEBUG   The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?
[06:35] <wgrant> Your upload path was /ubuntu.
[06:37] <jtv> How did that get set?
[06:37] <jtv> I used "dogfood:jtv/ppa"
[06:38] <wgrant> Sounds like your path in dput.cf is bad.
[06:38] <wgrant> It should have %(dogfood)s in it
[06:39] <StevenK> Actually, %(section name)
[06:39] <wgrant> Right.
[06:40] <jtv> I don't see any path in there
[06:40] <jtv> Oh, "incoming"?
[06:40] <jtv> It currently says "ubuntu/"
[06:40] <jtv> What should that be?
[06:41] <wgrant> Copy it from the ppa section, except s/ppa/dogfood/
[06:44] <jtv> I don't have a ppa section, only an lpdev section.
[06:44] <wgrant> Even in /etc/dput.cf?
[06:45] <jtv> There is one there.  ~%(ppa)s/ubuntu
[06:45] <jtv> So I'll use that then.
[06:46] <jtv> Grr packag has already been uploaded to dogfood… bumping version number
[06:47] <wgrant> No.
[06:47] <wgrant> Just dput -f
[06:48] <jtv> Too late
[06:48] <jtv> Already uploaded the new one.
[06:54] <wgrant> jtv: Looks like I need to run security.py
[06:54] <jtv> ahhh yes
[06:55] <wgrant> 2011-03-15 06:55:08 DEBUG   Creating PENDING publishing record.
[06:55] <wgrant> Still going,..
[06:55] <wgrant> This bit often takes a couple of minutes on mawson; NFI why.
[06:56] <poolie> https://bugs.launchpad.net/launchpad/+bug/735290 ouch
[06:56] <_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 >
[07:06] <wgrant> jtv: Accepted.
[07:06] <wgrant> jtv: You can check for a publication now.
[07:08] <jtv> wgrant: thanks!
[07:08] <wgrant> The publisher should be running now, too.
[07:09] <jtv> wgrant: the package's on the PPA listing
[07:09] <wgrant> Indeed.
[07:09] <wgrant> Shall I now check for jobs?
[07:09] <jtv> If that means an SPPH was just successfully created, then that's done.
[07:09] <jtv> Oh yes please, that too :)
[07:10] <wgrant> Which table?
[07:10] <StevenK> DistributionJob
[07:10] <jtv> DistributionJob
[07:10] <wgrant> Ah.
[07:10] <jtv> Look for json metadata consisting of {sourcepackagename: <id>}
[07:11] <wgrant> Nothing there.
[07:11] <wgrant> Only some package copy things.
[07:11] <wgrant> But I guess that's not surprising.
[07:11] <wgrant> As these are not derived series uploads.
[07:11] <jtv> Ahh of course
[07:12] <jtv> So we ought to try that as well.
[07:12] <StevenK> maverick is a derived series
[07:12] <StevenK> On DF
[07:12] <StevenK> So re-upload to that
[07:12] <jtv> From another distro?
[07:12] <wgrant> From sid, IIRC.
[07:12] <StevenK> Right
[07:12] <jtv> great
[07:12] <wgrant> I changed that in December.
[07:13] <wgrant> jtv: I'll give you upload privs. Upload again to /ubuntu
[07:13] <jtv> Thanks.  Uploading already.
[07:13] <jtv> (With maverick as the series)
[07:13] <wgrant> Great.
[07:14] <wgrant> Done?
[07:14] <wgrant> Seems to be.
[07:14] <jtv> Yup
[07:14] <wgrant> /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20110315-071355-000009/~jtv/ppa/ubuntu/libpqxx_3.2-1ppa4.dsc
[07:14] <wgrant> Wrong path.
[07:14] <wgrant> I'll move it.
[07:14] <jtv> Thanks.  I have no idea what was wrong about that, or indeed what might have been right
[07:15] <wgrant> ~jtv/ppa/ubuntu is your PPA, not the primary archive.
[07:15] <jtv> Ah, of course, we're not uploading to the ppa any more
[07:15] <jtv> Or at least, trying not to be
[07:15] <wgrant> Heh.
[07:16] <jtv> wgrant: and then I suppose it'd be also worth checking that we can copy a package into maverick.
[07:17] <wgrant> jtv: Indeed. I'll do that in a sec.
[07:17] <jtv> Thanks.
[07:17] <wgrant> :(
[07:17] <wgrant> JS hacks upon JS hacks.
[07:17] <jtv> A hex upon JS hacks.
[07:17] <lifeless> https://bugs.launchpad.net/launchpad/+bug/734751 made me sad
[07:17] <_mup_> Bug #734751: BranchSet:CollectionResource:#branches timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/734751 >
[07:18] <wgrant> lifeless: Oh?
[07:20] <wgrant> StevenK: Looks like someone fixed Maverick to derive from Lucid again.
[07:21] <StevenK> Rargh
[07:21] <wgrant> Actually, it might help if I look at DF.
[07:21] <StevenK> Haha
[07:21] <wgrant> Where it does derive from Sid.
[07:21] <jtv> Websquinting.  The latest meme.
[07:23] <lifeless> wgrant: incomplete fix :<
[07:24] <wgrant> lifeless: :(
[07:25] <wgrant> jtv: So, I can see some bugs in this, but I can't see why it's not working.
[07:26] <jtv> wgrant: what is it you're seeing?
[07:26] <wgrant> jtv: Even your upload did not create a DSDJ.
[07:27] <jtv> wgrant: is it possible to run "make harness" against the dogfood db?
[07:28] <wgrant> jtv: I am doing that right now.
[07:28] <wgrant> I wonder if the flag controller isn't set up properly in scripts.
[07:29] <lifeless> its not setup by scripts
[07:29] <jkakar> poolie: You rock! :)
[07:29] <lifeless> scripts need to setup an appropriate controller as part of setting up whatever work context they have
[07:30] <jtv> lifeless: does that mean that feature-flag checks will fail silently in scripts?
[07:30] <lifeless> they won't fail
[07:30] <lifeless> they will find no flags set
[07:31] <poolie> thanks jkakar, so do you :)
[07:32] <jkakar> :)
[07:32] <poolie> i'm just resolving conflicts in and manually testing the other branch
[07:34] <jkakar> poolie: Thanks.  I probably should have based that branch on the optional-needs-testing one, but I didn't think about it until too late.
[07:34] <StevenK> wgrant: Over the last 3 runs: 1054, 1061, 1120.
[07:34] <poolie> np
[07:34] <poolie> i can refactor the template slightly
[07:34] <jkakar> Cool.
[07:34] <LPCIBot> Project windmill build #50: STILL FAILING in 1 hr 6 min: https://hudson.wedontsleep.org/job/windmill/50/
[07:35] <jtv> lifeless: to me that means that the feature-flag check will fail silently.
[07:35] <jtv> Which sucks.
[07:35] <wgrant> StevenK: This is still in 15 minutes?
[07:35] <StevenK> wgrant: Yes
[07:35] <wgrant> StevenK: So it's more like 20 days?
[07:35] <StevenK> I have no idea
[07:35] <poolie> jtv it seems reasonable to me that the default feature flag controller fails (or doesn't exist) rather than doing nothing
[07:35] <StevenK> I was going to get a better idea after 3-5 days of it running
[07:36] <jtv> poolie: yes, I'd expect it to fail in the conventional sense of the word, not just return a value that's basically arbitrary.
[07:39] <jtv> So… how can we fix this and give the scripts in question access to the feature flags?
[07:44] <poolie> well, i guess, copy across or call the setup code
[07:44] <poolie> something similar to what's done in features/webapp.py
[07:49]  * jtv looks
[07:49] <jtv> wgrant: in any case, for now this bug is qa-untestable.  Thanks for all your help—I'm afraid we'll have to do it again later.
[07:52] <jtv> wgrant: by the way, which script(s) would be affected exactly?  gina soyuz_process_upload?
[08:00] <poolie> jkakar, do you think i can easily write a test for the handling of an 'access denied' error from lp?
[08:03] <StevenK> If it raises Unauthorized you can test for that.
[08:05] <wgrant> jtv: process-upload.py, gina.py, copy-package.py, at least.
[08:05] <jtv> whew
[08:05] <jtv> thanks
[08:06] <poolie> StevenK, my question was more whether there is enough mock-type framework in the client to raise Unauthorized at the right point
[08:06] <lifeless> jtv: you'll want a variant on the controller which supplies the script id as the pageid, or something along those lines
[08:09] <jtv> lifeless: good point
[08:09] <lifeless> I think the pageid scope reads from the wsgi stack
[08:09] <lifeless> so, there is some plumbing changes needed
[08:10] <jtv> :/
[08:10] <wgrant> lifeless: Why expose it as a pageid? Why not a separate namespace/
[08:11] <jtv> Well it needs a pageid anyway, doesn't it?
[08:11] <wgrant> Why?
[08:11] <wgrant> script != page
[08:11] <wgrant> => no pageid
[08:11] <lifeless> wgrant: could do that, though 'primary key for oops and other stuff' is good enough for me
[08:12] <lifeless> wgrant: I don't really care about the label; having the pageid scope present in the lookups in a script would be a bug (and make that scope more complex) and vice verca.
[08:12] <lifeless> pageid wsgi  based scope implementation, I mean.
[08:13] <jtv> This does not sound like something I ought to be resolving reactively in unrelated feature development.
[08:14] <lifeless> jtv: well, feature development shouldn't go down unnecessary diversions; this is probably 1/2 day to a day total, which is about break even vs having sysadmins enable/disable cron jobs during early deployment lessons
[08:15] <lifeless> jtv: so if I was on a feature squad, I'd consider it in scope to incrementally improve infrastructure to do the feature needed
[08:15] <jtv> It doesn't sound like something I could do in half a day.
[08:15] <jtv> But we'll see.
[08:26] <poolie> StevenK, fyi lazr.restfulclient apparently does not raise a separate subclass for unauthorized errors
[08:37] <wgrant> Argh.
[08:38] <wgrant> Private bugs make me sad.
[08:40] <wgrant> They make this NullBugTask removal a little difficult, because NBT is used to conceal the target.
[08:40] <wgrant> Although it doesn't do a very good job, so maybe we don't care.
[08:41] <lifeless> wgrant: thats probably the cause of poolies api disclosure bug
[08:42] <wgrant> lifeless: It is rather related, yes.
[08:42] <wgrant> I am trying to think of a sensible way to solve it.
[08:42] <lifeless> raise GoAwayDeniedHaHaHa
[08:43] <wgrant> lifeless: Do you know the issue?
[08:44] <wgrant> lifeless: We want to redirect users to the task they requested once they've logged in.
[08:44] <poolie> i just found another api privacy bug, if that makes you feel any better :)
[08:44] <wgrant> So we allow traversal to the BugTask.
[08:44] <lifeless> wgrant: possibly; I suggest you explain it for clarity.
[08:44] <wgrant> lifeless: This may involve returning a NullBugTask.
[08:45] <wgrant> Regardless, an unauthenticated user will not hold launchpad.View, so will be redirected to a login page.
[08:45] <wgrant> Even if the object doesn't *really* exist.
[08:45] <lifeless> wgrant: why? I mean: we refuse to acknowledge or deny the presence of private content
[08:45] <lifeless> wgrant: so just a not found error at the original url + a login button should be all we need to send.
[08:46] <lifeless> wgrant: for /all/ view-denied cases
[08:46] <wgrant> lifeless: Right, that's what I was hoping you'd agree with.
[08:46] <adeuring> good morning
[08:46] <wgrant> Since it's now consistent with what we do with projects.
[08:46] <wgrant> lifeless: I will redirect all access-denied cases to /bugs/1, which will ask for login and then redirect to the default task.
[08:46] <_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
[08:47] <wgrant> It means people will lose the task context if they're not logged in, but that only matters for nomination these days.
[08:47] <wgrant> So, stuff them.
[08:47] <poolie> https://bugs.launchpad.net/launchpad/+bug/735346
[08:47] <_mup_> Bug #735346: can't read a collection when one member is private <api> <bugs> <disclosure> <security> <Launchpad itself:New> <lazr.restfulclient:New> < https://launchpad.net/bugs/735346 >
[08:47] <lifeless> wgrant: *blink*
[08:47] <poolie> :)
[08:47] <wgrant> lifeless: Oh?
[08:47] <lifeless> poolie: thats a simple case by case bug
[08:48] <poolie> specific to linked_branches?
[08:48] <wgrant> poolie: That's very interesting.
[08:48] <poolie> thanks
[08:48] <wgrant> poolie: lazr.restful checks for launchpad.View on any object it returns rom from a collection.
[08:48] <wgrant> poolie: So that should work fine.
[08:48] <wgrant> lifeless: Why are you blinking?
[08:49] <poolie> lifeless, so i should say "linked_branches" in particular?
[08:49] <lifeless> yes, I've changed it
[08:49] <poolie> thanks
[08:50] <wgrant> poolie: That reveals yet another bug.
[08:50] <lifeless> wgrant: I thought what we did was issue a 404 *with no redirect*
[08:50] <lifeless> wgrant: so I'm surprised you're suggesting a redirect
[08:50] <henninge> rvba: ping ;)
[08:50] <wgrant> poolie: the __repr__ violates the security proxy and displays the unique_name anyway.
[08:50] <wgrant> lifeless: Eh, I guess.
[08:50] <rvba> henninge: yes
[08:51] <poolie> heh
[08:51] <wgrant> lifeless: I should probably be consistent, then, and deny traversal through /bugs too.
[08:51] <henninge> rvba: are you having trouble landing your branch? ;)
[08:51] <poolie> indeed, i was just going to say that too
[08:51] <wgrant> Since this seems to be the way we're going now.
[08:51] <wgrant> It will confuse people. But privacy is confusing.
[08:51] <lifeless> wgrant: so I think I'm saying:
[08:51] <lifeless>  - the users browser should show the url they put in
[08:51] <lifeless>  - if they are logged in its a 404
[08:52] <lifeless>  - if they are logged out its a 404
[08:52] <lifeless> [and logging in will let them see it if they have permission]
[08:52] <rvba> henninge: I was blocked by some failure (Steven called the failure furphy)... but I'm landing it right now and it seems to go fine.
[08:52] <lifeless> wgrant: unless we introduce 'can know, but can't see' vs 'cannot know about if cannot see' - which traversal permission is about
[08:52] <henninge> rvba: cool
[08:53] <lifeless> wgrant: for bugs i don't think we need traversal separate from view
[08:53] <wgrant> lifeless: What do you want to do about /bugs/1234, where 1234 is an invisible private bug?
[08:53] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[08:53] <lifeless> wgrant: 404
[08:53] <wgrant> lifeless: We don't, no.
[08:53] <lifeless> wgrant: no redirect
[08:53] <wgrant> lifeless: Right, OK.
[08:53] <wgrant> Thanks.
[08:53] <lifeless> wgrant: until we permit bug deletion, it will permit trivial probing to find private bugs, but it won't disclose their context
[08:54] <wgrant> lifeless: I imagine we probably have some transaction failures that make that false, but OK.
[08:54] <henninge> rvba: a branch like that does not have to go through ec2 testing AFAIUI.
[08:54] <wgrant> (incrementing the sequence but then aborting)
[08:55] <henninge> rvba: since you only changed test code it should be fine to just make sure those are still passing and then you can do bzr lp-land.
[08:55] <henninge> rvba: just thought I'd mention that.
[08:55] <lifeless> wgrant: right
[08:55] <rvba> henninge: does this mean that I should use special options to land it?
[08:55] <lifeless> wgrant: its a fault in using monotonic sequences as ids, not in the privacy story
[08:55] <wgrant> lifeless: Yup.
[08:56] <henninge> rvba: what I do: Run the tests locally, then do "bzr lp-land" to submit it to pqm.
[08:56] <henninge> rvba: no need for "ec2 test" or "ec2 land".
[08:56] <rvba> henninge: ok
[08:56] <henninge> It's just a lot quicker ...
[08:57] <rvba> henninge: I did "ec2 land" yesterday (this failed, well the PQM failed, not the tests)  but got advised to use lp-land this morning by Steven
[08:57] <henninge> rvba: yeah, that's another one.
[08:58] <henninge> rvb: if the branch already passed ec2 and just bounced off pqm, there is no need to run it through ec2 again.
[08:58] <rvba> henninge: indeed
[08:59] <poolie> lifeless, you asked the other day if my kanban script had got any faster because of lp's changes
[09:00] <henninge> rvba: also, I was surprised to find the merge proposal still in "Needs review" because AFAIK ec2 land and bzr lp-land won't land branches when the mp is not "Approved"
[09:00] <poolie> it's gone from 2:54 against old lpnet and 2:14 against old edge, down to 1:44
[09:00] <poolie> which is pretty good
[09:00] <henninge> rvba: you can set an MP to "Approved" yourself once you received all the necessary reviews.
[09:00] <poolie> _however_, the data its reading has also changed, and the timing will be data-dependent
[09:00] <poolie> so it's not a great benchmark
[09:01] <rvba> henninge: ok ... ec2 land --force can for a land AFAIK
[09:01] <poolie> but, better than getting slower
[09:01] <rvba> s/can for/can force/
[09:01] <henninge> yes ,)
[09:01] <henninge> ;)
[09:01] <henninge> but no need for that, that's what I mean.
[09:01] <rvba> henninge: ok, got it
[09:02] <StevenK> rvba: I have never used ec2 land --force
[09:02] <StevenK> So I'd strongly suggest you don't either
[09:03] <rvba> StevenK: sound pretty much the same to use --force or to Approve your own MP ... but I did it because henninge approved my MP and I had to commit a few cosmetic changes after that
[09:04] <rvba> StevenK: still, I get your point :-)
[09:04] <StevenK> rvba: You are allowed to Approve your own MP
[09:05] <rvba> StevenK: yes, much cleaner solution indeed
[09:05] <henninge> StevenK, rvba: Yeah, we once argued that setting it to "Approved" is to indicate that all reviews (code, ui, release-critical) have been received.
[09:05] <henninge> AFAIK tarmac will automatically land branches that are set to Approved.
[09:06] <henninge> but we are not yet usging that.
[09:06] <henninge> using, evin
[09:06] <henninge> even, even
[09:06] <henninge> ;)
[09:07] <StevenK> We should be!
[09:07] <StevenK> And Jenkins!
[09:07] <StevenK>  /rage, /bitch, /complain
[09:07] <wgrant> Pagetest stories are bad.
[09:08] <bigjools> page stories are good, if they are actually stories
[09:09] <wgrant> bigjools: Not when they span 10 files.
[09:09] <bigjools> that's not a story, that's a tome
[09:10] <wgrant> Point.
[09:10] <StevenK> "Page War & Peace"
[09:53] <jkakar> poolie: You could use mocker to write such a test, but it might be a bit tricky.
[09:56] <jtv> lifeless, if you're still here (which you probably shouldn't be :) would it make sense to have scopes like "script:gina"?
[09:57] <jtv> Or should we encode script names in the flag names where appropriate?
[09:58] <jtv> For example, we could have a flag "enable" in scope script:gina, and similar for all other scripts if we wanted.
[10:02] <lifeless> jtv: both
[10:03] <jtv> both what?
[10:03] <jtv> Oh,
[10:03] <jtv> yes, I see
[10:03] <lifeless> example from the web ui
[10:03] <lifeless> when we want to affect only one / some pages, even for common code, we use the pageid scope
[10:03] <poolie> jkakar, for now i just interactively tested it
[10:03] <poolie> mocker could be ok
[10:04] <jkakar> poolie: Cool.
[10:04] <lifeless> when we want to probe for something that its only relevant to a particular domain, we use the domain inthe flag name
[10:04] <lifeless> an example of the former is 'memcache pageid:BugTask:+index default '
[10:05] <lifeless> an example of the latter is 'recipes.beta default 1 on'
[10:05] <jtv> lifeless: right ho, get it.  A feature flag for disabling scripts sounds useful, no?  It suddenly looks pretty easy.
[10:05] <lifeless> jtv: exactly
[10:05] <jtv> (I wonder why lp.services.features.webapp doesn't export anything in __all__ btw)
[10:06] <lifeless> __all__ only matters if one is doing import *, or worried that pydoc will show too much
[10:06] <lifeless> we should probably delete most of our __all__'s now that the import fascist is years out of date
[10:07] <StevenK> So we should kill the import fascist?
[10:13] <lifeless> or fix it
[10:14] <lifeless> its not guarding much in the current layout, because all the layers are mixed up
[10:14] <jtv> Maybe we should depose the import fascist and have a customs officer instead.
[10:22] <LPCIBot> Project windmill build #51: STILL FAILING in 1 hr 9 min: https://hudson.wedontsleep.org/job/windmill/51/
[10:37] <stub> The goal with __all__ is to document public api from internal api.
[10:38] <stub> lifeless: I know I use it that way - if it is not in __all__, it is only supposed to be used by that package and its tests.
[10:42] <lifeless> stub: #ubuntu-meeting is looking for you
[10:42] <stub> We can already disable cronscripts using cronscripts.ini btw.
[10:54] <stub> If feature flags lived in a high available database, rather than the main db, we could use that for cronscripts.ini.
[10:55] <lifeless> tomorrow I should get my hbase vs cassandra mail rolling
[10:55] <lifeless> and I need to look into mongodb
[10:55] <stub> I suspect zookeeper might be suitable too... can't recall if you found a flaw in that?
[10:56] <lifeless> need to look more closely at it; its in an awkward spot AIUI
[10:56] <lifeless> theres some mutterings (long term) about being able to handle london being down
[10:57] <stub> IIRC zookeeper seemed pretty much designed for our feature flags stuff, but would probably be way overkill if that is all we used it for.
[10:59] <stub> (same with moving it out of PG - I'd rather have a little cruft like cronscripts.ini and feature flags duplicating work than over engineering a high availability database just for FF)
[10:59] <lifeless> hmm, why isn't rev 12595 on qas
[10:59] <lifeless> stub: me too
[11:01] <deryck> Morning, all.
[11:08] <lifeless> night all
[11:29] <LPCIBot> Yippie, build fixed!
[11:29] <LPCIBot> Project windmill build #52: FIXED in 43 min: https://hudson.wedontsleep.org/job/windmill/52/
[11:38] <wgrant> gmb: Thanks.
[11:38] <wgrant> Almost there.
[11:38] <gmb> np
[12:17] <henninge> gmb, leonardr: Hi! Can I ask a review of either of you, please? It's a UI-related branch that adds a new page.
[12:18] <leonardr> i think i should defer to gmb on that kind of branch, but i'll take a look if he's not around
[12:19] <LPCIBot> Project db-devel build #452: FAILURE in 4 hr 40 min: https://hudson.wedontsleep.org/job/db-devel/452/
[12:20] <henninge> leonardr: that would be nice but it's ok if you turn it down.
[12:20] <henninge> https://code.launchpad.net/~launchpad/launchpad/translation-sharing-status/+merge/53419
[12:20] <leonardr> henninge: i'll do what i can and note inthe review if i think it needs more eyes
[12:20] <leonardr> benji, are you around? i'd like you to look at https://code.launchpad.net/~leonardr/lazr.restful/handle-view-that-provides-no-status/+merge/53342 and tell me if it makes sense from a zope perspective
[12:21] <benji> leonardr: sure
[12:32] <benji> leonardr: getting a view is adapting an object and the request to Interface, so instead of getting a view of the execption and then checking that it is an insteance of WebServiceExceptionView you could instead...
[12:32] <benji> ...define, say, IWebServiceExceptionView and adapt the object and request to IWebServiceExceptionView
[12:33] <leonardr> benji: i thought about using interfaces. i rejected the idea because existing view classes don't implement any particular interface. but then i made the assumption that they would all be WebServiceExceptionView
[12:34] <leonardr> so yeah, i could define IWSEV, have it define .status, and make WSEV implement it
[12:35] <benji> you could register an adapter from (WebServiceExceptionView, request) to IWebServiceExceptionView which simply returns the WebServiceExceptionView instance
[12:36] <leonardr> benji: is there any advantage of that over having WSEV implement IWSEV?
[12:37] <benji> leonardr: it depends on how you structure the code, if you adapt from (e, request) to Interface and then check if the result provides IWSEV, then it's esentially the same thing you have now (i.e., not evil, but doing things indirectly)
[12:38] <benji> but just making WSEV implement IWSEV will not make adapting (e, request) to IWSEV work because the CA doesn't have an adapter registered for that signature
[12:39] <leonardr> benji: i see. i may change the registrations then. after i do this review i'll see what works
[12:39] <benji> k
[12:45] <leonardr> henninge: what exactly is a translation template? is it like a list of strings to be translated?
[12:45] <henninge> leonardr: exactly
[12:46] <leonardr> henninge: in template_info, i don't understand why you can assume that self.context has a productseries (line 221 of the diff)
[12:48] <leonardr> it has an upstream, but is an upstream always the kind of thing that has a productseries?
[13:06] <henninge> leonardr: this view is only for sourcepackages, so the upstream is always a productseries.
[13:07] <henninge> leonardr: self.is_configuration_complete includes the check if the productseries exists.
[13:07] <henninge> leonardr: sorry, was distracted
[13:07] <leonardr> henninge: np
[13:08] <henninge> leonardr: actually, I am about to have lunch
[13:08] <leonardr> henninge: ok, if i have more questions i'll just put them in this channel
[13:08] <henninge> leonardr: cool, thanks
[13:09] <leonardr> you have some copy-and-paste comments on line 398 and line 405
[13:09] <leonardr> and 413
[13:16] <leonardr> on line 543, the docstring reads like a commit message. you should say what you're actually setting up
[13:17] <leonardr> you could also refactor the many times you call getViewBrowser, but that's not a big deal
[13:22] <maxb> Is there any particular reason lazr-js's embedded fulljslint.js is such an old version?
[13:22] <jml> deryck: your blog forbids me commenting
[13:22] <deryck> really?
[13:22] <jml> deryck: so I'll just heckle here
[13:23] <jml> deryck: "Is the solution to move to Selenium and anything other than Zope test runner? :P"
[13:23] <deryck> jml: how does it forbid?
[13:23] <jml> deryck: Forbidden (403)
[13:23] <jml> CSRF verification failed. Request aborted.
[13:23] <jml> More information is available with DEBUG=True.
[13:23] <deryck> ah, crap
[13:23] <deryck> stupid Django.
[13:24] <rvba> leonardr: Hi, I just saw you mentioned refactoring tests with getViewBrowser ... it happens that I'm having trouble with a test that uses this
[13:24] <leonardr> rvba: ok, i don't know anything about this but i'll do my best
[13:24] <deryck> jml: as to your question, yes I think that is the best solution.  Something of that sort. Either Selenium or Windmill without the Zope wrapping.
[13:24] <deryck> jml: Though I think Windmill has some general fragility, just because there are fewer people using it and working on it
[13:25] <leonardr> henninge: line 753, "Translations are enable" -> "are enabled"
[13:25] <jml> deryck: yeah. that's what I hear.
[13:25] <rvba> leonardr: it looks to my -newbie- eyes like, when getViewBrowser is used, something might go wrong with the authentication machinery
[13:27] <rvba> leonardr: but if you're not sure, don't worry, I'm in the process of figuring it out ...
[13:27] <leonardr> rvba: ok. looking at the code, it looks like getUserBrowser logs in as anonymous and never logs out. are you getting an 'interaction already active' type error?
[13:29] <rvba> no, the test uses  getUserBrowser with a user, then check a perm ... when I debug the whole thing, I see that the perm is checked against anon
[13:30] <rvba> leonardr: if you says it might never log out after login in as anon, looks like this might be related
[13:30] <leonardr> rvba: paste your test to me?
[13:31] <rvba> leonardr: just sent you an email with the description of the problem
[13:32] <leonardr> ok
[13:32] <deryck> jml: comments fixed.  Thanks for the heads up.
[13:32] <jml> deryck: np.
[13:38] <leonardr> rvba: i don't know if this will help, but: there are two different levels of authentication in a unit test
[13:38] <rvba> leonardr: yes?
[13:39] <deryck> henninge-lunch: can you reply to the email sinzui sent? I suspect your domain expertise can answer this much more quickly than mine.
[13:39] <leonardr> there's the level at which you're authenticated with the launchpad layer
[13:39] <leonardr> that's what login(ANONYMOUS) takes care of
[13:39] <leonardr> that's necessary when you need to access the database or call launchpad utility functions
[13:39] <henninge> deryck: I can do that.
[13:39] <leonardr> and then when you get a browser, there's the user whose password gets sent in the Authorization header
[13:39] <deryck> henninge: many thanks!
[13:40] <leonardr> if your test checks a permission, that code runs in the launchpad layer
[13:41] <leonardr> and it will be checked against anonymous
[13:41] <leonardr> (since getViewBrowser logs in as anonymous and doesn't log out)
[13:41] <leonardr> if you use the browser to make a request, that code runs as the user whose browser it is
[13:41] <leonardr> does that make anything you've seen make more sense?
[13:41] <rvba> leonardr: yes, thanks for the clarification ... not sure this is related to my problem because, like you saw in my revision, I fixed it by changing the owner of the related distroseries
[13:42] <sinzui> Why do we need getViewBrowser? what does it do that we cannot do using the standard helpers like create_view
[13:43] <leonardr> sinzui: i dunno. it gives you a browser object, so you can navigate from page to page
[13:45] <jml> off to cafe for lunch, will work from there.
[13:47] <sinzui> leonardr: I think navigating from page to page is excellent for user stories. If I want to test a view or a page I think I should with with the actual objects.
[13:49] <leonardr> sinzui: that sounds fine to me
[13:53] <leonardr> rvba: as sinzui implies, you might have better luck using create_view instead of getUserBrowser. that would keep all the code in the same level--the launchpad level
[13:53] <leonardr> something to consider
[13:53] <leonardr> sinzui: i got a bunch more test failures when i ran our branch through ec2. i haven't had time to look at them yet, but the first one i saw was just am issing import, so here's hoping...
[13:54] <rvba> leonardr: yes
[14:01] <deryck> adeuring: ping for standup
[14:01] <adeuring> whoops, coming...
[14:08] <sinzui> henninge: I wrongly set the status of your MP to needs fixing. I only had a question
[14:08] <jcsackett> does profiling still show the query if it's hitting the storm cache instead of the database?
[14:08] <henninge> sinzui: I'll look at it in a minute
[14:15] <leonardr> benji: i've got your suggestion working. i'm a little taken aback by the fact that queryAdapter(view, IWebServiceExceptionView) returns None if view is already an IWebServiceExceptionView but there is no no-op adapter registered for it
[14:15] <leonardr> is there any way around that?
[14:18] <benji> leonardr: that surprises me; although, I'm also surprised that you need to do that.  Looking at the MP again.
[14:18] <leonardr> benji: let me push my changes (with the no-op adapter) and maybe you can help me improve it
[14:19] <benji> sure
[14:19] <leonardr> pushed
[14:34] <gmb> leonardr: Can you take a look at https://code.launchpad.net/~gmb/launchpad/mute-button-cleanup-bug-204980/+merge/53401 for me?
[14:35] <benji> leonardr: instead of view = getMultiAdapter((e, self.request), name="index.html") I expected view = getMultiAdapter((e, self.request), IWSEV); you want a view that provides a particular interface (i.e., it has a status attribute) and there's no need for it to have a particular name
[14:35] <leonardr> gmb, sure
[14:35] <gmb> Thanks
[14:36] <benji> leonardr: wait, I think I'm looking in the wrong place, I'm looking at https://code.launchpad.net/~leonardr/lazr.restful/consistent-error-exposing/+merge/51946 which isn't right
[14:37] <leonardr> benji: yeah, look at lp:~leonardr/lazr.restful/handle-view-that-provides-no-status
[14:37] <benji> thanks
[14:38] <leonardr> sinzui: i'm pretty sure that missing import was the only thing keeping us from finally landing that branch. i've fixed it and am running through ec2 land again
[14:38] <sinzui> \o/
[14:44] <leonardr> gmb: describe or give me a link to the bug mail mute button story, so i know what i'm looking at?
[14:44] <gmb> leonardr: The word "Story" is probably misleading, but to sum it up:
[14:44] <gmb> As a Launchpad user who receives a lot of bug mail
[14:44] <gmb> I want to be able to click a "Mute bug mail" button for a given bug
[14:44] <gmb> So that I no longer receive any email about that bug
[14:45] <gmb> (This is distinct from unsubscribing, since even if you unsubscribe from a bug it's possible to receive mail about it, for example if you own a project that has no bug supervisor)
[14:45] <gmb> Muting the bug makes Launchpad drop *any* email it's going to send to you about it.
[14:46] <leonardr> i see. it's an anti-subscription
[14:46] <gmb> Yes :)
[14:46] <leonardr> ok
[14:52] <leonardr> gmb: in bugtask_index_portlets, it looks like you took a code path for 'is not subscribed' and just changed it to 'is muted'. what happens if you're not subscribed?
[14:53] <gmb> leonardr: That was because I've added the new CSS class to explictly describe someone as muted. Previously it relied on the subscribed-foo CSS class since muted subscriptions are just another type of subscription.
[14:53] <gmb> If you're not subscribed you can still click the mute link and it will work perfectly.
[14:53] <leonardr> ok, so it was code to control the mute button
[14:53] <gmb> What it does behind the scenes is subscribe you to the bug with a BugNotificationLevel of NOTHING.
[14:53] <gmb> Right.
[14:54] <gmb> (Note that gary_poster and I are of the opinion that this way of doing mutes is a bit of a kludge, but I think it's a decent first step).
[14:54]  * gary_poster nods
[14:56] <leonardr> gmb: on line 140 and line 143, what is the 'true' vs. 'false' passed in to set_subscription_link_parent_class?
[14:57] <gmb> function set_subscription_link_parent_class(user_link, subscribed, dupe_subscribed)
[14:57] <gmb> is the signature.
[14:58] <leonardr> ok, i'm not sure what it means to have duplicate descriptions. you have a regular one, plus a 'mute' one?
[14:58] <gmb> leonardr: dupe_subscribed means "Subscribed to a duplicate of this bug"
[14:58] <benji> leonardr: I checked out the branch and got the appropriate response to queryAdapter(view, IWebServiceExceptionView) when view was an instance of WebServiceExceptionView; I'm working up a small change to your branch to suggest to you.
[14:58] <gmb> There Can Be Only One (Person, Bug) subscription.
[14:59] <leonardr> ah, it's a subscription _to_ a duplicate
[14:59] <gmb> right
[14:59] <leonardr> ok, you're just setting up the appropriate presentation when subscription is un-muted
[15:00] <gmb> yes
[15:02] <leonardr> ok, looks good
[15:02] <gmb> Cool
[15:12] <benji> leonardr: how about this: http://pastebin.ubuntu.com/580611/
[15:19] <leonardr> benji: that runs into the same problem i encountered when i tried something similar, which is that all other web service error view registrations need to provide IWebServiceExceptionView, not Interface
[15:20] <benji> leonardr: do the other web service error views have the status attribute?
[15:20] <leonardr> yeah, they all subclass WebServiceExceptionView
[15:20] <benji> and are they subsclasses of WSEV?
[15:20] <leonardr> basically i'm afraid that something that used to work like other view registrations no longer works that way
[15:21] <leonardr> that this will confuse people and possibly cause more failures on the launchpad side
[15:22] <leonardr> my fears are fuelled by the fact that i can't get all the tests to pass with a system like this
[15:23] <benji> leonardr: yeah, that is an issue... so in your estimation it is ok to require that the error views be subclasses of WSEV but the existing registration of adapters to the views (i.e., (e, request), Interface, name='index.html) should still work; right?
[15:26] <leonardr> benji: yeah, i think that's fine. or, we can require that the error views implement IWSEV, since all that matters is that they have a .status
[15:26] <benji> ok, so if we don't want to change the signature that the adapters have we're stuck with the same adaptation as on the trunk, so that part is a constant
[15:29] <leonardr> that's the adaptation from WSEV to IWSEV?
[15:29] <benji> leonardr: I think the code as you have it is the best route.
[15:30] <benji> leonardr: no, the adaptation to (e, request), Interface, name='index.html to get the view; that part we can't change
[15:30] <leonardr> ok, let me see how the code is now to remember...
[15:31] <leonardr> benji: and there's no way to get rid of the no-op adapter?
[15:31] <leonardr> (without going down one of the paths we've rejected)
[15:33] <benji> leonardr: you probably can; at least for adaptation like IFoo(obj) where obj already provides IFoo there is no need for anadapter and obj is just returned stright away, I don't recall if the same is done for queryAdapter; worst-case you can put try: IWSEV(view) except: raise e (where e is the original exception)
[15:33] <leonardr> trying that now
[15:39]  * jml fixes the conflict
[15:45] <jml> deryck[lunch]: I guess bug 607438 should be critical these days, since it's an OOPS.
[15:46] <_mup_> Bug #607438: NoCanonicalUrl: No url for message because message broke the chain. <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/607438 >
[15:52] <leonardr> benji: take a look at the latest revision
[15:52] <benji> k
[15:54]  * jml off home
[15:54] <bigjools> I am calling "ec2 test" on a db-devel branch but it's getting merged into devel, how can I fix that?
[15:54] <bigjools> there's a conflict which is not in db-devel yet, or I'd not worry about it
[15:55] <benji> leonardr: looks good
[15:55] <leonardr> queryAdapter doesn't work, unfortunately
[15:56] <benji> that makes some sense though, since there isn't an adapter, but IWSEV(WSEV) first checks to see if the interface is already provided and if not invokes adaptation
[15:57] <benji> a little philosophysing: in an ideal world we would be adapting (e, request) to IWSEV (without a name) and use that result since that adaptation better captures the intent; that being said, this approach is eminently reasonable given the constraints of the situation
[16:14] <leonardr> benji, can i get a formal review from you so i can land the branch?
[16:14] <benji> leonardr: sure; which MP?
[16:15] <leonardr> https://code.launchpad.net/~leonardr/lazr.restful/handle-view-that-provides-no-status/+merge/53342
[16:33] <deryck> jml: agreed.  I raised it.
[16:34] <benji> leonardr: MP approved; I put a couple of notes on there for things you might want to look at
[16:36] <LPCIBot> Yippie, build fixed!
[16:36] <LPCIBot> Project db-devel build #453: FIXED in 4 hr 16 min: https://hudson.wedontsleep.org/job/db-devel/453/
[16:44] <gary_poster> hey sinzui (or deryck), is there a brief history of our IE JS issues I could hear?  AIUI, we generally just turn off JS for IE.  In particular, I'm curious why we are more restrictive than YUI itself; I'm curious if we considered supporting IE >= 7, and just ignoring 6 and below; and I'm curious if we know what our OEM people are using.
[16:45] <sinzui> gary_poster: We turned of IE because we were too lazy or inexperienced to make our site work with the dominate browsers of the ent
[16:45] <deryck> gary_poster: what sinzui said ;)
[16:46] <deryck> gary_poster: and because we don't know how to write js and make common mistakes outside of YUI and found it easier to avoid
[16:46] <deryck> oem definitely uses IE heavily
[16:46] <gary_poster> ok, thank you deryck and sinzui
[16:46] <deryck> well, oem clients or partners or whatever.  *the* oems use IE, not Canonical's division.
[16:47] <sinzui> gary_poster: Our argument against ie6 is that it represents .05% of traffic and MS does not support it. However, Oor Chinese partners often do use ie6
[16:47] <sinzui> gary_poster: Canonical/Ubuntu CSS does not support ie6, and I removed out CSS hacks for ie6. I think we are are concerned about ie7-9
[16:47] <gary_poster> sinzui, I'm less surprised by IE 6 (which is notoriously unpleasant to work with) than IE generally (I've read that 7 and higher are much more acceptable)
[16:48] <gary_poster> sinzui, I'm +1 on supporting 7-9 and ignoring 6
[16:49] <deryck> I'm +1 on that as well.
[16:49] <sinzui> IE 9 likes Lp, but I think several parts are disabled for 9 because our scripts are blocking all ie
[16:49] <gary_poster> right
[16:49] <deryck> We need some knowledge sharing so people are comfortable running IE either via wine or VMs.
[16:49] <gary_poster> yeah
[16:50] <gary_poster> VMs are easy enough...but then you have to buy Windows
[16:50] <deryck> right
[16:50] <sinzui> I do not have Windows. I rely on the good will of volunteers :(
[16:50] <gary_poster> :-/
[16:51] <gary_poster> I have a license/vm for XP at least
[16:51]  * sinzui looks at analytics
[16:52] <deryck> I keep windows for taxes and gaming, so IE is easy enough for me
[16:52] <gary_poster> heh
[16:52] <deryck> i have my priorities clear!
[16:52] <gary_poster> :-) makes sense to me
[16:53] <sinzui> gary_poster: deryck 27% of visitors are on Windows, 10% xp 10% 7
[16:53] <gary_poster> hm
[16:54] <gary_poster> what about IE versions, sinzui?
[16:54]  * gary_poster should get the information for our google analytics account
[16:54] <deryck> but how bad is their experience, too?  There has to be some argue for getting better at IE, just because the experience can be so broken at times.
[16:55] <gary_poster> deryck, some of the biggest functionality we are building is JS only
[16:55] <sinzui> gary_poster: deryck: 6% is ie...4% being ie8, 1% ie7, the remaining is 6 and 9
[16:55] <gary_poster> (I mean, our squad)
[16:55] <gary_poster> wow
[16:55] <gary_poster> that's so small
[16:55] <deryck> yeah, that's incredibly tiny
[16:56] <gary_poster> and I guess that tells us that 8 is the one to look at right now if we are going to look at all, and not look comprehensively
[16:56] <deryck> maybe do better going forward, but not worry about past functionality so much?
[16:56] <gary_poster> (which is such a PITA :-/ )
[16:56] <gary_poster> I'm alright with that, but if we don't provide noscript alternatives then we may have to set a higher bar
[16:56] <sinzui> deryck: I do not think ie users can report bugs because the suggestion UI is 100% ajax
[16:57] <gary_poster> (which again points to "going forward")
[16:57] <gary_poster> lol
[16:57] <gary_poster> +1
[16:57] <deryck> they can't comment on bugs, I know that for sure ;)
[16:57] <gary_poster> Then we're safe! :-)
[16:58] <sinzui> deryck: so in this case, we had a show of hands of who wanted support, but ie users did not raise their had :)
[16:58] <sinzui> hand
[16:58] <deryck> heh
[16:58] <gary_poster> lol
[17:00] <jml> deryck: ta
[17:01] <sinzui> gary_poster: <rants> We chose YUI because it had good cross browser support, but its support is not as good as jquery.
[17:02] <gary_poster> sinzui :-( and the majority of the rest of the world uses jquery
[17:02] <sinzui> correct
[17:03] <deryck> and we could have picked the best of both -- used jquery for coding, but yui's test framework for testing, for example.
[17:03] <deryck> but hindsight is always better
[17:04]  * sinzui recalls some engineers had foresight
[17:04] <deryck> altough I like YUI 3 very much.  But I'm probably in the minority on this.
[17:04] <gary_poster> I like it so far too.  But I'd prefer to be with the majority of the world where we can.
[17:05] <deryck> yeah, agreed.  But if we had built lazr-js with jquery, it would have still be painful.  Sometimes it's not the tool, but what we do with it. ;)
[17:05] <gary_poster> heh, I believe you :-)
[17:06] <deryck> so jqeury lovers in LP rejoice that we didn't kill your love of jquery! ;) :)
[17:06] <sinzui> gary_poster: deryc: the ie issue may not be as bad as the reported bugs. I could not test them during the bugjam to verify two YUI upgrades fixed the issue.
[17:06]  * deryck always looks at the bright side
[17:06] <gary_poster> heh
[17:06] <gary_poster> that would be nice
[17:07] <deryck> I wondered that, too.  If we could turn it on in various places and see.
[17:08] <sinzui> We could answer that in a day. I suspect the issues can be fixed by one engineer in less than 8 man days.
[17:08] <gary_poster> we'd need a critical bug for it to happen anytime soon, I suspect
[17:08] <leonardr> benji: re "test the previous behavior is gone". that was my intention with test_exception_whose_view_has_no_status
[17:08] <leonardr> it could probably be renamed
[17:09] <leonardr> test_non_web_service_exception_is_reraised
[17:10] <sinzui> gary_poster: deryck, I suspect that many opera bugs may be fixed in the newer versions of Opera. We stopped getting bug reports about it when BjornT left the team
[17:10] <gary_poster> heh
[17:10] <gary_poster> I'm afraid I don't care about Opera :-/
[17:11] <deryck> I think we can't have broken anything serious or BjornT would still file bugs. :-)
[17:11] <gary_poster> heh, maybe so
[17:12] <sinzui> gary_poster:  it is 3% of traffic and 90% is 11+
[17:13] <sinzui> oh wow, that might be the lat zune ever to visit lp
[17:14] <gary_poster> do you think we should care about Opera's 3% sinzui?  opera is such a choice that I think people can be expected to choose other things.  I'm generally more inclined to care about browser choices that are defaults on popular OSes, and of course browsers that have large percentages irrespective of OS defaults.  Opera is neither.
[17:14] <sinzui> There are still more iOS browsers than android
[17:15] <sinzui> gary_poster: I do not think Opera is important at 3%. Opera is always a choice. I think YUI and Opera upgrades allow us to close all opera bugs, but I cannot bring myself to do that without confirmation
[17:15] <gary_poster> makes sense
[17:18] <sinzui> gary_poster: We closed a lot of safari bug when Chromium reached 15%. At that point, we unconsciously decided to ensure Lp works with webkit
[17:19] <deryck> Opera > 9.5 X grade on YUI, which means they assume it works but don't test.  And they close all bugs opened against that browser.
[17:19] <gary_poster> Chromium meant that we started using webkit regularly too, which may be at least one aspect of the "unconscious" part
[17:19] <gary_poster> heh, I like that last bit :-)
[17:19] <gary_poster> ("close all bugs opened against")
[17:20] <deryck> heh, I thought you might
[17:21] <sinzui> gary_poster: have you ever looked at who reported and commented on all open and closed Safari bugs? I'll save you the tiime. It is Us. Both Lp and Canonical engineers use Safari.
[17:21] <gary_poster> huh
[17:21] <jml> :(
[17:22] <sinzui> 90% of all safari bugs were report by a Canonical employee, or is the primary user in the comments
[17:32] <benji> leonardr: (was at lunch) oh, I misunderstood that test, looks good
[18:15] <lifeless> moin
[18:22] <lifeless> allenap: ping (qa)
[18:23] <lifeless> jtv: rev 12599 I'm guessing is also untestable for now ?
[19:14]  * jcsackett realizes answers is not exported at all.
[19:19] <henninge> sinzui: I replied to your question on the MP. ;)
[19:21] <henninge> sinzui: would be great if you could approve the ui now ;)
[19:22] <sinzui> henninge: r=me
[19:22] <henninge> sinzui: cool, thanks!
[20:15] <thumper> morning
[20:20] <thumper> leonardr: I'm going to miss the standup today as a close friend had a stroke, and I'm going to visit him in hospital
[20:21] <leonardr> thumper: oh no! i'll run the standup
[20:21] <thumper> leonardr: just you and wallyworld_ :)
[20:21] <leonardr> ok, wallyworld, mumble?
[20:21] <thumper> leonardr: he doesn't arrive for about 40 minutes :)
[20:21] <thumper> and even then it is 7am for him
[20:21] <leonardr> ah, ok
[20:22] <leonardr> wallyworld_ -^ let me know when you get this
[20:22] <thumper> lifeless: I wish we had a simple way to load all of the objects needed to create canonical urls
[20:31] <sinzui> thumper: lifeless. I need to change the permissions in for person-merge-job in security.cfg. My branch is based on devel. Will those changes be applied by a no downtime release?
[20:31] <thumper> sinzui: I think new permissions are added
[20:31] <thumper> but old ones are not dropped
[20:31] <thumper> I may be wrong
[20:32] <sinzui> yeah. I think that too, but I keep hearing disappointing results. I could switch to db-devel and be certain that my changes work
[20:37] <lifeless> thumper: sinzui: you are correct
[20:37] <lifeless> it will work
[20:37] <lifeless> it doesn't work on qastaging yet, but does on prod
[20:37] <sinzui> ;?
[20:37] <sinzui> :/
[20:38] <sinzui> lifeless: Can I ask a losa to do something when the time comes to qa? I can qa on staging at the very least
[20:48] <lifeless> sinzui: ask them to 'update the qastaging tree on sourcherry and run security.py with --no-revoke'
[20:49] <sinzui> noted. Thanks!
[20:51] <wallyworld_> leonardr: hi, will be there in 5-10 minutes. just have to make the kid's lunch
[20:51] <leonardr> sure
[20:58] <wallyworld_> leonardr: here now
[20:58] <leonardr> wallyworld_: ok, 1 sec
[21:01] <lifeless> matsubara: https://lpstats.canonical.com/graphs/OopsLpnetHourly/20110315/20110316/ is spiky
[21:01] <lifeless> matsubara: do you know what might be up there?
[21:01] <leonardr> wallyworld_, i'm on mumble
[21:01]  * matsubara looks
[21:01] <wallyworld_> leonardr: can't hear me?
[21:02] <leonardr> i can hear you
[21:02] <leonardr> but not vice versa, apparently
[21:10] <StevenK> lifeless: Sigh. That should happen automatically.
[21:11] <lifeless> StevenK: it should
[21:11] <lifeless> StevenK: which of the several things affecting production stability should I defer to get that happening :( ?
[21:12] <StevenK> lifeless: Ah, well, it is a bug with the update scripts or something more sinister?
[21:13] <lifeless> StevenK: the losas have a policy that automated scripts can only talk down trust levels, not up
[21:13] <lifeless> StevenK: and db servers are near the top of the pile
[21:13] <lifeless> StevenK: so the update script needs to get more complex, part of it moved to sourcherry, become pull rather than push, that sort of thing
[21:14] <leonardr> sinzui, looks like our branch has landed
[21:14] <sinzui> \o/
[21:15] <StevenK> lifeless: That's our issue to fix, or a LOSA issue?
[21:15] <lifeless> StevenK: losa
[21:15] <StevenK> Right, and we both know the issue there.
[21:15] <lifeless> indeed
[21:18] <leonardr> wallyworld_: `python setup.py sdist` seems to work for me, generating a tarball for lazr-js
[21:18] <leonardr> what happens when you try that?
[21:18]  * wallyworld_ looks
[21:20] <lifeless> StevenK: does bug 734719 count as fix released?
[21:20] <_mup_> Bug #734719: DSD.base_source_pub assumes the base version is published in the child <derivation> <qa-untestable> <Launchpad itself:Fix Committed by stevenk> < https://launchpad.net/bugs/734719 >
[21:21] <wallyworld_> leonardr: ok, that worked. not sure what i did yesterday. i assume i need to edit setup.py to change __version__ and commit that before I package?
[21:21] <lifeless> bugger
[21:21] <lifeless> one rev in the deploy queue
[21:22] <StevenK> I was just wondering when we deployed
[21:22] <lifeless> StevenK: just now
[21:22] <StevenK> lifeless: Since prod is running r12599, yes, kill it
[21:22] <leonardr> wallyworld: yes, the __version__ is kept in setup.py for lazr-js
[21:23] <wallyworld_> leonardr: cool. thanks
[21:25] <matsubara> lifeless, https://devpad.canonical.com/~lpqateam/oops-temp.html partial report for today and it doesn't have any oops that caught my eye as causing the spike
[21:25] <lifeless> matsubara: oh, I was unclear
[21:25] <matsubara> lifeless, btw, you can see there that your fix is working :-)
[21:25] <lifeless> matsubara: the 50 per hour spike was the bug search issue I referenced in my email
[21:25] <lifeless> matsubara: the spike I was referring to when I pinged you is how every second how is 0 for everything
[21:25] <lifeless> so its like 0, something, 0 ,something
[21:26] <lifeless> Cool, that report is much more useful
[21:26] <lifeless> the one remaining thing I'd love
[21:26] <lifeless> and I wasn't sure how to do it easily
[21:26] <lifeless> would be to make sure that we get one-of-each pageid from the summary, in the detail section
[21:27] <lifeless> but perhaps thats covered by my change anyway
[21:38] <lifeless> hmm
[21:38] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1900C772
[21:38] <lifeless> 7.6 seconds of python time
[21:39] <lifeless> 127 LFA lookups
[22:01] <bdmurray> Hello, I've noticed a typo in test name and wanted to check on the best way to fix it.
[22:01] <bdmurray> A whole branch seems like a bit much
[22:02] <lifeless> bdmurray: we can only land branches
[22:02] <lifeless> bdmurray: if you're a reviewer you can self review and JFDI
[22:04] <bdmurray> I guess my hope was somebody would JFDI in the branch they are currently working on
[22:04]  * thumper is back
[22:08] <StevenK> bdmurray: Branches are cheap, what's the test name?
[22:10] <bdmurray> StevenK: its in lib/lp/bugs/model/tests/test_bugtask_status.py - -    def test_privileged_user_can_unset_wont_fix_released(self):
[22:10] <bdmurray> StevenK: should be unset_fix_released_status
[22:23] <wgrant> Anyone want to review https://code.launchpad.net/~wgrant/launchpad/hide-inaccessible-bugs/+merge/53529?
[22:24] <StevenK> bdmurray: Submitted to PQM, thank!
[22:24] <StevenK> s/!$/s!/
[22:28] <StevenK> wgrant: Done.
[22:30] <wgrant> StevenK: Thanks.
[22:32] <sinzui> wgrant: mumble
[22:45] <lifeless> flacoste: ppr failed to render I think ?
[22:45] <lifeless> flacoste: where should I look to see whats up ?
[23:06]  * thumper sighs