| sinzui | thumper: mumble? | 00:04 |
|---|---|---|
| huwshimi | sinzui: I think he's away today | 00:08 |
| === salgado is now known as salgado-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | wallyworld: I may be misunderstanding here, but picker.js' animate_validation_content and reset_form appear to be global. Is that intentional? | 01:22 |
| wallyworld | wgrant: no, they should be global but i though because they were not added to the namespace they wouldn't be exposed?? | 01:24 |
| wallyworld | should *not* be | 01:24 |
| wgrant | wallyworld: I'm not really sure how that works. | 01:26 |
| wgrant | As I said, I may be misunderstanding. | 01:26 |
| wallyworld | wgrant: i'm not sure either but i thought i was doing it correctly. that's why i've asked for a ui review cause whoever does that typically knows javascript better than me | 01:26 |
| * wallyworld sighs. doctests make me sad | 01:27 | |
| wgrant | wallyworld: I just tried it myself... it's very pretty. | 01:29 |
| wgrant | Although it has the issue that plagues most LP overlays: it resizes a lot. | 01:29 |
| wallyworld | wgrant: it was a bit of a learning curve for me but i enjoyed it. the resizing i didn't think was too obtrusive. i thought it better than leaving the overlay way too big for the content | 01:30 |
| wgrant | wallyworld: Yeah, it's a general problem that we don't really have a solution for. | 01:32 |
| wallyworld | wgrant: the animation really helps i think. not sure why but it's easier on the eye when there's resizing involved rather than something just splatting onto the screen | 01:34 |
| wgrant | Yeah. | 01:34 |
| wgrant | Although it's possibly a bit long, it looks great. | 01:34 |
| wallyworld | wgrant: i experimented with the timing. it';s easy to change. i didn't think it was too bad myself but i'll happily be guided bu someone else | 01:35 |
| wallyworld | if it's too short you don't see the effect | 01:36 |
| wgrant | wallyworld: Re-reviewed. | 01:48 |
| wallyworld | wgrant: thanks. looking now | 01:49 |
| lifeless | ok, so bugtag needs to be redesigned | 01:52 |
| wallyworld | wgrant: the use of inline styles for the buttons div was copied from an existing usage | 01:55 |
| wgrant | wallyworld: Ugh. OK. | 01:55 |
| lifeless | sinzui: still around ? | 01:55 |
| sinzui | I am | 01:55 |
| lifeless | sinzui: oh hai | 01:55 |
| lifeless | sinzui: there is a refactoring we need to do to fix performance in soyuz/recipes/translation template builds | 01:56 |
| lifeless | sinzui: I don't know if wgrant has mentioned it to you yet (or not) | 01:56 |
| wallyworld | wgrant: but we should propogate bad practice so i'll fix it | 01:56 |
| wallyworld | *shouldn't* | 01:56 |
| wgrant | wallyworld: Thanks. | 01:57 |
| wgrant | lifeless: I hadn't. | 01:57 |
| lifeless | sinzui: the BFJ/PB tables need to be folded into their adjacent tables (which are all 1:1) to permit context specific scans rather than all-builds-ever-history-scans | 01:57 |
| sinzui | lifeless: I can make those related bug the next ones to be started | 01:57 |
| wgrant | wallyworld: Oh, one other thing... are there spinners on both ends of the picker, if there is latency before it updates? | 01:57 |
| lifeless | sinzui: its going to be a new-schema, migrate-over-a-week-or-so, then start using transition job | 01:58 |
| lifeless | sinzui: I'll get a bug filed with supporting analysis and point you at it. | 01:59 |
| wallyworld | wgrant: you mean when the confirmation info is loaded? no. i don't see an obvious place to put a spinner. even though there probably should be one | 02:00 |
| wgrant | wallyworld: Yeah, that was my thought, too... it's not clear where it should be. | 02:00 |
| wallyworld | there no need for one when the user confirms the selection cause there's already one there as per a normal save | 02:00 |
| wgrant | Right. | 02:00 |
| wallyworld | if it were a desktop app i'd change the cursor | 02:01 |
| wgrant | Ouch. | 02:03 |
| wgrant | 138 / 434 Distribution:EntryResource:searchTasks | 02:03 |
| lifeless | wgrant: btw we repacked the fti index last night | 02:04 |
| wgrant | I saw that. | 02:04 |
| wgrant | And the resulting timeouts :) | 02:04 |
| wgrant | (looks like the lock was held for a little too long) | 02:05 |
| lifeless | sinzui: bug 758258 | 02:20 |
| _mup_ | Bug #758258: buildfarmjob schema is inefficient for reporting <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/758258 > | 02:20 |
| sinzui | I assigned it to the green squad | 02:20 |
| lifeless | thank you! | 02:27 |
| lifeless | its almost small enough that I tackled it mysself | 02:27 |
| lifeless | but not quite | 02:27 |
| wgrant | lifeless: Could you please mentor https://code.launchpad.net/~wallyworld/launchpad/disabled-project-bugs-shown/+merge/57265? | 02:52 |
| lifeless | wgrant: you missed a bit :) | 03:10 |
| wgrant | Mm, I guess. | 03:11 |
| wgrant | Well. | 03:11 |
| wgrant | Something has completely destroyed my monospace fonts. | 03:12 |
| wgrant | I think I may reboot and see if it is any better. | 03:12 |
| wgrant | brb | 03:12 |
| wallyworld | lifeless: the reason for just adding to the doc tests is that all the other testing for getBugTaskAndNominationViews is done there. i new unit tests were written, then the doc test would have to be ported over to keep it all together. i can do that, but it seemed like much extra work for marginal benefit | 03:14 |
| lifeless | wallyworld: I don't buy the keep it together argument | 03:14 |
| lifeless | wallyworld: given the following options: | 03:15 |
| lifeless | - a longer doctest | 03:15 |
| lifeless | - unaltered doctest and some unit tests | 03:15 |
| lifeless | - all unit tests | 03:15 |
| lifeless | clearly the third option is best | 03:15 |
| lifeless | but I argue that the second option is better than the first | 03:15 |
| wallyworld | lifeless: i agree that #1 or #3 is preferable but #2 is bad. all tests for a given piece of code should be together so they are easily discoverable etc imho | 03:16 |
| wallyworld | you don't want to fragment the tests for a given module/class all over the code base | 03:17 |
| lifeless | depends on what you value | 03:18 |
| lifeless | right now, you can't safely change that function and only run that doctest | 03:18 |
| lifeless | I think the tech debt of increasing the doctest outweighs the tech debt of having the tests in two different places | 03:18 |
| lifeless | but thats up to you, I can only share why I would do it differently. | 03:19 |
| wallyworld | lifeless: np. it's a matter of opinion in this case. i'll add a new unit test then | 03:19 |
| lifeless | wallyworld: the other issues are significantly more important :) | 03:20 |
| wallyworld | lifeless: with the filter - there was already filtering being done in the list comprehension. i just added an extra condition. | 03:20 |
| lifeless | wallyworld: I think you are reading too shallowly | 03:21 |
| lifeless | wallyworld: Thats a partition, not a filter | 03:21 |
| lifeless | or 'thats a partition special case of multiple filters' | 03:21 |
| wallyworld | my thinking was that the bugtasks were already eagerly loaded prior to the method being called. we were already extracting the ones we wanted from that list using a comprehension. why not add another condition to the filter? | 03:22 |
| lifeless | wallyworld: because: | 03:23 |
| lifeless | - things that iterate on the bugtasks will show too many | 03:23 |
| lifeless | - we'll be eager loading too much data | 03:23 |
| wallyworld | ah ok. so you want the initial loading of the self.bugtasks to be filtered | 03:24 |
| wallyworld | although these com from the context | 03:25 |
| lifeless | right, the context has the wrong bugtasks | 03:25 |
| lifeless | searchTasks knows how to do all the filtering you're doing | 03:25 |
| lifeless | (though, why are you filtering on experimental distroseries?!) | 03:26 |
| wallyworld | ok. makes more sense now. i was trying to make the smallest change to fix the reported issue | 03:26 |
| lifeless | wallyworld: I am totally in favour of doing the simplest thing that meets all the criteria | 03:26 |
| wallyworld | but in this case it made sense to look a little further afield | 03:27 |
| lifeless | I don't think that this code need sto change at all though, and the filtering rules need to be harmonised - we don't want to duplicate stuff | 03:27 |
| lifeless | note this: | 03:28 |
| lifeless | self.bugtasks = list(self.context.bugtasks) | 03:28 |
| wallyworld | yes, agreed. sometimes i'm more wary than needed for fear of breaking things like code i'm not 100% fmilar with | 03:28 |
| wallyworld | lifeless: so self.context.bugtasks a resultset then? | 03:29 |
| lifeless | wallyworld: *blink* | 03:30 |
| wallyworld | is a | 03:30 |
| lifeless | wallyworld: no, nor should it be | 03:30 |
| wallyworld | ok. a collection. which is not loaded until the list() is constructed. but we want to so a search instead | 03:32 |
| lifeless | yup | 03:32 |
| lifeless | self.context is a Bug | 03:32 |
| lifeless | so do a bugtask search with bug=self.context.id | 03:33 |
| lifeless | listify the result | 03:33 |
| wallyworld | right. i knew self.context was a bug but didn;t realise it's bugtasks would not already be loaded | 03:33 |
| lifeless | wallyworld: one of them will be | 03:33 |
| lifeless | wallyworld: (the one for the url we're on) | 03:33 |
| lifeless | wallyworld: more /may be/ - but the key thing is the eager loading | 03:33 |
| lifeless | wallyworld: see all the other work the constructor does | 03:33 |
| lifeless | wallyworld: we dont' want to do that on unwanted bugtasks. | 03:34 |
| wallyworld | sure. but i thought they would all already be loaded, hence not seeing the issue with the list comprehension. makes more sense now. | 03:34 |
| wallyworld | thanks for the input | 03:35 |
| lifeless | wallyworld: no worries | 03:35 |
| lifeless | wallyworld: the trick here when looking at other cases | 03:35 |
| lifeless | wallyworld: is to look at what *else* is done to the same data | 03:35 |
| lifeless | wallyworld: sorry that I wasn't clearer in my review; I guess I had some hidden assumptions aout what you'd looked at | 03:44 |
| wallyworld | lifeless: np. i had a wrong assumption about what had already been loaded and that lead me down an incorrect path | 03:45 |
| lifeless | wgrant: I would analyse the current searchTasks timeouts but | 04:01 |
| lifeless | bug 740750 | 04:01 |
| _mup_ | Bug #740750: API timeouts broken and returning no useful data... <regression> <Launchpad itself:Triaged> <lazr.restful:Triaged> < https://launchpad.net/bugs/740750 > | 04:01 |
| wallyworld | lifeless: turns out self.bugtasks = list(self.context.bugtasks) doesn't do any new sql cause all bugtasks are already loaded earlier. so doing a search actually *increases* the sql count. i'm tracking down where the earlier loading of all bugtasks is done | 04:40 |
| lifeless | wallyworld: traversal | 04:41 |
| wallyworld | lifeless: yeah, just got a hit on my conditional breakpoint. gotta figure out what to do about it | 04:42 |
| lifeless | wallyworld: I'd ignore it; the traversal load almost certainly doesn't do the right query | 04:47 |
| lifeless | wallyworld: and its not a significant cost | 04:47 |
| wallyworld | lifeless: in the traversal code BugTargetTraversalMixin._get_task_for_context() it just loops through bug.bugtasks, hence loading them all | 04:48 |
| lifeless | [compared to loading milestones etc for disabled rows] | 04:48 |
| lifeless | wallyworld: yup | 04:48 |
| wallyworld | lifeless: ok, will do the search. bugtaskset.search() only filters on active projects. not distroseries or productseries. i guess that doesn't matter and it's really just the active projects we care about filtering? | 04:50 |
| lifeless | wallyworld: right, I wasn't aware distros could be inactive | 04:50 |
| wallyworld | lifeless: (product|distro)series have a read only property "active" | 04:51 |
| wallyworld | set to false when the status is experimental etc | 04:51 |
| lifeless | wallyworld: ah, this is different to the pillar 'active' field I think | 04:51 |
| lifeless | wallyworld: the pillar active is set to false when we disable and hide a product/project | 04:51 |
| wallyworld | ok. that's me not fully understanding the domain model then | 04:51 |
| lifeless | or me, IMBW | 04:52 |
| lifeless | second opinon time | 04:52 |
| lifeless | wgrant: ^ second opinion plox | 04:52 |
| lifeless | wallyworld: anyhow, if we should filter more, then searchtasks should be filtering more. | 04:57 |
| lifeless | wallyworld: so useing searchtasks is right either way | 04:57 |
| lifeless | jtv: hi | 04:57 |
| lifeless | https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html | 04:57 |
| jtv | hi lifeless | 04:57 |
| lifeless | has a few patches from you needing qa | 04:58 |
| wallyworld | lifeless: agreed. i'll just leave it as is for now (filtering only on active projects) since that appears to be the issue at hand | 04:58 |
| jtv | lifeless: I shall see to it fortwith—think all of it is probably safe-to-deploy regardless of actual Q/A. | 04:59 |
| jtv | forthwith. | 04:59 |
| lifeless | jtv: cool | 04:59 |
| jtv | Thank you spell checquer. | 04:59 |
| lifeless | jtv: we have a couple of weaks (sic) :) | 04:59 |
| jtv | (sick) | 04:59 |
| jtv | Wee half er Koppel | 05:00 |
| wgrant | lifeless: Hi, sorry, having fglrx issues. | 05:01 |
| wgrant | lifeless, wallyworld: IPillar['active'] is what we want here. | 05:01 |
| wgrant | Product has a DB field, Distribution is always True. | 05:01 |
| wgrant | But it's what we want. | 05:01 |
| jtv | lifeless: the first one is the only one where deployment has any repercussions at all. | 05:01 |
| lifeless | wgrant: bugtaskset.searchtasks is required to honour this anyway | 05:02 |
| lifeless | wgrant: right? | 05:02 |
| wgrant | lifeless: I believe it is fixed, yes. | 05:02 |
| lifeless | right | 05:02 |
| lifeless | so , searchtasks ftw | 05:02 |
| lifeless | registry will be able to see the disabled tasks (which is appropriate) | 05:02 |
| wgrant | Yeah. | 05:03 |
| jtv | wgrant: the branch that gets rid of all the cache-flushing and gc'ing in the publisher… you tried it out on dogfood before it landed; did you see enough detail to know that it's safe to deploy? | 05:03 |
| * jtv corrects himself | 05:03 | |
| jtv | "that it looks reasonably safe to deploy" | 05:03 |
| wgrant | jtv: Let me just look through the diff again, but it all seemed to work OK. | 05:03 |
| wgrant | I'd like to try fully publishing lucid to get a memory worst-case, but we don't have enough disk. | 05:04 |
| wgrant | So natty will have to do, and it manages that fine. | 05:04 |
| jtv | Then I think the only reasonable concern is memory usage, which is _probably_ solved and even if it's not, we'd ultimately be better off addressing afresh. | 05:05 |
| jtv | So… let's say that makes it qa-ok. | 05:06 |
| wgrant | Right. I'm going to get it to publish natty again and watch the peak usage, but I would qa-ok it. | 05:06 |
| jtv | Thanks! | 05:06 |
| jtv | The effects won't be as dramatic as they were in the test, since we tested with the replacement publish-ftpmaster script. | 05:07 |
| jtv | That means that publish-distro will have its memory to itself, and any flushing it fails to do won't affect anything else in the procedure. | 05:07 |
| jtv | lifeless: you have a clear runway | 05:09 |
| lifeless | \o/ | 05:11 |
| lifeless | we really should finish up the lmirror stuff | 05:12 |
| wgrant | I haven't heard much about that in a while. | 05:12 |
| lifeless | I haven't had time to optimise the parser, which was the only scaling problem I recall in it | 05:14 |
| lifeless | wallyworld: ping | 05:22 |
| lifeless | wallyworld: bug 756878 | 05:22 |
| _mup_ | Bug #756878: Old bzr-builder <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/756878 > | 05:22 |
| lifeless | wallyworld: why did you close it wont fix ? | 05:22 |
| wallyworld | lifeless: there's nothing to fix? nest-part is already supported since 0.4 and the current release is 0.6 | 05:23 |
| wgrant | The bug suggests we've reverted Launchpad's. | 05:23 |
| lifeless | wallyworld: the version in natty has /nothing/ to do with what we're running on the web servers. | 05:24 |
| lifeless | wallyworld: nor with the version we run on the build slaves. | 05:24 |
| StevenK | Or on the buildds themselves, where it matters. | 05:24 |
| StevenK | lifeless: Snap | 05:24 |
| lifeless | wallyworld: both of which matter, because the one on the web server is where our validation code runs | 05:24 |
| lifeless | wallyworld: and the buildds is where the actual builds happen | 05:24 |
| wallyworld | lifeless: where do we get the package for the servers you just mentioned? | 05:25 |
| wallyworld | maybe i misunderstood the bug, sorry :-( | 05:25 |
| wgrant | The buildds use hardy-cat, the webapp should use sourcecode. | 05:25 |
| lifeless | wallyworld: there are three dependency systems we have | 05:25 |
| lifeless | wallyworld: launchpad-dependencies package | 05:25 |
| lifeless | wallyworld: utilities/sourcedeps.conf | 05:26 |
| lifeless | wallyworld: and versions.cfg | 05:26 |
| StevenK | wgrant: hardy-cat? They're still hardy? | 05:26 |
| wgrant | StevenK: Yes, until dapper dies. | 05:26 |
| StevenK | Ah | 05:26 |
| StevenK | Which is soon, I think | 05:26 |
| wgrant | Yes! | 05:26 |
| lifeless | wallyworld: so in this case, if you check utilities/sourcedeps.conf and look at the branch, you can see there is unused work on the branch | 05:27 |
| lifeless | not to mention it may be arbitrarily out of date with upstream | 05:27 |
| wallyworld | looking now | 05:27 |
| lifeless | wallyworld: in general nothing in lp will depend on current distro versions - not because we don't use them - we do, but because we're version locked, in one of those dependency tools, and we have custom archives for things that aren't present on the LTS release of the distro we are running | 05:29 |
| wallyworld | lifeless: ok. sorry. sourcedeps.conf does refer to a really ancient rev | 05:30 |
| wallyworld | should we be updating that? | 05:30 |
| lifeless | wallyworld: its only one rev back on the branch we run from | 05:31 |
| lifeless | wallyworld: but yes. | 05:31 |
| lifeless | bzr-builder is alittle more complex because you need to upgrade the web ui & the buildds separately | 05:31 |
| wallyworld | lifeless: rev 68 was around jan 2010. tip is 119 | 05:31 |
| lifeless | wallyworld: different branches | 05:31 |
| lifeless | wallyworld: you can't compare the revnos | 05:31 |
| wallyworld | lifeless: i thought i was looking just at trunk | 05:32 |
| lifeless | wallyworld: sourcedeps.conf lists a branch and a revno | 05:32 |
| lifeless | wallyworld: that branch is the lp branch, not the upstream branch | 05:33 |
| lifeless | revno: 68 [merge] | 05:33 |
| lifeless | committer: Launchpad Patch Queue Manager <launchpad@pqm.canonical.com> | 05:33 |
| lifeless | branch nick: trunk | 05:33 |
| lifeless | timestamp: Tue 2010-11-23 18:32:13 +0000 | 05:33 |
| lifeless | we're running a version merged in late november 2010 | 05:33 |
| lifeless | rev 69 | 05:33 |
| lifeless | timestamp: Tue 2010-12-07 21:24:13 +0000 | 05:33 |
| lifeless | message: | 05:33 |
| lifeless | [r=me] Update to lp:bzr-builder tip | 05:33 |
| lifeless | is available | 05:33 |
| StevenK | Isn't there some test harness thing that takes care of running scripts? I thought it was 'runscript' but I can't find it. | 05:33 |
| lifeless | and presumably there is more work in upstream trunk too | 05:33 |
| wallyworld | ok. so i'll re-open the bug | 05:33 |
| lifeless | wallyworld: checking the work missing against trunk just requires branching our branch and running bzr missing lp:bzr-builder | 05:34 |
| wallyworld | lifeless: ok. should the bug be marked as "high"? or "critical" since it affects a major lp feature? | 05:36 |
| lifeless | I don't know if we ever actually supported nest-part | 05:36 |
| lifeless | I suspect someone got mostly through upgrading but didn't quite finish it (that rev 69 in our branch) | 05:37 |
| lifeless | it may be as simple as s/68/69/ in sourcedeps.conf and send to pqm | 05:37 |
| wallyworld | well we can hope | 05:38 |
| wallyworld | i'll take a look later | 05:39 |
| huwshimi | Can someone explain to me the rules for what types of links/info we display in the sidebar? | 05:42 |
| huwshimi | or point me to a doc | 05:42 |
| wallyworld | lifeless: the gui does say "Assign", "Choose Again". but the code is generic. the labels to put on the buttons are specified by the caller | 05:55 |
| lifeless | ah, kk. | 05:56 |
| StevenK | Can haz review? | 06:02 |
| lifeless | no | 06:05 |
| lifeless | can't has | 06:05 |
| lifeless | wgrant: want to, and I"ll mentor? | 06:07 |
| wgrant | StevenK: Where is it? | 06:07 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/ids-bugfixes/+merge/57270 | 06:07 |
| lifeless | https://mail.google.com/mail/u/1/?ui=2&shva=1#inbox/12f481611058e601 | 06:07 |
| lifeless | :P | 06:07 |
| StevenK | I was so tempted to answer "On Launchpad. Duh." | 06:08 |
| wgrant | StevenK: IDSJ takes forever... the job runner won't block on that? | 06:08 |
| StevenK | wgrant: IDS or IDSJ? | 06:09 |
| wgrant | Both. | 06:09 |
| StevenK | wgrant: Oh, I should have added to the MP that I've QA'd this on dogfood before submitting. | 06:09 |
| StevenK | wgrant: But run_jobs -v initialisedistroseries is happy enough on DF | 06:10 |
| wgrant | StevenK: Oh, you give run_jobs a job type to run, it doesn't just run all of them? | 06:12 |
| StevenK | wgrant: Exactly -- the run_jobs cronscript looks pretty much identical to the one I removed, it just pulls the source interface from the schema. | 06:14 |
| === Ursinha is now known as Ursinha-afk | ||
| StevenK | wgrant: The flush did seem to be required, when running the job runner it would OOPS saying the DAS could not be found. | 06:29 |
| StevenK | wgrant: You're right, it seems it just wants ChildSeries.parent_series to get at the parent. I'd *love* to rewrite that horrible query, but it scares me. | 06:32 |
| StevenK | wgrant: That error came from i-f-p. I got Julian'd into keeping the wording when I originally did the work. | 06:33 |
| === Ursinha-afk is now known as Ursinha | ||
| StevenK | wgrant: I've reverted the Store.find() change, and fixed the query. You feel nervous about the pending builds change? | 07:21 |
| wgrant | StevenK: It has potentially disastrous consequences. | 07:21 |
| wgrant | Copying an incomplete build set is terrible terrible thing to do in the current model. | 07:22 |
| wgrant | In the worst case you can never copy that source again! | 07:22 |
| StevenK | wgrant: You know IDS just uses the package cloner, right? | 07:23 |
| wgrant | Yes. And? | 07:23 |
| StevenK | But it doesn't touch BPB at all | 07:24 |
| wgrant | createMissingBuilds does... | 07:24 |
| StevenK | So, we copy a SPPH for a source, and a BPPH for the completed i386 build, since the amd64 build is NEEDSBUILD. The package cloner calls createMissingBuilds() which creates the missing amd64 build. And this is wrong? | 07:26 |
| wgrant | StevenK: You now have two amd64 NEEDSBUILD builds in the same archive. | 07:26 |
| wgrant | One can upload, the other will fail. | 07:27 |
| wgrant | And you can never reconcile that. | 07:27 |
| StevenK | Even if they are targeted to different distroseries? | 07:27 |
| lifeless | so | 07:27 |
| lifeless | big picture, IIUC | 07:27 |
| wgrant | Same binary name in same archive = oh god what have we done | 07:27 |
| lifeless | is that we need to do this $anytime | 07:27 |
| lifeless | so waiting for quiesced == problem | 07:28 |
| wgrant | lifeless: Sure. | 07:28 |
| wgrant | But we cannot resolve this until we make binary copying not stupid. | 07:28 |
| StevenK | wgrant: Right, so it's okay, IFF it's a different archive? | 07:28 |
| lifeless | is this the same root issue as uploading to both poopies ? | 07:28 |
| wgrant | StevenK: It's not okay, it's just not definitely going to fuck shit up. | 07:28 |
| wgrant | lifeless: Not really. | 07:28 |
| wgrant | lifeless: Not at all, actually. | 07:29 |
| lifeless | wgrant: I asked because bigjools said that the upload issue and in-ui copying were the same problem | 07:29 |
| lifeless | or at least, thats what I thought he said | 07:29 |
| wgrant | lifeless: Yes, but that is a different in-UI copying issue. | 07:29 |
| wgrant | They both have the same file conflict race. | 07:29 |
| wgrant | But the race there is that the conflict will not be detected. | 07:30 |
| wgrant | Here it will be detected, but you are stuck with it forever. | 07:30 |
| lifeless | why would it create a missing build when there is a pending build? | 07:31 |
| StevenK | Because .createMissingBuilds() is dumb. | 07:32 |
| lifeless | ok | 07:32 |
| wgrant | No, because our binary copying model is dumb. | 07:32 |
| wgrant | And impossible to handle sanely. | 07:32 |
| lifeless | so given my (admittedly shallow) understanding, we have more work todo before we can do this safely. | 07:32 |
| lifeless | however | 07:32 |
| wgrant | It's going to be amusing when we have armel PPAs. | 07:32 |
| lifeless | given our isolation levels we're probably not entirely safe even when there are no pending builds | 07:33 |
| wgrant | You will no longer be able to copy between all series. | 07:33 |
| lifeless | [we only require serializable] | 07:33 |
| wgrant | Upload to one series, builds (i386, amd64, armel). Copy to hardy, creates new lpia build. Can no longer copy either, because they don't have a superset of the archive's binaries. | 07:33 |
| lifeless | argh bug 434733 comments | 07:34 |
| _mup_ | Bug #434733: marking public bug as duplicate of private bug leads to confusing UI <404> <confusing-ui> <disclosure> <lp-bugs> <privacy> <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/434733 > | 07:34 |
| StevenK | wgrant: Okay, so this obviously requires more thought. If I revert the NEEDSBUILD changes, are you broadly happy with the MP? | 07:36 |
| wgrant | StevenK: I'll look over it again, but that is indeed the only deal- and distro-breaker. | 07:37 |
| poolie_ | does https://bugs.launchpad.net/launchpadlib/+bug/758460 ring any bells? | 07:46 |
| _mup_ | Bug #758460: ConfigParser.NoOptionError: No option 'consumer_key' in section: '1' <launchpadlib :New> < https://launchpad.net/bugs/758460 > | 07:46 |
| === poolie_ is now known as poolie | ||
| StevenK | wgrant: Changes pushed, diff updated. | 07:48 |
| wgrant | StevenK: You've fixed bug #744849, right? | 07:58 |
| _mup_ | Bug #744849: populate-archive.py unusably slow <Launchpad itself:Triaged> < https://launchpad.net/bugs/744849 > | 07:58 |
| poolie | ah it's just the same as bug 745801 | 07:59 |
| _mup_ | Bug #745801: system-based authorization doesn't store useful credentials in gnome-keyring <amd64> <apport-bug> <natty> <launchpadlib :New> <python-launchpadlib (Ubuntu):New> < https://launchpad.net/bugs/745801 > | 07:59 |
| wgrant | lifeless: Can bug #637761 be closed? | 08:00 |
| _mup_ | Bug #637761: single-thread appserver experiment (rt41361) <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/637761 > | 08:00 |
| wgrant | lifeless: Given that it was the greatest success we have had in years? | 08:00 |
| lifeless | in a sense | 08:00 |
| lifeless | though we're not migrated yet | 08:00 |
| lifeless | I don't mind either way | 08:00 |
| wgrant | We've run the experiment. | 08:01 |
| wgrant | => experiment bug is old. | 08:01 |
| lifeless | wgrant: like I say, I don't mind either way | 08:04 |
| StevenK | wgrant: The branch that fixes bug #744849 landed this morning. | 08:04 |
| _mup_ | Bug #744849: populate-archive.py unusably slow <Launchpad itself:Triaged> < https://launchpad.net/bugs/744849 > | 08:04 |
| lifeless | man, conflict wise, its going to be a long month | 08:05 |
| StevenK | Argh structual-subscription.js AGAIN? | 08:05 |
| StevenK | wgrant: In fact, the fix hit stable about 30 minutes ago. | 08:06 |
| wgrant | lifeless: Yeah, it's tempting to restrict features to a single branch :( | 08:07 |
| wgrant | lifeless: Or just roll out more frequently. | 08:07 |
| wgrant | s/roll out/DB-downtime/ | 08:07 |
| StevenK | wgrant: The qa-tagger would have done that in about 30 minutes? :-) | 08:08 |
| wgrant | StevenK: Is it linked? | 08:08 |
| StevenK | [r=lifeless, wgrant][bug=744849][no-qa] ... | 08:09 |
| lifeless | wgrant: well, working on more often | 08:09 |
| wgrant | StevenK: Ah. | 08:10 |
| wgrant | lifeless: :( | 08:10 |
| lifeless | wgrant: bigger branches have worse penalties | 08:11 |
| wgrant | lifeless: One branch meaning either db-devel or devel. | 08:11 |
| wgrant | Not a single feature branch. | 08:11 |
| StevenK | Yes, a single feature branch would be crackful. | 08:12 |
| wgrant | StevenK: pre-2008-Soyuz crackful, yes. | 08:12 |
| StevenK | wgrant: You don't think the commit is needed? | 08:12 |
| wgrant | StevenK: It wasn't before, was it? | 08:12 |
| wgrant | What has changed? | 08:12 |
| StevenK | I wanted to be explicit, I guess | 08:12 |
| wgrant | Oh, did the thing at the end commit itself? | 08:12 |
| wgrant | Whereas setParent does not? | 08:13 |
| wgrant | I guess. | 08:13 |
| wgrant | That's a reasonable justification :) | 08:13 |
| StevenK | So you just withdrew your objection to the commit? | 08:13 |
| wgrant | I asked for a reason. | 08:13 |
| wgrant | You gave one! | 08:14 |
| StevenK | Well, that's sort of an objection | 08:14 |
| StevenK | The flush is due to a number of OOPS I saw on dogfood | 08:14 |
| lifeless | wgrant: oh; hmmm | 08:14 |
| wgrant | lifeless: Otherwise it's going to be a very long month on this side of the world :) | 08:15 |
| StevenK | wgrant: According to Julian, large parts of Soyuz use parent_series as a "Yes, this series is initialised." | 08:15 |
| wgrant | StevenK: Those are bugs. | 08:15 |
| StevenK | Not according to Julian. | 08:15 |
| StevenK | I've had this argument with him, I lost. | 08:15 |
| wgrant | He is going to lose to me. | 08:16 |
| wgrant | :) | 08:16 |
| lifeless | if /any/ part of the system does not honour that, using it as such a flag would be a bug. | 08:16 |
| wgrant | StevenK: Warty exists, so Soyuz does not require it. | 08:16 |
| lifeless | As there must be at least one series with no parent. | 08:16 |
| wgrant | StevenK: Warty even had lots of security uploads. | 08:16 |
| lifeless | Some part of the system cannot honour it. | 08:16 |
| lifeless | And thus using parent_series to pun with 'is initialised' is a bug. | 08:17 |
| wgrant | Precisely. | 08:17 |
| wgrant | It is both a stupid overloading and *impossible*. | 08:17 |
| StevenK | wgrant: Julian also said that if Warty was touched Soyuz would blow up. | 08:17 |
| lifeless | StevenK: add a field | 08:17 |
| wgrant | StevenK: You couldn't +edit warty for a while, no. | 08:17 |
| wgrant | StevenK: But you can do anything else to it. | 08:17 |
| StevenK | lifeless: I like that idea even less. | 08:17 |
| lifeless | StevenK: its entirely appropriate to be explicit about these things. | 08:17 |
| StevenK | The other option is IDSJ.Job.status | 08:18 |
| wgrant | DistroSeries.i_am_not_going_to_break_everything | 08:18 |
| wgrant | StevenK: No. | 08:18 |
| wgrant | StevenK: Hardy doesn't have an IDSJ. | 08:18 |
| lifeless | StevenK: whats your objection | 08:18 |
| wgrant | Even Natty probably doesn't. | 08:18 |
| StevenK | I'm just moving the set parent call to the end | 08:19 |
| === Ursinha is now known as Ursinha-afk | ||
| lifeless | StevenK: does this run as one transaction ? | 08:19 |
| StevenK | lifeless: To other useless field? DistroSeries is bloated already, and it's a use-once thing | 08:19 |
| StevenK | Once the distroseries is done initialized it's pointless | 08:19 |
| lifeless | StevenK: thats rather beside the point | 08:20 |
| lifeless | StevenK: either this thing is atomic and always consistent | 08:20 |
| lifeless | or its eventually consistent | 08:20 |
| lifeless | if its eventually consistent then the rest of the system has to handle it being inconsistent | 08:21 |
| lifeless | there are multiple ways you can do that | 08:21 |
| StevenK | lifeless: No, it doesn't run as one transaction, the package cloner calls commit a lot | 08:21 |
| lifeless | a flag which is propogated atomically once and only once the thing is consistent is a simple way to do this. | 08:21 |
| lifeless | StevenK: distroseries - the whole table - is 16kb | 08:22 |
| StevenK | Sorry, I'm not talking about the table, I'm talking about the *object* | 08:23 |
| StevenK | IDistroSeries is *enormous* | 08:23 |
| lifeless | StevenK: so, either design out the eventual consistency, or embrace it. | 08:25 |
| lifeless | StevenK: conflating 'used in a particular way' with 'has had all its initial data copied in' seems guaranteed to create boobytraps | 08:25 |
| StevenK | wgrant: So you think my reasoning is crack, and I should revert the placement of set parent? | 08:27 |
| lifeless | what we did in bzr was take out a write lock on the object and only release that when the object was usable | 08:27 |
| wgrant | StevenK: Yes. I will defeat bigjools on this if I have to. | 08:28 |
| StevenK | lifeless: Given it takes 10 minutes or more to initialise a series, I suspect you'll shoot me. | 08:28 |
| lifeless | StevenK: if you were to do one transaction, yes | 08:29 |
| wgrant | Anyone want to review https://code.launchpad.net/~wgrant/launchpad/bug-736002/+merge/57278? | 08:32 |
| jtv | wgrant: I'll trade you for this one, since you're OCR: https://code.launchpad.net/~jtv/launchpad/db-bug-752279/+merge/57277 | 08:32 |
| wgrant | I am intrigued to see how "Simplify and harden directory movements in publish-ftpmaster." works out to 819 lines. | 08:33 |
| jtv | wgrant: there's one way to find out! | 08:33 |
| wgrant | Indeed. | 08:33 |
| lifeless | wgrant: what does the executed sql look like | 08:33 |
| wgrant | http://paste.ubuntu.com/593003/ | 08:35 |
| wgrant | lifeless: WITH made the code terribly hard to work with, and this is just as fast AFAICT. | 08:35 |
| wgrant | Although the SQL is much cleaner with WITH. | 08:35 |
| lifeless | wgrant: how did it make it hard to work with ? | 08:37 |
| wgrant | lifeless: I would have had to do the union inside gUBTWOC. | 08:38 |
| jtv | wgrant: isn't "top 10 unofficial tags" a matter of querying the top 10+<#official tags> tags and eliminating the official ones? | 08:39 |
| wgrant | jtv: It is. | 08:39 |
| wgrant | But I doubt anybody will notice. | 08:39 |
| wgrant | Speed > trivialities that nobody will notice | 08:39 |
| lifeless | jtv: you'd need to query the top 20 | 08:40 |
| lifeless | jtv: and then take official + 10 more | 08:40 |
| jtv | But is it a triviality or a specialized workflow? I imagine there is a useful process of reviewing the most popular unofficial tags and blessing them. | 08:40 |
| wgrant | jtv: I considered that. | 08:40 |
| lifeless | in fact, you need to take 10 more than the count of official tags | 08:40 |
| wgrant | But decided I didn't care enough. I can do it if someone convinces me to, but it seems to be of very limited utility. | 08:41 |
| wgrant | lifeless: That's what jtv said. | 08:41 |
| jtv | :-P | 08:41 |
| lifeless | I'm slow :) | 08:41 |
| jtv | wgrant: I'm not particularly bothered, just bringing it up. Maybe we'll find we want a marker for "(unofficial)" instead or something. | 08:41 |
| lifeless | Time: 4001.783 ms | 08:42 |
| lifeless | cool | 08:42 |
| wgrant | lifeless: Is that cold? | 08:42 |
| jtv | Cool is sort of cold… | 08:42 |
| wgrant | Hot was more like 3700ms yesterday... although this is a different official tag set. | 08:42 |
| wgrant | Also the DB has been restored since then. | 08:42 |
| wgrant | So I guess that's OK. | 08:42 |
| lifeless | wgrant: hot | 08:43 |
| StevenK | wgrant: The last thing is the enormous if block -- can you suggest something? I touched it because I hated the idea of if <>: raise ; if <>: raise which is what is was before | 08:44 |
| wgrant | StevenK: You could just remove the bool() bits. | 08:45 |
| lifeless | also | 08:45 |
| wgrant | Or use any() | 08:45 |
| lifeless | only sqlobjectresultset has __nonzero__ | 08:45 |
| wgrant | Right. | 08:45 |
| lifeless | don't use it. anywhere. | 08:45 |
| wgrant | I did suggest is_empty | 08:45 |
| wgrant | So... | 08:45 |
| wgrant | if not all(map(lambda r: r.is_empty(), [foo, bar, baz]))! | 08:46 |
| StevenK | Let me get a rusty spoon | 08:46 |
| wgrant | Yes, lambda syntax is foul :( | 08:46 |
| lifeless | any(map(methodcaller('is_empty'), [foo, bar, baz])) | 08:47 |
| StevenK | wgrant: http://pastebin.ubuntu.com/593012/ | 08:47 |
| lifeless | if you're going to go functional, go all the way | 08:47 |
| wgrant | lifeless: Bah, forgot about methodcaller. | 08:49 |
| wgrant | I normally only have cause to use attrgetter and itemgetter. | 08:49 |
| wgrant | StevenK: That is using __nonzero__. | 08:49 |
| wgrant | Which I discourage, and lifeless forbids. | 08:49 |
| lifeless | we're trying to migrate to stormresultsets everywhere | 08:50 |
| lifeless | because of the storm migration | 08:50 |
| wgrant | Right. | 08:50 |
| lifeless | using __nonzero__ is a step backwards | 08:50 |
| lifeless | not to mention horribly confusing | 08:50 |
| jtv | wgrant: in your top-tags branch, is "factor" used for anything but sorting? | 08:51 |
| wgrant | jtv: It's used as size in the tag cloud. | 08:52 |
| jtv | AFAICS you could make the "bonus" that official tags clearer by adding max_count/2 to count, instead of adding 0.5 to count/max_count. | 08:52 |
| lifeless | wwwwow | 08:53 |
| lifeless | that was a fun test blowup | 08:53 |
| lifeless | File "/var/launchpad/tmp/eggs/bzr-2.2.2_lp_2-py2.6-linux-x86_64.egg/bzrlib/lazy_import.py", line 97, in _cleanup | 08:53 |
| lifeless | del self._factory | 08:53 |
| lifeless | AttributeError: _factory | 08:53 |
| lifeless | ------------ | 08:53 |
| jtv | wgrant: although maybe that just moves it closer towards the "how do we arrive at this" side at the cost of the "what does this imply for the tag clould" side. | 08:54 |
| jtv | *cloud | 08:54 |
| StevenK | Is methodcaller in 2.6? | 08:54 |
| spiv | lifeless: threading race, I guess? | 08:54 |
| wgrant | StevenK: Yes. | 08:55 |
| lifeless | spiv: https://bugs.launchpad.net/bzr/+bug/396819 | 08:55 |
| _mup_ | Bug #396819: AttributeError: _factory - lazy imports are not threadsafe <lazy-imports> <Bazaar:Confirmed> < https://launchpad.net/bugs/396819 > | 08:55 |
| spiv | lifeless: threads racing to replace a lazy import stub with a real object I guess. | 08:55 |
| jtv | Ye olde concurrent singleton update problemme | 08:55 |
| spiv | lifeless: yeah | 08:56 |
| StevenK | wgrant: Ah, it's hiding in operator. Sneaky. | 08:56 |
| StevenK | Which leads to: ForbiddenAttribute: ('is_empty', <storm.sqlobject.SQLObjectResultSet object at 0xe6cab90>) | 08:57 |
| lifeless | ughhhh | 08:57 |
| lifeless | headdesk headdesk headdesk headdesk | 08:57 |
| wgrant | StevenK: Ah, I guess SQLObjectResultSet doesn't have an is_empty :/ | 08:58 |
| wgrant | Or maybe it's just not on the interface. | 08:58 |
| lifeless | its on the interface | 08:58 |
| lifeless | bah | 08:58 |
| lifeless | not on | 08:59 |
| lifeless | it is on the class | 08:59 |
| lifeless | line 563 of sqlobject.py | 08:59 |
| lifeless | storm/zope/interfaces.py is bust | 08:59 |
| lifeless | if you want to be lazy you can add is_empty manually in lp | 09:00 |
| adeuring | good morning | 09:03 |
| jtv | hi adeuring | 09:07 |
| adeuring | good evening jtv! | 09:07 |
| jtv | new year's eve :) | 09:07 |
| adeuring | jtv: so, have a nice party! | 09:12 |
| jtv | Thanks | 09:12 |
| bigjools | good morning all | 09:13 |
| wgrant | Morning bigjools. | 09:15 |
| wgrant | jtv: Reviewed. | 09:15 |
| jtv | wgrant: thanks, that was fast. Reviewed yours as well. | 09:15 |
| === Ursinha-afk is now known as Ursinha | ||
| wgrant | jtv: Thanks. | 09:18 |
| lifeless | stub: thinking about a fact table for bug tags | 09:27 |
| lifeless | stub: I think we might also cater for milestones & bug status at the same time | 09:27 |
| lifeless | more rows (because more unique combinations) but still very few | 09:28 |
| stub | on phone | 09:28 |
| lifeless | stub: sure, no worries | 09:28 |
| wgrant | lifeless: But milestone and status are on BugTask... are they a problem? | 09:28 |
| lifeless | wgrant: so will the bug tag sumamry | 09:28 |
| wgrant | lifeless: When are milestones and statuses slow? | 09:29 |
| wgrant | We can index directly into those. | 09:29 |
| lifeless | wgrant: all the time | 09:29 |
| lifeless | we have three portlets | 09:30 |
| lifeless | all of which have now had *an* optimisation pass done | 09:30 |
| lifeless | and none of which are snappy. | 09:30 |
| lifeless | 53 / 101 Distribution:+bugtarget-portlet-tags-content you have just done | 09:30 |
| wgrant | Ah, right, that sort of query. | 09:31 |
| wgrant | I was thinking of searches. | 09:31 |
| lifeless | wgrant: status is slow when the scope is huge | 09:31 |
| lifeless | we've more work to do there, but I was thinking about the aggregate case specifically | 09:32 |
| stub | yo | 09:35 |
| stub | lifeless: This is moving towards a bugSearch table, which I've considered before. | 09:36 |
| stub | ie. throwing together the information we query on in a denormalized format suitable for querying | 09:36 |
| lifeless | stub: hmm | 09:37 |
| lifeless | stub: so we'd what - add a link to the summary row in the bugtask; so we could pick the summaries we want and search for bugs matching ? | 09:37 |
| stub | (bug, status, bugtag[], milestones[], fti, ...) | 09:39 |
| lifeless | stub: ah so - no this is different | 09:39 |
| lifeless | stub: opposite direction of denorm | 09:39 |
| stub | lifeless: Something like that. GIN indexes on the arrays should allow us to match rows containing certain milestones | 09:39 |
| stub | k | 09:39 |
| lifeless | stub: we may well need both | 09:40 |
| lifeless | stub: this is a bug that may benefit from a bugsearch table - 757426 | 09:40 |
| lifeless | bug 757426 | 09:41 |
| _mup_ | Bug #757426: Distribution:+bugs timeout with combinator ALL <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/757426 > | 09:41 |
| lifeless | (warning, eye bleeding and gouging may result) | 09:41 |
| lifeless | also bug 750445 | 09:41 |
| _mup_ | Bug #750445: MaloneApplication:+bugs timeout on 'any tag {pcert, blockshwcert}' <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/750445 > | 09:41 |
| stub | lifeless: oic. This is purely for caching the aggregate values so we don't have to calculate on the fly. | 09:42 |
| lifeless | yeah | 09:42 |
| stub | lifeless: Sure. We have some similar structures already btw. | 09:42 |
| lifeless | I'm filing a bug describing the problem clearly now | 09:43 |
| lifeless | if there is an existing one I should update, I'd be delighted to | 09:43 |
| lifeless | (existing structure) | 09:43 |
| stub | karmacache and karmatotalcache are the ones I can think of atm. | 09:44 |
| lifeless | we have some stuff shoved into pillars too | 09:44 |
| lifeless | which I think is a locking mistake | 09:44 |
| wgrant | And archives. | 09:44 |
| wgrant | And D(S)PC | 09:45 |
| jtv | wgrant: responded to your review — please let me know if you agree. Also, since this is EOW for me, any chance you could assume the Q/A burden for the combined changes to publish-ftpmaster? | 09:52 |
| wgrant | jtv: Sure. | 09:52 |
| jtv | Thanks. | 09:52 |
| wgrant | I was going to QA it myself anyway. | 09:52 |
| wgrant | Something like this.. | 09:52 |
| wgrant | jtv: Looks good. | 09:54 |
| wgrant | lifeless: Still around to mentor https://code.launchpad.net/~jtv/launchpad/db-bug-752279/+merge/57277? | 09:54 |
| jtv | wgrant: thanks. Yes, I've had to rely on you for the soyuz Q/A anyway — the difference is I may not be online to change the bug tags. :) Note that the branch actually attaches to two bugs. | 09:55 |
| lifeless | wgrant: its late; my eyes are trying to shut :) | 10:23 |
| lifeless | wgrant: I can look first thing tomorrow, or you can nab someone else to mentor | 10:23 |
| lifeless | sorry | 10:23 |
| rvba | I'd be happy if someone could give me a hand with the branch I'm working with. I've a strange problem with a test and I think the problem is either: | 10:26 |
| rvba | a) something stupid that I don't see anymore because my nose is too close to my screen | 10:26 |
| rvba | b) something wrong with the way feature flags are setup in tests | 10:26 |
| rvba | here is the MP (still in the works) https://code.launchpad.net/~rvb/launchpad/dds-stats-portlet/+merge/57280 | 10:26 |
| rvba | my problem is that this test "./bin/test -cvv test_series_views test_differences_portlet_all_differences" is failing basically the feature flag is not set. | 10:27 |
| rvba | if I remove the line "tal:condition="request/features/soyuz.derived-series-ui.enabled">" the test passes | 10:27 |
| rvba | the feature flag in the test is set the same way it's set in other tests (I think) and that's why I don't understand why it's not working. | 10:27 |
| rvba | Putting a breakpoint inside the feature flag controller code told me that, for some reason, the NullFeatureController is used ... I guess that's the reason why the feature flag is not set and the test is failing ... but can't figure out how to do it properly. | 10:27 |
| lifeless | night all | 11:03 |
| stub | jtv: So at the moment, we block dblooptuner stuff on long running transactions to avoid bloat. | 11:39 |
| jtv | stub: I'm not complaining—only about the check being cluster-wide rather than local to the database. | 11:40 |
| stub | jtv: Instead, I wonder if it is sane to occasionally check dead tuples on a specified list of tables, and if there is a large enough number, block until autovacuum can clean them up? | 11:40 |
| jtv | Risky. | 11:40 |
| stub | We have had some huge bloat on indexes and tables that have been migrated, despite the check for long running transactions. I think autovacuum is backing off because the batch job wants access. | 11:41 |
| jtv | I mean, if we get that wrong, isn't there a danger that we block just because autovacuum doesn't think it's worth cleaning up yet? | 11:41 |
| stub | Yes, so we need a higher threshold than autovacuum. | 11:41 |
| jtv | Once things get that bad though, is it really a matter for the dblooptuner? It sounds as if it might be more something we should raise alarms about and fix. | 11:42 |
| jtv | (Once the thresholds are high enough, obviously) | 11:42 |
| stub | When we raise alarms, the bloat has already happened. | 11:43 |
| stub | And cleaning it up is sometimes impossible (bloated primary key indexes for instance...) without rebuilding nodes. | 11:43 |
| jtv | I see. | 11:43 |
| stub | I suspect there is a flaw somewhere, or else autovacuum would check dead tuple counts rather than #updates. Maybe the dead tuple count doesn't get updated until autovacuum has had a look? | 11:44 |
| * stub goes to do some research | 11:44 | |
| stub | Maybe I just need to stick in delays, which would suck. | 11:45 |
| jtv | This is what I mean: I like the idea, but not the way you need to model the database's internals somewhat correctly to make it robust. | 11:45 |
| stub | jtv: The alternative is to keep the existing long running transaction checks (to cope with vacuum not doing anything useful due to the backups being in progress) and manually vacuum in dblooptuner on occasions. | 11:46 |
| jtv | BTW I'm not as deeply into this as you are, but it does sound sensible that we don't know the number of dead tuples until we've done a vacuum. And dead tuples don't really matter I guess until a "vacuum full" because until then you can't reclaim the space anyway. | 11:47 |
| jtv | I don't suppose there's some subtle tweak to count transaction time from the time an actual transaction id is assigned? | 11:47 |
| stub | dead tuples matter because when dead tuples are not converted to free space quickly enough we get bloat. | 11:48 |
| stub | jtv: Not sure if they are actually different. I just use what pg_stat_activity gives me, and if it is wrong tough because there is no other source of information :) | 11:49 |
| stub | I suspect they are the same - <IDLE> connections don't have a transaction start time | 11:51 |
| jtv | Late transaction id assignment was added pretty recently — 8.3 or so I think. Shame. :( | 11:52 |
| jtv | Nowadays, transaction ids only get assigned when the transaction starts making changes. | 11:52 |
| stub | oic. | 11:52 |
| jtv | Which I'm guessing a backup doesn't do. | 11:52 |
| stub | backup needs a consistent snapshot of the database, so vacuum can't clean up stuff until the backup transaction is completed. | 11:53 |
| === henninge_ is now known as henninge-lunch | ||
| deryck | Morning, all. | 12:07 |
| jml | deryck: good morning! | 12:18 |
| jml | deryck: I wish to talk with you | 12:18 |
| jtv | bigjools: oh! I just realized I could just compare using "IS DISTINCT FROM." That'll treat nulls as equal, but we're not going to get two nulls there. | 12:19 |
| deryck | jml, ok, let's do. mumble or chat? | 12:20 |
| bigjools | jtv: that's the same as the old code? | 12:20 |
| jml | deryck: chat. | 12:20 |
| jtv | bigjools: yup, does the same thing. | 12:20 |
| bigjools | jtv: the old *buggy* code? | 12:21 |
| jtv | bigjools: no, not _that_ old :) | 12:21 |
| jtv | This is internet time. | 12:21 |
| jtv | It does the same as the "IS NOT TRUE" expression. | 12:21 |
| jtv | But more succinctly. | 12:22 |
| jtv | (And FTR it passes tests) | 12:22 |
| * bigjools is confused! | 12:22 | |
| jtv | bigjools: IS DISTINCT FROM will return True or False. | 12:23 |
| jtv | So "'foo' is distinct from null" → true, whereas "'foo' <> null" → null | 12:24 |
| bigjools | jtv: what are you comparing? | 12:24 |
| jtv | version numbers. | 12:24 |
| jtv | One or the other may be null, that that's considered "different." | 12:24 |
| jtv | *and that's considered "different." | 12:24 |
| jtv | bigjools: oh I see what you mean now—it's the same operator that the old, deployed code uses. | 12:25 |
| jtv | Sorry, was a bit rushed. | 12:26 |
| bigjools | jtv: ok, now it makes more sense :) | 12:26 |
| * jtv blushes | 12:26 | |
| bigjools | jtv: approved the MP, thanks | 12:29 |
| jtv | thanks | 12:30 |
| === jtv is now known as jtv-afk | ||
| LPCIBot | Project devel build #630: FAILURE in 5 hr 11 min: https://lpci.wedontsleep.org/job/devel/630/ | 14:08 |
| === almaisan-away is now known as al-maisan | ||
| abentley_ | deryck: http://pastebin.ubuntu.com/593119/ | 14:32 |
| === jkakar_ is now known as jkakar | ||
| abentley | bac: I am trying to extend lazr.FormOverlay, but getting a rendering bug. I understand you've navigated these murky waters before. Could you give me a hand? | 14:42 |
| bac | abentley: sure. the work we did is in registry/javascript/structuralsubscription.js | 14:43 |
| bac | abentley: we didn't actually extend FormOverlay, though. just instantiated and used one | 14:44 |
| abentley | bac: This is what I have so far: http://pastebin.ubuntu.com/593119/ | 14:45 |
| === al-maisan is now known as almaisan-away | ||
| bac | abentley: you're going down a completely different path. it is probably the right thing to do i just haven't done it before. | 14:48 |
| abentley | bac: Okay, thanks. | 14:48 |
| === almaisan-away is now known as al-maisan | ||
| === Chex_ is now known as Chex | ||
| === salgado is now known as salgado-lunch | ||
| jkakar | Can anyone think of a reason why my launchpadlib-based code is talking to staging when I've specified LPNET_SERVICE_ROOT as the endpoint...? This is on natty with the latest updated. | 17:07 |
| === al-maisan is now known as almaisan-away | ||
| sinzui | jkakar: I am not sure, but I stopped using LPNET_SERVICE_ROOT and non-versioned scripts | 17:12 |
| jkakar | sinzui: What do you use instead of LPNET_SERVICE_ROOT? | 17:13 |
| sinzui | jkakar: I use this to be precise: | 17:13 |
| sinzui | lp = Launchpad.login_with( | 17:13 |
| sinzui | 'testing', service_root='https://api.launchpad.net', version='devel') | 17:13 |
| jkakar | I have code like this: credentials = Credentials(); credentials.load(<path-to-credentials>); return Launchpad(credentials, LPNET_SERVICE_ROOT, getCachePath()) | 17:14 |
| jkakar | sinzui: ^^ I should be using login_with instead of that? | 17:14 |
| sinzui | jkakar: I think that is a very old way of setting up credentials and oauth | 17:16 |
| === almaisan-away is now known as al-maisan | ||
| jkakar | sinzui: Okay, I'll try login_with, thanks. | 17:17 |
| sinzui | I do not see LPNET_SERVICE_ROOT in the modern version of launchpadlib | 17:17 |
| sinzui | I see staging and edge, and I know edge is dead | 17:18 |
| jkakar | sinzui: It's in launchpadlib.uris. | 17:18 |
| jkakar | sinzui: With a bunch of other odd looking stuff. :) | 17:18 |
| sinzui | I see. Yes, that is odd | 17:19 |
| bigjools | james_w: hey, got a moment? | 17:20 |
| sinzui | I like to use the real URL so that I do not need to guess what I am talking too | 17:20 |
| bigjools | jkakar: hello there, still hanging around? :) | 17:21 |
| jkakar | bigjools: Hi :) | 17:22 |
| james_w | bigjools, yeah | 17:23 |
| jkakar | sinzui: That seems to have done the trick, thanks for the advice. | 17:23 |
| bigjools | james_w: remember we talked about pockets in derived distros? Would it be a blocker for Linaro if you had to use the same pocket paradigm as Ubuntu? | 17:23 |
| james_w | bigjools, I don't think so | 17:24 |
| bigjools | james_w: you made my day | 17:24 |
| james_w | I expect OEM will be the difficulty with things like that | 17:24 |
| bigjools | yes, they are | 17:24 |
| bigjools | but we're like Cylons, we have a plan | 17:24 |
| === beuno is now known as beuno-lunch | ||
| === al-maisan is now known as almaisan-away | ||
| === deryck is now known as deryck[lunch] | ||
| === salgado-lunch is now known as salgado | ||
| jml | gah, bad punctuation. | 18:02 |
| bigjools | good night folks | 18:12 |
| === beuno-lunch is now known as beuno | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jcsackett | is anyone available to review https://code.launchpad.net/~jcsackett/launchpad/private-bugs-404 | 18:39 |
| jcsackett | it's some template changes and a test. | 18:39 |
| jcsackett | sorry, mp link is https://code.launchpad.net/~jcsackett/launchpad/private-bugs-404/+merge/57244 | 18:39 |
| === Ursinha is now known as Ursinha-afk | ||
| === deryck[lunch] is now known as deryck | ||
| LPCIBot | Yippie, build fixed! | 19:56 |
| LPCIBot | Project devel build #631: FIXED in 5 hr 7 min: https://lpci.wedontsleep.org/job/devel/631/ | 19:56 |
| sinzui | A user has errors building a recipe. https://answers.launchpad.net/launchpad/+question/152534 | 20:10 |
| sinzui | ^ I think the solution is to delete then recreate https://code.launchpad.net/~vcs-imports/bugzilla/main so that the branch is modern | 20:11 |
| jelmer | sinzui: the branch should be upgraded | 20:19 |
| sinzui | jelmer: how do I upgrade a ~vcs-imports branch | 20:19 |
| jelmer | sinzui: I've been wondering the same thing :-/ | 20:21 |
| jelmer | I think Bazaar experts can do upgrades, or at least LOSAs | 20:21 |
| sinzui | jelmer, the bzr and Lp teams might all have permission to branch, upgrade, and push to ~vcs-imports... | 20:23 |
| sinzui | which begs the question, if so, why haven't we done it for the 1000's of branchs | 20:23 |
| jelmer | sinzui: the problem is that some users of ~vcs-imports might still be using an older version of bzr that doesn't support the 2a format | 20:23 |
| jelmer | sinzui: and each upstream URL can only have one matching Launchpad branch | 20:24 |
| sinzui | jelmer :( | 20:24 |
| sinzui | I think users making recipes that using different formats will then need to do all the work to make alternate branches to ensure everything is the same format | 20:25 |
| jelmer | sinzui: it's impossible to register alternate branches at the moment as launchpad only allows one vcs import for a particular upstream URL :-/ | 20:26 |
| sinzui | right | 20:26 |
| sinzui | so the 1000s of imported branches might prove to be useless. Developers are keeping current, but we keep the formats to support old distros | 20:27 |
| sinzui | I do mean old distros because a developer can always update his tools | 20:28 |
| jelmer | sinzui: perhaps we should bring this up on the list | 20:28 |
| sinzui | I think so. I will | 20:28 |
| jelmer | sinzui: at this point or within a year from now, it's probably reasonable to require users to upgrade. It's something that we will keep hitting though as bzr adds new features | 20:29 |
| jelmer | It might well be something we can fix on the Bazaar side, by not making format changes as rigorous as they are at the moment | 20:30 |
| sinzui | Well I think the issue is a little different. Most of the vcs-imports exist to feed Ubuntu, and it only cares about new code. I think that is true of all developers. Lp should be using the latest version. bzr and Lp both need to inform users where they are using old tools and how to upgrade | 20:32 |
| lifeless | moin | 20:36 |
| lifeless | gary_poster: hi | 20:36 |
| gary_poster | lifeless, hi | 20:43 |
| timrc | sinzui: We talked awhile ago when I reported a problem with attempting to set a PPA private via launchpadlib (https://pastebin.canonical.com/46008/). The problem was linked to https://bugs.launchpad.net/bugs/724522 | 21:53 |
| _mup_ | Bug #724522: Retried transactions retry forever <canonical-losa-lp> <qa-ok> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/724522 > | 21:53 |
| timrc | sinzui: it's still not possible to make a ppa private via the api… are there plans to do this? or maybe there is a way, now, and I'm just unfamiliar with it | 21:54 |
| sinzui | timrc: I do not know the answer off hand | 21:54 |
| sinzui | oh, maybe I do. I think we verified that no, it cannot be done now | 21:55 |
| sinzui | timrc: There are no plans at the moment to allow setting a PPA private over the api. The state is bool, but making the PPA private actually requires several things to happen, among them you would need to provide a secret | 21:57 |
| cody-somerville | sinzui, I believe the secret is automatically generated (it is for the form). | 21:59 |
| timrc | sinzui: So how does launchpad achieve this? | 21:59 |
| sinzui | The view is doing lots of things | 21:59 |
| lifeless | sinzui: why can't the api generate a random secret on the server ? | 21:59 |
| sinzui | A methods must be added to archive that allows an archive to be made private | 21:59 |
| sinzui | ^ lifeless My answer remains the same | 22:00 |
| lifeless | sinzui: possible in principle but not being worked on right now ? | 22:00 |
| sinzui | lifeless: yes. I am channeling someone's voice from Soyuz. | 22:00 |
| lifeless | sinzui: cool | 22:01 |
| sinzui | I wanted to do the same and it was explained to me that there are missing steps to accomplish the bool state we see | 22:01 |
| sinzui | Oh, I can see I have search for this bug before | 22:02 |
| lifeless | bug 724740 ? | 22:02 |
| _mup_ | Bug #724740: setting a ppa private fails for commercial admins <oem-services> <Launchpad itself:Triaged> < https://launchpad.net/bugs/724740 > | 22:02 |
| sinzui | lifeless: timrc: bug 724740 | 22:03 |
| _mup_ | Bug #724740: setting a ppa private cannot be done over the API <oem-services> <Launchpad itself:Triaged> < https://launchpad.net/bugs/724740 > | 22:03 |
| cody-somerville | So sounds like a simple fix. | 22:04 |
| sinzui | bugzilla uses bzr now? | 22:06 |
| lifeless | yes | 22:06 |
| lifeless | davemiller (who registered launchpad.net/bugzilla and is a prime mover upstream) spearheaded a migration | 22:07 |
| timrc | cody-somerville: you volunteering? :) *bats eyelashes* | 22:07 |
| timrc | cody-somerville: while you're add it can you add support to enable arm builders? | 22:07 |
| timrc | s/add/at/ | 22:07 |
| sinzui | lifeless: I think I am running in circles here since I am just trying to get our copy on format 2a so that a recipe will build | 22:08 |
| lifeless | I think we need a mirrored branch | 22:10 |
| lifeless | bzr://bzr.mozilla.org/bugzilla/trunk is trunk | 22:11 |
| sinzui | yep: https://code.launchpad.net/~registry/bugzilla/trunk | 22:11 |
| sinzui | I am waiting for the import to start | 22:11 |
| lifeless | we have a typo | 22:12 |
| sinzui | This is a unholy recipe using an import from github and buzilla | 22:12 |
| lifeless | isHosted | 22:12 |
| lifeless | on https://code.launchpad.net/~registry/bugzilla/trunk/+edit | 22:12 |
| sinzui | I bet that is string concatenation in the interface. I fix my own mistake like that a few months ago | 22:13 |
| lifeless | wow, so why are they using a github branch as well... | 22:15 |
| lifeless | oh, I see | 22:16 |
| lifeless | their branch should be in the packaging namespace | 22:16 |
| lifeless | but I guess code imports don't support that yet | 22:16 |
| sinzui | lifeless: the user only knows git and is a github user. I want to try new lp features | 22:18 |
| sinzui | This has been an adventure moving from the concept of "I have code" to "lets share code" | 22:19 |
| * sinzui just fized ishosted | 22:22 | |
| lifeless | thanks! | 22:22 |
| sinzui | I have a trivial branch open as I make movies of how to use Launchpad | 22:23 |
| lifeless | can anyone make heads or tails of Bug 759160 | 22:23 |
| _mup_ | Bug #759160: normal search <Launchpad itself:New> < https://launchpad.net/bugs/759160 > | 22:23 |
| sinzui | The experience is not pleasant. I keep feeling like I have to apologies tp users | 22:23 |
| sinzui | looks like batching does not scale with that app. But is that app using Lp's API? | 22:26 |
| lifeless | sinzui: I have *no* idea | 22:26 |
| sinzui | ah | 22:26 |
| sinzui | retarget the bug to webtrees | 22:27 |
| === Ursinha-afk is now known as Ursinha | ||
| sinzui | That project was registered recently. | 22:28 |
| sinzui | The owner is not too familar with Lp | 22:28 |
| === salgado is now known as salgado-afk | ||
| groo_ | hi/2 all | 22:46 |
| groo_ | im already using LP dev | 22:46 |
| groo_ | is there a branch i could use to be able to use git nested trees? and dont get : The repository you are fetching from contains submodules. To continue, upgrade your Bazaar repository to a format that supports nested trees, such as 'development-subtree' | 22:46 |
| sinzui | groo_: I do not think bzr supports nested trees | 23:02 |
| sinzui | groo_: See http://wiki.bazaar.canonical.com/NestedTrees | 23:03 |
| lifeless | groo_: jelmer, in #bzr, can tell you more about where the progress has gotten to. | 23:04 |
| groo_ | tks lifeless, sinzui | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!