[00:00] <lifeless> spm: so thats about 1/2 what we see
[00:00] <lifeless> at most
[00:01] <lifeless> (even allowing for 2 instances)
[00:03] <wgrant> lifeless: The deloyment report is happy now, except for 12272 which has been rolled back, but is still shown as not being OK.
[00:03] <wgrant> lifeless: Halp?
[00:04] <thumper> hmm...
[00:05] <thumper> IArchive says description is requried
[00:05] <spm> lifeless: huh, not even that. looking at prod-1 from the 12th of Jan, ~ 5-8 nagios pings are logged on guava per *hour*.
[00:05] <thumper> Archive.description says it isn't required
[00:06] <spm> I wonder. we may have multiple redundant checks coming from elsewhere....
[00:06] <poolie> wa-hey, a kanban!
[00:06] <lifeless> wgrant: gmb filed bugs about rollback not being set properly
[00:06] <lifeless> wgrant: you may need to ignore it
[00:06] <wgrant> lifeless: Do I have your blessing to request a deploy of 12274, despite qa-tagger's protests?
[00:06] <lifeless> poolie: https://bugs.launchpad.net/launchpad/+bug/708961
[00:06] <_mup_> Bug #708961: loggerhead oops reports are missing diagnostic data <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/708961 >
[00:06] <lifeless> wgrant: let me eyeball
[00:07] <poolie> anyhow, spm, whenever you get a moment (it's not urgent) i would like to get a bucket-ful of the firehose
[00:07] <lifeless> wgrant: yes
[00:07] <poolie> then we can turn it off again
[00:07] <lifeless> wgrant: there is a partially complete request you can extend to save some time
[00:07] <StevenK> I don't think we can QA r12272.
[00:07] <lifeless> wgrant: just grab the new bug numbers etc
[00:07] <spm> poolie: yeah will do
[00:07] <lifeless> StevenK: its rolledback
[00:08] <wgrant> lifeless: Yup.
[00:08] <StevenK> Right
[00:08] <lifeless> StevenK: read 12274
[00:08] <StevenK> lifeless: Yes, but the QA tagger thinks we're blocked on 72
[00:08] <wgrant> lifeless: Just the bugs listed on the deployment report?
[00:08] <lifeless> StevenK: so, did you see my reply to your query; you were not less shiny, you were answered.
[00:08] <spm> lifeless: poolie: we do have other checks, but even that only takes it to around 15 an hour max.
[00:08] <StevenK> lifeless: Sorry, I thought you were going to explain more
[00:08] <lifeless> wgrant: for rev in revs, copy Bug 123 -> Bug:123 in the deploy request
[00:08] <_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
[00:08] <wgrant> Right.
[00:08] <lifeless> wgrant: where revs starts at the one after the one I'd gotten up to
[00:09] <lifeless> StevenK: you need to shuffle order of parameters in your python code
[00:09] <lifeless> StevenK: to control how things are output
[00:09] <lifeless> StevenK: do you understand what right outer does?
[00:09] <StevenK> lifeless: If I follow your query, you're selecting from SPRB, which storm then returns
[00:10] <lifeless> StevenK: no, I'm not
[00:10] <StevenK> SELECT SourcePackageRecipe.name, SourcePackageRecipe.owner FROM
[00:10] <StevenK> SourcePackageRecipeBuild
[00:10] <spm> poolie: actually - I wonder. is this something we could possibly trial on staging at all? I don't believe we have a haproxy there (??). Just thinking we could start there and see if we can dupe, or get sufficient WTF info. and then look into prod?
[00:10] <lifeless> StevenK: the *entire* thing between FROM and WHERE is what you select from
[00:10] <lifeless> StevenK: its a composite table
[00:11] <lifeless> StevenK: store.using(table description) is how you tell storm about that, which you already do
[00:11] <poolie> if we have an haproxy there that would be a great place to do it
[00:11] <StevenK> Right.
[00:11] <lifeless> StevenK: the .find((Things to select), constraints) is where you tell it *what* to pull out of the composite
[00:15] <StevenK> lifeless: Out of interest, I can't find any other uses of RightJoin
[00:16] <lifeless> StevenK: doesn't surprise me
[00:16] <lifeless> it is materializing a view
[00:17] <lifeless> but it will scale quite a bit I think
[00:17] <lifeless> we'll have to revisit it when we're in the 5K mark, I'd say
[00:18] <lifeless> however
[00:18] <StevenK> Now the query looks good
[00:18] <StevenK> Well, it's ordered differently to yours
[00:18] <lifeless> http://pastebin.com/Vf6Manng
[00:22] <poolie> searching for bugs assigned to me through the api seems to consistently time out
[00:22] <poolie> should i file or is this probably known?
[00:25] <poolie> ah, it is
[00:26] <lifeless> StevenK: so, fiddling suggests left outers on all the joins will be better here
[00:26] <lifeless> StevenK: but can I ask
[00:26] <lifeless> StevenK: why do we need all these different tables ?
[00:26] <lifeless> poolie: which bug ?
[00:27] <poolie> the oops finder says https://bugs.launchpad.net/launchpad/+bug/638924
[00:27] <_mup_> Bug #638924: Milestone:+index timeouts with many bugs <lp-registry> <pg83> <qa-ok> <timeout> <Launchpad itself:Fix Released by edwin-grubbs> < https://launchpad.net/bugs/638924 >
[00:27] <poolie> and it looks similar, but it's not fixed
[00:27] <lifeless> the oops finder?
[00:27] <poolie> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1854EA3
[00:27] <lifeless> if you mean the lp-oops ui, its useless
[00:27] <lifeless> (for our needs)
[00:28] <StevenK> lifeless: Because BuildFarmJob tells us when the build was created, which links from PackageBuild, which links from SourcePackageRecipeBuild
[00:28] <lifeless> awesome data collection, brilliant rendering. Terrible heuristic about what bug
[00:28] <lifeless> StevenK: and we always have all three tables, or never all three, right ?
[00:28] <poolie> ah, is it
[00:28] <poolie> in this case it's not a bad guess
[00:28] <lifeless> poolie: I've been ranting since day one :)
[00:29] <StevenK> lifeless: Right, we need a SPRecipeBuild to have the other two
[00:29] <poolie> i don't know if this indicates the same bug was not totally fixed, or if it needs a different bug
[00:29] <poolie> s//fix
[00:29] <lifeless> poolie: no, its a terrible guess. Its only chance that it seems relevant to you
[00:29] <lifeless> the page id is Person:EntryResource:searchTasks
[00:29] <lifeless> go to https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
[00:29] <lifeless> and search for searchTasks
[00:31] <lifeless> poolie:  https://bugs.launchpad.net/launchpad/+bug/669766
[00:31] <_mup_> Bug #669766: Person:+bugs timeouts <dba> <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669766 >
[00:31] <poolie> seems similar
[00:31] <lifeless> same query
[00:31] <lifeless> the unions in there are a red flag to me
[00:32] <poolie> right, it looks a bit insane
[00:33] <lifeless> StevenK: so if we have all three, why are they separate tables?
[00:33] <lifeless> StevenK: its a great way to make sql slow
[00:34] <lifeless> StevenK: anyhow, on balance, I've tried a bunch of query plans
[00:34] <lifeless> StevenK: go with LEFT OUTER...LEFT OUTER...LEFT OUTER
[00:34] <lifeless> that this whole schema needs fixing is a separate problem.
[00:35] <lifeless> hmm, I'm getting biting. Lunchtime, please excuse me folks
[00:56] <poolie> wow i don't know what changed but apis are distinctly faster than they used to be
[01:00] <wgrant> Which APIs?
[01:03] <poolie> reading bugs
[01:04] <poolie> actually i'm not really sure if that's true; i think what this process is doing is not comparable
[01:04] <poolie> still actually several seconds per bug :(
[01:04] <wgrant> :D
[01:11]  * wgrant fixes the db-devel merge conflict.
[01:23] <thumper> I'm finally done with the text widget refactoring
[01:23] <thumper> \o/
[01:24] <thumper> the diff is a bit bigger than originally expected
[01:25] <thumper> good thing that flacoste has already committed to reviewing it
[01:25] <thumper> otherwise I'm sure it'd get rejected due to size
[01:28] <wgrant> haha.
[01:28] <wgrant> What does it change?
[01:30] <lifeless> everything!
[01:30] <wgrant> Surely not.
[01:33] <thumper> https://code.launchpad.net/~thumper/launchpad/refactor-lazrjs-text-widgets/+merge/47634
[01:34] <thumper> wgrant: look at the documentation in the diff
[01:34] <thumper> wgrant: it covers most of the interesting stuff
[01:34] <wgrant> Yay.
[01:34] <wgrant> Also ouch.
[01:41] <thumper> wgrant: why ouch?
[01:42] <StevenK> thumper: That moves an awful lot of code around, but nice work!
[01:42] <thumper> StevenK: thanks
[01:43] <wgrant> thumper: The diff size.
[01:43] <thumper> the simple enum chooser needs some similar treatment
[01:43] <thumper> but I'll get to that at some stage
[01:43] <thumper> wgrant: yeah, it did kinda grow on me
[01:44] <thumper> wgrant: when flacoste looked at it last night, it was only 850 or so
[01:44] <wgrant> Heh.
[01:44] <thumper> but I added lots of documentation
[01:44] <StevenK> wgrant: Did I tell you how large the bpb-current-component diff got?
[01:44] <wgrant> StevenK: 4.5kish?
[01:44] <StevenK> wgrant: 4,800
[01:44] <wgrant> Ow.
[01:44] <StevenK> Not quite as bad as the soyuz enums branch, but as close as I've gotten
[01:46] <poolie> hi
[01:46] <poolie> i'm getting "sorry there was a problem" talking to the api server
[01:46] <lifeless> 502?
[01:46] <lifeless> is there an OOPS?
[01:46] <poolie> yes 502
[01:46] <poolie> no oops
[01:47] <lifeless> one off or repeatedly?
[01:47] <poolie> at least twice
[01:47] <poolie> very long timout
[01:47] <wgrant> edge or lpnet?
[01:47] <wgrant> When?
[01:47] <poolie> just now; lpnet
[01:47] <poolie> curl -v  https://api.launchpad.net/devel/ -H "Accept: application/vd.sun.wadl+xml"
[01:48] <poolie> pretty sure i ran that command successfully the other day
[01:48] <poolie> ok, this time it worked, after a _long_ delay
[01:48] <poolie> between when i pasted the curl line and now
[01:48] <StevenK> Last revision deployed to QAStaging is 12274. There are no revisions waiting in the queue.
[01:48] <StevenK> \o/
[01:49] <poolie> i'll look for or file a bug
[01:50] <poolie> maybe bug 607961
[01:50] <_mup_> Bug #607961: wadl generation timeout? <lp-foundations> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/607961 >
[01:51] <poolie> yes, that's it
[01:52] <lifeless> wgrant: feel like sending a yee-ha mail to the list ? :)
[01:53] <wgrant> lifeless: Just finishing closing old bugs.
[01:54] <wgrant> Did someone just put loggerhead into launchpad-project?
[01:54] <lifeless> yes
[01:54] <wgrant> :(
[01:54] <lifeless> why so sad?
[01:54] <thumper> wow, we are up to date with production
[01:54] <thumper> awesome
[01:54] <wgrant> Need to fix my bugmail rules.
[01:55] <lifeless> thumper: cunning plan working :)
[01:55] <wgrant> 237 critical bugs!
[01:55] <wgrant> We are down to what we were at at the start of last week!
[01:55] <wgrant> Yay...
[01:57]  * spm files some more
[01:58] <wgrant> lifeless: Do all these Bugs story-* tags need to be official?
[01:59] <lifeless> wgrant: how do you mean?
[01:59] <wgrant> lifeless: launchpadtags portlet
[01:59] <wgrant> Ugh.
[01:59] <wgrant> launchpad's tags portlet is rather cluttered.
[01:59] <lifeless> wgrant: so, it is, but thats all not just official
[01:59] <wgrant> Partly because there are lots of very long story-* official tags from back when Bugs was separate.
[01:59] <wgrant> isn't it?
[01:59] <wgrant> I thought it was now.
[02:08] <lifeless> poolie: hi
[02:08] <lifeless> you marked bug 492614 as new, but I'm unclear why
[02:08] <_mup_> Bug #492614: bzr serve --http cannot find module loggerhead.util <loggerhead:New> < https://launchpad.net/bugs/492614 >
[02:10] <poolie> wow, benji's thing in https://launchpad.net/+feature-info is really classy
[02:11] <poolie> lifeless, i marked it new because it seems possible someone could solve it since he gave more data
[02:11] <poolie> i may be wrong
[02:11] <wgrant> poolie: Yeah, I saw that while checking what to close.
[02:11] <wgrant> It is really nice.
[02:11] <poolie> at the moment i use 'incomplete' as 'should be killed by the expiry-bot if no more data is provided'
[02:11] <lifeless> poolie: I'm driving NEW to zero
[02:13] <poolie> so i see!
[02:13] <poolie> feel free to take a guess at whether it's invalid or confirmed
[02:14] <poolie> i would suspect something weird in his environment therefore invalid
[02:14] <lifeless> jelmer has it assigned to him already
[02:15] <lifeless> hmm
[02:15] <lifeless> no, another bug has jelmer
[02:20] <lifeless> ok, 0 untriaged bugs
[02:20] <lifeless> phew
[02:21] <thumper> jelmer: are you working on bug 698032?  I was told you had a solution.
[02:21] <_mup_> Bug #698032: recipe build for removed recipe triggers uploader exception <oops> <recipe> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/698032 >
[02:25] <lifeless> [02:25] <lifeless>     Hard / Soft  Page ID
[02:25] <lifeless>     1398 /  424  BugTask:+index
[02:25] <lifeless>       34 /   83  DistroSeries:+queue
[02:25] <lifeless>       18 /   44  Branch:+index
[02:25] <lifeless>       17 /  356  Distribution:+bugtarget-portlet-bugfilters-stats
[02:25] <lifeless>       16 /  236  POFile:+translate
[02:25] <lifeless>       12 /   14  NullBugTask:+index
[02:25] <lifeless>       12 /   13  Cve:+index
[02:25] <lifeless> going to be fun on monday
[02:26] <poolie> thumper i think jelmer is on holiday this week
[02:26] <poolie> how do i create a team with 'canonical' in the name?
[02:26] <thumper> poolie: ok, np, just wanting a status update
[02:26] <thumper> poolie: it isn't urgent
[02:27] <thumper> poolie: ask a losa to rename a team once you've made it
[02:27] <wgrant> poolie: There's a fix for that on db-devel. But now you have to get LOSAs to SQL it up.
[02:27] <lifeless> poolie: hi
[02:27] <lifeless> poolie: if you're going to set the status of new bugs in Launchpad, can you please follow the bug triage guidelines?
[02:27] <poolie> wgrant, by asking them to make a new one, or to rename one?
[02:27] <wgrant> poolie: Rename.
[02:28] <poolie> lifeless, i'm trying to; in what way am i not?
[02:29] <lifeless> we don't use confirmed
[02:29] <lifeless> confirmed is a state an end user might set it to
[02:29] <poolie> i know
[02:29] <lifeless> but its a noop for our process
[02:29] <poolie> i'm setting them to that state specifically because i'm not doing your tirage
[02:29] <poolie> *triage
[02:29] <lifeless> poolie: please don't then
[02:30] <poolie> look, the guidelines don't say "don't use confirmed"
[02:30] <lifeless> the guidelines are for devs
[02:30] <poolie> but, i'm happy to not use it if you want
[02:30] <poolie> would you prefer i triage them, or leave them new?
[02:31] <lifeless> triaging is great
[02:31] <poolie> ok
[02:31] <lifeless> that would be ideal
[02:31] <poolie> np
[02:32] <lifeless> I'm sorry if something I said there came across negatively
[02:32] <poolie> it's fine
[02:32] <lifeless> confirmed is not a very useful status in the bug tracker IMO - its there mainly to support the Ubuntu 'lets get unskilled labour en masse' meme
[02:32] <poolie> it's just that i was using Confirmed specifically because i didn't want to contradict your triage process
[02:33] <lifeless> confirmed doesn't contradict it, it just doesn't help it
[02:33] <poolie> i certainly agree about that
[02:33] <poolie> no, i was concerned that i would make it say triaged/high when you didn't think it would be high etc
[02:34] <lifeless> if there is disagreement, it can be altered beyond the first persons assessment
[02:34] <lifeless> the broad rule of thumb is critical-for-emergencies, high for next-6-months, low for everythingelse
[02:34] <poolie> great, i shall do that from here on
[02:34] <lifeless> cool
[02:35] <wgrant> Is there any point keeping bug #705841 open?
[02:35] <_mup_> Bug #705841: bzr branch error: Error -3 while decompressing: incorrect data check <Launchpad itself:Confirmed> < https://launchpad.net/bugs/705841 >
[02:36] <lifeless> wgrant: I've commented and closed it
[02:38] <poolie> i think there's another bug asking for a better message
[02:38] <thumper> does anyone know if it is possible to annotate an existing exception class with a webservice_error code?
[02:38] <thumper> i.e. one that is in a separate module
[02:38] <thumper> like bzr-builder
[02:39] <thumper> in particular InstructionParseError
[02:39] <StevenK> subclass it and feed it webservice_error?
[02:41] <thumper> StevenK: but the exception is being raised in bzr-builder code
[02:42] <StevenK> thumper: Intercept it and raise the subclassed one?
[02:42] <poolie> stupid question i guess, but you can't just stick attributes onto it?
[02:43] <thumper> poolie: possibly
[02:43] <thumper> poolie: I was just reading the webservice_error code
[02:44] <thumper> found it
[02:44] <thumper>  error_status(400)(InstructionParseError)
[02:44] <thumper> where error_status is in lazr.restful.declarations
[02:48] <lifeless> wgrant: can you triage bug 338858?
[02:48] <_mup_> Bug #338858: Buildds do not follow versioned build-dependencies <sbuild> <Launchpad Auto Build System:Confirmed> < https://launchpad.net/bugs/338858 >
[02:49] <lifeless> huwshimi: bug 336913 might be nice if you're driving the wiki theme stuff to zero
[02:49] <_mup_> Bug #336913: Marking text as --(strike through)-- has no effect <Launchpad Development Wiki Moin theme:Triaged> < https://launchpad.net/bugs/336913 >
[02:49] <lifeless> huwshimi: (I don't know if you are)
[02:49] <wgrant> lifeless: sbuild makes me cry.
[02:49] <wgrant> But sure.
[02:49] <lifeless> wgrant: sadly we own the stack.
[02:50] <lifeless> noone in ubuntu looks at these projects
[02:50] <lifeless> not by default
[02:50] <wgrant> I know.
[02:50] <wgrant> However, I have an evil plan and branch to make us use system sbuild, which almost pushes the Perl onto Ubuntu :)
[02:51] <lifeless> bug 309645 needs a more stateful eye too
[02:51] <_mup_> Bug #309645: sbuild gets confused when the dsc version does not match the changelog one <sbuild> <Launchpad Auto Build System:Confirmed> < https://launchpad.net/bugs/309645 >
[02:51] <persia> wgrant, Were you able to address lamont's outstanding issues with that branch?
[02:52] <wgrant> The main issue is that it probably needs a couple of lines added to sbuild.
[02:52] <wgrant> And I moved onto other things before I worked out how to solve that nicely.
[02:53] <huwshimi> lifeless: I was doing some work on the help wiki and decided to clear out all the bugs that had a status above low. I haven't really touched the dev wiki yet. Hopefully I'll do the same thing for that at some stage.
[02:54] <lifeless> huwshimi: no worries
[03:02] <StevenK> Can I instruct bin/test to match tests with a regex?
[03:03] <wgrant> It should by default.
[03:03] <wgrant> -t takes a regex, doesn't it?
[03:03]  * StevenK adds a $ and tries it
[03:03] <wgrant>     -t TEST, --test=TEST
[03:03] <wgrant>                         Specify a test filter as a regular expression.
[03:27] <poolie> lifeless, i don't think bug 703807 should be incomplete
[03:27] <_mup_> Bug #703807: "easy_install pyOpenSSL" says "error: Unexpected HTML page found at http://launchpad.net/pyopenssl/main/0.11/+download/pyOpenSSL-0.11.tar.gz" <Launchpad itself:Incomplete> <pyOpenSSL:New> < https://launchpad.net/bugs/703807 >
[03:27] <poolie> it's an intermittent error but it can be reproduced, and the user has given as much as they reasonably can
[03:27] <poolie> there are multiple dupes
[03:28] <lifeless> sure
[03:28] <poolie> sorry, there is a dupe, and i reproduced it myself
[03:28] <lifeless> from what I could see theres still no evidence of lp itself having the issue
[03:28] <poolie> rather than what?
[03:29] <lifeless> setup.py doing something weird perhaps?
[03:29] <poolie> i could reproduce it using curl
[03:29] <wgrant> I can reproduce it right now using curl.
[03:29] <lifeless> ok, then triaged critical
[03:29] <poolie> i'll do that
[03:29] <lifeless> if the headers show crap coming from the lp squids
[03:30] <StevenK> lifeless: You did mean this when you said left outer join, right: http://pastebin.ubuntu.com/559348/ ?
[03:31] <wgrant> At the moment, http://launchpadlibrarian.net/58498441/pyOpenSSL-0.11.tar.gz gets the right type from nutmeg, but the wrong from banana.
[03:59] <lifeless> wgrant: check_permission('launchpad.Edit', branch) isn't really a URI call
[04:00] <wgrant> lifeless: That's another way to bypass the security check.
[04:00] <wgrant> You get to see the URL if any of these three conditions are satisfied: the URL is None, you can edit the branch, or the URL is not on a blacklisted domain.
[04:00] <lifeless> ok
[04:00] <lifeless> like I said
[04:00] <lifeless> it was a question
[04:02] <lifeless> man
[04:02] <lifeless> another day
[04:02] <lifeless> no code
[04:05] <wgrant> :(
[04:32] <lifeless> https://devpad.canonical.com/~lpqateam/lpnet-oops.html
[04:32] <lifeless> Time Out Counts by Page ID
[04:32] <lifeless> Hard	Soft	Page ID
[04:32] <lifeless> 384	1807	Distribution:EntryResource:searchTasks
[04:32] <lifeless> thats a little alarming this early into the day
[04:32] <lifeless> or perhaps its just one script ;)
[04:33] <lifeless> all steve beattie :)
[04:34] <lifeless> hmm 12200 still
[04:35] <wgrant> Is there a better way of getting the webapp's root URL than looking directly in the config?
[04:35] <StevenK> Sigh. SQL sucks
[04:37] <lifeless> StevenK: yes thats what I meant
[04:37] <StevenK> Which doesn't actually work anyway
[04:38] <lifeless> you forgot the distinct
[04:38] <StevenK> How does a distinct help me when the query returns zero rows?
[04:38] <lifeless> oh
[04:38] <lifeless> hang on
[04:38] <lifeless> you need SPR left join SPRB
[04:39] <lifeless> because you want all rows in SPR
[04:40] <lifeless> works for me
[04:40] <lifeless> 97 rows
[04:40] <lifeless> 96.751 ms
[04:41] <StevenK> On staging?
[04:41] <lifeless> yes
[04:41] <StevenK> How out of date is that database?
[04:41] <lifeless> using 2010-11-26 as the date
[04:41] <lifeless> your query doesn't work
[04:41] <lifeless> the fixed one (switch the SPRB and SPR right after the FROM) does
[04:41] <lifeless> SELECT DISTINCT SourcePackageRecipe.build_daily,
[04:41] <lifeless>                 SourcePackageRecipe.daily_build_archive,
[04:41] <lifeless>                 SourcePackageRecipe.date_created,
[04:41] <lifeless>                 SourcePackageRecipe.is_stale,
[04:41] <lifeless>                 SourcePackageRecipe.name,
[04:41] <lifeless>                 SourcePackageRecipe.OWNER, SourcePackageRecipe.registrant
[04:42] <lifeless> FROM SourcePackageRecipe
[04:42] <lifeless> LEFT JOIN SourcePackageRecipeBuild ON SourcePackageRecipeBuild.recipe = SourcePackageRecipe.id
[04:42] <lifeless> LEFT JOIN PackageBuild ON PackageBuild.id = SourcePackageRecipeBuild.package_build
[04:42] <lifeless> LEFT JOIN BuildFarmJob ON BuildFarmJob.id = PackageBuild.build_farm_job
[04:42] <lifeless> WHERE SourcePackageRecipe.is_stale = TRUE
[04:42] <lifeless>   AND SourcePackageRecipe.build_daily = TRUE
[04:42] <lifeless>   AND (SourcePackageRecipeBuild.id IS NULL
[04:42] <lifeless>        OR BuildFarmJob.date_created < '2010-11-26 22:47');
[04:42] <lifeless> btw http://sqlformat.appspot.com/ is your friend :)
[04:42] <lifeless> back soon, grocery shopping time
[04:50] <StevenK> Hm. How do I shoehorn DISTINCT into Storm?
[04:50] <StevenK> grep is not being my friend
[04:52] <wgrant> .config(distinct=True)
[04:54] <StevenK> wgrant: Ah! Thanks
[05:09] <stub> I think there is a nicer spelling of that, but I can never remember it :-(
[05:36] <LPCIBot> Project devel build (399): FAILURE in 4 hr 51 min: https://hudson.wedontsleep.org/job/devel/399/
[05:36] <LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][ui=none][bug=687564] Fixed bug #687564 so that the license
[05:36] <LPCIBot> selection widget on new project does not overlap other content
[05:36] <LPCIBot> on the page.
[05:36] <_mup_> Bug #687564: license widget sections overlaps on projectgroup +newproject and projects/+new <bug-1> <javascript> <lazr-js-upgrade> <lp-registry> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/687564 >
[05:36] <LPCIBot> * Launchpad Patch Queue Manager: [r=bac,jcsackett][ui=none][bug=613958,681125] Fix recipe build mail.
[06:03] <wgrant> allenap: Can bug #656823 be closed? I know it's probably not actually done yet, but the revs are all deployed.
[06:03] <_mup_> Bug #656823: Subscribing to a search lacks a UI <lp-bugs> <qa-ok> <story-subscribe-to-search> <Launchpad itself:Fix Committed by allenap> < https://launchpad.net/bugs/656823 >
[06:08] <wgrant> OK, now this is interesting.
[06:09] <wgrant> Hudson and buildbot both have the same spurious-looking error which I haven't seen recently, and there are no relevant changes :(
[06:11] <StevenK> The Hudson error looks to have confused subunit, too
[06:12] <wgrant> Well, in both cases something has gone catastrophically wrong.
[06:12] <wgrant> With the subprocess hanging and then being killed.
[06:12]  * StevenK has a closer look at Hudson
[06:12] <wgrant> But they are on different branches.
[06:13] <wgrant> It is rather unlikely that they would both show up within an hour of each other.
[06:13] <StevenK> That looks like a deadlock to me
[06:13] <wgrant> Oh.
[06:13] <wgrant> Windmill was reenabled this morning.
[06:13] <wgrant> I bet that's not unrelated.
[06:14] <wgrant> Oh look.
[06:15] <wgrant> It was tearing down AppWindmillLayer.
[06:15] <wgrant> Let's see if it does the same locally.
[06:27] <wgrant> I've so far had it crash in 6 other ways, but not that way :(
[07:12] <lifeless> wgrant: bug 192135
[07:12] <_mup_> Bug #192135: Bug nickname field needs better validation <lp-bugs> <oops> <Launchpad itself:Invalid> < https://launchpad.net/bugs/192135 >
[07:12] <lifeless> wgrant: does the API allow bug nicknames to be set?
[07:15] <jelmer> thumper: hi
[07:16] <jelmer> thumper: with regard to bug 698032, I would just ignore and delete the build if the recipe has disappeared
[07:16] <_mup_> Bug #698032: recipe build for removed recipe triggers uploader exception <oops> <recipe> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/698032 >
[07:16] <jelmer> we're doing the same thing for binary builds of source uploads
[07:18] <wgrant> lifeless: Yes, and I thought the validator was OK there.
[07:18] <wgrant> But it misses one case :(
[07:18] <lifeless> wgrant: so perhaps invalid is premature ? :)
[07:18] <wgrant> lifeless: It wasn't until you just prompted me to test further. :(
[07:19] <lifeless> wgrant: don't you hate attention to detail ? :)
[07:19] <wgrant> Indeed.
[07:21] <lifeless> \o/
[07:26] <wgrant> WTF
[07:26] <wgrant> Bug #32464
[07:26] <_mup_> Bug #32464: guess_bugtask() fails on distribution tasks without a source package <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/32464 >
[07:26] <wgrant> The function referenced there has a higher WTF level than any part of Soyuz.
[07:29]  * jelmer is curious
[07:30] <wgrant> I always wondered what IDistribution.members was for.
[07:30] <wgrant> It turns out it's for making wild guesses at which bugtask an email is directed at.
[07:31] <jelmer> what is it used for, just for telling the user in what way they are subscribed?
[07:31] <wgrant> No, it's for incoming email.
[07:31] <wgrant> That function is used to determine the bugtask to edit, if you don't explicitly tell it.
[07:31] <wgrant> I just presumed it failed if there was more than one.
[07:31] <wgrant> But no, it guesses.
[07:32] <wgrant> In the wrong order.
[07:34] <lifeless> wgrant: members is a PublicPersonChoice ?
[07:34] <wgrant> lifeless: Sounds right.
[07:34] <lifeless> wtf
[07:34] <wgrant> I presumed it was used for nothing at all.
[07:35] <wgrant> But I didn't know this wonderful piece of guesswork existed.
[07:35] <wgrant> It appears to be the only callsite.
[07:35] <lifeless> nuke it ?
[07:36] <lifeless> email ubuntu-dev, then nuke it
[08:56] <adeuring> good morning
[09:09] <allenap> wgrant: Yes, I've marked bug #656823 released.
[09:09] <_mup_> Bug #656823: Subscribing to a search lacks a UI <lp-bugs> <qa-ok> <story-subscribe-to-search> <Launchpad itself:Fix Released by allenap> < https://launchpad.net/bugs/656823 >
[09:10] <mrevell> Hi
[09:12] <wgrant> allenap: Thanks.
[10:55] <gmb> Does anyone know if there's a canonical example of a good way of handling Zope enum values in JS widgets (i.e. where we pull in the form with ++form++) other than just rewriting the form manually?
[10:56] <gmb> I ask because Zope widgets that use enums have uppercase values, but our API demands that they be standard-caps (e.g. Lifecycle instead of LIFECYCLE).
[11:03] <Ursinha> good morning
[11:19] <gmb> Oh, never mind. What you do is make the vocabulary not suck.
[11:19] <LPCIBot> Project db-devel build (329): FAILURE in 5 hr 43 min: https://hudson.wedontsleep.org/job/db-devel/329/
[12:04] <deryck> Morning, all.
[12:33] <jelmer> jkakar: hi
[12:33] <jelmer> jkakar: how does the categorization in the HTML kanban boards work?
[12:34] <bac> adeuring: are you reviewing today?
[12:39] <jkakar> jelmer: Hi!
[12:40] <jkakar> jelmer: It's based on bug tags that start with 'story-'.  Any bugs that are part of the same story will be grouped together in a lane.
[12:41] <jelmer> jkakar: ah, thanks
[12:41] <jkakar> jelmer: np.
[12:41] <jkakar> jelmer: There's one other convention that's worth noting.
[12:42] <jkakar> jelmer: The bug states, 'Queued', 'In progress', 'Needs review', etc. are all based on information from Launchpad.  You don't need to do anything special to have a bug in the right place, with the exception of 'Needs testing'.
[12:42] <jkakar> jelmer: Er, sorry, with the exception of 'Verified'.  In order to move a bug from the 'Needs testing' column to the 'Verified' column you need to add a 'verified' tag to it.
[12:43] <jelmer> jkakar: Ah - I was wondering about that. I have a bunch of "Fix Committed" bugs that are currently sitting in Needs Testing
[12:45] <jkakar> jelmer: The columns are based on the process we use in Landscape where a QA step happens after code review... so it might not make sense for your projects if you do things differently.
[12:46] <jelmer> jkakar: yeah, because of the way bzr development works we don't really need a separate step for that
[12:47] <jelmer> jkakar: It's only minor overhead to set that tag though. I'm going to give the HTML kanban board a try and evaluate in a week or two. If it works well enough we can always improve it.
[12:49] <jkakar> jelmer: Cool, I'm curious to know how you find it.
[12:49] <jkakar> jelmer: Also, if you don't care about the difference between 'Needs testing' and 'Verified' you could just ignore the tag.  I might be nice to add an option to turn those columns into 'Ready to release' or something.
[13:05] <gmb> deryck: You might know the answer to this: are Windmill tests automatically run as part of our test suite? I'm guessing so given the most recent build failure, but I wanted to check.
[13:05] <deryck> gmb: yeah, they are now again.
[13:05] <gmb> deryck: Cool, thanks.
[13:06] <deryck> I'm also about to start looking into that failure, unless someone else has a fix worked up.
[13:09] <gmb> deryck: I was going to look into it in a bit, but if you're going to take a look I'm happy for you to do so ;)
[13:09] <gmb> Though if you need an extra pair of eyes just ping me.
[13:16] <adeuring> bac: well, I am also CHR today... I focused more on that task. Also, I did not see any review requests  this morning I dared to take. But I'll add myself to the OCR set.
[13:17] <bac> adeuring: ok, i was just curious
[13:21] <maxb> Hi, is the revno shown at the botton of production pages a stable branch revno?
[13:22] <maxb> Basically I'm trying to establish whether http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12201 has reached prod yet
[13:28]  * maxb reopens bug 680733
[13:28] <_mup_> Bug #680733: broken recipe build gets stuck at top of "5 latest builds" list on recipe page, forever <lp-code> <qa-ok> <recipe> <Launchpad itself:New for thumper> < https://launchpad.net/bugs/680733 >
[13:29] <gmb> benji, bac: Howdy. Can you take a look at https://code.launchpad.net/~gmb/launchpad/hooky-hooky-bug-699719/+merge/47803 for me?
[13:29] <benji> gmb: sure
[13:29] <gmb> Ta
[13:58] <sinzui> Hello everyone. Hello, power, hello internet, hello small heater at my feet
[13:59] <deryck> hello sinzui.  glad to hear you have power again.
[14:00] <deryck> adeuring, abentley -- standup ping
[14:00] <adeuring> yes
[14:00] <abentley> deryck, hi.
[14:02] <bac> ping mrevell
[14:02] <bac> sinzui: how was that "hand ground" coffee?
[14:03] <sinzui> It was good. I used a French press (why is it French when it was invented in New Jersy)
[14:05] <deryck> maybe someone from Belgium living in New Jersey made it
[14:05] <bac> sinzui: would you buy a New Jersey Press?
[14:05] <bac> oh, the cachet
[14:06] <sinzui> Or the inventor was named Frenchie (As in the case of the French dipped sandwich)
[14:06] <benji> sinzui: the same reason Chinese fortune cookies were invented in a Japanese restaurant in San Francisco
[14:06] <bac> benji: gullible white people?
[14:06] <sinzui> benji: yes. Those were Shito fortunes
[14:07] <benji> sinzui: they've gotten better since then
[14:07] <sinzui> Ice cream was invented in China...a nation of lactose intolerant people. That does not make sense
[14:08] <sinzui> leonardr and I had some interesting fortune cookies in Montreal. I like the misreading of "You will have an affair with one of your students."
[14:09] <mrevell> hi bac
[14:16] <vila> abentley: ping
[14:17] <vila> oh, standup, bad time I guess
[14:17] <benji> gary_poster: yellow/Subscriptions includes a first cut description of the mute UI; I'd say we shouldn't include the "no events" part in the normal subscribe workflow
[14:18]  * benji wanders away into the right channel.
[14:18] <gary_poster> :-)
[14:18] <abentley> vila, pong
[14:19] <vila> abentley: I cam across https://dev.launchpad.net/Foundations/NewTaskSystem/Requirements in the context of the package importer,
[14:19] <vila> abentley: AIUI from a related thread in lp-dev, the best candidate at one point was celery+rabbitt, is this still true ?
[14:20] <abentley> vila, yes, that was the leading candidate, but the project was put on hold before I could reach a conclusion.
[14:21] <vila> abentley: ok, no urgency
[14:22] <vila> abentley: thanks !
[14:22] <abentley> vila, no problem.
[14:25] <abentley> vila, you could consider using one of our existing systems such as the Job System or the build farm if you're looking at migrating.
[14:26] <vila> abentley: yup, that's was my understanding from the thread
[14:26] <vila> s/'s//
[14:27] <vila> i.e. tss
[14:31] <bigjools> morning
[14:32] <vila> bigjools: ha, that's why I thought you weren't in England ;-D
[14:32] <bigjools> vila: yeah, but *Holland*? :)
[14:33] <vila> bigjools: people wake up later there :D
[14:33] <bigjools> lol - having been jelmer's manager I know that :)
[14:56] <abentley> losa, bigjools: do normal staging updates include refreshing the archiveuploader?
[14:56] <bigjools> abentley: what's the archiveuploader?
[14:57] <abentley> bigjools, lib/lp/archiveuploader/
[14:58] <bigjools> abentley: yes, but staging can only do binary uploads from the build farm
[14:58] <bigjools> or recipe builds
[15:00] <abentley> I'm not sure what you mean by "can only do binary uploads from the build farm".  Do you mean that the code that performs uploads for recipes is on the build farm and therefore not updated?
[15:02] <abentley> bigjools, ^^
[15:03] <bigjools> abentley: there's a process-upload.py cron job that processes any build coming from the build farm; there's no mechanism to process external source package uploads yet.
[15:03] <bigjools> it's not on the build farm, no
[15:05] <abentley> bigjools, I'm trying to figure out why my email changes haven't taken effect.  They landed in r10158, which is deployed on staging.
[15:05] <bigjools> is that recipe build failure notifications?
[15:05] <bigjools> or success in your case
[15:06] <benji> bac: will you review my review of https://code.launchpad.net/~gmb/launchpad/hooky-hooky-bug-699719/+merge/47803?
[15:06] <bac> yep
[15:06] <abentley> bigjools, yes success notifications.  I'm testing failure now.
[15:06] <bigjools> okidoki
[15:07] <bigjools> not sure why you're not seeing those then - you're looking in the staging outbox?
[15:07] <gmb> benji, bac: FTR, there *is* a feature flag: malone.use-advanced-subscriptions (or something of that nature). But I couldn't use it here because this is very, very pre-alpha.
[15:07] <abentley> bigjools, yes.  The message "[STAGING] [PPA abentley-test] [ubuntu/maverick] wakeonlan 5.5~maverick1	(Accepted)" is formatted as if it were a user upload rather than a build upload.
[15:07] <gmb> bac, benji: But Y.bugs.bugtask_index.use_advanced_subscriptions will be set to true by that feature flag once this is ready for alpha testing.
[15:10] <benji> gmb: that's cool; I was thinking of something more pre-alpha-like; I'm not entirely sure feature flags are well suited for that though, because you may just want the functionality on demand.  I'm curious how you enable that functionality now (i.e., in development).
[15:11] <gmb> benji: I just hack "Y.bugs.bugtask_index.use_advanced_subscriptions = true; " in above the call to Y.bugs.bugtask_index.setup_bugtask_index().
[15:15] <abentley> bigjools, my failure test is still "uploading", 3 minutes after the build completed: https://code.staging.launchpad.net/~abentley/+archive/test/+buildjob/2185120
[15:16] <benji> bac: https://code.launchpad.net/~wgrant/launchpad/trivial-soyuz-ui/+merge/47767 looks like it could use some review love; shall I claim it?
[15:16] <bac> benji: yes, it looks pretty straightforward
[15:17] <bigjools> abentley: I'm not sure how often the cron job runs to upload them on staging
[15:17] <bigjools> DEATH TO pagetitles.py
[15:17] <abentley> bigjools, Oh, completed now.
[15:18] <bigjools> coolio
[15:19] <abentley> bigjools, failure behaviour is unchanged too.  I am really strongly suspecting that process-email was not updated.  Do you know where it runs?
[15:20] <bigjools> abentley: on staging itself
[15:20] <bigjools> whatever that box is called
[15:20] <bigjools> maybe there's a separate tree?
[15:20] <abentley> bigjools, there are a bunch of boxes that make up staging.
[15:20] <bigjools> ok
[15:20] <bigjools> you need to find a friendly neighbourhood losa
[15:22] <allenap> bdmurray: Do you remember doing @operation_removed_in_version stuff for IHasBugs.searchTasks()?
[15:25] <abentley> losa, I can't figure out which machine runs "process-upload.py --builds" on staging, but whatever it is, I think it hasn't been updated to r10158.  Could you please investigate?
[15:27] <Chex> abentley: let me look for you
[15:29] <allenap> deryck, gmb, abel: Do you remember anything about @operation_removed_in_version stuff for IHasBugs.searchTasks()? I think (well, bzr ann says) that bdmurray was the last to touch the API declaration.
[15:29] <abentley> Chex, ty
[15:30] <deryck> allenap: yeah, I think he did that to add a couple params that weren't there before.
[15:32] <allenap> deryck: Yeah, it looks like there's a different set of defaults for the arguments in devel to 1.0 (no mention of beta). I can't see that it needs the operation_removed_in_version() declaration though, and wondered why its there. I haven't tried removing it, so maybe I should see if smokes comes out.
[15:32] <deryck> allenap: yeah, I would.  I'm sorry, but I don't recall the specifics.  He worked with leonard to get the format this is in now.
[15:33] <allenap> deryck: Okay, thanks.
[15:33] <gmb> allenap: What are the params being removed from?
[15:34] <gmb> removed.
[15:34] <gmb> Now here's an amusing thing, my IRC client is only sending *some* of what I'm typing.
[15:34] <allenap> gmb: The devel declaration it appears, though I'm not sure if the declarations group up or down.
[15:35]  * gmb looks
[15:37] <gmb> allenap: For the first time in my life, I dislike decorators.
[15:37] <gmb> I have NFI.
[15:37] <jml> ooh
[15:37] <jml> I know things about stuff
[15:37] <jml> esp decorators
[15:37] <allenap> gmb: Lol, cheers :)
[15:38]  * gmb sits back and waits for the wisdom to flow forth from jml
[15:38] <jml> what's the question?
[15:38] <allenap> jml: IHasBugs.searchTasks() has a whatimcalling compound declaration.
[15:39] <allenap> jml: So that devel and 1.0 have different arguments.
[15:39] <allenap> jml: But there's an @operation_removed_in_version("devel") declaration.
[15:40] <allenap> jml: However, the operation appears to be available still in devel.
[15:40] <allenap> jml: And I'm not sure what was meant to replace it.
[15:40] <allenap> We'll get lynched if we remove searchTasks.
[15:41] <bdmurray> Is there anyway to find the mp that added that?
[15:41] <gmb> bdmurray: Maybe.
[15:41] <abentley> bdmurray, sure.
[15:41] <gmb> (Ooh, forensics).
[15:41] <allenap> bdmurray: Hello :) I guess it was yours from the 18th August.
[15:41] <gmb> Damn, I was going to get all Grissom.
[15:41] <abentley> bdmurray, see bzr lp-find-proposal
[15:42] <bdmurray> allenap: hey, I don't recall specifically but if I looked at it I might remember better
[15:42] <jml> allenap: searchTasks gets re-exported with different params in devel
[15:42] <jml> allenap: above the "removed" line is an export line
[15:43] <jml> allenap: the order of decoration goes from bottom to top, and each decorator gets executed
[15:43] <bdmurray> this is starting to sound familiar ...
[15:43] <jml> allenap: so the "export_read_operation" just above the "def" is for the 1.0 version
[15:43] <allenap> jml: Ah, so when we export different declarations according to API version we need to remove it so that the next one can fit... getting vague, lights dimming...
[15:43] <jml> and the one just above the "operation_removed" is for the devel version
[15:44] <jml> it's sort of abusing the fact that decorators are actually executed in a particular order
[15:44] <jml> as in, it's using them imperatively rather than declaratively
[15:45] <jml> which is not _so_ bad I guess, but enough to make me start wondering if there's a better way.
[15:45] <allenap> jml: If I removed the operation_removed_in_version it'll either complain that it's already declared, or it'll stomp over the previous declaration?
[15:46] <allenap> Sorry, tenses all over the place.
[15:46] <jml> allenap: I don't know. I know how to find out though :)
[15:46] <allenap> Okay, I'm going to run some tests now :)
[15:46] <allenap> Smoke comes out.
[15:46] <allenap> How interesting.
[15:46] <bdmurray> this was for bug 320596
[15:47] <_mup_> Bug #320596: Series.searchTasks() always returns an empty collection <api> <lp-bugs> <qa-ok> <ubuntu-qa> <Launchpad itself:Fix Released by brian-murray> < https://launchpad.net/bugs/320596 >
[15:48] <brendand_> hello launchpadders
[15:48] <brendand_> can i please stop getting two emails for each bug status change. kthxbye
[15:50] <allenap> brendand_: Do you have an example bug?
[15:50] <allenap> bdmurray: Awesome, thanks for digging that up.
[15:51] <allenap> And thanks jml too.
[15:51] <brendand_> allenap - any bug
[15:51] <brendand_> allenap - it's because i'm a member of a mailing list
[15:51] <allenap> brendand_: Ah, yes :-/
[15:51] <brendand_> allenap - which gets set the bug mail
[15:51] <jml> allenap: my pleasure.
[15:52] <brendand_> allenap - i guess i could address it with a filter. but can't something be done in launchpad?
[15:54] <allenap> brendand_: I'm sure that something could be done, but my guess is that it's harder than it seems. The new Yellow Squad are currently working on bug subscription improvements. They might have something in mind.
[15:56] <jml> is there a bug filed about it?
[15:56] <allenap> gmb: As a yellow squaddie, can you help brendand_?
[15:57] <gmb> allenap, brendand_: Do either of you know if there's a bug filed about this problem?
[15:57] <gmb> (If not, I'll file one)
[15:57] <brendand_> gmb - i don't know
[15:57] <allenap> gmb: I don't know; my knowledge of bugs in Launchpad is the exact opposite of mpt's.
[15:57] <gmb> :D
[15:58]  * gmb goes to file a bug
[15:58] <brendand_> gmb - it is easily worked around once you know why it's happening, but i'm sure it happens to lot's of people
[15:59] <mpt> it appears to be bug 187346
[15:59] <_mup_> Bug #187346: Multiple duplicate bug mails received when both subscribed to an external list which is the contact for a team subscribed to a bug and subscribed to the bug in some other fashion <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/187346 >
[16:00] <gmb> \0/
[16:00] <maxb> Does anyone have any recommendations for how to start learning YUI3 ?
[16:01] <gmb> brendand_: Does bug 187346 accurately summarise your problem?
[16:01] <_mup_> Bug #187346: Multiple duplicate bug mails received when both subscribed to an external list which is the contact for a team subscribed to a bug and subscribed to the bug in some other fashion <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/187346 >
[16:02] <brendand_> mpt - not just bug mails
[16:02] <brendand_> mpt - even more annoyingly it's merge mails too
[16:02] <allenap> brendand_, gmb: Also bug 350390 is interesting because of its status.
[16:02] <_mup_> Bug #350390: Duplicate Messages Across System <email> <lp-registry> <mailing-lists> <oem-services> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/350390 >
[16:02] <brendand_> mpt - 'more annoyingly' because the message fields are exactly the same, so impossible to filter
[16:03] <mpt> Any time a team is subscribed to something, it's a symptom of a missing feature in Launchpad
[16:04] <jml> hah
[16:06] <abentley> Chex, how's it going?
[16:08] <Chex> abentley: ok, I found the branch, and its not on the correct revison, chekcing the restore process now
[16:09] <abentley> Chex, cool, thanks.
[16:10] <benji> ok, bac: you can review my review of https://code.launchpad.net/~wgrant/launchpad/trivial-soyuz-ui/+merge/47767 at your leisure
[16:10] <bac> rt
[16:21] <jcsackett> sinzui: might you have some time to mumble in a bit? i'm hitting something odd in the testcase for that question assertion bug. (which i can finally work on again).
[16:22] <LPCIBot> Yippie, build fixed!
[16:22] <LPCIBot> Project devel build (400): FIXED in 5 hr 2 min: https://hudson.wedontsleep.org/job/devel/400/
[16:22] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=688479,
[16:22] <LPCIBot> 708028] Dragged updateTranslation and its evil allies out of their
[16:22] <LPCIBot> holes and gave them to the sharks for breakfast.
[16:22] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=707478] bugs.freedesktop.org (Bugzilla 3.4.6)
[16:22] <LPCIBot> has decided to take notice of the columnlist parameter we pass over.
[16:22] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=665135] Don't OOPS when attempting to
[16:22] <LPCIBot> display an empty remote branch URL.
[16:22] <LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][ui=none][bug=669288,
[16:22] <LPCIBot> 683798] Delete SourcePackageRecipes when merging.
[16:25] <sinzui> jcsackett: in a few minutes
[16:25] <jcsackett> sinzui: thanks.
[16:47] <bac> benji: re CSS i was talking about the same section
[16:50] <benji> bac: ok, cool; I still don't understand why that constitues "CSS ... for global styles".  I will continue to seek enlightenment.
[16:51] <bac> benji: perhaps i wrote badly.  i was trying to say only put stuff in the CSS file if it is reusable
[16:52] <dpm_> hi deryck. It seems we've got a critical problem with translations, whereby upstream imports are overriding Launchpad transaltions unconditionally. I've been in touch with Danilo and Henning about this, but they are away today, and I'm not sure whether I should talk to your team or to the maintenance squads. May I just forward you the e-mail with the discussion and let you decide?
[16:52] <deryck> dpm_: sure, that works.
[16:52] <deryck> dpm_: is it fallout from the recent feature work?  i.e. something has changed and now causing issues?
[16:53] <benji> bac: ah, that makes more sense; perhaps I've been hit over the head with the inline-styles-will-kill-kittens stick too many times
[16:53] <bac> :)
[17:00] <jcsackett> sinzui: have a sec? i don't know that mumble is necessary.
[17:05] <dpm_> deryck, sorry for the delay, Evolution crashed on me. I've now put you on CC on the thread. Yes, it seems that this has to do with the new upstream imports in Ubuntu that came with the last LP rollout
[17:06] <jcsackett> sinzui: https://bugs.launchpad.net/launchpad/+bug/697294
[17:06] <_mup_> Bug #697294: AssertionError editing a question  <oops> <questions> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/697294 >
[17:06] <deryck> dpm_: ok, cool.  I'll look closely at the thread now.
[17:07] <dpm_> thanks a lot deryck. I can provide more info if it helps, but I'm not familiar with the LP code
[17:07] <deryck> dpm_: no worries.  I'm new to translations, too. :-)  But I'll see if I can at least get my head around the issue, and work out what we can do next.
[17:09] <dpm_> deryck, I appreciate that, I know you guys are doing an extra effort getting your way around parts of LP new to you now :-)
[17:12] <deryck> dpm_: ok, so let me see if I get the main points right....
[17:13] <dpm_> ok
[17:13] <deryck> dpm_: 1) we messed up huge here :-) because we're updating translations we shouldn't (i.e. we're not following the precedence rules we always have....
[17:14] <dpm_> yep
[17:14] <deryck> dpm_: 2) but the damage is done for now since you disabled imports.....
[17:14] <dpm_> yes
[17:14] <deryck> dpm_: 3) and we need to work out a) what happened and b) how quickly we can get this fixed.
[17:15] <dpm_> exactly, well summed up. At least that's my understanding. Henning or Danilo would perhaps be able to add more context, but that's how I understood it.
[17:15] <deryck> ok, cool.
[17:15] <deryck> so the problem is that we really don't have any domain expertise until Monday
[17:16] <deryck> and if we're not causing any more damage, I don't think we should call people at home now, unless you think it requires that kind of attention.
[17:16] <dpm_> no, I don't think it does
[17:17] <deryck> dpm_: ok, so I'll send email to my squad now, and make sure we're clear that this has to be looked into ASAP when everyone is working again Monday.  sound fair?
[17:18] <dpm_> Right now I just wanted to raise the issue, I assumed that even with domain expertise this is not something that can be fixed quickly
[17:18] <dpm_> deryck, that sounds good, thanks a lot
[17:18] <deryck> dpm_: np.  Sorry this got messed up so badly.
[17:19] <dpm_> no need to apologise, let's look at how to fix it next week :)
[17:25] <jml> gary_poster: hi
[17:25] <gary_poster> hey jml
[17:25] <jml> gary_poster: just letting you know that I have indeed received your email, and that I'll be looking at the LEP again as soon as I may. (Probably my Monday morning)
[17:26] <gary_poster> jml, awesome, thank you.  I'm hopeful that there won't be any surprises for you given out previous conversations, and am proceeding in that hope, so that timing is fine.
[17:26] <gary_poster> *our
[17:26] <jml> gary_poster: cool :)
[17:33] <jml> I wish subunit were one project per language
[17:35] <jelmer> I sometimes wish that too, but that's only because I'm not doing the release management / packaging :-)
[18:22] <jml> gah, emacs redraw bugs
[18:38] <deryck> bdmurray, hey.... I thought you were one of the main ones driving to disable subscriptions for ubuntu.  Am I completely recalling this wrong?
[18:42] <gmb> Have a good weekend folks.
[18:42]  * gmb -> exeunt, in pursuit of a Friday evening
[18:44]  * benji thought exeunt was plural; maybe gmb is a colonial organism.
[18:45] <bdmurray> deryck: No, you are right and have exposed me!
[18:46] <deryck> heh
[18:46] <deryck> bdmurray: ok, at least I'm not crazy then
[18:48] <bdmurray> deryck: nope not at all.
[18:49] <bdmurray> deryck: its complicated ;-)
[18:51] <deryck> bdmurray: invariably everything with Launchpad is, for some reason ;)
[18:52] <deryck> bdmurray: I won't call you out on list for the two-faced requester that you have become.  but I'll probably tell gary_poster this in secret.
[18:52] <gary_poster> deryck, bdmurray, lol
[18:53] <bdmurray> deryck: I think I wrote some of the code disabling it so it wouldn't be hard for somebody to out me
[18:53] <deryck> heh
[18:53] <gary_poster> so, bdmurray, you share deryck's social concern, but would really like the functionality for yourself?
[18:54] <gary_poster> IOW, as a clunky interface example, you would like to say that users *can* subscribe to distributions, but they get warned about it?  Or...you have to be a member of some team?
[18:55] <bdmurray> gary_poster: yes, that's a fair statement my concern is people doing something they didn't intend and getting hate mail about it.
[18:55] <gary_poster> got it, bdmurray.  yeah, hate mail is no fun.  OK, I'll add that to the LEP discussion too.  thank you
[18:56] <bdmurray> It'd be neat if you could see how many bugs would have met your criteria over the past 24 hours or a week
[18:56] <bdmurray> You could even just allow distro subscriptions via the API and I'd be happy
[18:57] <gary_poster> how many bugs: that would be neat, I agree.
[18:57] <gary_poster> distro subscriptions via API: ok
[19:13] <deryck> I need someone smarter than me about layers to weigh in on my proposed fix for Windmill LayerIsolationError issues.
[19:13] <deryck> maybe gary_poster or lifeless  (if around)? :-) ^^
[19:15] <gary_poster> deryck: oh meh.  :-) lifeless' layer knowledge is way more recent than mine, but I guess I'll give it a try.  I know you are EoD soon, but I'd like to wrap something up first.  10 min?
[19:15] <deryck> gary_poster: totally fine.  I don't EOD for another 2 hours.
[19:15] <gary_poster> oh ok cool
[19:16] <gary_poster> will ping soon then
[19:16] <deryck> gary_poster: ok, cool.  thanks!
[19:16] <gary_poster> np
[19:16] <lifeless> gary_poster: deryck: ?
[19:16] <gary_poster> +1 on lifeless answering your question, deryck ;-)
[19:16] <deryck> hi lifeless.  So I'm trying to fix the LayerIsolationError problems breaking the build....
[19:17] <lifeless> \o/
[19:17] <deryck> lifeless: the simpleness of this fix has me worried I missed something.  https://code.launchpad.net/~deryck/launchpad/kill-windmill-test-pain-ftw/+merge/47852
[19:17] <deryck> would value input from you
[19:17] <lifeless> uhoh, we're in trouble then :P
[19:17] <deryck> heh
[19:17] <lifeless> looking
[19:19] <lifeless> hmm
[19:19] <lifeless> so this assumes that None is the correct value
[19:19] <lifeless> what is actually making the change?
[19:20] <lifeless> ah
[19:20] <deryck> well the BaseLayer throws the error if it isn't None, i.e. we want it to be None when we're done.  Windmill messes with the timeout at various places.  Windmill itself, not our use of it.
[19:20] <lifeless> so our hardcoded check is for a timeout of None
[19:20] <deryck> right
[19:20] <lifeless> so setting it to None is indeed appropriate
[19:20] <lifeless> grah, someone needs to take that library out and shoot it; changing global state is Not Cool
[19:21] <deryck> yeah, and just as I was making peace with the monster
[19:21] <deryck> :-)
[19:21] <lifeless> an ideal fix would be to find and wrap all those places
[19:21] <lifeless> as we *may* still run into issues within the layer that uses it
[19:21] <deryck> I can fix Windmill itself, but I was wondering if this would get the build working again as a temp fix.
[19:21] <lifeless> but this certainly should address our symptoms
[19:22] <deryck> shall I XXX this line with a bug describing the badness of Windmill and then land it?
[19:22] <lifeless> deryck: +1
[19:22] <deryck> lifeless: cool, thanks!
[19:22] <lifeless> yes indeedy, and a bug somewhere for us to hammer on later; High pri IMO.
[19:27] <deryck> bug 709438
[19:27] <_mup_> Bug #709438: Windmill mucks about with socket default timeout and shouldn't <javascript> <windmill> <Launchpad itself:Triaged> < https://launchpad.net/bugs/709438 >
[19:27] <deryck> I can fix this next week.
[19:28] <deryck> I need to get a patch upstream for the 512k bug anyway
[19:48] <bdmurray> gary_poster: looking again I think bug supervisors can structurally subscribe to distro bugs if a bug supervisor is set
[19:50] <bdmurray> gary_poster: at least that is the way it was when I wrote it
[19:51] <gary_poster> bdmurray, oh?  I'm afraid I'm not even sure how bug supervisors fit into it
[19:53] <bdmurray> gary_poster: its only for distributions with bug supervisors set that structural subscriptions are restricted for and they are restricted to the members of the bug supervisor team
[19:54] <bdmurray> gary_poster: so there is no need to "re-allow" structural subscriptions on distributions
[19:55] <gary_poster> ah!  so you can already subscribe to distributions, so if we add filtering for that then that will allow you to use that again?
[19:55] <bdmurray> not again but yes
[19:56] <gary_poster> I thought you were not using that now, because it was too much?
[19:57] <bdmurray> Okay, yes *I* personally have not been subscribed to all ubuntu bugs for a long time now
[19:57] <gary_poster> :-)
[19:57] <gary_poster> ok
[19:57] <gary_poster> I think I got you, then.  thanks for clarifying
[19:58] <bdmurray> gary_poster: here is the mp https://code.launchpad.net/~brian-murray/launchpad/bug-556489-distro-struct-sub/+merge/31090
[19:58] <gary_poster> awesome, thanks
[19:59] <bdmurray> no problem
[20:20] <SpamapS> why oh why can't I delete my own comments on a bug? :-(
[20:28] <dobey> SpamapS: buyer's remorse? :)
[20:28] <SpamapS> wrong window :-/
[20:28] <SpamapS> at any given time of day I have between 5 and 20 bugs open in chrome
[20:28] <SpamapS> sometimes I mistake them for eachother..
[20:29] <SpamapS> I can only imagine how that lady with octuplets must feel :-P
[20:31] <dobey> heh, i wish i could delete others' comments sometimes. especially when they are mailer autoreplies
[20:31] <lifeless> so
[20:31] <lifeless> that would be nice
[20:31] <lifeless> before we make it cheaper
[20:31] <lifeless> I think we need stable indices (in progress), as well as some sort of defined rule for who can hide what, and who can unhide what.
[20:32] <lifeless> (and who can see whats hidden)
[20:32] <dobey> or a collapsable view that is collapsed by default except the most recent comment, or something
[20:33] <dobey> busy bugs can be pain to follow when you have to scroll 2000 pages to see the last comment :)
[20:33] <lifeless> that might be nice too
[20:33] <lifeless> I don't know if you know, but we don't show all comments by default
[20:33] <lifeless> we show first + last 80 or something
[20:34] <dobey> still too much, i think. even with only showing partial comments, because each comment can still be quite large, even if it's partial
[20:34] <lifeless> sure
[20:35] <lifeless> the End key is also helpful
[20:35] <dobey> but no i didn't really know that
[20:35] <dobey> yes, but browsers are slow.
[20:35] <lifeless> excellent, I think we squashed Distribution:EntryResource:searchTasks
[20:35] <dobey> especially on complex sites like launchpad
[20:36] <lifeless> Monday, time to drop a second off of the timeouts
[20:36] <lifeless> dobey: Launchpad is slow for many reasons :)
[20:37] <dobey> indeed
[20:49] <cr3> lifeless: I noticed a bug mentionned in a thread by poolie about a couple queries taking a long time, one for the count() and the other for the actual result set. have there been discussions to improve retrieving result sets so that they don't necessarily need to also return the count?
[20:50] <lifeless> yes
[20:51] <lifeless> I first raised this in July I think
[20:51] <cr3> lifeless: if these discussions are recorded somewhere, I'd be interested :)
[20:51] <lifeless> jtv made a good suggestion on a different dimension at the epic, to improve the efficiency of slicing
[20:51] <lifeless> cr3: the dev mailing list
[20:52] <cr3> lifeless: will have a look, I had ideas too about retrieving slice+1 items or somesuch, nothing terribly innovative but might provide a good bang for the buck
[20:52] <lifeless> cr3: so for nontrivial counts we should use query plan estimates - there is code in the tree
[20:52] <lifeless> cr3: for efficiency rather than offsets we should use limits
[20:53] <lifeless> e.g. instead of offset 100 limit 76, use id > 1234 LIMIT 76
[20:54] <cr3> lifeless: hm, that never occured to me but makes total sense!
[20:54] <deryck> Have a nice weekend everyone.
[21:09] <wgrant> sinzui: Morning.
[21:10] <sinzui> hi wgrant
[21:11] <wgrant> sinzui: The new nightly.sh is on loganberry, which means p-r-f won't run until you land your crontab change.
[21:11] <sinzui> yes
[21:11] <sinzui> I struggled with that.
[21:12] <sinzui> spm merged it about 18 hours ago, but did not push the branch. Chex helped with that
[21:12] <wgrant> Ahh, I asked him about that, but he didn't say he'd merged it.
[21:13] <sinzui> There was a lot of confusion when I asked Chex to merge it and we had a zero-length patch
[21:13] <wgrant> Heh.
[21:13] <lifeless> hi sinzui
[21:13] <sinzui> So the next step is to ensure crontabs are live
[21:13] <sinzui> hi lifeless
[21:14] <wgrant> sinzui: Apparently that is done before the branch is touched.
[21:14] <wgrant> That is, the crontabs become live *first*.
[21:14] <sinzui> ?
[21:15] <sinzui> So so I wait for hate mail form script-monitor to learn of the change is in production?
[21:15] <wgrant> sinzui: IIRC spm said that the change is made live first, then put into the branch.
[21:15] <wgrant> So we should have no hatemail.
[21:15] <wgrant> Which will be a pleasant change.
[21:17] <lifeless> laters
[21:21] <wgrant> sinzui: In https://code.launchpad.net/~wgrant/launchpad/trivial-soyuz-ui/+merge/47767 I hardcode 'https://launchpad.net/'... is there a good way to determine that from the config?
[21:25]  * sinzui thinks
[21:26] <wgrant> Hmm.
[21:26] <wgrant> It is really tempting to kick Windmill out again until deryck can get it to work.
[21:26] <wgrant> Because we're not leaving testfix until that happens.
[21:26] <wgrant> Any objections?
[21:27] <wgrant> It's a one-line change to reblacklist.
[21:29] <bigjools> jfdi
[21:29] <sinzui> wgrant: I think we want to use config.vhost.mainsite.hostname for the case I see in the merge
[21:30] <wgrant> sinzui: OK, I wondered if there was some way apart from digging directly in the config.
[21:30] <sinzui> wgrant: list a helper function?
[21:30] <sinzui> s/list/like/
[21:30] <wgrant> Yeah.
[21:35] <sinzui> We may have had some in the past, but not now. webapp.vhosts.allvhosts is used in some places. it is a specialised config
[21:41] <wgrant> sinzui: allvhosts.configs['mainsite'].rooturl looks relevant.
[21:41] <sinzui> indeed. I think that is what canonical_url uses
[22:35] <jcsackett> sinzui: are we doing standup today, given it's wgrant's saturday?
[22:39] <wgrant> I hope not.
[22:39] <jcsackett> wgrant, i think you're free. :-)