| thumper | ok | 00:00 |
|---|---|---|
| thumper | sort_order is only for iteration | 00:00 |
| thumper | and comparison | 00:00 |
| thumper | inside the enum code itself | 00:00 |
| thumper | used primarily for ordering the enum values inside drop down lists et al | 00:00 |
| thumper | nothing to do with the db queries | 00:00 |
| thumper | or the db_value | 00:01 |
| lifeless | right | 00:01 |
| lifeless | so I think the thing to do then is to change from mid 30's for the INCOMPLETE_WITH_RESPONSE and INCOMPLETE_WITHOUT_RESPONSE | 00:01 |
| lifeless | and insert them adjacent to the existing INCOMPLETE value | 00:02 |
| thumper | ah... sure | 00:02 |
| lifeless | thumper: is the default sort order numeric ? | 00:15 |
| * thumper tries to recall | 00:16 | |
| * thumper looks at the code | 00:16 | |
| thumper | lifeless: the enum item has a sortkey value that is numeric | 00:17 |
| thumper | the sort_order is used to recreate the sortkey values | 00:17 |
| lifeless | so if its absent its numeric | 00:17 |
| lifeless | cool | 00:17 |
| lifeless | hmm | 00:23 |
| poolie_ | hi | 00:27 |
| wallyworld | lifeless: i have a test which calls DocTestMatches. It fails if "matchee" is unicode but passes if I encode to utf-8 as in: self.assertThat(markups[1].encode('utf-8'), DocTestMatches(expected_item_1, self.doctest_opts)) | 00:29 |
| wallyworld | lifeless: the error is | 00:29 |
| wallyworld | File "/var/launchpad/tmp/eggs/testtools-0.9.10-py2.6.egg/testtools/matchers.py", line 169, in _with_nl | 00:29 |
| wallyworld | result = str(actual) | 00:29 |
| wallyworld | UnicodeEncodeError: 'ascii' codec can't encode character u'\u2026' in position 2121: ordinal not in range(128) | 00:29 |
| wallyworld | lifeless: should DocTestMatches be fixed? is it broken? ie should str(actual) be replaced with actual.encode('utf-8')? | 00:30 |
| wallyworld | lifeless: this is an existing test that broke when a change to made to what was rendered on a page. it was not previously being passed a unicode string | 00:31 |
| lifeless | wallyworld: I don't remember if its a doctest limitation or a shallow bug in testtools | 00:31 |
| lifeless | it seems reasonable to me that we'd support self.assertThat(u'fo', DocTestMatches(u'bar')) | 00:32 |
| wallyworld | lifeless: ok. for now i can amend the test with the .encode() and file a testtools bug or look up and existing one and include a XXX in the test? | 00:32 |
| lifeless | certainly file a test tools bug | 00:34 |
| wallyworld | will do | 00:34 |
| lifeless | encoding to utf8 is a tolerable workaround, though it will break if someone runs the lp test suite on a cp* or shift-jis system [but it wouldn't be the only thing to break that] | 00:35 |
| wallyworld | unless there's another workaround i can use? | 00:35 |
| lifeless | you could fix the bug :) | 00:35 |
| wallyworld | lifeless: sure. but i want to get my branch landed without the blockage caused by having to land a testtools update | 00:37 |
| wallyworld | or i guess i could do them together | 00:37 |
| lifeless | In terms of fixing it, I think something like: | 00:38 |
| lifeless | if type(foo) is unicode: | 00:38 |
| lifeless | ... | 00:38 |
| lifeless | else: | 00:38 |
| lifeless | foo = str(foo) | 00:38 |
| lifeless | ... | 00:38 |
| lifeless | [that is, special case handling of foo] | 00:38 |
| lifeless | it won't be entirely correct unless you also handle both sides being conditionally unicode | 00:38 |
| wallyworld | yes | 00:39 |
| wallyworld | i wish my unicode foo was better | 00:39 |
| lifeless | Its not you, its python. | 00:40 |
| wgrant | Python, and all of the people who refuse to use UTF-8. | 00:40 |
| wgrant | wallyworld: I think we need to disable the YUI tests :( | 00:40 |
| wallyworld | wgrant: i saw another failure :-( | 00:40 |
| wgrant | Yeah. | 00:41 |
| wallyworld | well it was worth a try | 00:41 |
| wgrant | Definitely. | 00:41 |
| wgrant | it was a useful test. | 00:41 |
| wallyworld | we need to look at perhaps another harness to run them besides windmill | 00:42 |
| wgrant | wallyworld: YUITestLayer? | 00:45 |
| wallyworld | wgrant: i think so | 00:45 |
| wgrant | WTF | 00:50 |
| wgrant | Unity just went insane. | 00:50 |
| lifeless | ‽just ? | 00:50 |
| wgrant | It all worked fine, except that any window that you clicked on disappeared. | 00:50 |
| wgrant | Then reappeared when I clicked again. | 00:50 |
| wallyworld | KDE is rock solid :-P | 00:51 |
| lifeless | but you loose 30K pixels. Thats got to hurt. | 00:52 |
| huwshimi | wallyworld: That's irrelevant. So is Gnome, XFCE etc. | 00:52 |
| wallyworld | huwshimi: i was just stirring | 00:53 |
| wgrant | https://code.launchpad.net/~wgrant/launchpad/disable-yuitestlayer/+merge/58058 | 01:08 |
| wgrant | Bug #763604 sounds like a browser bug... | 01:09 |
| _mup_ | Bug #763604: Cannot remove attachment when reporting new bug <Launchpad itself:New> < https://launchpad.net/bugs/763604 > | 01:09 |
| wgrant | Isn' | 01:09 |
| wgrant | t most of the point of that widget to not be manipulatable except by the user? | 01:10 |
| poolie_ | lifeless: https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/764086 is a slightly interesting example of your task unification thing | 01:12 |
| _mup_ | Bug #764086: dchroot.conf parser uses deprecated key "location" <schroot (Ubuntu):New> < https://launchpad.net/bugs/764086 > | 01:12 |
| poolie_ | like many bugs it's already fixed in natty but we really want to say, to start with, 'please fix it in lucid-updates' | 01:13 |
| poolie_ | and there are two ambiguous ways to do it: nominate for lucid, or target the main task to lucid-updates | 01:13 |
| lifeless | indeed | 01:23 |
| lifeless | so this is something I think a clueful user would reasonably file directly on lucid | 01:23 |
| poolie_ | i agree it is something they would want to file directly on lucid | 01:28 |
| poolie_ | can you do that in lp today? | 01:29 |
| wgrant | No. | 01:30 |
| dobey | a script could nominate for release and target milestone to lucid-updates, but you can't do it on the web | 01:35 |
| dobey | i guess | 01:35 |
| lifeless | interestingly | 01:41 |
| lifeless | apport tags bugs as | 01:41 |
| lifeless | natty | 01:41 |
| lifeless | etc | 01:41 |
| lifeless | the nomination stuff is intended to stop incorrect bugtasks | 01:41 |
| lifeless | more precisely | 01:42 |
| lifeless | on a frozen series | 01:42 |
| lifeless | developers opt in to having tasks | 01:42 |
| lifeless | and non-priviliged folk can suggest where a task should be using nominations | 01:42 |
| lifeless | there is an unresolved tension between 'bug exists' and 'task to work on the bug' | 01:42 |
| poolie_ | what's the semantic difference between nominating for lucid, and targeting to lucid-updates? | 01:43 |
| lifeless | theres a few | 01:43 |
| lifeless | firstly you can't target to lucid-updates, that isn't a series. | 01:44 |
| lifeless | you can target to lucid, if you have access | 01:44 |
| lifeless | nominating to lucid would write a proposal that it should be targeted against lucid | 01:44 |
| poolie_ | there is a milestone called 'lucid-updates' and you can target it | 01:44 |
| lifeless | ah | 01:44 |
| lifeless | so 'target' and milestone are different again | 01:44 |
| poolie_ | the milestone ui says 'target to milestone' :) | 01:45 |
| lifeless | right | 01:45 |
| lifeless | 'bug tasks' have a 'target' field | 01:45 |
| lifeless | which is the IBugTarget that the bug is for | 01:45 |
| lifeless | bah | 01:45 |
| lifeless | bugtask is for | 01:45 |
| poolie_ | so, in your proposed change | 01:45 |
| lifeless | which can be a product/productseries/distro/distrosourcepackagename/distroseries/distroseriessourcepackagename | 01:45 |
| poolie_ | the default bugtask target would be the current development series, natty | 01:46 |
| dobey | what i find really annoying, is that it is impossible to remove a bugtask from a bug | 01:46 |
| poolie_ | and then it would be obviously silly to have a natty series milestone called lucid-updates | 01:46 |
| lifeless | dobey: yes, we're going to do something about that. | 01:46 |
| dobey | you can only change the project/package | 01:46 |
| dobey | cool | 01:46 |
| lifeless | dobey: one proposed thing is to hide 'Invalid' status tasks, unless *all* the tasks are invalid. | 01:47 |
| lifeless | dobey: what do you think of that? | 01:47 |
| poolie_ | ! | 01:47 |
| poolie_ | seems like that would make it hard to undo some changes | 01:47 |
| lifeless | poolie_: it might; its a discussion point at the moment | 01:47 |
| dobey | lifeless: it's not so much the web ui that bugs me, so much that i continue to get unneccesary e-mail | 01:47 |
| lifeless | dobey: there is a separate bug I filed about that :) | 01:48 |
| lifeless | poolie_: so the common case is one task per bug | 01:49 |
| dobey | i would really like to be able to remove a bugtask; but shouldn't be able to if there's only one task on a bug | 01:49 |
| lifeless | poolie_: in that case, the task would just show as invalid | 01:49 |
| lifeless | poolie_: not show up by default in searches (thats the current behaviour anyway) | 01:49 |
| lifeless | poolie_: in there are two tasks, and one is invalid and one is (say) wontfix. | 01:49 |
| poolie_ | yeah, i can imagine | 01:50 |
| poolie_ | the case i was thinking of is, suppose it's affecting 'bzr (Ubuntu)' and 'bzr' | 01:50 |
| poolie_ | and a cosmic-ray commenter changes 'bzr' to invalid | 01:50 |
| poolie_ | i suppose you would just click 'also affects project' again | 01:50 |
| lifeless | you would fix this by saying 'also affects' | 01:50 |
| lifeless | yup | 01:50 |
| poolie_ | would that resurrect the existing task? | 01:50 |
| lifeless | something equivalent to | 01:51 |
| poolie_ | i would like the dates to remain accurate | 01:51 |
| poolie_ | such as they are | 01:51 |
| poolie_ | rather than actually deleting it | 01:51 |
| lifeless | open question is whether the dates etc /should/ be preserved or not | 01:51 |
| poolie_ | mm | 01:51 |
| lifeless | note that this question applies whether we reuse invalid to hide, or have a new 'deleted' status. | 01:51 |
| poolie_ | anyhow, i can see how it would be a tidy implementation | 01:51 |
| poolie_ | right | 01:51 |
| dobey | but only allow driver/owner/maintainer/whatever to remove tasks, and not arbitrary users | 01:51 |
| poolie_ | right, the job of arbitrary users is to _add_ more task lines :) | 01:52 |
| lifeless | the only time that this question doesn't apply is if we actually delete things - which presupposes that we've concluded the dates not mattering, and that the error rate on deletes would be low enough to not need an undo facility. | 01:52 |
| poolie_ | a la http://pad.lv/410407 | 01:52 |
| poolie_ | hm | 01:53 |
| poolie_ | i think of .status as being something like a member variable of the task | 01:53 |
| poolie_ | it's pretty much presented that way in the ui and api | 01:54 |
| poolie_ | whereas deleting a task, such that you'll need to create a new one later, is more like a method | 01:54 |
| lifeless | thats a display issue | 01:55 |
| lifeless | we could: | 01:55 |
| lifeless | (agurably a display issue) | 01:55 |
| lifeless | we could: | 01:55 |
| lifeless | - show a button to delete | 01:55 |
| lifeless | - hide invalid except when there is only one task | 01:55 |
| poolie_ | i think it would be weird if, over the api | 01:58 |
| poolie_ | bt.status=invalid;bt.lp_save(); bt.status=confirmed | 01:58 |
| poolie_ | did not work | 01:58 |
| lifeless | I agree | 01:59 |
| lifeless | I see no reason it wouldn't | 01:59 |
| lifeless | what is weird is that bt.lp_delete(); bt.status=confirmed;bt.lp_save() would work. | 01:59 |
| lifeless | if we chose to expose it as a semantic delete. | 01:59 |
| poolie_ | why not just delete it? | 01:59 |
| lifeless | destructive delete is harder to undo | 02:00 |
| lifeless | and users make lots of mistakes | 02:00 |
| poolie_ | both true | 02:02 |
| lifeless | that combined with a 300GB database is a pretty powerful trifecta | 02:03 |
| lifeless | wgrant: https://launchpad.net/ubuntu/+bugtarget-portlet-tags-content (Distribution:+bugtarget-portlet-tags-content) | 02:04 |
| lifeless | OOPS-1933A810, OOPS-1933J816 | 02:04 |
| lifeless | bah | 02:04 |
| dobey | if delete was restricted to privileged users though, would they really make that many mistakes? | 02:04 |
| lifeless | fail font in chromium, I read that as JB for a second | 02:04 |
| wgrant | dobey: Hahahah | 02:04 |
| lifeless | dobey: privilege correlates to experience not accuracy ;) | 02:04 |
| dobey | could preserve the history before the delete. | 02:05 |
| lifeless | thats what this proposal does. | 02:05 |
| dobey | lifeless: heck, i'd be happy if it was only available via API even. :) | 02:05 |
| poolie_ | well, marking the object 'deleted' or whatever is a classic way to all it to be undone | 02:05 |
| poolie_ | i guess you could start by even just hiding invalid tasks from the bug page, or not sending mail about them | 02:05 |
| poolie_ | in fact the second case is interesting | 02:06 |
| poolie_ | bug is marked invalid, then a person replies to say 'no it really is valid' | 02:06 |
| poolie_ | hm, or they change the existing task to point at the project with the invalid task | 02:06 |
| wgrant | Past proposals have suggested that invalid tasks get bugmail when no tasks are valid. | 02:06 |
| poolie_ | and otherwise it's the job of whoever is getting the bugmail to make decisions about it? | 02:07 |
| dobey | problem is, i don't want the bugmail :) | 02:09 |
| wgrant | poolie_: Right. | 02:10 |
| wgrant | poolie_: Just like if the task was retargetted. | 02:10 |
| wgrant | Retargeted meaning having its target changed, not being targeted to a series, or targeted to a milestone. | 02:10 |
| wgrant | lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1933A108 | 02:11 |
| wgrant | lifeless: lazr.restful's exception handling is buggy in other ways too :( | 02:11 |
| lifeless | dobey: yes, me too | 02:11 |
| lifeless | dobey: long list of things to fix | 02:12 |
| lifeless | wgrant: thank you so -very very very- much for getting even this much | 02:12 |
| wgrant | lifeless: Erm, the fix isn't landed yet, but yeah. | 02:12 |
| lifeless | wgrant: though that looks pretty ok | 02:13 |
| wgrant | lifeless: This isn't a timeout, so the data is fine. | 02:13 |
| lifeless | oh of course | 02:13 |
| lifeless | mea culpa | 02:13 |
| wgrant | lifeless: But the traceback is obliterated by lazr.restful explicitly reraising the exception object. | 02:13 |
| lifeless | yes | 02:13 |
| wgrant | (in 2.7 this would work fine) | 02:13 |
| wgrant | Er, 3.x. | 02:13 |
| wgrant | Not backported to 2.7, is it... | 02:13 |
| lifeless | works fine in 2.x if include the backtrace | 02:13 |
| lifeless | 3 arg raise | 02:14 |
| lifeless | its just poor python | 02:14 |
| wgrant | Yeah. | 02:15 |
| lifeless | GRAH | 02:17 |
| lifeless | whoever thought a bug couldn't have 1000 actions | 02:17 |
| * lifeless puts on the positive face | 02:17 | |
| wgrant | Actions as in BugActivity? | 02:17 |
| lifeless | ROM BugActivity | 02:17 |
| lifeless | WHERE BugActivity.bug = 659052 | 02:17 |
| lifeless | ORDER BY BugActivity.id LIMIT 1001 | 02:17 |
| lifeless | thats whats triggering the shortlimit | 02:17 |
| wgrant | what. | 02:18 |
| wgrant | At least there was shortlist() there to warn. | 02:18 |
| lifeless | I think it is | 02:18 |
| lifeless | lets check | 02:18 |
| lifeless | yup | 02:20 |
| jtv | hi wgrant | 02:45 |
| wgrant | Hi jtv. | 02:45 |
| jtv | Had a chance to look at the updated publish-ftpmaster script? | 02:46 |
| wgrant | Not enough. | 02:46 |
| jtv | Which, on a sidenote, I found may actually have been slower than it needed to be all this time. | 02:46 |
| wgrant | Oh? | 02:46 |
| jtv | I tried not to work during the holidays, honest. | 02:46 |
| jtv | You see, it tries to update these two directories from each other using hardlinks. | 02:47 |
| jtv | Far as I can tell, it does that by passing rsync the -H option. | 02:47 |
| jtv | Which says "try to figure out whether there are any hardlinks within the source, and recreate those in the destination." | 02:47 |
| jtv | Whereas what I think is really wanted is --link-dest. | 02:47 |
| wgrant | Hmmm, -H makes sense, but I'm not sure --link-dest is what we want. | 02:48 |
| wgrant | -H is there to not undo fdupes. | 02:48 |
| wgrant | It's possible that --link-dest would be faster than what we have now, bit it really depends. | 02:48 |
| jtv | Oh, so there are "meaningful" hardlinks in the publishing directory? | 02:49 |
| wgrant | s/bit/but/ | 02:49 |
| jtv | (Besides faster, it'd also be much more space-efficient of course) | 02:49 |
| wgrant | Saving about a megabyte, I believe, yes. | 02:49 |
| wgrant | Right. | 02:49 |
| jtv | There's only a megabyte in the dists directories? | 02:49 |
| wgrant | No, I mean the current hardlinking done by dsync link-dupes saves about a megabyte. | 02:50 |
| jtv | Oh | 02:51 |
| jtv | But are the hardlinks significant? Or are they still just a space-saving measure? | 02:51 |
| wgrant | Not significant AFAIK. | 02:51 |
| wgrant | Total space saved by merging 28.1kb. 577 files affected. | 02:51 |
| wgrant | Oooh yeah. | 02:51 |
| wgrant | I guess it saves inodes and a trivial amount of space. | 02:52 |
| jtv | wgrant: it sounds pretty insignificant compared to what we could save on not duplicating the dists directory itself. | 02:57 |
| wgrant | jtv: Indeed. | 02:58 |
| wgrant | Although the rsync only takes 23 seconds. | 02:58 |
| jtv | In that case, why do we go to all the trouble of re-using that directory? | 02:59 |
| wgrant | Copying the whole thing would take much longer. | 02:59 |
| wgrant | Hard-linking maybe not so much. | 02:59 |
| jtv | Exactly. | 03:00 |
| jtv | It'd even save the time of reading files. | 03:00 |
| wgrant | Yeah. But we have to hope that nobody uses O_APPEND :) | 03:01 |
| jtv | I guess | 03:01 |
| jtv | Except | 03:01 |
| jtv | no | 03:01 |
| jtv | All the risks are from re-using the directory. | 03:02 |
| jtv | Hmm | 03:02 |
| wgrant | No... | 03:02 |
| jtv | It depends on when, I guess. | 03:03 |
| jtv | Changing a hardlinked file and then rolling back the publication would cause trouble. | 03:03 |
| wgrant | If they're hard-linked and someone writes a file without first unlinking it, your archive is borked. | 03:03 |
| jtv | So the risk is that publish-distro or one of the publish-distro plugin scripts might modify a file. | 03:03 |
| wgrant | s/might/probably do/ | 03:03 |
| wgrant | In lots of places. | 03:04 |
| jtv | Oh | 03:04 |
| jtv | Well never mind that then. | 03:04 |
| wgrant | Just about nothing explicitly unlinks first... | 03:04 |
| lifeless | pop quiz | 03:04 |
| lifeless | nvm | 03:05 |
| lifeless | we already expose it ;0 | 03:05 |
| wgrant | jtv: Release file generation, for example. | 03:05 |
| wgrant | f = open(os.path.join( | 03:05 |
| wgrant | self._config.distsroot, suite, "Release"), "w") | 03:05 |
| wgrant | Bye. | 03:05 |
| jtv | Well never mind that then. | 03:05 |
| lifeless | actually | 03:06 |
| lifeless | here is a question | 03:06 |
| lifeless | should we still expose an unqualified 'incomplete' | 03:06 |
| wgrant | Yes. | 03:06 |
| lifeless | where ? | 03:07 |
| wgrant | Needed for backwards compatibility. | 03:07 |
| wgrant | And stuff does use it. | 03:07 |
| wgrant | (good luck with that) | 03:07 |
| lifeless | wgrant: outside of migration support | 03:08 |
| lifeless | where do you you think we should expose it? | 03:08 |
| wgrant | I personally think that s/New/Unconfirmed/ and merge "Incomplete with response | 03:08 |
| wgrant | " into that. | 03:08 |
| wgrant | There's very little useful distinction. | 03:08 |
| lifeless | wgrant: while I'm pro that thats a larger discussion to do | 03:09 |
| lifeless | what I'm doing is materialising an inferred status | 03:09 |
| wgrant | We're going to need to break API clients at least once. | 03:09 |
| lifeless | so that we can aggregate it sensible. | 03:09 |
| wgrant | Let's do it only once. | 03:09 |
| lifeless | separate problem | 03:10 |
| lifeless | I'm hoping not to break anything at all | 03:10 |
| wgrant | Ah. | 03:10 |
| wgrant | OK. | 03:10 |
| lifeless | I'm talking about UI | 03:10 |
| lifeless | like | 03:10 |
| lifeless | show 'incomplete' but set to incomplete-without-response | 03:11 |
| lifeless | thats a place I think showing incomplete is useful | 03:11 |
| lifeless | but | 03:11 |
| lifeless | a bug that is incomplete | 03:11 |
| lifeless | cannot be asked for more input without toggling to new and back to incomplete. | 03:11 |
| lifeless | this is nuts | 03:11 |
| lifeless | so if we show the bug status as incomplete-with-reponse and show incomplete in the list | 03:12 |
| wgrant | I guess. I am fairly strongly against making any UI changes without fixing it properly, though. | 03:12 |
| lifeless | folk can trivially set it back to incomplete-without-response [by choosing incomplete] | 03:12 |
| wgrant | Since this is just going to be awkward. | 03:12 |
| lifeless | one option is to not change the ui at all | 03:12 |
| wgrant | That would be my preference. | 03:13 |
| wgrant | Your proposal is less awkward than the status quo, but the change is probably more awkward. | 03:13 |
| lifeless | is getInitialValuesFromSearchParams dead code ? | 03:14 |
| lifeless | please-say-yes-please-say-yes-please-say-yes | 03:14 |
| wgrant | It seems to be... but that's very odd. | 03:15 |
| lifeless | \o/ | 03:15 |
| lifeless | I'd kind of like to expose the actual status | 03:18 |
| lifeless | why do you say a change would be awkwards | 03:18 |
| lifeless | I wonder how many folk set 'incomplete' and *then* make a comment using ajax saying 'please tell us more' | 03:20 |
| lifeless | thus defeating the incomplete-without-response entirely. | 03:20 |
| wgrant | lifeless: Change to a bad solution is awkward, even if the solution is better than what we have now. | 03:28 |
| wgrant | Particularly since we're planning to change this again in the next 12 months. | 03:28 |
| lifeless | why is it awkward though? | 03:36 |
| wgrant | We have a status field that doesn't show the status. | 03:36 |
| lifeless | thats what we have now | 03:38 |
| wgrant | It has the same idea of 'status' as most of the rest of the UI. | 03:38 |
| lifeless | the bug search form shows two incomplete statuses | 03:40 |
| lifeless | the drop down widget to change a bug status shows one | 03:40 |
| wgrant | The with/without reponse statuses only show up on the search form. | 03:41 |
| lifeless | and the bug portlet exposes that there are two in yet another way by doing incomplete(can expire) but searching for a variant again | 03:41 |
| wgrant | On the advanced search form, even. | 03:41 |
| lifeless | bug expiry discusses this in the various bits of help | 03:41 |
| lifeless | so I don't know that I accept your assertion about most of the ui pretending their is one such status | 03:42 |
| lifeless | s/their/there/ | 03:42 |
| wgrant | Mmm. | 03:44 |
| wgrant | Well, it's a terrible mess at the moment. | 03:44 |
| lifeless | agreed. | 03:45 |
| lifeless | I want to understand what is awkward about reducing the amount of inconsistent UI here - by accepting that we have two incompletes and starting to propogate them. | 03:46 |
| lifeless | we can do a totally hidden thing, I'm sure. | 03:46 |
| wgrant | Aaaa | 03:46 |
| wgrant | aaaaaaaaaaaaaaaaa | 03:46 |
| lifeless | ECAT ? | 03:47 |
| wgrant | process-accepted is crap. | 03:47 |
| wgrant | It goes through all pending uploads. | 03:47 |
| wgrant | processing them. | 03:47 |
| wgrant | logging errors if they fail. | 03:47 |
| wgrant | That sort of thing. | 03:47 |
| wgrant | But it doesn't do any transaction stuff. | 03:47 |
| lifeless | \o/ | 03:47 |
| wgrant | So a failed upload gets the partial state left uncommitted, so it gets committed at the end. | 03:47 |
| wgrant | (and library files created in early uploads aren't accessible to later ones) | 03:48 |
| wgrant | This is the sort of thing that you *really really* want to be transactional :/ | 03:50 |
| lifeless | headdesk | 04:01 |
| lifeless | Bug.permits_expiration | 04:01 |
| === poolie__ is now known as poolie | ||
| wgrant | Hmmmmmm. | 04:35 |
| wgrant | Our Referer parsing sucks. | 04:35 |
| wgrant | OOPS-1934A83 | 04:36 |
| wgrant | Grar. | 04:41 |
| wgrant | Web browsers suck. | 04:41 |
| wgrant | Backslashes are not legal URI characters, please don't send them. | 04:41 |
| * wgrant stabs Chromium in the eye. | 04:45 | |
| wgrant | And Firefox. | 04:45 |
| wgrant | Stop autocorrecting my backslashes to slashes. | 04:45 |
| lifeless | wgrant: which browser ? | 04:46 |
| wgrant | lifeless: Chromium and Firefox appear to both happily send backslashes in URLs. | 04:47 |
| wgrant | Despite RFC2396 excluding them. | 04:48 |
| wgrant | Why don't people follow specs :( | 04:48 |
| wgrant | And why does Chromium insist on treating URLs as non-opaque entities to be autocorrected unoverridably? | 04:48 |
| wgrant | Huh. | 04:52 |
| wgrant | Firefox encodes it correctly if it's in the path, but not if it's in the query string. | 04:53 |
| wgrant | Yeah, that's pretty clearly illegal. | 04:54 |
| wgrant | Gah. | 04:54 |
| wgrant | Can we please delete the Web and start over? | 04:57 |
| lifeless | oh yay | 05:00 |
| lifeless | unwise turns up exactly twice in 2396 | 05:01 |
| wgrant | lifeless: It's only documenting the rationale for the exclusions. | 05:01 |
| lifeless | yeah | 05:01 |
| lifeless | but its really strange to use a BNF rule to do that | 05:02 |
| wgrant | It is. | 05:02 |
| lifeless | and then not reference that elsewhere | 05:02 |
| wgrant | Oh hmm. | 05:03 |
| lifeless | query = *uric | 05:03 |
| lifeless | uric = reserved | unreserved | escaped | 05:03 |
| lifeless | reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | | 05:03 |
| lifeless | "$" | "," | 05:03 |
| lifeless | unreserved = alphanum | mark | 05:03 |
| lifeless | mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | | 05:03 |
| lifeless | "(" | ")" | 05:03 |
| wgrant | Yes. | 05:03 |
| lifeless | so yues | 05:04 |
| lifeless | clearly FUBAR | 05:04 |
| wgrant | In this case the URL actually comes from apport, not generated from a form. | 05:04 |
| wgrant | However, it still sends bad stuff if you type it in the address bar :/ | 05:04 |
| lifeless | user input cannot be trusted. | 05:05 |
| lifeless | Thats like rule 1 of programming, right ? | 05:05 |
| lifeless | which reminds me | 05:05 |
| lifeless | need to talk to pitti about apport + privacy. | 05:05 |
| lifeless | but now, grocery shopping | 05:05 |
| wgrant | Except apport generates the URL with the backslash urlencoded. | 05:07 |
| lifeless | are you sure we aren't double decoding somewhere ? | 05:11 |
| lifeless | -> gone | 05:12 |
| wgrant | Other stuff is still encoded. | 05:13 |
| 16WAAA4BV | StevenK: i have 2 mp's to fix the failing windmill tests if you are interested... | 05:19 |
| 16WAAA4BV | https://code.launchpad.net/~wallyworld/launchpad/picker-textfield-plugin/+merge/57819 | 05:19 |
| 16WAAA4BV | https://code.launchpad.net/~wallyworld/launchpad/fix-windmill-tests/+merge/58066 | 05:19 |
| StevenK | 16WAAA4BV: Have you seen your nick? :-) | 05:20 |
| 16WAAA4BV | yes, just now :-/ | 05:20 |
| 16WAAA4BV | StevenK: sadly, those windmill tests, if run, would have prevented a ui regression :-( | 05:20 |
| 16WAAA4BV | and it's not letting me change my nick back | 05:21 |
| StevenK | 16WAAA4BV: The windmill tests are run on Jenkins? Do you check the results? | 05:21 |
| 16WAAA4BV | looks like wallyworld is known as '16WAAA4BV' :-) | 05:21 |
| 16WAAA4BV | StevenK: i did today, but because they are not in-process, stuff got landed and merged without the failure being noticed | 05:22 |
| 16WAAA4BV | and if i had checked earlier, it would not have prevented the bad landing | 05:22 |
| StevenK | 16WAAA4BV: Identify to NickServ as wallyworld and then release | 05:22 |
| 16WAAA4BV | we gotta get these tests reliable | 05:23 |
| StevenK | 16WAAA4BV: I'm not comfortable enough with my JS to approve the first one, but r=me for the second. | 05:23 |
| 16WAAA4BV | StevenK: ok. i'll get someone to look at the first one later tonight. that's the real bad one which breaks the picker :-( | 05:25 |
| StevenK | 16WAAA4BV: You could ask lifeless or wgrant to review it? | 05:25 |
| StevenK | Or thumper if he's unbusy | 05:25 |
| 16WAAA4BV | still trying to figure out how to fix my nick | 05:25 |
| 16WAAA4BV | stupid quassel | 05:26 |
| === 16WAAA4BV is now known as wallyworld1 | ||
| StevenK | wallyworld1: What error do you get if you try to change to wallyworld? | 05:27 |
| wallyworld1 | no error it just doesn't accept it. but let me try something else | 05:27 |
| StevenK | wallyworld1: If you get the nick is in use, I daresay services has taken over your nick and you need to instruct it to release its lockout | 05:27 |
| wallyworld1 | StevenK: how do i do that? | 05:28 |
| wgrant | StevenK: What? | 05:28 |
| StevenK | wallyworld1: Open a query window to Nickserv and identify to it by "identify wallyworld <your password>" and then "release" | 05:28 |
| wgrant | Oh, if you've got that extra protection on, right. | 05:28 |
| StevenK | wgrant: And I'm not comfortable with my JS for https://code.launchpad.net/~wallyworld/launchpad/picker-textfield-plugin/+merge/57819 | 05:29 |
| * wallyworld has the right nick again | 05:38 | |
| StevenK | wallyworld: \o/ | 05:44 |
| wallyworld | StevenK: thanks for the help. i've registered it this time too :-) | 05:44 |
| === almaisan-away is now known as al-maisan | ||
| StevenK | wallyworld: You should have registered it quite some time ago :-) | 05:57 |
| wallyworld | StevenK: yes, such a noob that i didn't know i had too | 05:57 |
| StevenK | Registered : Oct 28 14:46:18 2000 (10 | 05:57 |
| StevenK | years, 24 weeks, 5 days, 14:11:07 ago) | 05:57 |
| StevenK | Bloody hell | 05:57 |
| wallyworld | wtf? 10 years. | 05:58 |
| StevenK | That's mine | 05:58 |
| wallyworld | realise that :-) | 05:58 |
| StevenK | I've been around free software for a long while | 05:58 |
| wallyworld | StevenK: you don't look that old :-) | 05:59 |
| StevenK | Hm, I think that's the era that #debian-devel was still on this network | 05:59 |
| ajmitch | StevenK: not bad | 05:59 |
| StevenK | I was ... 19. | 06:00 |
| StevenK | wgrant still beats me, since he was 12. | 06:00 |
| ajmitch | StevenK: funnily enough, my nick was registered 3 weeks later than yours | 06:00 |
| wgrant | StevenK: 14 :( | 06:00 |
| wgrant | lifeless: Aha. | 06:01 |
| StevenK | wgrant: Which was what, 2008? :-P | 06:01 |
| wgrant | lifeless: I grepped appserver logs. | 06:01 |
| StevenK | ajmitch: Heh, nice. | 06:02 |
| ajmitch | bug 434244 annoys me :( | 06:02 |
| _mup_ | Bug #434244: No search method on bugs collection in API <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434244 > | 06:02 |
| spm | my first patches accepted were in 1990. I had no idea was the GPL was. Opensource as a phrase was years in the future. It was just "code" and it didn't work the way I wanted on the hardware I was using; so played around with the signals generation/timing and got it mostly working. | 06:03 |
| lifeless | wgrant: any? | 06:03 |
| wgrant | lifeless: Well, I thought I'd found something. But just realised I was one level of encoding off. | 06:03 |
| StevenK | spm: Patches to what, out of interest? | 06:04 |
| wgrant | lifeless: I think the initial request was somewhat mangled by OpenID, and then subsequent requests were mangled by the browser (firefox and chromiuim show %5c as \ in the address bar, and put \ into the clipboard when it's copied) | 06:05 |
| StevenK | "Tear down canonical.testing.layers.AppServerLayer in 3 minutes 0.709 seconds." :-( | 06:05 |
| wgrant | But there's still an initial bug in the OpenID stuff somewhere. | 06:05 |
| spm | gawd. wonder if I can recall what it was called. it was a graphical game that was played on X workstations. a clone of balderdash? from memory. Plus I think there were some to another game xconq. Not sure if the work we were doing on the VMS port of ISODE ever went back in as patches either. suspect didn't. | 06:05 |
| wgrant | spm: How's it going? | 06:06 |
| spm | still pushing | 06:06 |
| wgrant | Looks like we may have to give up :( | 06:06 |
| wgrant | ……… | 06:24 |
| wgrant | lifeless: Have a look at form_args in lib/canonical/launchpad/webapp/login.py | 06:27 |
| wgrant | (peril sensitive sunglasses may inhibit your viewing ability) | 06:28 |
| LPCIBot | Project windmill build #186: STILL FAILING in 10 min: https://lpci.wedontsleep.org/job/windmill/186/ | 06:37 |
| lifeless | wgrant: thanks for the warning. | 06:39 |
| StevenK | Can haz review from someone? | 06:40 |
| === al-maisan is now known as almaisan-away | ||
| StevenK | https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 | 06:41 |
| wgrant | lifeless: So, there's the non-browser part of our problem :/ | 06:42 |
| lifeless | wgrant: the UnicodeDammit thing ? | 06:42 |
| lifeless | ' Thanks Diogo; If LP can digest these URLs now, it seems I don't need to | 06:43 |
| lifeless | > change anything in apport.' | 06:43 |
| lifeless | >< | 06:43 |
| lifeless | bad urls are bad | 06:43 |
| wgrant | lifeless: No... it gets the values from request.form (they're decoded), and puts them back into a URL. | 06:44 |
| wgrant | Decoded. | 06:44 |
| lifeless | wgrant: oh. ha. ha. ha. | 06:44 |
| lifeless | wgrant: I just saw key=value and didn't glue that to 'and those will be used in urls.' | 06:44 |
| jtv | StevenK: I'm looking at the generate-contents script, but the /srv/launchpad.net/ubuntu-contents directory it's supposed to create isn't on mawson. Any idea why that is? | 07:01 |
| StevenK | Because it would take until the heat death of the universe to run on mawson. | 07:02 |
| jtv | StevenK: this universe heat death you mention… is it expected anytime soon? | 07:06 |
| StevenK | I dunno | 07:06 |
| StevenK | jtv: I doubt we've ever run generate-contents on mawson. | 07:06 |
| jtv | Well, that certainly answers that question. Thanks. | 07:06 |
| lifeless | mmm corn chowder with basil. | 07:20 |
| lifeless | nice fresh soup | 07:20 |
| StevenK | wgrant: Bah, my clever hack doesn't work | 07:29 |
| wgrant | StevenK: Oh? | 07:29 |
| StevenK | if not any(( | 07:29 |
| StevenK | self.source_pub, self.parent_source_pub, self.base_source_pub)): | 07:29 |
| StevenK | return | 07:29 |
| lifeless | bah, thai internets | 07:29 |
| wgrant | StevenK: not all | 07:29 |
| wgrant | StevenK: But anyway, that's wrong. | 07:29 |
| wgrant | StevenK: You can still create a diff if just parent or source are missing. | 07:30 |
| StevenK | This is just looking for diffs, but fair point | 07:30 |
| StevenK | wgrant: No other tests in that file need to create SPPHs. :-( | 07:35 |
| wgrant | :( | 07:35 |
| wgrant | Still, you need to do it twice there, and it is ugly. Helper method. | 07:35 |
| StevenK | wgrant: I can move the test to the job integration tests, which does have a helper method already\ | 07:36 |
| wgrant | StevenK: That sounds suboptimal. | 07:36 |
| lifeless | what does the helper do ? | 07:41 |
| lifeless | stub: hi there | 07:41 |
| lifeless | oh cool, jtv is back too. | 07:42 |
| jtv | Yes. Hi. | 07:42 |
| lifeless | stub: jtv: How well do array types get indexed in pg ? | 07:42 |
| jtv | ur | 07:42 |
| lifeless | specifically, searching for bug tags is slow | 07:42 |
| lifeless | I'm wondering if we'd be better having them as arrays on bug | 07:42 |
| lifeless | (rather than the key-value table they are | 07:42 |
| jtv | Sounds like a potential win, yes | 07:43 |
| lifeless | doing a simple foo AND bar search is triggering seq scans | 07:43 |
| jtv | You may not be able to avoid that though. | 07:43 |
| lifeless | jtv: perhaps you'd like to have a poke at the plans ? | 07:44 |
| jtv | lifeless: sure | 07:44 |
| lifeless | bug 750445 and bug 757426 | 07:44 |
| _mup_ | Bug #750445: MaloneApplication:+bugs timeout on 'any tag {pcert, blockshwcert}' <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/750445 > | 07:44 |
| _mup_ | Bug #757426: Distribution:+bugs timeout with combinator ALL <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/757426 > | 07:44 |
| lifeless | our fk for official bug tags is the text of the tag | 07:45 |
| lifeless | so we've no referential integrity issues that I can see with moving this around | 07:45 |
| jtv | Just about impossible to read these queries… | 07:48 |
| stub | Yo | 07:49 |
| StevenK | wgrant: Do you also want to review https://code.launchpad.net/~stevenk/launchpad/drop-psc/+merge/57807 ? | 07:50 |
| stub | lifeless: There is decent support using GIN indexes. Landscape uses this. There are special operators for stuff like item in array etc. | 07:50 |
| stub | GiST indexes too, but we prefer GIN due to low write, high read. | 07:51 |
| wgrant | lifeless: Could you please mentor https://code.launchpad.net/~stevenk/launchpad/drop-psc/+merge/57807? | 07:52 |
| stub | lifeless: But faster than a separate table mapping bug -> tag? Dunno. | 07:52 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews | ||
| lifeless | wgrant: can you please leave a space after urls ? :) | 07:55 |
| wgrant | lifeless: ? on the end of a URL shouldn't matter... | 07:55 |
| wgrant | But OK. | 07:56 |
| jtv | lifeless: still just scanning the information, but… wouldn't an index on BugTask(importance DESC, status) take away part of the pain? | 07:57 |
| stub | Today is the day I (literally) get off my arse and build a temporary standing desk. | 08:00 |
| jtv | lifeless: still just scanning the information, but… wouldn't an index on BugTask(importance DESC, status) take away part of the pain? | 08:01 |
| StevenK | wgrant: Can you have another look at https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 ? | 08:02 |
| StevenK | wgrant: I think I've addressed everything. | 08:03 |
| jtv | lifeless: also, the queries would be tremendously easier to read if they just did "SELECT *" instead of repeating a full page of mis-indented and inconsistently capitalized column names every time! | 08:03 |
| jtv | This is the first thing I change when I copy queries from oopses. It really helps. | 08:03 |
| jtv | I'm guessing you're either trying out various different phrasings for optimization, or profiling different scenarios. | 08:05 |
| lifeless | jtv: I've found that that can mess up the timings because we have some tables with multi-MB text fields | 08:05 |
| lifeless | jtv: I may be being overly cautious | 08:05 |
| lifeless | stub: \o/ | 08:06 |
| wgrant | StevenK: Rereviewed. Looks mostly good. | 08:06 |
| stub | lifeless: SELECT * performs the same as SELECT [every column in excruciating detail] | 08:06 |
| StevenK | Mostly good? :-( | 08:06 |
| stub | lifeless: SELECT Person.*, TeamParticipation.* for prejoins etc. too. | 08:06 |
| lifeless | stub: yeah, but thats not the same as SELECT table1, table2 | 08:06 |
| lifeless | stub: bingo :)_ | 08:06 |
| jtv | lifeless: shouldn't matter as long as (1) you're consistent and (2) you only change the list of columns in your query, as opposed to the list of tables. | 08:07 |
| lifeless | stub: but also factor in columns in the db that storm doesn't know about | 08:07 |
| StevenK | wgrant: Right, so I should revert to Storm? | 08:07 |
| wgrant | StevenK: Hmm? Use PackageDiffSet.getDiffBetweenReleases. | 08:07 |
| stub | lifeless: That is pretty rare, and either the column shortly dropped or Storm DB class shortly extended. | 08:08 |
| StevenK | wgrant: But how can I be sure it returns the right diff? | 08:08 |
| wgrant | StevenK: *Between*, not To. | 08:08 |
| lifeless | stub: fti vectors | 08:09 |
| StevenK | wgrant: OH! | 08:09 |
| StevenK | wgrant: Sorry | 08:09 |
| stub | I guess. That will slow down the transmission to client time, but I don't think it slows down the query time | 08:09 |
| StevenK | wgrant: Damn function names are too close | 08:09 |
| lifeless | stub: remember when we were debugging that packagerelease.changelog thing or whatever it was | 08:10 |
| lifeless | stub: the plan was much faster than the timing reported by the client | 08:10 |
| lifeless | stub: until we actually selected the right columns | 08:11 |
| lifeless | all I'm saying is once-bitten twice shy | 08:11 |
| StevenK | wgrant: Er, I can't see IPackageDiffSet.getDiffBetweenReleases() defined? | 08:12 |
| stub | analyze reports the query time, \timing reports time as seen by the client | 08:12 |
| lifeless | stub: yup | 08:13 |
| wgrant | StevenK: That should be but a temporary hindrance :) | 08:13 |
| lifeless | stub: and its the \timing that matters for fixing a page; the analyze is crucial data in figuring out how to reducing the timing, but its the timing we need to care about | 08:13 |
| StevenK | wgrant: Well, clearly one of us is wrong. I'm just trying to work out who. | 08:14 |
| jtv | lifeless: anyway, I'd just try the indexed-array approach on staging and see what it does. If it's too costly to add the column, consider a linking table of (bug_id, [tags]) | 08:14 |
| wgrant | StevenK: Hmm? it doesn't exist, but it should. | 08:14 |
| lifeless | jtv: can make a temporary table with all the constraints and indices but without FK relationships quite happily. | 08:15 |
| lifeless | jtv: its how I played with the fact table for doing aggregates | 08:15 |
| jtv | Great. | 08:15 |
| StevenK | wgrant: But why would you suggest a function that doesn't exist? :-) | 08:15 |
| jtv | lifeless: How did that fact table play out, by the way? | 08:16 |
| wgrant | StevenK: I said you should use it. I didn't say you wouldn't also have to write it ;) | 08:16 |
| wgrant | StevenK: Basically, it's generally useful, model-specific, and longish. Should be factored out. | 08:16 |
| StevenK | I can't use it if it's doesn't exist. | 08:16 |
| lifeless | jtv: can do our existing 3+ second queries in 0.5s including privacy at the cost of overcounting private bugs | 08:16 |
| lifeless | jtv: jml & flacoste are convinced that as an incremental fix-performance step this is ok and I've mailed stakeholders@ for objections. | 08:17 |
| lifeless | jtv: anonymous user lookups it answers in 0.1s | 08:17 |
| jtv | lifeless: I saw at least some of the list discussion… it's nice, though once you go this radical, it'd be nicer if it could be done in negligible time. | 08:17 |
| lifeless | jtv: the table could possibly be trimmed more by discarded bugs we don't show in the portlet | 08:18 |
| jtv | Not that 0.1s isn't about negligible! | 08:18 |
| lifeless | the nice thing is that its 0.5seconds *cold* | 08:18 |
| lifeless | or if not totally cold then at least lukewarm | 08:19 |
| jtv | So that's lukewarm taken care of… what about tepid? | 08:21 |
| jtv | And more importantly, how fast is it at scalding? | 08:21 |
| stub | Performance decreases when the server is on fire. | 08:22 |
| jtv | That's scorching. Let's not get confused here. | 08:23 |
| spiv | stub: but a server on fire is red, and everyone knows red goes faster! | 08:23 |
| jtv | Yeeees, but red also attracts more fines. It's science™. | 08:24 |
| jtv | Interesting that so many words for temperatures should have been invented on an island that has so few. | 08:24 |
| lifeless | jtv: so, 0.5s was when I left it overnight and tried in the morning with my test user + ubuntu | 08:24 |
| lifeless | test user being someone in 200 teams | 08:25 |
| jtv | So a fairly difficult case. | 08:25 |
| lifeless | yes | 08:25 |
| lifeless | man, the way we compile status checks is -so- bogus | 08:26 |
| lifeless | stub: could you time this on prod - http://pastebin.com/jBbVgP8J please ? | 08:27 |
| lifeless | I know its crap | 08:27 |
| lifeless | its interim while we migrate crap to be less crap so the query can be less crap | 08:27 |
| stub | After the performance drive, we can have a crap purging. Launchpad Enema. | 08:29 |
| stub | lifeless: you want an explain or an explain analyze? | 08:30 |
| stub | slow, slow, slow. | 08:32 |
| stub | http://pastebin.com/vJySZ6Jb | 08:33 |
| stub | lifeless: ^^^ | 08:33 |
| lifeless | stub: I've edited it - try again ? | 08:34 |
| stub | lifeless: still crap | 08:35 |
| lifeless | stub: 9.4 seconds still ? | 08:36 |
| stub | lifeless: http://pastebin.com/03sAFpYk | 08:36 |
| stub | Less crap, but crap | 08:36 |
| lifeless | wow | 08:36 |
| lifeless | stub: http://pastebin.com/B5fg7fsH | 08:37 |
| lifeless | bah | 08:37 |
| lifeless | failed edit | 08:37 |
| lifeless | stub: it was the same, so that less crap is query variation | 08:38 |
| lifeless | stub: ok, - http://pastebin.com/j62T5HyY | 08:38 |
| lifeless | stub: nearly done - http://pastebin.com/JSad5jbs and | 08:40 |
| stub | http://pastebin.com/KVqUabau is the first one | 08:41 |
| lifeless | last variant - http://pastebin.com/MYU1WKFA | 08:41 |
| stub | http://pastebin.com/2znv9HBp is the second | 08:42 |
| adeuring | good morning | 08:42 |
| StevenK | wgrant: Another look at https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 , please? | 08:43 |
| stub | lifeless: http://pastebin.com/bB1KXJ2S is the last variant | 08:43 |
| lifeless | stub: thanks! | 08:48 |
| stub | bouncy bouncy thai internet | 08:48 |
| lifeless | stub: interesting that that triggers qual seq scans | 08:49 |
| lifeless | stub: even though its semantically identical | 08:49 |
| stub | qual? | 08:49 |
| lifeless | dual | 08:49 |
| lifeless | though bug is already being sequentially scanned | 08:49 |
| stub | The simplest version is generally best to see how well the planner can do without help. | 08:50 |
| lifeless | stub: the > < being the simplest version ? | 08:51 |
| stub | When thinking about a BugSearch table containing denormalized bug information, I was thinking of using arrays for tags etc. | 08:51 |
| stub | lifeless: Dunno. I wasn't reading the queries apart from ensuring you were not bobby tabling me :) | 08:51 |
| lifeless | stub: :) | 08:51 |
| lifeless | stub: I wonder if we can improve BugTask in situ | 08:51 |
| lifeless | Bug + BugTask I guess I mean | 08:52 |
| lifeless | anyhow, thanks for those tests | 08:52 |
| lifeless | it says that doing compatible searches won't be a disaster | 08:52 |
| lifeless | but sadly also that the result won't be magically faster once we migrate. | 08:53 |
| wgrant | bigjools: Morning. | 09:00 |
| bigjools | morning | 09:00 |
| wgrant | bigjools: Bug #761439. | 09:00 |
| _mup_ | Bug #761439: Delayed copy publication sometimes crashes when reading changes file content <oops> <soyuz-publish> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/761439 > | 09:00 |
| wgrant | bigjools: process-accepted's transaction management is awful. | 09:00 |
| bigjools | colour me surprised | 09:00 |
| wgrant | bigjools: But I'm not quite sure how to fix it. | 09:00 |
| wgrant | I'm not sure we can safely abort a transaction that encounters an exception. | 09:01 |
| bigjools | hang on, just having to file a bug about my network card driver | 09:01 |
| wgrant | Hah. Sure. | 09:01 |
| lifeless | _getUnconfirmedBugCondition - so if one target expires, the entire bug gets expired. | 09:01 |
| StevenK | wgrant: *prod* | 09:01 |
| lifeless | >< | 09:01 |
| wgrant | StevenK: 'tis done. | 09:01 |
| wgrant | lifeless: Hah, fun. | 09:01 |
| StevenK | wgrant: Thanks | 09:02 |
| bigjools | I guess it's the kernel I need to file it on | 09:02 |
| lifeless | that implies that a single incomplete task cannot expire if any task is valid | 09:02 |
| lifeless | or something | 09:02 |
| wgrant | lifeless: Want to mentor https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070? | 09:02 |
| wgrant | lifeless: That's intended behaviour, yes. | 09:02 |
| wgrant | lifeless: Tasks should will not expire if the bug is known to be valid. | 09:03 |
| lifeless | wgrant: that means that as a developer of project X and a bug with an added task, I cannot say 'hey, tell me if X so I can see if its relevant here' and have it expire out of my project. | 09:03 |
| lifeless | wgrant: if the bug also has a task on Y, which I don't care about. | 09:04 |
| wgrant | lifeless: Sure, I didn't say it was reasonable behaviour. | 09:04 |
| StevenK | wgrant: I can't remove the intermediate use, they're set if either SPPH is None | 09:04 |
| lifeless | !hah | 09:05 |
| wgrant | StevenK: if blah: self.parent_package_diff = None; else: self.parent_package_diff = ... | 09:05 |
| StevenK | Bleh | 09:06 |
| StevenK | But okay | 09:06 |
| wgrant | StevenK: Really you want a ternary statement. But I think they were only allowed into Python with a syntax so abhorrent that nobody could use them. | 09:07 |
| StevenK | Haha | 09:07 |
| lifeless | trueclause if condition else falseclause | 09:08 |
| bigjools | /vomit | 09:09 |
| lifeless | nowhere near a strong enough reaction | 09:09 |
| lifeless | personally I think this was a huge troll on guidos part | 09:09 |
| lifeless | like | 09:09 |
| wgrant | lifeless: That was my point, yes. | 09:09 |
| lifeless | how bad can we make things in the name of backwards compat | 09:09 |
| wgrant | He only permitted them with an utterly atrocious syntax. | 09:09 |
| wgrant | Just to spite people. | 09:09 |
| wgrant | To stop them complaining about the lack of it. | 09:09 |
| lifeless | and then that can be used to get leverage to make py3k break compat | 09:09 |
| wgrant | Hah | 09:09 |
| StevenK | Ooooh, languages features as a stick | 09:10 |
| wgrant | Ahhh py3k. | 09:11 |
| wgrant | Such a wasted opportunity :( | 09:11 |
| bigjools | wgrant: can you describe the scenario in that bug | 09:12 |
| bigjools | is the whole session in a single txn? | 09:12 |
| wgrant | bigjools: The entire script run, yes. | 09:13 |
| bigjools | /vomit | 09:13 |
| wgrant | bigjools: So, what happens here is that there are two delayed copies of the one source. | 09:13 |
| wgrant | bigjools: THe first one unembargoes the files, including the changes file. | 09:14 |
| wgrant | The second one sees the new changes file LFA, tries to read it. | 09:14 |
| StevenK | lifeless: Can haz mentor of https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 ? | 09:14 |
| wgrant | Not committed yet, so not accessible from the librarian. | 09:14 |
| wgrant | Boom. | 09:14 |
| bigjools | wgrant: yay | 09:14 |
| bigjools | wgrant: so what's the issue with adding transactions? | 09:14 |
| wgrant | bigjools: I could just commit after each PU. But I'm not sure if we should abort on failure instead. | 09:14 |
| wgrant | bigjools: Since part of a PU could have hit disk. | 09:15 |
| wgrant | eg. the source could be published. | 09:15 |
| bigjools | wgrant: it sounds like we need either commit() or abort() after processing each queue item | 09:15 |
| wgrant | So the file is on disk, but the abort would revert the status from published to pending. | 09:15 |
| wgrant | Right. | 09:15 |
| wgrant | But I'm not sure if abort() is safe. | 09:15 |
| bigjools | why? | 09:15 |
| bigjools | if it's not, we've got much bigger problems :) | 09:15 |
| wgrant | We do have much bigger problems, yes, but I'm not sure if they're actually that much of a problem. | 09:16 |
| * bigjools cries: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/764334 | 09:16 | |
| _mup_ | Bug #764334: Network card driver failure, stack trace <linux (Ubuntu):New> < https://launchpad.net/bugs/764334 > | 09:16 |
| wgrant | I guess worst case there is a bit of cruft left on disk if we screw up manual cleanup. | 09:16 |
| bigjools | you might as well just do it, it seems wrong otherwise | 09:17 |
| wgrant | Yeah. | 09:17 |
| bigjools | and any abort should probably reject the queue item as well | 09:17 |
| wgrant | No. That's exactly what we don't want to do. | 09:17 |
| bigjools | well if it's going to crash and crash it will stick there for ever | 09:17 |
| wgrant | That *will* leave bad cruft on disk forever. | 09:17 |
| wgrant | Since we don't have a transactional FS. | 09:18 |
| bigjools | what will get left? | 09:18 |
| wgrant | eg. we're processing a delayed copy. | 09:18 |
| wgrant | We publish the source to disk. | 09:18 |
| wgrant | It gets set to Published. | 09:18 |
| wgrant | Then publishing a binary crashes, so the transaction is aborted and the PU gets set to Rejected. | 09:18 |
| bigjools | ok | 09:18 |
| wgrant | Now we have the source file on disk forever, while there is no publishing record. | 09:19 |
| bigjools | I keep forgetting that p-a puts stuff on disk :/ | 09:19 |
| wgrant | Yeah. | 09:20 |
| wgrant | We need diskless archives :( | 09:20 |
| bigjools | it is somewhat concerning that kpackagekit has been waiting for grub to install for 5 minutes now :/ | 09:20 |
| wgrant | Or just transactional filesystems. | 09:21 |
| wgrant | Which only really Windows has :( | 09:21 |
| bigjools | oh FFS, server down AGAIN | 09:21 |
| bigjools | that should not make dpkg hang | 09:21 |
| wgrant | Yay | 09:21 |
| bigjools | it's rather sad that I need to use reisub on my server all the time | 09:26 |
| mrevell | Good morning -devers | 09:27 |
| wgrant | bigjools: Ew. What sort of hardware is it? | 09:30 |
| bigjools | wgrant: built-in skge gigabit | 09:30 |
| bigjools | going meh | 09:30 |
| === almaisan-away is now known as al-maisan | ||
| * StevenK attempts to get lifeless' attention again | 09:37 | |
| StevenK | lifeless: Clearly, not important enough to get your attention. :-P | 09:41 |
| lifeless | StevenK: hmm? | 09:41 |
| StevenK | [18:14] < StevenK> lifeless: Can haz mentor of https://code.launchpad.net/~stevenk/launchpad/dsd-packagediff/+merge/58070 ? | 09:42 |
| StevenK | lifeless: I've been attempting to get your attention for 35 minutes with little success | 09:42 |
| lifeless | StevenK: I have it open in a tab | 09:42 |
| lifeless | StevenK: its 8:40 at night; I have a mild headache | 09:42 |
| bigjools | StevenK: https://code.launchpad.net/~julian-edwards/launchpad/schema-distro-parents/+merge/57898 | 09:47 |
| bigjools | stub: can you look at that --^ too please, it needs DB review-fu | 09:48 |
| bigjools | lifeless: feel free to look from an architect pov | 09:48 |
| === dpm_ is now known as dpm | ||
| stub | jtv: I discovered your notes on the pqxx wiki more up to date than the ones I was working from, so am making progress on dropping branchrevision.id | 10:56 |
| bigjools | stub: do I need to buy you cookies or ammo to get a db review? :) | 11:00 |
| stub | depends on the code quality. Will I need a beer or ammo after seeing it? | 11:00 |
| bigjools | hopefully not both | 11:01 |
| stub | schema-distro-parents? | 11:01 |
| stub | Oh yay. A derived distro can have multiple parents? | 11:02 |
| bigjools | stub: tes | 11:02 |
| bigjools | yes* | 11:02 |
| jtv | stub: oh! that's great news | 11:03 |
| jtv | bigjools: buy him beer first. His shooting may be less accurate given enough of that. | 11:03 |
| stub | jtv: Only issue I'm seeing is that final update is updating 0 rows... will investigate after review. Perhaps you where using an existing UNIQUE constraint and the index I've picked isn't one? | 11:03 |
| * jtv looks up his own wiki | 11:03 | |
| bigjools | jtv: that was my worry, he'll start hitting stuff | 11:04 |
| jtv | stub: quite possible, yes | 11:04 |
| jtv | bigjools: and by the way, for the last time: I made him write down the bit about ammo. He's not the gun nut. | 11:04 |
| stub | I'll try with the other index later - it doesn't matter *that* much which one I run with. | 11:04 |
| stub | I wouldn't hurt a fly. | 11:05 |
| jtv | #$%@ bug spam | 11:05 |
| bigjools | jtv: I know, but you didn't have the guts to stand up and do the presentation | 11:05 |
| stub | You won't feel a thing. | 11:05 |
| bigjools | ;) | 11:05 |
| jtv | I would hurt a spammer | 11:05 |
| jtv | bigjools: classic misdirection. | 11:05 |
| stub | bigjools: So we don't need a priority or something to tell which parent overrides which if there are conflicts? | 11:07 |
| bigjools | stub: conflicts in what? | 11:07 |
| stub | I dunno. I was thinking a derived distro is a set of packages inherited from a parent, with overrides. | 11:07 |
| bigjools | normally the higher package version wins | 11:08 |
| stub | Excuse my naivety :) | 11:08 |
| bigjools | excused :) | 11:08 |
| bigjools | it's a hard feature this | 11:08 |
| bigjools | the package conflicts will be dealt with elsewhere anyway | 11:09 |
| wgrant | bigjools: Hm, so it's going to inherit from -updates and stuff? | 11:09 |
| stub | So If I inherit from two distros, one of which has a policy where packagex is pinned at version 2.0, then I'll end up with the newer version of packagex unless I somehow pin it too? | 11:09 |
| wgrant | eg. natty is going to show maverick-updates? | 11:09 |
| bigjools | wgrant: no | 11:09 |
| bigjools | won't work like that | 11:09 |
| bigjools | unless you're stupid enough to set it up like that | 11:09 |
| wgrant | Well, how will it not? | 11:09 |
| wgrant | How do we have a maverick->natty relationship? | 11:10 |
| bigjools | it's a single inheritance | 11:10 |
| bigjools | besides | 11:10 |
| jtv | stub: my impression is that if that last update didn't update anything, the index may have been created by a unique constraint in the database you're working with. | 11:10 |
| bigjools | natty does does not inherit from maverick | 11:10 |
| stub | I don't quite understand what 'initialized' does, but you are reasonably sure a boolean is suitable rather than an enum? | 11:10 |
| wgrant | bigjools: It was initialised from maverick. | 11:10 |
| wgrant | bigjools: And the relation needs to be stored in the DB. | 11:11 |
| bigjools | wgrant: nope :) | 11:11 |
| wgrant | bigjools: for at least createMissingBuilds. | 11:11 |
| bigjools | it was initialised from Debian | 11:11 |
| wgrant | Ubuntu was. | 11:11 |
| wgrant | Natty was not. | 11:11 |
| bigjools | yes, it was | 11:11 |
| bigjools | in our model | 11:11 |
| wgrant | So IDS does not initialise? | 11:11 |
| bigjools | initialisation happens once | 11:12 |
| === al-maisan is now known as almaisan-away | ||
| wgrant | What does IDS do, then? | 11:12 |
| bigjools | adding a new series is not quite the same thing, although it looks similar | 11:12 |
| bigjools | it's semantics | 11:12 |
| wgrant | Since it apparently doesn't initialise. | 11:12 |
| wgrant | Anyway, apart from semantics, how is this going to be modelled? | 11:12 |
| wgrant | Natty has two parents, only one of which should show up on +localpackagediffs. | 11:12 |
| wgrant | This table doesn't support that. | 11:13 |
| bigjools | stub: yes, should be, we just use it to indicate to various parts whether it was initialised or nto | 11:13 |
| bigjools | natty does not have 2 parents | 11:13 |
| stub | What are nattys parents btw.? Debian (mumble) and Maverick? | 11:13 |
| bigjools | it inherits from Debian, end of story. | 11:13 |
| stub | Cool. | 11:13 |
| wgrant | bigjools: But LP code needs to know that it inherits from maverick too. | 11:14 |
| bigjools | where? | 11:14 |
| bigjools | and why? | 11:14 |
| bigjools | we've already discussed this in the team | 11:14 |
| wgrant | getBuildForArch traverses the tree to avoid creating builds where one exists in an earlier series. | 11:14 |
| wgrant | That's the only case I know of off-hand. | 11:14 |
| wgrant | (that's used by createMissingBuilds) | 11:14 |
| bigjools | it doesn't need parent_series to do that | 11:14 |
| wgrant | (so please don't break it | 11:14 |
| wgrant | Oh? | 11:15 |
| bigjools | it's fairly trivial to iterate over series ... | 11:15 |
| bigjools | (in the same distro) | 11:15 |
| wgrant | Um, ew. | 11:15 |
| bigjools | dude | 11:15 |
| wgrant | What about Debian? | 11:15 |
| bigjools | sigh | 11:15 |
| wgrant | Debian isn't a series of series. | 11:15 |
| wgrant | We need to think carefully about this before we throw away a relationship that code needs!@ | 11:16 |
| stub | This is an implicit relationship because we don't have derived distros at the moment? | 11:17 |
| wgrant | It's explicit. DistroSeries.parent_series. | 11:17 |
| wgrant | natty's parent_series is maverick. | 11:17 |
| wgrant | etc. | 11:17 |
| stub | The patch is not throwing that away yet. | 11:18 |
| wgrant | It's not. | 11:18 |
| wgrant | But it seems to be suggested that this new table will supersede it. | 11:18 |
| wgrant | When it cannot. | 11:18 |
| wgrant | (without extension) | 11:19 |
| stub | Right. But if you two can't agree atm, then code can talk. Or are we talking about a more fundamental change to the data model to add in the relationship you say we need? | 11:20 |
| wgrant | I think that it's probably a good idea to get the DB patch correct now, since correcting it is slow, hard, and migrating data sucks. | 11:21 |
| bigjools | nothing is changing with parent_series right now, please stop talking about it. We're moving the concept of *tracking derived distros* to a separate table | 11:25 |
| lifeless | bigjools: is there any precedence rules between parents ? | 11:25 |
| henninge | bigjools: I just reviewed your branch for that, please have a look. | 11:25 |
| wgrant | ... to a table named DistroSeriesParent, but OK. | 11:25 |
| bigjools | henninge: not seen your review yet I am just fixing the security adapter BTW :) | 11:25 |
| bigjools | lifeless: no | 11:26 |
| henninge | bigjools: ;-) | 11:26 |
| stub | If the data model needs extension, would it actually get as far as accumulating production data? I would have thought the test suite would pick up the lack. | 11:26 |
| lifeless | wgrant: getBuildForArch has to stay in the same archive right ? | 11:26 |
| wgrant | lifeless: At the moment. | 11:26 |
| wgrant | lifeless: It's not clear how it works in a multi-archive world. | 11:27 |
| lifeless | for the use case of avoiding builds of something already in the archive | 11:27 |
| lifeless | (createMissingBuilds) | 11:27 |
| wgrant | Right. | 11:27 |
| wgrant | Probably. | 11:27 |
| wgrant | Except maybe not. | 11:27 |
| lifeless | that seems to be a definitional thing | 11:27 |
| lifeless | like | 11:27 |
| wgrant | createMissingBuilds is overcomplicated crack with triplicated checks. | 11:27 |
| lifeless | it should be 'grab the archive; for all series in the *archive* check for existing builds*' | 11:28 |
| wgrant | The behaviour in this case is not well defined. | 11:28 |
| bigjools | lifeless: the use case is that OEM will make sure packages don't get duplicated | 11:28 |
| wgrant | That may be the solution. | 11:28 |
| lifeless | bigjools: as in they will scream if we get it wrong ? ;) | 11:28 |
| wgrant | But we need to have some idea that there is an alternate solution before we go making changes that can only be fixed once a month. | 11:28 |
| bigjools | lifeless: *they* get it wrong you mean? :) | 11:28 |
| lifeless | wgrant: I grant you that | 11:28 |
| lifeless | wgrant: OTOH the field in question isn't gone yet | 11:29 |
| henninge | bigjools: I assume you are just fixing the one adapter, not all uses of check_permission? | 11:29 |
| lifeless | wgrant: its when *that* is proposed I'll start getting the padded underwear if we don't have answers for key questions | 11:29 |
| bigjools | lifeless: they have checks already to see when critical packages are superseded somewhere else, and they act on that | 11:29 |
| lifeless | wgrant: I agree that data modelling and migration is expensive | 11:29 |
| bigjools | henninge: just the one | 11:29 |
| henninge | bigjools: ok, I'll whip up a branch for a general fix. | 11:29 |
| wgrant | lifeless: I figured I might as well raise the potential issues now rather than in two months when deadlines are approaching and the data model cannot be fixed in a sufficiently timely fashion. | 11:30 |
| lifeless | wgrant: but I think putting a lot of stress on this patch isn't needed because there isn't any modelling or migration to do yet. | 11:30 |
| bigjools | henninge: you're a star | 11:30 |
| lifeless | wgrant: its good to have the conversation | 11:30 |
| lifeless | wgrant: I think it can be a little less stressful | 11:30 |
| lifeless | bigjools: I suspect we'll need to iterate on this a little; I also suspect that its got a potential boobytrap built in which is that: | 11:31 |
| lifeless | - we want an ordering of series in an archive (don't we?) | 11:31 |
| bigjools | lifeless: we already have that | 11:31 |
| lifeless | - DistroSeriesParent is cross-archive | 11:31 |
| bigjools | intentionally | 11:31 |
| lifeless | bigjools: will we still have that if we go forward and supersede .parent_series with DSP ? | 11:31 |
| lifeless | bigjools: right, I get that DSP is (and needs to be) cross-archive. | 11:32 |
| bigjools | parent_series may or may not get superseded by DSP, it's completely orthogonal to this | 11:32 |
| lifeless | bigjools: your cover letter was a bit more gung ho about that :) | 11:32 |
| bigjools | it was? :) | 11:32 |
| lifeless | 'This will eventually replace DistroSeries.parent_series as we need to track more than one parent for a derived series' | 11:33 |
| bigjools | s/will/may/ :-) | 11:33 |
| lifeless | ahhh :) | 11:33 |
| bigjools | well | 11:33 |
| bigjools | it's taken in the wrong context | 11:33 |
| wgrant | Ahh. I read it as "this is going to replace parent_series as soon as we can migrate the code" | 11:33 |
| bigjools | everyone stop | 11:33 |
| bigjools | we are currently using parent_series for 2 things | 11:33 |
| bigjools | that was a mistake | 11:33 |
| bigjools | I am migrating the 2nd usage to a separate table | 11:34 |
| bigjools | hence the language in the MP | 11:34 |
| bigjools | which I can see was rather confusing | 11:34 |
| bigjools | so my apologies for that | 11:34 |
| lifeless | bigjools: no worries | 11:34 |
| lifeless | I'm a hearty +1 | 11:35 |
| bigjools | :) | 11:35 |
| bigjools | there will be some issues around precendence I expect | 11:35 |
| lifeless | yes | 11:35 |
| bigjools | precedence, too | 11:35 |
| lifeless | but its a small table | 11:35 |
| stub | review is already in anyway :) | 11:35 |
| bigjools | but only when the versions are the same | 11:35 |
| lifeless | and you know the db deploy schedule :) | 11:35 |
| bigjools | yes :) | 11:35 |
| lifeless | a more interesting question for me is the impact on queries | 11:36 |
| lifeless | but as we haven't got this live at all its hard to tell | 11:36 |
| lifeless | you may find you want an array in DistroSeries instead. | 11:36 |
| lifeless | EFUTURE | 11:36 |
| bigjools | henninge: grar, unused setup! forgot to remove that | 11:36 |
| henninge | bigjools: I thought so | 11:37 |
| bigjools | lifeless: array column? | 11:37 |
| bigjools | *gibber* | 11:37 |
| wgrant | It's less slow. | 11:37 |
| wgrant | But a bit more evil. | 11:37 |
| stub | wgrant: You assuming or have some evidence? I haven't tested anything with arrays yet. | 11:39 |
| bigjools | henninge: for my own info, how can a separate user happen when using check_permission in the adapter? | 11:40 |
| wgrant | stub: Well, for some queries it will be quicker. If you can grab the field directly rather than joining. But for this case it shouldn't matter unless your code is terrifyingly naïve. | 11:40 |
| henninge | bigjools: I think it is more a theoretical possibility. | 11:41 |
| henninge | bigjools: still, I find it a waste that we already know the user and make the machinery go through all that again. | 11:41 |
| bigjools | henninge: it certainly has me scratching my head as to how | 11:41 |
| bigjools | yes, that is a far better reason :) | 11:42 |
| bigjools | it'll be quicker to do it that way | 11:42 |
| henninge | bigjools: could not some-one come up with code that calls checkAuthenticated directly, to check permission for another user? | 11:42 |
| henninge | In that case the adapter would still check his own permissions. | 11:43 |
| henninge | So it is also a bad interface because it pretends to do something (check permission for a given user) which it doesn't. | 11:44 |
| bigjools | I think I'd need to see an example | 11:44 |
| bigjools | but don't worryu | 11:44 |
| * bigjools thinks the "insert" button needs to hang in hell | 11:46 | |
| lifeless | henninge: bigjools: separate user cannot happen in *lp*, can happen in *zope* | 11:49 |
| lifeless | we cripple the interaction model somewhat | 11:49 |
| wgrant | But we can still call IAuthorization adapters with something other than the requesting user. | 11:49 |
| lifeless | I'd actually like to uncripple it so that we can have impersonation | 11:49 |
| bigjools | ah ok | 11:49 |
| lifeless | night all | 12:00 |
| wgrant | Night lifeless. | 12:01 |
| deryck | Morning, all. | 12:02 |
| wgrant | Hi deryck. | 12:03 |
| wgrant | Do you have any more insight into the windmill timeouts? I had to turn off YUITestLayer :/ | 12:04 |
| === almaisan-away is now known as al-maisan | ||
| deryck | wgrant, I don't, sorry. Was on vacation most of last week, so haven't really had time to look into it yet. | 12:08 |
| wgrant | Ah, sure. | 12:08 |
| LPCIBot | Project devel build #648: FAILURE in 5 hr 0 min: https://lpci.wedontsleep.org/job/devel/648/ | 12:20 |
| henninge | lifeless, bigjools: either of you want to review my branch for this? | 12:20 |
| henninge | https://code.launchpad.net/~henninge/launchpad/devel-764406-security-adapters/+merge/58109 | 12:20 |
| === mrevell is now known as mrevell-lunch | ||
| danilos | henninge, hi, I've got a nice oversized JS branch up for review :) | 12:23 |
| danilos | henninge, https://code.launchpad.net/~danilo/launchpad/bug728370-action-display/+merge/58108 if you think you'll have time for it | 12:23 |
| henninge | Hi danilos! | 12:24 |
| stub | jtv: So that final update is incorrect, because with BranchRevision the existing UNIQUE indexes are linked to UNIQUE constraints. The end result is a table that looks and smells like it has a primary key, but the pg_constraint table contains no contype='p' rows for the branchrevision table. | 12:31 |
| wgrant | henninge: Do you have any suggestions for answering the question in #launchpad? | 12:32 |
| jtv | stub: hang on, looking up the page again… did that last update constrain for contype='p'? | 12:32 |
| jtv | I thought the last update was for dependencies? | 12:32 |
| stub | jtv: Oh... it isn't the final query that is the problem. | 12:33 |
| * jtv is slightly less confused now | 12:33 | |
| jtv | stub: what query is then? | 12:34 |
| stub | I'll need to step through this some more tomorrow. At some point, the 'p' row in pg_constraint disappears. | 12:34 |
| stub | jtv: Ahh... it disappears when I drop the id column. | 12:36 |
| jtv | Hmm | 12:36 |
| jtv | I thought I transferred it to the new key. | 12:37 |
| stub | jtv: pebkac. Think I should stop now :) | 12:38 |
| jtv | stub: we should have T-shirts with a gunsight aimed at a foot (toes pointing away from the gun) and some inspirational slogan. | 12:39 |
| lifeless | 'I /hack/ on Launchpad' | 12:41 |
| bigjools | well, we have a team meeting coming up, maybe mrevell-lunch can do the bizness :) | 12:42 |
| stub | jtv: So now I end up with an index that is used by both a UNIQUE and a PRIMARY KEY constraint :) | 12:43 |
| jtv | ooh kewl | 12:43 |
| jtv | see if you can start a fire in the DC | 12:43 |
| stub | This is only visible in the pg_constraint table so non-obvious | 12:52 |
| === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === mrevell-lunch is now known as mrevell | ||
| bigjools | stub: around? | 13:29 |
| bigjools | I can't remember if unreferenced LFAs get GCed | 13:29 |
| wgrant | bigjools: Yes. | 13:30 |
| wgrant | After some timeout. | 13:31 |
| bigjools | so setting the expiry is not necessary, great | 13:31 |
| wgrant | One of the timeouts is a week, the other 24 hours. Can't remember which is which. | 13:31 |
| bigjools | expiry is a week | 13:31 |
| wgrant | This is the second step in a full garbage collection sweep. We determine | 13:32 |
| wgrant | which LibraryFileAlias entries are not being referenced by other objects | 13:32 |
| wgrant | in the database and delete them, if they are expired (expiry in the past | 13:32 |
| wgrant | or NULL), and if they have not been recently accessed (last_access over | 13:32 |
| wgrant | one week in the past). | 13:32 |
| wgrant | I always forget that detail about the expiry field. | 13:32 |
| wgrant | NULL is now. expiry is used to *extend* lifetime, not restrict it. | 13:33 |
| bigjools | fun | 13:33 |
| === Ursinha-afk is now known as Ursinha | ||
| deryck | henninge, standup ping | 14:02 |
| henninge | oh | 14:02 |
| henninge | deryck: ... | 14:03 |
| henninge | coming | 14:03 |
| henninge | deryck: notebook hang :( | 14:04 |
| === salgado is now known as salgado-lunch | ||
| jcsackett | sinzui: per chat on friday, i'm available for mumbling through permissions whenever is good for you. | 15:14 |
| * jcsackett sees sinzui is not online. stops talking. | 15:15 | |
| deryck | it feels weird sinzui not being online, doesn't it? | 15:17 |
| benji | henninge: if you get a chance, I have a branch up for review: https://code.launchpad.net/~benji/launchpad/direct-personal-subscription-actions-scaffolding/+merge/58124 | 15:31 |
| bigjools | henninge: I replied to your review | 15:32 |
| henninge | benji: did you take danilos? | 15:38 |
| danilos | henninge, he did | 15:38 |
| henninge | danilos: sorry, lunch and other things got in the way ... | 15:38 |
| danilos | but I've got another one up: https://code.launchpad.net/~danilo/launchpad/duplicate-pillars-subscriptions/+merge/58135 | 15:38 |
| adeuring | henninge, benji: could one of you please have a look at this mp: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136 ? | 15:38 |
| danilos | heh, it's getting crowded :) | 15:39 |
| henninge | danilos: I'll have a look after I replied to bigjools and looked a benji's. | 15:39 |
| danilos | henninge, thanks | 15:39 |
| === al-maisan is now known as almaisan-away | ||
| jcsackett | sinzui: per chat on friday, i'm available for mumbling through permissions whenever is good for you. | 15:48 |
| deryck | sinzui, I'd like to voice chat sometime today when you have time. no rush. Since Orange is joining Green on maintenance. | 15:58 |
| adeuring | henninge, benji, ping | 16:00 |
| henninge | bigjools: r=me, thank you ;) | 16:00 |
| henninge | adeuring: yes? | 16:00 |
| sinzui | deryck: fab, I'll be available in 15 minutes | 16:00 |
| henninge | benji: thanks for your review | 16:00 |
| benji | my pleasure | 16:00 |
| adeuring | can you have a look at this MP: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136 | 16:00 |
| adeuring | henninge: , benji: ^^^ | 16:01 |
| bigjools | henninge: and thank *you* :) | 16:01 |
| deryck | sinzui, ok, cool. Thanks! | 16:01 |
| henninge | adeuring: benj's is first | 16:02 |
| henninge | ;-P | 16:02 |
| adeuring | henninge: sure ;) | 16:02 |
| allenap | henninge, benji: Will either of you have time to review a 240-line branch? https://code.launchpad.net/~allenap/launchpad/no-diffs-for-underprivileged-bug-760648/+merge/58137 | 16:06 |
| benji | allenap: I'm sure one of us will. | 16:06 |
| allenap | Cheers :) | 16:07 |
| henninge | benji: spaces as seperator for feature flag fields work just as well. | 16:12 |
| benji | henninge: cool, I didn't know that; thanks | 16:12 |
| benji | we should ditch the tabs then; they're especially irritating in text boxes | 16:12 |
| === jkakar_ is now known as jkakar | ||
| bac | benji or henninge: could you have a look at https://code.launchpad.net/~bac/launchpad/bug-761124/+merge/58140 please? | 16:23 |
| benji | bac: sure | 16:23 |
| danilos | benji, how's the review coming along? I am about to leave so if you've still got a long way to go, I am sure gary_poster can pick it up for me :) | 16:24 |
| danilos | ah, it's there :) | 16:24 |
| benji | :) | 16:25 |
| === salgado-lunch is now known as salgado | ||
| danilos | benji, as for the whitespace, I noticed that gary_poster and I have different practices :) | 16:26 |
| benji | it's the story of our lives | 16:27 |
| danilos | benji, also, the thing jslint complains about is var not being at the top of function definition with "for (var index in ...)"; does that make sense to you as well? | 16:27 |
| LPCIBot | Project windmill build #187: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/windmill/187/ | 16:28 |
| benji | danilos: I'm not sure why it complains about that one, but I'm a make-lint-happy-unless-I-have-a-really-good-reason kind of guy, so I'd go along with it | 16:29 |
| benji | danilos: as I said, I'll be doing a big lint branch today, so no need for you to change anything | 16:29 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews | ||
| henninge | benji: I see how things are piling up but I have to run... sorry | 16:44 |
| benji | henninge: no problem, I'll plow through them | 16:44 |
| henninge | cool, thanks | 16:45 |
| henninge | ;) | 16:45 |
| sinzui | deryck: mumble? | 16:54 |
| deryck | sinzui, indeed. Firing it up now. | 16:55 |
| deryck | sinzui, meet me in the orange 1 o 1, please. | 16:55 |
| bigjools | to anyone who knows about our appserver innards, I'm seeing a request going to dogfood that is crashing out with a database IntegrityError, but no oops is generated and Apache returns a 502 proxy error. Why would it not oops? | 16:58 |
| adeuring | abentley: fancy a review of this branch: https://code.launchpad.net/~adeuring/launchpad/api-query-permissions-on-object/+merge/58136 ? (seems that henninge and benji are quite busy.) | 17:22 |
| LPCIBot | Project devel build #649: STILL FAILING in 5 hr 3 min: https://lpci.wedontsleep.org/job/devel/649/ | 17:23 |
| bigjools | good night all | 17:32 |
| abentley | adeuring: still around? | 18:08 |
| adeuring | abentley: yes | 18:08 |
| abentley | In your branch, why are you raising Unauthorized yourself instead of providing a permission checker? | 18:09 |
| === deryck is now known as deryck[lunch] | ||
| abentley | adeuring: On line 78, you mention "bug xxxxxxxxx". Have you filed a bug for that? | 18:10 |
| adeuring | abentley: gahhh, forgot that. Let me do it now... | 18:10 |
| abentley | adeuring: Also, could you use ILaunchBag.user rather than interaction.participations[0].principal? | 18:13 |
| adeuring | abentley: that was a suggestion from gary | 18:13 |
| gary_poster | argument: he is actually dealing with security machinery, so look at security machinery for value. | 18:14 |
| gary_poster | don't feel strongly about it | 18:14 |
| gary_poster | but still seems reasonable to me | 18:14 |
| gary_poster | could make for better unit tests | 18:15 |
| abentley | gary_poster: counter-argument: I've never dealt with interaction.participations[0].principal and would have to guess what it meant. | 18:15 |
| gary_poster | abentley: you are the reviewer, your call. :-) adeuring is dealing with low-level Zope security machinery here, so it seems appropriate to do what I suggested: Launchpad's overlay relly is irrelevant. <shrug> | 18:16 |
| gary_poster | really | 18:16 |
| abentley | gary_poster: If ILaunchBag.user can differ from interaction.participations[0].principal then I guess I need to understand when and how. If it can't, then I don't see why we would deviate from our usual idiom. | 18:20 |
| gary_poster | abentley, it should not within LP. "don't see why":I'll defer to you. | 18:20 |
| abentley | adeuring: please change it to ILaunchBag.user per "There should be one-- and preferably only one --obvious way to do it." | 18:22 |
| * gary_poster can't stop himself: obvious according to whom? | 18:22 | |
| adeuring | abentley: ok, I don't that much. (sorry for silence, had a phone call) | 18:22 |
| * gary_poster goes away | 18:23 | |
| abentley | gary_poster: Dutch people, apparently. | 18:23 |
| gary_poster | :-) | 18:23 |
| abentley | gary_poster: jelmer's dutch, should I ask him? | 18:23 |
| * gary_poster is half Dutch | 18:23 | |
| abentley | adeuring: In your branch, why are you raising Unauthorized yourself instead of providing a permission checker? | 18:26 |
| adeuring | abentley: oops. right... | 18:27 |
| adeuring | abentley: but then I'll finish the branch as late as tomorrow ;) | 18:29 |
| abentley | adeuring: That's okay. I've got other fish to fry today. | 18:29 |
| adeuring | ok | 18:29 |
| jcsackett | benji: super short review for you, if you have the time: https://code.launchpad.net/~jcsackett/launchpad/bug-expiration/+merge/58168 | 18:50 |
| benji | jcsackett: sure | 18:50 |
| === deryck[lunch] is now known as deryck | ||
| benji | jcsackett: done | 18:57 |
| jcsackett | benji: thanks! | 18:58 |
| === beuno is now known as beuno-lunch | ||
| mrevell | Night all | 19:20 |
| === beuno-lunch is now known as beuno | ||
| === lifeless changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews | ||
| abentley | lifeless: injecting the permissions into the json cache only helps at page load time. | 20:27 |
| abentley | lifeless: We also need to evaluate the permissions when we retrieve the objects over the web service. | 20:28 |
| lifeless | abentley: that surprises me | 20:28 |
| lifeless | abentley: can you help me understand why thats needed ? | 20:28 |
| abentley | lifeless: A +sharing-details page may start with no productseries associated with the sourcepackage. When the user adds a productseries, we need to know whether the user can change the branch associated with the productseries. | 20:29 |
| lifeless | ok | 20:30 |
| lifeless | adding a productseries is a named method right ? | 20:30 |
| abentley | lifeless: yes. | 20:30 |
| lifeless | so, I can suggest alternative implementations here | 20:30 |
| lifeless | such as return the permissions with the result of the add | 20:31 |
| lifeless | or do a separate lookup (though latency is a pain) | 20:31 |
| abentley | lifeless: Yes, the reason I asked for them to be properties was to avoid latency. | 20:31 |
| lifeless | I understand - and sympathise - the problem though is simply that lazr evaluates -all- properties every time | 20:32 |
| lifeless | and permission checks are often very expensive | 20:32 |
| abentley | lifeless: another option would be to use the json cache and then provide a way to get an updated version of the json cache. | 20:34 |
| lifeless | abentley: that sounds like an interesting approach | 20:34 |
| lifeless | because the json cache is tailored to the page AIUI | 20:34 |
| abentley | lifeless: it would slay a lot of other latency concerns I have, too. | 20:34 |
| abentley | lifeless: The json cache is tailored per-view. | 20:35 |
| lifeless | abentley: excellent! | 20:37 |
| abentley | lifeless: well, except that it's scope-creepy. | 20:38 |
| lifeless | in terms of feature delivery? I guess yes :( | 20:39 |
| abentley | lifeless: Originally, we were just going to expose Person.canWrite etc. But that doesn't work because lazr.restful doesn't support dynamic typing. | 20:41 |
| lifeless | yeah, I saw the comment | 20:43 |
| lifeless | its a shame, that would have been fairly pithy | 20:44 |
| lifeless | would still have incurred a round trip for you | 20:44 |
| lifeless | abentley: I don't want to leave you & your team hanging | 20:49 |
| lifeless | abentley: would doing a separate round trip be tolerable for the page? If so that seems like low development overhead (change the property to a method) | 20:50 |
| abentley | lifeless: We could certainly start there. | 20:51 |
| abentley | lifeless: I have no idea what the performance of the page is like on production. | 20:52 |
| lifeless | only one way to find out | 20:53 |
| abentley | lifeless: about 2 seconds. | 20:57 |
| abentley | lifeless: for natty/bzrtools on qastaging | 20:57 |
| lifeless | abentley: thats from choosing the productseries till it shows up in the form, or the initial page load? | 20:57 |
| abentley | lifeless: the former. | 20:58 |
| lifeless | if you unset it | 20:58 |
| lifeless | and set it again | 20:58 |
| lifeless | it may be faster | 20:58 |
| lifeless | qastaging only holds about 5% of the prod DB in RAM | 20:58 |
| abentley | lifeless: I did actually. | 20:58 |
| abentley | lifeless: that time's from the second run. | 20:59 |
| lifeless | ah | 21:02 |
| lifeless | doh ! | 21:02 |
| lifeless | possibly too many collections on the object being altered | 21:02 |
| lifeless | lazr restful snapshots can be reallly expensive | 21:02 |
| abentley | lifeless: You mean that the object in question has too many collections, making snapshotting expensive? You don't mean altered collections? | 21:03 |
| lifeless | right | 21:04 |
| abentley | lifeless: It looks like one of the AJAX requests is 1.2 seconds, but I can't tell what the request was. | 21:05 |
| lifeless | yeah | 21:05 |
| lifeless | thats coming | 21:05 |
| lifeless | using the chromium or firefox debug tools can give better insight, if you know you need it | 21:06 |
| abentley | lifeless: looks like setPackaging is the big delay, and that's not exactly optional... | 21:09 |
| lifeless | ah | 21:13 |
| lifeless | I'm on a call now - sorry | 21:13 |
| LPCIBot | Project windmill build #188: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/windmill/188/ | 21:58 |
| thumper | morning | 22:04 |
| === benji changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| sinzui | flacoste: are you serious should be accepted bug 728408? Lp's font size is the same as other canonical sites and the user who reported the bug did not know how to zoom his browser | 22:24 |
| _mup_ | Bug #728408: Launchpad font is far too small <Launchpad itself:Triaged> < https://launchpad.net/bugs/728408 > | 22:24 |
| sinzui | flacoste: I think huw and UX may be the only people who can say it is a bug | 22:24 |
| mwhudson | thumper: huh, the boost import failures are obscure | 22:30 |
| thumper | mwhudson: yeah | 22:30 |
| thumper | NFI what is going on there | 22:30 |
| thumper | mwhudson: any idea how we can bootstrap it? | 22:30 |
| mwhudson | thumper: if i had to guess, i would say some kind of DOS prevention on the server | 22:32 |
| mwhudson | thumper: not really | 22:32 |
| thumper | I'll look to see if they have an anon svn protocol server | 22:32 |
| thumper | that'd be faster | 22:32 |
| flacoste | sinzui: then be my guest and mark it as invalid | 22:35 |
| LPCIBot | Yippie, build fixed! | 22:37 |
| LPCIBot | Project devel build #650: FIXED in 5 hr 14 min: https://lpci.wedontsleep.org/job/devel/650/ | 22:37 |
| sinzui | jcsackett: mumble | 22:47 |
| sinzui | ? | 22:47 |
| === salgado is now known as salgado-afk | ||
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | flacoste: btw | 23:51 |
| lifeless | flacoste: bug expiry should be fixed in a day or so | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!