| === StevenK changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: StevenK | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === matsubara is now known as matsubara-afk | ||
| lifeless | sinzui: ping | 02:06 |
|---|---|---|
| LPCIBot | Project windmill build #91: FAILURE in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/91/ | 02:06 |
| lifeless | thats better, | 02:45 |
| lifeless | more closed bugs | 02:45 |
| lifeless | and one more hidden critical unearthed | 02:45 |
| * lifeless resists the urge to start at bug oldest and walk forward | 02:55 | |
| lifeless | wgrant: ping | 02:55 |
| lifeless | I'm pinging you cause curtis had better be asleep by now :) - where is Cve:+index - is jc still on it, or would it be ok if I pick it up? its our #2 frequency OOPS | 02:56 |
| wgrant | lifeless: He's still on it. | 02:56 |
| lifeless | kk | 02:56 |
| lifeless | wgrant: have you poked at +needs-packaging at all ? | 03:08 |
| lifeless | wgrant: I'm struggling to find top-10 timeouts that are not fixed-undeployed, bugtask:+index, or in-progress by someone | 03:08 |
| wgrant | lifeless: Not at all. | 03:10 |
| wgrant | You seem to love BugTask:+index | 03:11 |
| lifeless | wgrant: Not at all. | 03:11 |
| lifeless | wgrant: the next obvious thing is a paginated message display | 03:12 |
| lifeless | wgrant: which is to big for me: I get called away all over the place. | 03:12 |
| lifeless | wgrant: I mean, making a vertical page-reloading batchnav is easy. | 03:12 |
| lifeless | wgrant: making one that uses js to incrementally pull in new messages and actions and shows the comment form once you read to the bottom - a bit harder. | 03:13 |
| wgrant | Yeah. | 03:14 |
| lifeless | wgrant: so other than ratcheting scaling down a bit more, I'm not likely to really touch it for a bit | 03:15 |
| lifeless | dammit, I need to finish my analysis of deletable bugtasks etc | 03:15 |
| * lifeless adds a note to talk to jml about said | 03:15 | |
| lifeless | wgrant: (oh, and I'd be delighted for someone else to do the next iteration on bugtask:+index) | 03:16 |
| lifeless | wow | 03:18 |
| lifeless | 400ms overhead per page atm | 03:18 |
| lifeless | just doing traversal | 03:19 |
| lifeless | https://lp-oops.canonical.com/oops.py/?oopsid=1907C1055 | 03:19 |
| lifeless | probably a busy appserver contributing | 03:19 |
| mwhudson | i worry a bit sometimes about the minimum time launchpad can produce a page in | 03:27 |
| mwhudson | (i think it's quite a while, like 100ms) | 03:27 |
| mwhudson | maybe not that bad | 03:27 |
| lifeless | mwhudson: well, the page I'm looking at - 400ms minimum. | 03:28 |
| lifeless | mwhudson: trace the queries down to the session update after traversal | 03:28 |
| mwhudson | lifeless: erk | 03:29 |
| lifeless | we're still in phase one though - drive the 99th% percentile down by fixing poor scaling in pages | 03:29 |
| mwhudson | oh that's the server machine wgrant is always complaining about isn't it? | 03:30 |
| lifeless | mwhudson: well, its not the hardware. | 03:30 |
| wgrant | It's partly the hardware. | 03:30 |
| lifeless | mwhudson: its a 4-thread appserver with maybe 2-4 additional requests parsed and awaiting handoff | 03:30 |
| lifeless | wgrant: it really isn't :) | 03:30 |
| wgrant | lifeless: soybean has lots of them as well. | 03:30 |
| wgrant | But we see most of our timeouts from the old appservers. | 03:30 |
| mwhudson | lifeless: yeah, something smells off about that that's not entirely related to the code in lp:launchpad | 03:31 |
| lifeless | anyhow | 03:31 |
| lifeless | tonight is pounce on the sysadmins night | 03:31 |
| StevenK | Poor sysadmins | 03:31 |
| lifeless | (not nastily) | 03:31 |
| lifeless | just that tom is the guy working this progression | 03:32 |
| wallyworld_ | lifeless: if there's a bug with total crap in it (random text), do we just mark it as incomplete or do we need to get it deleted? | 03:34 |
| lifeless | invalid probably. | 03:36 |
| lifeless | whats the bug #? | 03:36 |
| lifeless | wallyworld_: ^ | 03:37 |
| wgrant | wallyworld_: Sorry, I meant to look at that earlier, but got sorta distracted :/ | 03:37 |
| wallyworld_ | 738023 | 03:37 |
| lifeless | lol - classic - http://programming-motherfucker.com/ | 03:38 |
| lifeless | wallyworld_: that seems to be outside the launchpad project? | 03:38 |
| wallyworld_ | yes | 03:39 |
| wallyworld_ | but it's an open lp question | 03:39 |
| lifeless | ah | 03:39 |
| wallyworld_ | so i thought i'd clean it up since it's clearly a crap bug | 03:39 |
| lifeless | so there is no spam in it | 03:39 |
| lifeless | incomplete leaves it open | 03:39 |
| lifeless | I would make it invalid | 03:40 |
| wallyworld_ | no. just crap | 03:40 |
| wallyworld_ | ok | 03:40 |
| wallyworld_ | thanks | 03:40 |
| cody-somerville | Why does the series filter on the main pages of PPAs have such huge text? lol | 03:47 |
| wgrant | Someone embedded a form inside a heading, and this was exposed in the recent style unifications. | 03:47 |
| lifeless | H1 is big | 03:48 |
| lifeless | I can has review https://code.launchpad.net/~lifeless/launchpad/bug-722794/+merge/54466 ? | 04:45 |
| StevenK | lifeless: Done, r=me | 04:51 |
| lifeless | thanks | 04:52 |
| lifeless | wgrant: wtf: https://lp-oops.canonical.com/oops.py/?oopsid=1907C2337 | 05:36 |
| lifeless | wgrant: I'm pinging you cause you added the transaction status to the timeline :) | 05:37 |
| wgrant | lifeless: Huh. | 05:40 |
| wgrant | But API timeouts normally work fine :/ | 05:40 |
| wgrant | Although leonardr did change them recently. | 05:41 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/730396 | 05:41 |
| _mup_ | Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 > | 05:41 |
| === jtv is now known as jtv-eat | ||
| === almaisan-away is now known as al-maisan | ||
| lifeless | what does BuildFarmJob.status <> 1 OR BuildFarmJob.date_finished IS NOT NULL imply | 05:54 |
| lifeless | not fullybuilt and finished ? | 05:54 |
| lifeless | the query I'm looking at also checks for FAILEDTOBUILD | 05:54 |
| lifeless | can I drop the BuildFarmJob.date_finished IS NOT NULL condition without breaking semantics ? | 05:54 |
| lifeless | thumper: https://bugs.launchpad.net/launchpad/+bug/730396/comments/9 | 06:03 |
| _mup_ | Bug #730396: DistroSeries:EntryResource:getBuildRecords timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/730396 > | 06:03 |
| wgrant | lifeless: That query is stupid, yes. For some of the cases you can drop the first BFJ <> AND date_finished IS NOT NULL check, yes. | 06:15 |
| wgrant | lifeless: But we need to keep date_finished IS NOT NULL if status == 1. | 06:15 |
| lifeless | sure | 06:18 |
| lifeless | so over here | 06:18 |
| lifeless | uhm | 06:18 |
| lifeless | if we don't gc builds | 06:18 |
| lifeless | there is no point reading all *FTBFS* rows every time | 06:18 |
| lifeless | full stop | 06:18 |
| StevenK | Hmmm, looks like I didn't kill dogfood | 06:18 |
| wgrant | lifeless: If we move to an incremental model, sure. | 06:19 |
| wgrant | lifeless: But then we'd need to read all recent successes too. | 06:19 |
| lifeless | wgrant: why? | 06:19 |
| wgrant | lifeless: Because we need to be able to remove failures that are no longer failures. | 06:20 |
| lifeless | wgrant: do they get removed from this collection? | 06:20 |
| wgrant | If we're not reading the whole failure collection, we need to read every other collection. | 06:20 |
| lifeless | wgrant: do they get removed from this collection? | 06:23 |
| wgrant | lifeless: Which collection? | 06:25 |
| lifeless | fbtfs | 06:25 |
| wgrant | lifeless: A retried build is not a new build. | 06:25 |
| wgrant | A retried build will disappear from this page. | 06:25 |
| wgrant | (unless it fails again) | 06:25 |
| lifeless | wgrant: so, we do gc | 06:25 |
| wgrant | Pardon? | 06:25 |
| lifeless | or are you asying we reuse the BFJ ? | 06:25 |
| wgrant | We reuse the BFJ. | 06:26 |
| * lifeless headdesks | 06:26 | |
| wgrant | Yes. | 06:26 |
| wgrant | Someone made this decision 6 years ago, and uh, yeah. | 06:26 |
| lifeless | anyhow | 06:26 |
| lifeless | I'd read all collections incrementally | 06:26 |
| lifeless | that seems cheap and effective as long as you don't shutdown for a month | 06:27 |
| lifeless | wgrant: what rev has leonards change for timeouts ? | 06:28 |
| wgrant | lifeless: It was a lazr.restful upgrade. | 06:28 |
| lifeless | meh, I'll raise a critical | 06:29 |
| wgrant | I'm pretty sure this worked after my changes, although it's clearly somewhat related. | 06:29 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | https://bugs.launchpad.net/launchpad/+bug/740750 | 06:33 |
| _mup_ | Bug #740750: API timeouts broken and returning no useful data... <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 > | 06:33 |
| poolie | big f* jools? | 07:05 |
| lifeless | poolie: ? | 07:11 |
| poolie | <wgrant> We reuse the BFJ. | 07:15 |
| wgrant | Heh' | 07:16 |
| lifeless | poolie: before his time | 07:16 |
| StevenK | poolie: Build Farm Job | 07:16 |
| poolie | https://bugs.launchpad.net/launchpad/+bug/740759 might amuse you | 07:17 |
| _mup_ | Bug #740759: creating bzrdir on launchpad is slow (BzrDirFormat.initialize_ex_1.16) <codehosting-ssh> <hpss> <lp-code> <performance> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740759 > | 07:17 |
| adeuring | good morning | 08:28 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === almaisan-away is now known as al-maisan | ||
| lifeless | stub: hi | 09:03 |
| lifeless | stub: how are you feeling? | 09:03 |
| stub | yo | 09:03 |
| stub | Better today... slept 13 hours straight last night. | 09:03 |
| === jtv-eat is now known as jtv | ||
| lifeless | stub: good timing - we tried your live index docs but got the patch number wrong: https://code.launchpad.net/~wgrant/launchpad/fix-patch-57/+merge/54481 is meant to fix it, but wanted to confirm: is the db patch *in the tree* meant to be a .1 patch, or a .0 with the same major as the one done live ? | 09:04 |
| wgrant | I think the numbers have to match./ | 09:04 |
| wgrant | Or it will be reapplied on the next db-deploy and then blow up. | 09:04 |
| wgrant | I think. | 09:04 |
| stub | db patch in the tree is supposed to be a 2208-xx-01 (or -02 etc.) patch. The number should match what you inserted into LaunchpadDatabaseRevision on production | 09:04 |
| poolie | hi | 09:05 |
| poolie | would i be right in expecting that the qastaging database will be generally faster than lpnet? | 09:05 |
| poolie | because of less load | 09:05 |
| wgrant | It's a much smaller DB server. | 09:05 |
| wgrant | And the cache will be colder. | 09:06 |
| stub | Why this works - Launchpad appservers check LaunchpadDatabaseRevision for patches that have been applied that are not in the local source tree, and for patches in the local source tree that have not been applied. It ignores all patches that are non-zero in the 'patch' field. | 09:06 |
| StevenK | So it's generally slower | 09:06 |
| poolie | hm | 09:06 |
| stub | lifeless, wgrant: So that patch seems correct, and matches what I see on the production db. Did the patch also get applied to launchpad_prod_2 and launchpad_prod_1 ? | 09:07 |
| lifeless | stub: yup | 09:08 |
| stub | So it worked out best with id in the first field of the index? | 09:08 |
| wgrant | stub: It was applied as -0 to all three. | 09:08 |
| lifeless | stub: it was a lopsided problem | 09:08 |
| stub | I don't see -0 in LaunchpadDatabaseRevision - I only see 57-1 | 09:08 |
| wgrant | stub: Right, we had to fix it when an appserver failed to start. | 09:08 |
| lifeless | stub: we tried a number of permutations on qastaging, and found that a partial index on the queues that are driven to 0 (the NEW and INCOMPLETE) performed very well | 09:08 |
| wgrant | lifeless: NEW and UNAPPROVED | 09:08 |
| stub | I thought the index would have worked better with id in the last field, as the ordering would have been done last, but I hadn't checked and wasn't sure. | 09:09 |
| wgrant | stub: As would I. I didn't follow lifeless' trials very closely, though. | 09:09 |
| lifeless | can't do id last | 09:09 |
| lifeless | not without a bunch of headaches | 09:09 |
| stub | interesting | 09:09 |
| lifeless | right now we use one query for both: | 09:10 |
| lifeless | - queue processing | 09:10 |
| lifeless | - historical data analsis | 09:10 |
| lifeless | pg won't use the indices we tried with id last, unless the full index sort was given | 09:10 |
| lifeless | archive desc distroseries desc setc | 09:10 |
| lifeless | it *will*, but not for status=0 [or 1 we are pretty sure] | 09:11 |
| lifeless | because its a lopsided data problem | 09:11 |
| lifeless | status | count | 09:11 |
| lifeless | --------+--------- | 09:11 |
| lifeless | 4 | 5777 | 09:11 |
| lifeless | 1 | 182 | 09:11 |
| lifeless | 2 | 47494 | 09:11 |
| lifeless | 3 | 2289831 | 09:11 |
| lifeless | 0 | 40961 | 09:11 |
| wgrant | Um what? | 09:12 |
| wgrant | That's about 41000 more with status 0 than I would expect. | 09:12 |
| lifeless | wgrant: indeed, but not enough to worry the index | 09:12 |
| wgrant | Enough to worry me, though... | 09:12 |
| lifeless | wgrant: sure, separate problem | 09:13 |
| bigjools | *blink* | 09:13 |
| wgrant | Similar on mawson. | 09:13 |
| wgrant | Hmm. | 09:13 |
| wgrant | 0 | 97 | 40877 | 09:14 |
| wgrant | Distroseries 97 | 09:14 |
| lifeless | stub: so the headaches are: we would have to either: split out a separate query for the historical data, if we changed the status 0 case to use archive desc distroseries desc status 0 desc id desc | 09:14 |
| wgrant | karmic | 09:14 |
| lifeless | (because the historical data /wants/ id as the first sort key - and pg does a decent job there today) | 09:15 |
| wgrant | Oh. | 09:15 |
| lifeless | or | 09:15 |
| wgrant | bigjools: Old archive rebuilds :( | 09:15 |
| lifeless | well, no or | 09:15 |
| stub | lifeless: Sure. I recall the query. I'm interested in you found it works best with the id in the sort key. I think we have similar cases elsewhere - bugs or bugtask I think. | 09:15 |
| lifeless | basically, there are two totally different use cases in the one table | 09:15 |
| lifeless | stub: only because its essentially a micro-table embedded in the bigger one | 09:16 |
| lifeless | stub: thats why adding a partial index gave good results - -very- fast results once applied [to that particular query] | 09:16 |
| bigjools | wgrant: grar | 09:17 |
| wgrant | bigjools: 2009ish | 09:17 |
| bigjools | let's clear those out | 09:17 |
| wgrant | So long-fixed. | 09:17 |
| wgrant | But yes. | 09:17 |
| lifeless | stub: its possible you can come up with something better | 09:17 |
| wgrant | Also, accepted is pretty big... probably newer copy archives. | 09:17 |
| wgrant | Indeed, the newer copy archives. | 09:18 |
| stub | lifeless: If you tried the partial index on (distroseries, archive, id) instead of (id, distroseries, archive), that would be all I'm interested in at the moment. | 09:19 |
| lifeless | stub: but the nice thing here was that the partial index was small - 1280 kB | 09:19 |
| stub | lifeless: I think in earlier versions of PG, the index would not have been used at all because the first field in the index was not used until the very end. | 09:20 |
| lifeless | stub: we didn't try that variation, no | 09:20 |
| bigjools | wgrant: we need a way of cleaning out copy archives entirely | 09:21 |
| wgrant | bigjools: Yes. | 09:21 |
| bigjools | wgrant: I want to make derived distros supersede them | 09:21 |
| lifeless | stub: Limit (cost=0.00..104.34 rows=31 width=36) (actual time=0.132..83.965 rows=1 loops=1) | 09:21 |
| lifeless | -> Index Scan Backward using packageupload__distroseries__status__archive__idx on packageupload (cost=0.00..5287.65 rows=1571 width=36) (actual time=0.131..83.961 rows=1 loops=1) | 09:21 |
| wgrant | bigjools: An interesting plan. | 09:21 |
| lifeless | Index Cond: (distroseries = 104) | 09:21 |
| lifeless | Filter: ((archive = ANY ('{1,534}'::integer[])) AND (status = 0)) | 09:21 |
| lifeless | Total runtime: 84.023 ms | 09:22 |
| lifeless | stub: ignore the index name, thats on qastaging where we were experimenting | 09:22 |
| bigjools | wgrant: they're essentially the same thing, but copy archives have a spethial UI | 09:22 |
| lifeless | stub: also - thats *cold* runtime | 09:22 |
| wgrant | bigjools: Indeed. | 09:22 |
| stub | lifeless: Right. So in PG 8.4, it might well be more efficient to put the field we are ordering on first, and the ordering and filtering done in one index scan. | 09:23 |
| lifeless | stub: at least sometimes, yeah | 09:23 |
| stub | Which is different to how we optimized stuff before elsewhere in the schema. Might be some room for improvement there. | 09:23 |
| bigjools | wgrant: OOPS-1907BUILDMASTER3 .... | 09:25 |
| stub | lifeless: Where the live rollout docs good enough for the losas to apply the patch without hiccups? | 09:25 |
| wgrant | bigjools: What about it? | 09:25 |
| lifeless | stub: yup, except we got the patch # wrong | 09:25 |
| wgrant | bigjools: It's annoying, but ordinary and harmless. | 09:26 |
| bigjools | wgrant: it should not be an oops | 09:26 |
| wgrant | bigjools: Sure. | 09:26 |
| bigjools | well, we could see if someone deleted the source | 09:27 |
| wgrant | Someone uploaded one to supersede it. | 09:27 |
| bigjools | or that | 09:27 |
| stub | lifeless: Right. Applying a -0 patch live would mean the appservers fail to restart, so wouldn't even be immediately noticeable. | 09:27 |
| bigjools | that oops happened 3 times | 09:27 |
| wgrant | bigjools: Different archs? | 09:27 |
| bigjools | ah might be | 09:28 |
| wgrant | Hm, no. | 09:28 |
| wgrant | Different series. | 09:28 |
| wgrant | https://launchpad.net/~kxstudio-team/+archive/ppa/+packages?field.name_filter=lv2core&field.status_filter=&field.series_filter= | 09:28 |
| lifeless | stub: we only caught it when we tested dropping the appserver name from the lpnet configs and found it broke | 09:28 |
| bigjools | ok | 09:28 |
| lifeless | stub: so the name in db-devel is meant to be -1 ? | 09:28 |
| stub | lifeless: Yes. | 09:28 |
| lifeless | cool | 09:29 |
| stub | lifeless: Anything non-zero in that field. A non-zero in the 'patch' field means ignore this on runtime checks - it is a minor patch and you shouldn't care if it has been applied or not. Matches our life updates usecase exactly, so yay for prescience. | 09:29 |
| lifeless | stub: kk | 09:30 |
| henninge | jtv: Hi! | 09:31 |
| jtv | hi henninge | 09:31 |
| henninge | jtv: Are your reviewing today? | 09:31 |
| jtv | henninge: oh, completely forgot about it. :( OTP now. | 09:31 |
| henninge | np | 09:32 |
| stub | lifeless: Hmm.... in fact, I can't see why -1+ patches can't land on launchpad/devel .... | 09:32 |
| henninge | danilos should be reviewing today, too. ;-) | 09:32 |
| lifeless | stub: that would be great | 09:32 |
| stub | Where does that rule get changed now? | 09:33 |
| lifeless | the pqm config | 09:33 |
| lifeless | its out of the tree | 09:33 |
| wgrant | Heh, the first time it's needed a change in almost three years, a month after I argued that it never needed changing... | 09:34 |
| stub | :-) | 09:34 |
| stub | I think we just need to block *-0.sql from landing on launchpad/devel now. No problems landing updates to the scripts, security.cfg or minor db patches. | 09:36 |
| wgrant | Right. | 09:36 |
| stub | Anyone see a problem with that rule? | 09:36 |
| wgrant | Nope. We should also drop the conflict check while we're there, since it doesn't work. | 09:36 |
| wgrant | And is pointless. | 09:36 |
| lifeless | fine with me | 09:36 |
| stub | wgrant: Do you want to file an RT explaining that conflict check thing, or do you want to explain the conflict check thing to me so I can file the RT ? | 09:38 |
| wgrant | stub: https://pastebin.canonical.com/45073/ is the current hook. | 09:39 |
| stub | MY EYES! | 09:40 |
| wgrant | stub: The second bit (bzr ls -0 [...]) is meant to check for conflicts, but doesn't actually work. I considered removing it when we migrated the check from the tree to PQM, since it seems pretty pointless, but decided to make as few changes as possible. | 09:40 |
| stub | So precommit_hook=[ -z "$(bzr status -S database/schema/ | grep '-0.sql$')" ] ?? | 09:43 |
| wgrant | stub: Don't need to protect fti.py or anything? | 09:44 |
| stub | wgrant: fti.py is 50/50 - adding a new index could futz things, changing an existing one will not (the column will exist, it just won't have the expected data in it) | 09:45 |
| wgrant | Sounds good, then. | 09:47 |
| wgrant | RT time. | 09:47 |
| stub | I guess we should block it - we likely won't change anything there anyway until we know where our search is heading. | 09:47 |
| wgrant | stub: Thanks for the review. | 09:47 |
| stub | precommit_hook=[ -z "$(bzr status -S database/schema/ | grep -e '\(-0\.sql\|/fti.py\)$')" ] | 09:55 |
| stub | is what I end up with | 09:55 |
| wgrant | Looks sensible, as long as it works. | 09:56 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: danilos | https://code.launchpad.net/launchpad-project/+activereviews | ||
| henninge | danilos! ;) | 10:55 |
| danilos | henninge, :) | 10:55 |
| danilos | henninge, I don't know what you've been talking about ;) | 10:55 |
| henninge | danilos: I do, though! Can I please have a review? | 10:55 |
| danilos | henninge, sure thing | 10:56 |
| henninge | danilos: diff is only 1075 lines | 10:56 |
| henninge | https://code.launchpad.net/~henninge/launchpad/devel-605924-hastranslationtemplates/+merge/54470 | 10:56 |
| danilos | henninge, ha-ha-ha | 10:56 |
| danilos | henninge, ok, I'll take it | 10:56 |
| henninge | danilos: thanks | 10:56 |
| === al-maisan is now known as almaisan-away | ||
| danilos | henninge, btw, just looking through proposal text, "shortlist" is especially recommended when you expect something to return a short list | 10:58 |
| danilos | henninge, because then it catches bugs early | 10:58 |
| henninge | danilos: oh, i thought it was about cutting a list off. | 10:58 |
| danilos | henninge, no, it throws an OOPS/exception when hard limit is broken | 10:59 |
| henninge | ah | 10:59 |
| henninge | so using shortlist is saying "tell me if this ever gets longer than X" | 10:59 |
| henninge | danilos: thanks, I did not know that. I am happy to put it back in, then. | 11:00 |
| danilos | henninge, yeah, it's a developer tool :) | 11:00 |
| danilos | henninge, I don't know in what context did you drop it, so it all depends on that, but just clarifying what shortlist is about | 11:00 |
| LPCIBot | Project windmill build #92: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/92/ | 11:01 |
| deryck | Morning, folks. | 11:03 |
| danilos | henninge, good job clearing the inter-dependency between template count and uses-translations | 11:05 |
| henninge | yeah, that was strange to see | 11:06 |
| danilos | henninge, not yours, but line 226 of the diff: "hidding" | 11:16 |
| === jtv1 is now known as jtv | ||
| danilos | henninge, in TranslationTemplatesCollection, I am surprised target_pillar is not used anywhere, but since it's apparently not, good cleanup there as well :) | 11:29 |
| henninge | danilos: yes, that was only used to access translation_usage in getCurrentTranslationTemplates | 11:30 |
| danilos | henninge, also, instead of listifying stuff in tests, I suggest you use assertContentEqual instead | 11:31 |
| danilos | henninge, unless where you want to compare the order as well | 11:32 |
| danilos | henninge, fwiw, this is probably irrelevant comment when you get shortlist back :) | 11:32 |
| danilos | henninge, also, I'd rather see test_has_obsolete_translation_templates as 3 separate tests | 11:33 |
| danilos | henninge, or 4 | 11:33 |
| danilos | henninge, and also, you probably inserted list() on diff line 116 because you removed the shortlist as well, so that can probably go (and if you decided not to re-insert shortlist, this is where you should use it) | 11:36 |
| danilos | henninge, r=me | 11:38 |
| henninge | danilos: yup, that's just because of shortlist. | 11:38 |
| henninge | danilos: thanks | 11:38 |
| danilos | henninge, up to you to decide if you want shortlist back or not, not a big deal either way | 11:39 |
| henninge | danilos: I felt the same about test_translation_templates but I played along with what the rest of the file was doing. | 11:39 |
| henninge | I may just split up the other tests, too. | 11:39 |
| danilos | henninge, right, we did write tests that way in the past | 11:40 |
| henninge | danilos: And I was always the one saying "one assert per test"! | 11:40 |
| danilos | henninge, that'd be great, but if it gets complex, it might mean a new branch | 11:40 |
| * bigjools waves at danilos | 11:40 | |
| henninge | I'll have a look | 11:40 |
| danilos | henninge, heh, well, that is tricky because we sometimes use asserts to make sure input data is right | 11:40 |
| danilos | bigjools, hi there | 11:41 |
| henninge | danilos: ok, that is only a guideline. | 11:41 |
| henninge | ;-) | 11:41 |
| danilos | bigjools, I hope you just look forward to hearing my lovely voice :) | 11:41 |
| bigjools | danilos: are you reviewing? I have a short branch | 11:41 |
| danilos | bigjools, yeah, I do (but I am disappointed ;) | 11:41 |
| danilos | bigjools, pass it on, just done with henninge's | 11:41 |
| bigjools | danilos: I miss your booming presence on the TL calls :) | 11:41 |
| danilos | henninge, yep, cheers | 11:41 |
| danilos | bigjools, ok, now I feel better, thanks :) | 11:42 |
| bigjools | danilos: https://code.launchpad.net/~julian-edwards/launchpad/localdiff-sync-bug-739525/+merge/54496 | 11:42 |
| danilos | bigjools, branch sounds like a nice feature, but you've got a single lint issue so please fix it (I understand it may not be from your changes :) | 11:44 |
| danilos | looking at the code now | 11:44 |
| bigjools | :/ | 11:45 |
| LPCIBot | Project windmill build #93: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill/93/ | 11:45 |
| bigjools | it was my lint | 11:45 |
| danilos | bigjools, I am sad to see a message like "The following sources *would have been* synced if..." go from the real UI | 11:48 |
| bigjools | :) | 11:50 |
| wgrant | bigjools: Have you worked out how permissions are going to work? | 11:50 |
| bigjools | no | 11:50 |
| wgrant | Heh | 11:50 |
| danilos | bigjools, r=me, but I'd also remove the "XXX" from a comment about a thing you are not really going to fix unless it proves to be broken | 11:50 |
| bigjools | ok | 11:50 |
| bigjools | thanks danilos | 11:50 |
| bigjools | wgrant: right now it's launchpad.edit on the series | 11:51 |
| wgrant | bigjools: launchpad.Edit and launchpad.Append (since you need Append to run syncSources) | 11:52 |
| bigjools | right | 11:52 |
| bigjools | this will all fall out in the wash when we start doing intensive testing | 11:52 |
| wgrant | Yeah. | 11:52 |
| wgrant | And then we realise we need queues. | 11:52 |
| bigjools | which Steve is doing tomorrow :) | 11:53 |
| wgrant | And then you have an excuse to fix copying. | 11:53 |
| bigjools | queues would be nice | 11:53 |
| bigjools | I might have to badger flacoste and jml about that | 11:53 |
| jml | mushroom! mushroom! | 11:53 |
| bigjools | snaaaaaaaake | 11:53 |
| === matsubara-afk is now known as matsubara | ||
| === almaisan-away is now known as al-maisan | ||
| sinzui | jcsackett: I Untriaged bug 740225. The former rosetta team need to explain if this was inteded and why or if it is a regression. The behaviour is correct for Ubuntu so it appears to be by design | 13:29 |
| _mup_ | Bug #740225: The differences between New and Translated for upstreams was removed <rosetta-imports> <upstream-translations-sharing> <Launchpad itself:New> < https://launchpad.net/bugs/740225 > | 13:29 |
| stub | Are lp-propose-merge bugs bzr bugs or something else? | 13:36 |
| jcsackett | sinzui: understood. | 13:39 |
| jcsackett | sinzui: do you remember the issue you helped oem with regarding filing bugs in IE? | 13:42 |
| jcsackett | i believe it was an issue with an error popping up on the summary field? i've got an open question about it, and was wondering if there was a bug filed. i can't find one. | 13:43 |
| sinzui | jcsackett: The JS to populate the matches and enable the continue actions does not work in IE. It is impossible to report a bug since the user is forced to use the guided process | 13:44 |
| sinzui | jcsackett: The bug is filed and has many dupes. tag: javascript, text ie or ie8 or ie7 | 13:45 |
| jcsackett | ah right, tags! | 13:45 |
| * jcsackett never remembers tags when bug searching. | 13:45 | |
| sinzui | first match | 13:46 |
| sinzui | I always use tags but I hate the default ANY, I am not sure I have ever used ANY in a search | 13:46 |
| === mrevell is now known as mrevell-lunch | ||
| abentley | adeuring1: bzr+ssh://bazaar.launchpad.net/~abentley/launchpad/js-translation | 14:02 |
| abentley | adeuring1: https://code.launchpad.net/~abentley/launchpad/js-translation/+merge/54067 | 14:03 |
| henninge | deryck: I'll restart | 14:06 |
| abentley | adeuring1: do you want to chat in mumble about the template changes? | 14:10 |
| adeuring1 | abentley: no yet, let me first read a bit more | 14:10 |
| abentley | adeuring1: okay, ping me whenever. | 14:10 |
| leonardr | danilos, would you take a look at https://code.launchpad.net/~leonardr/lazr.restful/integrate-strict-versioning/+merge/54530 ? | 14:15 |
| adeuring1 | abentley: so your idea is to always render both variants of "X is configured/not configured" and to make the "wrong" variant invisible via CSS, right? | 14:16 |
| abentley | adeuring1: right. | 14:16 |
| adeuring1 | ok, so no need to mess with the menu:overview stuff, i think | 14:16 |
| adeuring1 | abentley: ^^^ | 14:16 |
| abentley | adeuring1: Actually, we probably do. | 14:18 |
| adeuring1 | abentley: why? | 14:18 |
| danilos | leonardr, after lunch, sorry | 14:18 |
| abentley | adeuring1: The icon is supposed to vary between "plus" and "edit". | 14:18 |
| adeuring1 | abentley: ah, right | 14:18 |
| abentley | adeuring1: Depending on whether there's already a value. | 14:18 |
| abentley | adeuring1: But that state is frozen when the template is rendered. | 14:19 |
| adeuring1 | right | 14:19 |
| abentley | adeuring1: So either we get two plusses or we get two edits. | 14:19 |
| adeuring1 | yeah | 14:19 |
| jam | dear codehosting devs, why is my +junk branch trying to stack on /~sathishmanohar/junk/main | 14:19 |
| jam | lp:~jameinel/+junk/one-rev-1 | 14:20 |
| jam | ah, stupid me, doing '/junk/" without the + | 14:20 |
| abentley | jam, right. | 14:20 |
| jam | I only noticed because it fails on qastaging because 'junk' doesn't exist | 14:20 |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: danilos, abentley | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === mrevell-lunch is now known as mrevell | ||
| jcsackett | danilos or abentley: could i request a review of https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/54408? | 14:26 |
| jam | any way to bulk upload attachments? I have 6 attachments I want to add to a bug, and it is a pain to do them one-by-one | 14:27 |
| benji | jam: not that I know of; I wonder if a little launchpadlib script would be helpful, but it will take longer to write than just doing the uploads | 14:31 |
| abentley | jcsackett: sure. | 14:37 |
| abentley | jcsackett: You say "the branch partially relies on a branch that exposes Question on the webservice". This sounds like a prerequisite branch to me. | 14:38 |
| abentley | jcsackett: Do you know about prerequisite branches? | 14:39 |
| LPCIBot | Project windmill build #94: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/94/ | 14:52 |
| jml | abentley: I learnt a thing about the job system today. It uses Python imports as a registry. | 14:58 |
| abentley | jml: that doesn't parse. | 14:59 |
| jml | abentley: as in, it very strongly encourages job sources to be defined as classes that have all of their state on the class so that it can then load these classes using import/module-lookup/getattr-fu in other processes. | 15:00 |
| abentley | jml: this is true. | 15:01 |
| jml | abentley: so in this regard, it's using Python's namespace/import system as a registry of job sources. sort of. | 15:02 |
| jml | abentley: I bumped into this because I thought having an instance job source would make testing easier, so I gave it a try. | 15:03 |
| abentley | jml: Seems like a stretch to me, unless you think that most python functionality uses imports (by which you mean packages/modules?) as a registry. | 15:03 |
| jml | abentley: well, maybe it is a stretch. it's just that I can imagine alternative implementations that make as much sense as importing that are more obviously registry-like | 15:04 |
| abentley | jml: In which case, it doesn't seem worth mentioning. | 15:04 |
| jml | e.g. pickling the job source to a known directory and passing the filename through to the child process | 15:04 |
| jml | or having a config file that maps names to ways of acquiring job source objects. | 15:05 |
| abentley | jml: we actually do have a config that maps names to job source classes. | 15:06 |
| jml | abentley: class names in Python modules? | 15:07 |
| abentley | jml: No, when we use cronscripts/run_jobs.py, we pass in a config name, which includes the job source as one of its variables. | 15:09 |
| abentley | jml: e.g. packaging_translations | 15:10 |
| jml | abentley: hmm. that's a more flexible than the TwistedJobRunner. Still assumes a particular mechanism for acquiring the IJobSource object though (it has to be a member of a module, available on import). | 15:13 |
| abentley | jml: I don't think it's more flexible. I can easily imagine using it with the TwistedJobRunner. | 15:14 |
| jml | abentley: you'd have to change TwistedJobRunner first, surely | 15:14 |
| abentley | jml: what would I need to change? | 15:14 |
| jml | abentley: the bit where it figures out the import name based on job_source.__name__ | 15:15 |
| abentley | jml: why? | 15:15 |
| jml | abentley: to use a non-class object as a job source | 15:15 |
| abentley | jml: I expect an interface to correspond to a class. Don't you? | 15:16 |
| jml | abentley: Yes, but that's not what I mean. | 15:16 |
| jcsackett | abentley: sorry i missed your comment earlier. i know about prereq branches, but the the prereq branch had other stuff that messed up the diff, as i only brought over the webservice bits. | 15:17 |
| jml | abentley: the TwistedJobRunner theoretically expects a job source object that provides ITwistedJobSource. The implementation demands that it is a class that classProvides ITwistedJobSource. | 15:18 |
| abentley | jml: From an interface, we get a class, from the class, we get job_source.__name__, what's the issue? | 15:18 |
| abentley | jml: still not following why I'd need to change TwistedJobRunner to make it work with run_jobs. | 15:19 |
| jml | oh right. | 15:19 |
| jml | abentley: run_jobs takes an arbitrary name to import, TwistedJobRunner infers the name from the passed in job source object (which has to be a class) | 15:20 |
| LPCIBot | Project devel build #569: FAILURE in 4 hr 52 min: https://lpci.wedontsleep.org/job/devel/569/ | 15:20 |
| abentley | jml: right, but these conditions are met for all of our job sources, so I don't need to address that in order to use TwistedJobRunner. | 15:23 |
| jml | job_source = somethingThatMakesAJobSource(); runner = TwistedJobRunner(job_source, ...); ... will explode unless job_source has a __module__ and __name__ and can be reconstructed by importing "%s.%s" % (job_source.__module__, job_source.__name__) | 15:23 |
| sinzui | jcsackett: set ~jcsackett/launchpad/questions-on-webservice as a dependency of https://code.launchpad.net/~jcsackett/launchpad/set-question-message-visibility/+merge/54408 | 15:23 |
| jcsackett | sinzui: ok. | 15:23 |
| jml | abentley: of course. I was trying something different and discovered these conditions. | 15:24 |
| adeuring1 | abentley: I think there is a more fundamental problem with the approach to hide the "wrong" <li> entries via CSS: If no packaging link is set, we can't generate the links "set source branch", "enable translations", "enable auto sync" at all: We don't know which target to use... | 15:25 |
| jcsackett | sinzui: is there a way to do that without redoing the proposal? | 15:26 |
| abentley | adeuring1: I've already addressed that for the branch link. | 15:26 |
| abentley | jcsackett: You resubmit the proposal. | 15:26 |
| adeuring1 | let me look... | 15:26 |
| abentley | adeuring1: It creates an empty link. | 15:26 |
| adeuring1 | abentley: ah, right! | 15:26 |
| sinzui | jcsackett: you may hate me. We should not export Question.priority. It is unused | 15:27 |
| adeuring1 | abentley: regarding the icons: I think we always have the pencil icon. So I think we don't have to tinker with the menu: stuff | 15:28 |
| jcsackett | sinzui: that's an easy fix. no need for hate. :-) | 15:28 |
| abentley | adeuring1: that's nice, but it's inconsistent with how we're handling branches. | 15:29 |
| abentley | deryck: adeuring1 reports that productseries always has an edit icon, never an add icon, unlike branches. Should we make them consistent? | 15:30 |
| deryck | abentley: I would think consistency would be better, yes. | 15:34 |
| leonardr | benji, i'd like to go over lp:~leonardr/launchpad/explicit-versions with you, both to do review and to bring you up to speed on my changes | 15:34 |
| abentley | jcsackett: If you base your branch on the other branch, it's much clearer what came from what. Why did you only bring over the webservice bits from the other branch? | 15:35 |
| jcsackett | abentley: prereq was based on devel, this is db-devel. didn't want all the changes coming across before pqm brought them over automatically. | 15:36 |
| LPCIBot | Project windmill build #95: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill/95/ | 15:36 |
| benji | leonardr: sure; I'm deep in something at the moment; how about after lunch (1 ish) | 15:36 |
| abentley | deryck: Do you want to change branch so it only uses edit, or productseries so it uses add and edit? | 15:36 |
| jcsackett | abentley: in retrospect, questions-on-webservice probably should have just been based on db-devel as well. | 15:36 |
| leonardr | o | 15:37 |
| leonardr | k | 15:37 |
| deryck | abentley: can productseries be none intially? (I assume so) | 15:37 |
| deryck | abentley: if so, that should behave like branch then. | 15:38 |
| abentley | deryck: Yes, and this is the most important case. | 15:38 |
| deryck | abentley: yes, so it should get an add icon to start with, I think. | 15:38 |
| abentley | adeuring1: ^^ could you do this as part of your work, please? | 15:38 |
| adeuring1 | deryck. abentley: yes. | 15:39 |
| abentley | adeuring1: thanks. | 15:39 |
| danilos | leonardr, looks good, r=me | 15:42 |
| leonardr | great | 15:42 |
| abentley | jcsackett: I wouldn't worry overmuch about applying the changes before PQM brings them across automatically. You might get a criss-cross merge, but --lca or --weave merge should handle it fine. | 15:43 |
| jcsackett | abentley: dig. | 15:43 |
| === al-maisan is now known as almaisan-away | ||
| jcsackett | if you like, i can merge the prereq completely in before you review. | 15:43 |
| jcsackett | abentley ^ | 15:44 |
| abentley | jcsackett: I don't think I need that. It just stuck out as weird, and I didn't want to start reviewing until I understood what was going on. | 15:45 |
| jcsackett | abentley: got it. sorry for the oddities.:-) | 15:46 |
| === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews | ||
| abentley | jcsackett: For your tests, did you consider using WebServiceTestCase? | 15:53 |
| jcsackett | abentley: i did not. i am not aware of WebServiceTestCase | 15:53 |
| abentley | jcsackett: It allows you to test your code using launchpadlib. | 15:54 |
| abentley | jcsackett: So you're testing something closer to what users will actually use, and it's closer to native code, too. | 15:55 |
| sinzui | jcsackett: I had a few notes about the branch too. I added them to the MP | 15:56 |
| === deryck is now known as deryck[lunch] | ||
| jcsackett | abentley: seems worth looking at then. :-) | 15:58 |
| jcsackett | there are a lot of tests i've seen that could benefit from that. | 15:59 |
| abentley | jcsackett: it's similar to what you're doing in TestSetCommentVisibility, only generic. | 15:59 |
| sinzui | jcsackett: wgrant. allhands should know about your participation in the 2011 campaign now. | 15:59 |
| abentley | jcsackett: Why are you testing the XHTML? This seems like your are testing the webservice implementation, not your exports. | 16:01 |
| jcsackett | abentley: it looks like even the "clean" diff i pasted in has some noise--if you're looking at TestQuestionRepresentation, that's from the other branch. sorry. | 16:04 |
| abentley | jcsackett: yes, I was. | 16:05 |
| jcsackett | i'm not sure why that made it into the diff i generated. | 16:05 |
| sinzui | abentley: jcsackett: this testing point relates to my experience with anon users and representations. The simple doctests for the representation easily documents what anon users can see | 16:05 |
| sinzui | jcsackett: and about my anon + IQuestionMessage remark on the Mp, may be we do not want them public, see bug 740208 | 16:06 |
| abentley | jcsackett: Was there a preimplementation discussion? | 16:10 |
| jcsackett | yes, sinzui and i have talked a lot about how to go about this. | 16:10 |
| * jcsackett sees he skipped that bit in the proposal. | 16:11 | |
| abentley | jcsackett: 1 out of 1 abentleys recommend lp-propose for all your merge-proposing needs. | 16:12 |
| stub | abentley: Are lp-propose bugs bzr bugs or some other package? | 16:13 |
| abentley | stub: bzr, I would say. | 16:13 |
| jcsackett | abentley: i have actually used lp-propose before, and while it opens a local editor and then pushes the whole thing to lp, it doesn't do so from a template. is there a config step i missed for that? | 16:14 |
| abentley | jcsackett: You may be missing the lpreview-body plugin. | 16:14 |
| jcsackett | i am indeed. | 16:15 |
| abentley | jcsackett: try apt-get install bzr-lpreview-body | 16:17 |
| jcsackett | i have it now. i'll see if alls well on the next branch. | 16:19 |
| abentley | jcsackett: cool. | 16:20 |
| === fjlacoste is now known as flacoste | ||
| benji | leonardr: ready when you are | 17:07 |
| leonardr | benji, let's go | 17:08 |
| leonardr | have you read the mp? | 17:08 |
| benji | looking at it now | 17:09 |
| === beuno is now known as beuno-lunch | ||
| benji | leonardr: ok, the MP makes sense | 17:12 |
| leonardr | benji: and you understand the basic require_explicit_versions rule, right? | 17:13 |
| benji | leonardr: yep, I believe so (its intent if not yet its implementation) | 17:13 |
| leonardr | ok, take a look at apihelpers.py to see how i hack into the implementation | 17:14 |
| benji | why did you have to add all the patch_entry_explicit_version calls in _schema_circular_imports? Is it really circular imports or something else? | 17:14 |
| leonardr | benji: it's something else, but it's the same kind of 'patch everything' logic | 17:16 |
| leonardr | i'm ok with moving it though the imports would be a pain | 17:16 |
| benji | just I wonder if making a new module and copying over all the imports and then running that through the linter to show unused imports would work well enough to make it worth it | 17:17 |
| benji | would those ideally be in the same file where the interface is defined? | 17:18 |
| leonardr | benji: yeah, but if you're going to go through that much trouble it approaches the amount of work necessary to just stop using it | 17:20 |
| benji | that makes sense; I'm cool on leaving them where they are. I might try the move-and-lint trick if I get 15 minutes. | 17:21 |
| === deryck[lunch] is now known as deryck | ||
| bigjools | night folks | 17:56 |
| === beuno-lunch is now known as beuno | ||
| abentley | deryck: chat? | 18:32 |
| deryck | abentley: I can't sorry. Sorry. Having to pull double duty now, since wife just came home sick. Kids need moderate supervision. | 18:47 |
| abentley | deryck: okay. Will want to chat tormorrow about branch picker and vocabulary context. | 18:48 |
| === Ursinha is now known as Ursinha-lunch | ||
| deryck | abentley: sure. we can do it first thing tomorrow. | 18:50 |
| sinzui | jcsackett: mumble? | 19:01 |
| jcsackett | sinzui: oh, it is 3. one sec. | 19:01 |
| jcsackett | abentley: my earlier mp is updated, both with new diff and comments. | 19:02 |
| abentley | jcsackett: cool. I'll have a look. | 19:03 |
| sinzui | jcsackett: http://pastebin.ubuntu.com/584448/ | 19:16 |
| jcsackett | abentley: ws_object is now used in the test, and your question about endInteraction was answered. | 19:46 |
| LPCIBot | Project devel build #570: STILL FAILING in 4 hr 53 min: https://lpci.wedontsleep.org/job/devel/570/ | 20:14 |
| === Ursinha-lunch is now known as Ursinha | ||
| lifeless | gary_poster: hi | 20:18 |
| lifeless | gary_poster: I noticed this - https://bugs.launchpad.net/launchpad/+bug/741234 - by chance when looking at a timeout | 20:18 |
| gary_poster | lifeless hi | 20:18 |
| lifeless | gary_poster: I don't know if you want to pick it up or not, I may well be misremembering which squad changed the visibility rules | 20:19 |
| _mup_ | Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment <Launchpad itself:Triaged> < https://launchpad.net/bugs/741234 > | 20:19 |
| lifeless | [I probably am misremembering] | 20:19 |
| gary_poster | lifeless, I don't *think* we touched that...it certainly doesn't ring any bells | 20:19 |
| lifeless | gary_poster: de nada :) | 20:19 |
| gary_poster | :-) | 20:19 |
| jml | lifeless: Red squad will be doing disclosure/visibility once one of the current squads finishes up | 20:20 |
| lifeless | jml: cool | 20:22 |
| lifeless | jml: this was missed during a change in the last few months which is why I mentioned it | 20:22 |
| lifeless | anyhow | 20:22 |
| lifeless | -> dentist | 20:22 |
| jml | \o/ | 20:22 |
| sinzui | jcsackett: how goes CVEs? | 20:32 |
| jml | https://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598 – fix for an intermittent failure (I think) | 20:32 |
| jml | wgrant: ^^ | 20:33 |
| jcsackett | sinzui: i got derailed by a hardware issue, but i think what we chatted about is showing promise. | 20:37 |
| jcsackett | i'm having to fight my desire to do something about the nested chain that is the various nomination-rows &c. | 20:38 |
| sinzui | jcsackett: are you working with BugLinksListingView ? | 20:38 |
| sinzui | I see the pairing of the view to the template is broken. That view ensures can_view_bug is available to avoid security checks, but the template ignores it in two cases. I think that view should also use the trick I showed you to change the security checker on the object so subsequent checks are fast | 20:40 |
| jcsackett | sinzui: how can you tell it is broken? i recall odd behavior when i was looking at this last which that might explain. | 20:44 |
| jcsackett | though i just have the recollection of said behavior, and can't recall exactly what it was. | 20:44 |
| * jcsackett needs to take better notes. | 20:44 | |
| sinzui | jcsackett: view build a dict of bug info to show. It recovered from an Unauthorized error and adds 'can_view_bug': False. The template does not need to call required:launchpad.View on the bug! | 20:45 |
| sinzui | jcsackett: I am sure the adaption to +bugtasks-and-nominations-table also calls permission checks. Since the view has done the work, we want a fast permission checker on the good ones. We can update the cve-index.pt template to always use can_view_bug | 20:50 |
| jcsackett | sinzui: dig. | 20:52 |
| sinzui | jcsackett: I can send you a diff of the changes actually, so you can have an adventure with milestones | 20:54 |
| === almaisan-away is now known as al-maisan | ||
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| jcsackett | sinzui: i'm not sure that's what i would call "adventuring" :-P | 20:57 |
| === al-maisan is now known as almaisan-away | ||
| wallyworld_ | leonardr: mumble? | 21:02 |
| jml | g'night all. | 21:05 |
| leonardr | wallyworld, 1 minute, sorry | 21:09 |
| wallyworld_ | np | 21:10 |
| leonardr | wallyworld, i can hear you | 21:11 |
| leonardr | wallyworld, go ahead and give me your status, i'll try to figure it out | 21:11 |
| lifeless | sinzui: jcsackett: are you talking bug security checks? | 21:11 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | sinzui: jcsackett: if so there is no need for that now, our searches inject the rules. | 21:11 |
| leonardr | wallyworld: sorry, still not working | 21:13 |
| lifeless | jml: I wrote the fixture you asked for | 21:13 |
| sinzui | lifeless: okay good to know. We could reimplement the oddness in the view | 21:14 |
| lifeless | sinzui: what symptoms are you seeing ? | 21:16 |
| sinzui | No symptoms. The does very odd things to build a dict of bugs, and the template ignores the work the view did hald the time. We have bool in the dict, which must be faster than adaption | 21:18 |
| lifeless | sinzui: any bug task gotten via IBugTaskSet.searchTasks will not trigger security lookups; bugs gotten via other methods that do not indirect to searchTasks should be updated to do so | 21:18 |
| lifeless | sinzui: ok | 21:18 |
| jml | lifeless: yeah, I saw, thanks. | 21:29 |
| leonardr | wallyworld_: take a look at lazr.restful.interfaces.IWebBrowserOriginatingRequest | 21:33 |
| leonardr | launchpad defines an adapter from WebServiceLayer (ie. a web service request) to IWebBrowserOriginatingRequest, in webapp/configure.zcml | 21:33 |
| leonardr | in _resource.py, applyChanges, lazr.restful casts the current request to IWebBrowserOriginatingRequest | 21:39 |
| leonardr | if the result is None (because the application never defined an adapter), one thing happens | 21:39 |
| leonardr | if it's not none (because this is launchpad), another thing happens | 21:39 |
| wgrant | jml: ! | 21:58 |
| wallyworld_ | leonardr: thanks! | 21:59 |
| leonardr | np | 21:59 |
| rockstar | huwshimi, hi | 22:02 |
| huwshimi | rockstar: Hey | 22:02 |
| rockstar | huwshimi, what particularly about YUI are you struggling with? | 22:03 |
| huwshimi | rockstar: Oh, nothing in particular (I've just replied to your email). | 22:04 |
| rockstar | huwshimi, yeah, I saw it. | 22:04 |
| huwshimi | rockstar: I just don't like the way it does certain things, but I can get over that and use it anyway | 22:04 |
| rockstar | huwshimi, most of the concerns I've seen from people about YUI (and javascript in general) are because there's something idiomatic that they don't understand. | 22:05 |
| rockstar | huwshimi, what particularly do you not like though? | 22:05 |
| rockstar | (It's quite possible that we are doing it wrong it YUI, and I'd like to help fix it if need be) | 22:05 |
| huwshimi | rockstar: I'm not sure exactly. I need to spend some more time with YUI3 to really be able to help you out with that | 22:08 |
| sinzui | wgrant: I think you should block about the private bug as 404 change. Many users are confused by this. They think Lp is broken (making bad links) | 22:44 |
| sinzui | wgrant: s/block/blog/ | 22:44 |
| cody-somerville | In that case why is it 404 instead of 403? | 22:48 |
| wgrant | cody-somerville: We are moving to deny the existence of private objects, because it is much simpler. :/ | 22:49 |
| wgrant | Private bugs are just about impossible to do sensibly. | 22:49 |
| wgrant | Without 404ing. | 22:49 |
| wgrant | (because of the redirects) | 22:49 |
| sinzui | wgrant: actually, I think switching to NotFound is a bug. We cannot make links that will 404. We need to ensure that the user has permission to see the link we are making | 22:49 |
| sinzui | wgrant: and yes, because of redirects this can be near impossible | 22:50 |
| wgrant | sinzui: We don't make links, AFAIK. | 22:50 |
| wgrant | Hmm. | 22:50 |
| cody-somerville | what redirects? | 22:50 |
| wgrant | Except perhaps if the bug is referenced in text. | 22:50 |
| wgrant | cody-somerville: /bugs/1 -> /ubuntu/+bug/1 | 22:50 |
| _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 | 22:50 |
| _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 | 22:50 |
| wgrant | cody-somerville: /otherproject/+bug/1 -> /ubuntu/+bug/1 | 22:50 |
| _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 | 22:50 |
| _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 | 22:50 |
| poolie | good thing that line is truncated :) | 22:50 |
| sinzui | wgrant: bug https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/739380 certainly does link to a private bug. I am sure it shows up in the 404 reports | 22:52 |
| _mup_ | Bug #739380: update-manager crashed with AuthorizationFailed in _run(): org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name': ':1.129'}): org.debian.apt.update-cache <apport-crash> <i386> <natty> <running-unity> <update-manager (Ubuntu):New> < https://launchpad.net/bugs/739380 > | 22:52 |
| sinzui | wgrant: I think this is another case where the is a right way to do something, but it is more fun to creaft your own links and play with interpolation | 22:53 |
| sinzui | sorry about the spelling. I am a wreck. I should end my day | 22:54 |
| lifeless | sinzui: we don't create links to hidden bugs though | 22:54 |
| cody-somerville | why not just handle this the same way as oh, I dunno... most other websites? :P lol. Sorry to be facetious but LP can't be the first website trying to solve these kinds of problems, can it? :P | 22:55 |
| lifeless | sinzui: (because we filter all hidden bug objects so they don't show up in miletones, search results etc) | 22:55 |
| sinzui | lifeless: But we do https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/739380 | 22:55 |
| _mup_ | Bug #739380: update-manager crashed with AuthorizationFailed in _run(): org.freedesktop.PolicyKit.Error.Failed: ('system-bus-name', {'name': ':1.129'}): org.debian.apt.update-cache <apport-crash> <i386> <natty> <running-unity> <update-manager (Ubuntu):New> < https://launchpad.net/bugs/739380 > | 22:55 |
| lifeless | cody-somerville: this is how other websites handle it | 22:55 |
| sinzui | lifeless: look above the comment box | 22:55 |
| lifeless | the 'Remember, this bug report is a duplicate of bug #710026. ' ? | 22:55 |
| lifeless | sinzui: so, this is related to the disclosure work - remember how you were saying that we shouldn't permit adding tasks outside of visibility zones | 22:56 |
| lifeless | sinzui: same thing - when something is duped on a private bug we need to take disclosure into account | 22:56 |
| wgrant | lifeless: I thought the duplicate warning avoided linking. Maybe only some of them do. | 22:56 |
| sinzui | lifeless: I think this relates to an even older rule I have when reviewing code. Do not craft a link that you are not will to write a test for to verify it behaves like the canonical link code. | 22:57 |
| lifeless | sinzui: sounds plausible to me | 22:58 |
| lifeless | interestingly | 22:58 |
| lifeless | sinzui: I can see that private bug | 22:58 |
| sinzui | your special | 22:58 |
| lifeless | I'm not an admin | 22:58 |
| wgrant | Any more, at least. | 22:58 |
| lifeless | sigh, rub it in :) | 22:59 |
| sinzui | I am just one of the proles. | 22:59 |
| lifeless | I'm in ubuntu-bugcontrol | 22:59 |
| wgrant | If it's apport, your MOTU membership will let you see it. | 22:59 |
| lifeless | wgrant: ah | 22:59 |
| lifeless | k | 22:59 |
| wgrant | Indeed, it is apport. | 22:59 |
| lifeless | sinzui: so you see a link there | 22:59 |
| lifeless | sinzui: and you can't see the master bug | 22:59 |
| lifeless | wgrant: looks to me like apport should have unprivated this | 23:00 |
| sinzui | I see "Remember, this bug report is a duplicate of bug #710026. Comment here only if you think the duplicate status is wrong." | 23:00 |
| lifeless | sinzui: and that is linkified ? | 23:00 |
| sinzui | yes | 23:00 |
| wgrant | lifeless: Indeed, nothing private there. | 23:01 |
| lifeless | wgrant: worth filing a bug about this? | 23:02 |
| wgrant | lifeless: Not sure. | 23:03 |
| sinzui | I think this instance I see is bug. Isn't the reason the oops reports have a NotFound section is to encourage us to not do stupid thinks to frustrate users. | 23:06 |
| lifeless | sinzui: indeed, we shouldn't generate links that break | 23:07 |
| lifeless | we need to teach the linkifier code to rewrite bug references too | 23:07 |
| lifeless | e,g. https://bugs.l.n./foo/+bugs/NNN -> check visibility and don't link otherwise. | 23:08 |
| sinzui | The message I see is wrong. Since the bug is private and I cannot see it, I cannot say I think the duplication was a mistake. I have to know to locate a bug contact for the zero-vector bug I cannot see and ask for it to be make pulic of be subscribed | 23:08 |
| lifeless | which also implies a batch scan-and-check for efficiency | 23:08 |
| sinzui | That is an daunting task for most users | 23:08 |
| lifeless | sinzui: I totally agree. I filed a couple of bugs about usability here earlier this week | 23:08 |
| lifeless | sinzui: let me dig them up | 23:08 |
| sinzui | oh, yes I do realised that my grievance is goes back to when we issued a 403. Users are just more confused since bugs privacy is volatile, unlike team privacy. | 23:10 |
| === salgado is now known as salgado-afk | ||
| lifeless | thumper: bug 740750 - I think I mailed you. | 23:11 |
| _mup_ | Bug #740750: API timeouts broken and returning no useful data... <regression> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 > | 23:11 |
| lifeless | bug 334130 | 23:16 |
| _mup_ | Bug #334130: misbehaviour in marking duplicates of a private bug <lp-bugs> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/334130 > | 23:16 |
| lifeless | bug 434733 | 23:16 |
| _mup_ | Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <confusing-ui> <disclosure> <lp-bugs> <privacy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 > | 23:16 |
| lifeless | I can't find the one I thought I filed | 23:16 |
| lifeless | bug 157899 | 23:17 |
| poolie | lifeless, oh just one more thing | 23:17 |
| _mup_ | Bug #157899: Shouldn't need access to private bug report to reverse a public duplicate marking <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/157899 > | 23:17 |
| lifeless | bug 136570 | 23:17 |
| _mup_ | Bug #136570: Can't unsubscribe from duplicates if dupe is private <duplicate-subscribing> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136570 > | 23:17 |
| poolie | i see people adding new apis for admin use etc | 23:17 |
| lifeless | poolie: yes? | 23:20 |
| poolie | it seems like it's kind of half-baked without a cli | 23:21 |
| poolie | i don't want to hold things hostage but i was wondering if people could add things to lptools for admin use | 23:21 |
| poolie | it shouldn't be much more incremental work | 23:21 |
| lifeless | poolie: I don't think they should | 23:21 |
| poolie | or, at least, to file a bugtask against lptools | 23:21 |
| lifeless | poolie: following reasons: | 23:21 |
| lifeless | - these apis are not productised; we don't want to have to care about them in the stable api, and lptools is a productised project | 23:22 |
| lifeless | - the api client for them should be the web ui, not a cli | 23:22 |
| poolie | oh | 23:23 |
| lifeless | I think its fine if a dev things lptools is the best place to do it, but its not where I would encourage them to go with these apis | 23:23 |
| poolie | are these meant to be internal-use things for ajax only? | 23:23 |
| poolie | i misunderstood | 23:23 |
| lifeless | poolie: we have /one/ api, it serves both launchpadlib (python) and a yui launchpad object that all the web ui ajax uses | 23:24 |
| lifeless | so theres no clear separation, for right or wrong | 23:24 |
| poolie | what does "not productised" mean in this context? | 23:24 |
| lifeless | we don't care about API churn | 23:25 |
| lifeless | we'll change them willynilly as needed | 23:25 |
| poolie | what is the intended client for them? ajax? | 23:27 |
| lifeless | I don't know | 23:28 |
| lifeless | the syadmin request is a button in the ui | 23:28 |
| lifeless | but the work is being done in spare timeslots | 23:28 |
| poolie | ok | 23:29 |
| poolie | i was confused because the bug seemed to say "please add an api" | 23:29 |
| poolie | i'll add lptools bugtasks | 23:29 |
| lifeless | the bug was added to reflect the unit of work, for tracking qa | 23:29 |
| lifeless | poolie: if the api is in devel, which I htink it is, you may not want lptools using it | 23:30 |
| lifeless | poolie: because lptools is a packaged product | 23:30 |
| lifeless | I wouldn't want bugs filed on lp if we change this api | 23:30 |
| poolie | ok | 23:30 |
| poolie | better to have the function than not at all though | 23:30 |
| lifeless | poolie: this doesn't seem like a thing that will broadly interest lptools users; I'm confused by your interest in it | 23:31 |
| poolie | anyhow | 23:31 |
| poolie | i had the misapprehension that people were adding an api so that other people could write ad hoc scripts to call it | 23:31 |
| poolie | and in that case i would rather those scripts went into lptools | 23:31 |
| sinzui | lifeless: one of those bugs may be a duplicate of a bug I reported 5 months ago. I would need to see a TB to be certain. Maybe Gary's team will fix the defect before they declare bug subscriptions ready. | 23:31 |
| lifeless | they may be; even if that is the case, why is it appropriate for lptools ? | 23:31 |
| poolie | it's more the general pattern than the specific case | 23:31 |
| poolie | sorry i've got to go get a haircut, biab | 23:32 |
| lifeless | poolie: I'm worried about the problem we have with edge and bzr happening here. Talk to you later about it. | 23:32 |
| lifeless | wgrant: https://bugs.launchpad.net/launchpad/+bug/434733/comments/4 | 23:37 |
| _mup_ | Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <confusing-ui> <disclosure> <lp-bugs> <privacy> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 > | 23:37 |
| lifeless | wgrant: it happens a lot, I think we need to talk to pitti | 23:37 |
| lifeless | do we still send mail to all duplicates when a master bug is altered, even if the master is privte? | 23:53 |
| wgrant | lifeless: I'm pretty sure not. | 23:53 |
| wgrant | Since only direct subscriptions function for private bugs. | 23:54 |
| lifeless | hmm, then I think I can close one of those bugs off completely | 23:55 |
| wgrant | Oh? | 23:55 |
| wgrant | Which? | 23:55 |
| lifeless | bug 136570 | 23:55 |
| _mup_ | Bug #136570: bug mail explaining cause of message has an inaccessible link when the the master is private and the subscription is is via duplicates <duplicate-subscribing> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/136570 > | 23:55 |
| lifeless | don't need to unsubscribe if you don't get mail | 23:56 |
| lifeless | bug 589878 looks nice, I was thinking of a branch of yours recently I'd love the bug subscribers to all be able to see | 23:57 |
| _mup_ | Bug #589878: bzr branches should be private by default if linked to a private bug <lp-code> <privacy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/589878 > | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!