| lifeless | I can has review? https://code.launchpad.net/~lifeless/lazr.batchnavigator/keyoffset/+merge/57091 | 00:22 |
|---|---|---|
| lifeless | huwshimi: hi | 00:43 |
| huwshimi | lifeless: Morning | 00:43 |
| lifeless | huwshimi: wondering if you could eyeball bug 119939 | 00:44 |
| _mup_ | Bug #119939: strike through resolved bugs <lp-bugs> <ui> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/119939 > | 00:44 |
| lifeless | huwshimi: I closed it wontfix because its clearly easy to do if we wanted to, and multiple ui refreshes haven't don it | 00:44 |
| lifeless | but I don't have a UI analysis for why its a bad idea, and the filer is (reasonably) asking why we have chosen not to do this | 00:44 |
| lifeless | huwshimi: if I was wrong to close it and you think it would be a good idea, we can reopen easily. | 00:45 |
| wgrant | lifeless: I might point out that multiple UI refreshes also haven't made the UI not suck. | 00:45 |
| lifeless | wgrant: you might | 00:46 |
| lifeless | wgrant: and thus me talking to huw :P | 00:46 |
| lifeless | it just seemed like a bug that would never get traction - do, or do not. | 00:46 |
| lifeless | mwhudson: perhaps I can rope you in for that review ^? | 00:47 |
| huwshimi | lifeless: So, I don't think we should do the strikethrough, but it would be super useful to have some kind of indication of the status of the linked bug (e.g. on tooltip or inline: bug #1234 [won't fix]). | 00:47 |
| _mup_ | Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 > | 00:47 |
| lifeless | huwshimi: do you mean in linkification, or other places? | 00:48 |
| lifeless | fmt: and linkification have different algorithms [not necessarily for good reasons] | 00:49 |
| lifeless | huwshimi: if you look here: | 00:49 |
| lifeless | https://code.launchpad.net/~sinzui/launchpad/person-merge-job-4 | 00:49 |
| lifeless | huwshimi: the linked bugs have a mouseover status - 'critical - in progress' | 00:49 |
| huwshimi | lifeless: I think this would be appropriate in bug comments/descriptions etc. | 00:49 |
| lifeless | huwshimi: ok, thats in linkification. The good news is that I have a canned answer for you. The bad news is 'that turns out to be suprisingly expensive performance wise, back burner at best'. | 00:50 |
| huwshimi | lifeless: Yeah I suspected. | 00:51 |
| lifeless | its expensive because of bug privacy | 00:51 |
| lifeless | huwshimi: anyhow, if you could comment on that bug [which is specifically about strikethrough] or perhaps alter it to talk about freeform bug linkfication and exposing more metadata, that would be cool. | 00:52 |
| huwshimi | lifeless: I think it would be a good thing to do, but if the chances of it ever happening are slim to none then maybe we should kill the bug | 00:53 |
| huwshimi | lifeless: OK will do. | 00:53 |
| huwshimi | lifeless: maybe you should also make a note that we can not do it yet due to performance | 00:53 |
| lifeless | huwshimi: all things are possible. I have no objection to a bug open saying 'linkified bugs would be more useful if they showed bug metadata such as title, status, milestone etc' | 00:53 |
| huwshimi | lifeless: is "linkified" the correct term for this situation? | 00:54 |
| wallyworld | huwshimi: hi. do you have any css you want to give me for the confirmation dialog? | 00:55 |
| huwshimi | lifeless: As in, will other people know what we're talking about | 00:55 |
| huwshimi | wallyworld: Not yet. But I do want to give you some :) | 00:55 |
| wallyworld | np. thanks | 00:55 |
| huwshimi | wallyworld: I should be able to send you some today | 00:56 |
| wallyworld | excellent smithers | 00:56 |
| lifeless | huwshimi: it may not be the official term but its close enough | 00:57 |
| huwshimi | lifeless: Sure thanks :) | 00:57 |
| lifeless | huwshimi: we have modelled links like 'duplicate' etc | 00:57 |
| lifeless | huwshimi: and we have freeform stuff we infer by linkification | 00:57 |
| lifeless | modelled stuff already shows the metadata (on mouse over) | 00:58 |
| lifeless | wgrant: have you seen https://bugs.launchpad.net/launchpad/+bug/454307 ? | 01:00 |
| _mup_ | Bug #454307: indices/md5sums.gz doesn't match repository <lp-registry> <mirror> <Launchpad itself:Triaged> < https://launchpad.net/bugs/454307 > | 01:00 |
| wgrant | thumper: Can you QA your branch-by-ID thing? | 01:00 |
| thumper | wgrant: yeah | 01:00 |
| thumper | I think | 01:00 |
| wgrant | lifeless: Never seen that before, because it was mistriaged. | 01:00 |
| thumper | lifeless: what do we have in place for codehosting on qastaging? | 01:00 |
| wgrant | Fixed. | 01:00 |
| lifeless | wgrant: I suspected as much - chalk another one up for silos | 01:00 |
| thumper | or easier to just use staging? | 01:01 |
| wgrant | thumper: Everything. | 01:01 |
| wgrant | thumper: codebrowse you need to access by port forwarding, but everything else works. | 01:01 |
| lifeless | wgrant: is it a genuine new bug and not a duplicate? | 01:01 |
| wgrant | lifeless: I don't recall anything like it. | 01:01 |
| lifeless | wgrant: win | 01:02 |
| wgrant | ShipIt should be running for the last time right now :) | 01:02 |
| wgrant | Then we can disable and delete it. | 01:02 |
| wgrant | lifeless: Do you think https://qastaging.launchpad.net/ubuntu is OK? The "Latest derivatives" portlet is new, not flagged, probably undesirable, and mostly bad data. | 01:06 |
| wgrant | Bug #747502 | 01:07 |
| _mup_ | Bug #747502: Derived distributions must be discoverable from the "parent" distribution <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/747502 > | 01:07 |
| lifeless | wgrant: I would hesitate to ship that | 01:08 |
| wgrant | Shall I flag it? | 01:08 |
| lifeless | wgrant: please | 01:08 |
| lifeless | wgrant: also a gentle reminder to the list 'if changing existing uis with unfinished stuff, feature flag it' | 01:09 |
| wgrant | Sure. | 01:09 |
| lifeless | mwhudson: ping | 01:28 |
| mwhudson | lifeless: hi? | 01:28 |
| lifeless | mwhudson: hi; did you see my query re a small lasr.batchnavigator review ? | 01:29 |
| mwhudson | oh right, i clicked the link and then forgot about it | 01:29 |
| lifeless | heh :) thanks! | 01:29 |
| lifeless | https://github.com/defunkt/jquery-pjax#readme | 01:33 |
| poolie | hi huwshimi? | 01:34 |
| huwshimi | poolie: Hey | 01:41 |
| poolie | hey there | 01:44 |
| poolie | i had a random idea the other day; i'm not saying it's very urgent to actually do, but i just thought i'd ask you | 01:44 |
| poolie | and that was, perhaps bug heat should just be hidden from display and used only as a sort key | 01:44 |
| poolie | (and perhaps be in the api) | 01:44 |
| poolie | that would avoid some number of complaints or bugs about the absolute values and the scaling onto flames being a bit weird | 01:45 |
| poolie | (eg that they're inconsistent across pillars) | 01:45 |
| lifeless | I think thats a bad idea | 01:46 |
| lifeless | because it hides the machinery | 01:46 |
| lifeless | which makes it less understandable, and thus more frustrating when its wrong | 01:46 |
| lifeless | I think we should fix the machinery instead | 01:46 |
| poolie | but the machinery is almost entirely hidden today | 01:47 |
| poolie | it is not understandable at all | 01:47 |
| lifeless | I'm not justifying what we have | 01:47 |
| lifeless | I explaining why I think making it less visible would be a mistake | 01:47 |
| huwshimi | Interesting. I don't really know much about bug heat. What do we use it for apart from the default bugs page? | 01:47 |
| poolie | it's shown as a series of flames in some bug lists, and on bug pages | 01:48 |
| lifeless | we permit a search sorted by heat | 01:48 |
| poolie | and for sort ordering | 01:48 |
| poolie | in fact that order is a common default | 01:48 |
| lifeless | and the distro and some other teams use hot bugs as a health check | 01:48 |
| lifeless | poolie: the default sort is importance | 01:48 |
| lifeless | poolie: only the hot bugs widget sorts by heat by default | 01:48 |
| poolie | really? | 01:48 |
| poolie | because <https://bugs.launchpad.net/bzr> claims they are hot bugs | 01:49 |
| poolie | the title may be wrong | 01:49 |
| lifeless | poolie: right thats the widget | 01:49 |
| lifeless | note that it doesn't show page navigation | 01:49 |
| lifeless | it does link to a sort by heat | 01:49 |
| poolie | ok, and the 'show me more' is by heat | 01:49 |
| lifeless | but if you click on search at the top | 01:49 |
| poolie | but, you're right, 'open bugs' is by importance | 01:49 |
| lifeless | you get by importance | 01:49 |
| lifeless | etc, yes. | 01:49 |
| poolie | and, amusingly enough 'high bugs' sorts by importance too | 01:50 |
| lifeless | there is/was a bug open saying 'please show the inputs to the heat on the flames' | 01:50 |
| poolie | i might have filed it | 01:50 |
| poolie | when you say people use it as a health check | 01:50 |
| poolie | do you mean they count how many 4-flame bugs there are? | 01:50 |
| poolie | or they just look at the open bugs sorted by heat | 01:50 |
| lifeless | One of the complicating factors there is that the algorithm decays, so you can't statically calculate, you have to redo each time. | 01:50 |
| lifeless | poolie: the latter | 01:51 |
| poolie | well, my idea would keep that | 01:51 |
| lifeless | stub is investigating heat as a possible cause of index bloat | 01:51 |
| poolie | i think sorting is pretty worthwhile | 01:51 |
| poolie | i suspect showing it on the bug page is pretty much noise | 01:51 |
| lifeless | if it is, we'll need to revisit the entire implementation | 01:51 |
| lifeless | I suspect we'll get the same sort with a /little/ fuzz without the decay | 01:52 |
| lifeless | (because commenting on a bug removes the decay for a day) | 01:52 |
| poolie | anyhow, it was just a random thought | 01:52 |
| poolie | that perhaps making it serve the purpose of providing an ordering, and making it provide an absolute metric, and making it provide a scaled ranking | 01:52 |
| poolie | may be asking too much | 01:53 |
| wgrant | lifeless: https://code.launchpad.net/~wgrant/launchpad/bug-756983/+merge/57097 | 01:54 |
| poolie | lifeless, do you think anyone loves, or looks at, the flame icon? | 01:55 |
| poolie | they may well do | 01:55 |
| lifeless | wgrant: I think bigjools and raphael may be confused by your comment abot desirability | 01:55 |
| poolie | but not me | 01:55 |
| wgrant | lifeless: Possibly. | 01:55 |
| lifeless | poolie: I think that if we don't expose it, we will have questions like your one about 'sort by date changed' | 01:57 |
| lifeless | poolie: we don't expose date changed in the UI, so you can't decide if its buggy or not and you file a bug. | 01:57 |
| poolie | lifeless, if you mean the bug i filed, i think that was actually a complaint about it not being in the ui | 01:58 |
| poolie | gah, in the API | 01:58 |
| lifeless | poolie: the bug you filed was that a particular bug was sorted at the top of 'my bugs sorted by date' | 01:58 |
| poolie | well, that is just weird | 01:59 |
| lifeless | poolie: bug 752169 | 02:00 |
| poolie | it seems like there for some reason the value is correct but the sort is wrong | 02:00 |
| _mup_ | Bug #752169: wrong ordering for date_last_updated? <Launchpad itself:Triaged> < https://launchpad.net/bugs/752169 > | 02:00 |
| poolie | right | 02:00 |
| lifeless | poolie: all I'm saying is that when there is a sort order and the data behind it isn't visible, folk will get confused. | 02:00 |
| poolie | sure | 02:00 |
| poolie | i don't think the bug is very analogous | 02:01 |
| poolie | but i agree that being able to see "why is it doing that" can be good | 02:01 |
| poolie | i don't think the flames are very helpful in understanding it | 02:02 |
| poolie | i think it's more likely people will consider the numeric heat is wrong, than that lp will fail to sort integers once they have been calculated | 02:03 |
| poolie | (which seems to be happening in 752169) | 02:03 |
| lifeless | sure | 02:03 |
| mwhudson | lifeless: i don't know if you care, but ListRangeFactory.getSlice will not DTRT in size==0 and forwards=False | 02:12 |
| mwhudson | i think | 02:12 |
| mwhudson | (as in, i think it will return the whole list) | 02:13 |
| mwhudson | slicing is one of the points were one wants a negative zero | 02:13 |
| lifeless | mwhudson: I don't think we need to care; size 0 is utterly bogus anyway. | 02:14 |
| lifeless | of course, some one will trigger a timeout using that someday. | 02:14 |
| thumper | :( | 02:17 |
| thumper | lp://qastaging/ urls don't work | 02:17 |
| mwhudson | lifeless: it's almost a natural law, any code around slices will get at least one edge case a bit wrong | 02:17 |
| thumper | spm: what's the status of the staging code update? | 02:17 |
| spm | should be able to kick that off shortly actually | 02:18 |
| mwhudson | (i spent a long time fixing problems in CPython's code wrt this sort of thing) | 02:18 |
| thumper | spm: it says it is doing one now | 02:18 |
| spm | thumper: technically that's a lie, it's just the existing locks and blocks still in place from the fail on the w/e | 02:18 |
| thumper | spm: ok, so ETA? | 02:19 |
| spm | to kick it off, RSN, completion, no idea. | 02:19 |
| thumper | ok | 02:19 |
| spm | I think the last successful full restore was ages back, and rob's asked for a full in that case, so... 15-20 hours? | 02:20 |
| lifeless | mwhudson: yup, I've at least one patch in CPython for this too - on find() IIRC | 02:21 |
| lifeless | (which takes slice params, but didn't interpret them correctly) | 02:21 |
| huwshimi | wallyworld: On the dialogue do you know how to get the green bar on below the title back? | 02:21 |
| wallyworld | huwshimi: is that missing? let me look | 02:25 |
| wallyworld | huwshimi: so it is. i will figure out how to make that stay. it may be that it's tied to the "steps" node which is hidden when the confirmation is shown | 02:27 |
| huwshimi | yeah I wondered that. I had a look at the privacy dialog on the same page and it somehow manages to have it | 02:28 |
| lifeless | win | 02:30 |
| lifeless | DataError: OFFSET must not be negative | 02:30 |
| lifeless | StevenK: good morning | 02:41 |
| StevenK | Morning | 02:41 |
| thumper | lifeless: anyway to see the post params for the oops? https://lp-oops.canonical.com/oops.py/?oopsid=1131EC415 | 02:43 |
| lifeless | thumper: sure it | 02:44 |
| lifeless | s | 02:44 |
| lifeless | field.actions.* in the request variables | 02:45 |
| wgrant | It's in the URL. | 02:45 |
| thumper | ah... I see it now | 02:45 |
| lifeless | http://infram.wordpress.com/kadosu-categorized-document-search/specification-\u2026put-of-pluginsspecification-for-filtering-text-output-of-plugins | 02:45 |
| lifeless | is the problem | 02:45 |
| lifeless | erm | 02:47 |
| lifeless | wtf | 02:47 |
| lifeless | # Branch: launchpad | 02:47 |
| lifeless | # Revno: 7688 | 02:47 |
| thumper | ? | 02:47 |
| lifeless | the revno | 02:48 |
| lifeless | oh | 02:48 |
| lifeless | 2009 oops | 02:48 |
| thumper | :) | 02:48 |
| lifeless | https://lp-oops.canonical.com/oops/?oopsid=OOPS-1926EE1366 looks more interesting | 02:48 |
| thumper | :( | 02:48 |
| thumper | it seems the middle click button on my mouse is dying | 02:49 |
| lifeless | argh | 02:49 |
| lifeless | sqlobject fail fail fail fail fail fail fail fail fail fail fail | 02:49 |
| wgrant | lifeless: Oh? | 02:49 |
| lifeless | partial implementation of slice protocol | 02:50 |
| lifeless | resultset[-5:None] -> boom | 02:50 |
| lifeless | mwhudson: pushing a tweak | 03:01 |
| mwhudson | lifeless: whee! | 03:01 |
| lifeless | rule #1 if you make it look like a slice, let it damn well implement slice | 03:02 |
| * lifeless grumps | 03:02 | |
| mwhudson | lifeless: does resultset[-5:] work? | 03:02 |
| thumper | WTF? we have our own urlparse? | 03:02 |
| thumper | all it does is encode('ascii') | 03:03 |
| mwhudson | thumper: something to do with unicode | 03:03 |
| thumper | yeah, but I'm still trying to work out why we care | 03:03 |
| wgrant | We are broken and generate Unicode URLs in a lot of places. | 03:03 |
| mwhudson | the cache gets polluted with unicode objects if you feed it a unicode url | 03:03 |
| mwhudson | or did, maybe that's fixed in 2.6... | 03:04 |
| thumper | what cache? | 03:04 |
| lifeless | mwhudson: the fail is because it passes the offset down to sql unaltered | 03:04 |
| mwhudson | lifeless: lovely | 03:04 |
| lifeless | mwhudson: in principle it could reverse all the sort elements automatically and adjust | 03:04 |
| lifeless | mwhudson: -5:None = reversed[:5] afterall | 03:04 |
| wgrant | lifeless: total_size is replaced with total_size_link in recent webservice versions. | 03:05 |
| mwhudson | thumper: urlparse has a cache | 03:05 |
| wgrant | (re bug #757007) | 03:05 |
| _mup_ | Bug #757007: total_size element returned in all batch retrievals <lazr.restful:Triaged> < https://launchpad.net/bugs/757007 > | 03:05 |
| lifeless | mwhudson: I realise you're asking if __getitem__ in storm handles the second parameter differently; I haven't checked all the way | 03:05 |
| lifeless | wgrant: our tests look for total_size | 03:05 |
| lifeless | wgrant: and its still there | 03:05 |
| thumper | mwhudson: really? | 03:05 |
| thumper | WTF for? | 03:05 |
| mwhudson | thumper: beats me | 03:05 |
| lifeless | because parsing urls is slow | 03:06 |
| wgrant | lifeless: They must be using an older version. | 03:06 |
| wgrant | I forget the threshold.. possibly 1.0. | 03:06 |
| lifeless | and rather than expose a parser object with state, - win - | 03:06 |
| wgrant | first_version_with_total_size_link = "devel" | 03:06 |
| mwhudson | lifeless: yes because parsing the same url over and over again is a common case, obviously | 03:06 |
| * mwhudson coughs | 03:06 | |
| lifeless | mwhudson: if you use damaged stacks, yes. | 03:07 |
| mwhudson | thumper: looks like the bug launchpad is working around is fixed though | 03:07 |
| thumper | mwhudson: yeah | 03:07 |
| thumper | ? | 03:07 |
| lifeless | encoding a url to ascii is sensible though | 03:07 |
| lifeless | if it can't be encoded, its *not* a valid url and we should reject it. | 03:08 |
| lifeless | the stdlib url stuff is broken in many more ways than mere caching | 03:08 |
| * lifeless wouldn't ever use it by choice | 03:08 | |
| lifeless | even more sadly upstream just fundamentally don't understand what urls are. | 03:08 |
| lifeless | See the 50 mail thread or whatever was on the *worse* breaking in 3.x | 03:09 |
| thumper | lifeless: catching the unicode decode error in validate url seems pretty simple | 03:09 |
| lifeless | thumper: yup, works for me | 03:10 |
| wgrant | lifeless: A friend from uni tried to fix various bits of the 3.x stdlib URL unicode stuff... it was all pretty wrong and upstream was not at all receptive to fixing it in a reasonable way. | 03:11 |
| lifeless | s/pretty/entirely/ :) | 03:11 |
| wgrant | Yeah. | 03:11 |
| lifeless | as your friend probably knows | 03:11 |
| wgrant | I think it's less bad now, though. | 03:11 |
| wgrant | Still awful, though! | 03:11 |
| lifeless | py3 broke email, broke the web stacks. | 03:12 |
| wgrant | The latest WSGI is 3.xable, isn't it? | 03:12 |
| lifeless | I suspect so | 03:12 |
| wgrant | They finally fixed that, IIRC. | 03:12 |
| lifeless | yes | 03:12 |
| lifeless | with class sensitive string manipulation functions | 03:12 |
| wgrant | Yay | 03:13 |
| lifeless | because bytes cannot be permitted to have a find() method, obviously. | 03:13 |
| wgrant | I wish they'd backported more of the bytes API to 2.7 :/ | 03:15 |
| wgrant | Like, say, having a bytes type that indexes like a bytes, rather than making it index like a str. | 03:15 |
| lifeless | other than a misleading type alias? | 03:15 |
| wgrant | Grar. | 03:15 |
| wgrant | Exactly. | 03:16 |
| wgrant | It's an alias to something that is not at all like a bytes! | 03:16 |
| lifeless | gustavo had a pretty solid rant on this | 03:16 |
| lifeless | my opinion is that the bytes type is daft | 03:16 |
| wgrant | I ended up casting lots of stuff to a bytearray to get compatible indexing. | 03:16 |
| lifeless | mwhudson: can you check my incremental commit, see if still happy ? | 03:17 |
| mwhudson | lifeless: looking | 03:17 |
| lifeless | With that, at the cost of one more count(*) on Last links & only on Last links | 03:17 |
| lifeless | it fixes the last of the test fallout | 03:17 |
| StevenK | Is r12758 actually QA-able at all? | 03:18 |
| StevenK | It's been top of the deployment report for a few days | 03:19 |
| wgrant | StevenK: thumper was looking at it earlier. | 03:19 |
| lifeless | probably got distwacted | 03:19 |
| wgrant | The HWDB thing needs QA. | 03:19 |
| thumper | StevenK: if this is the stacking issue, yes it is qa-able | 03:19 |
| thumper | I'm wanting staging to update to poke properly | 03:20 |
| lifeless | wgrant: revno? | 03:20 |
| wgrant | r12787 | 03:20 |
| lifeless | thumper: thats going to be a day or more | 03:20 |
| lifeless | thumper: use qastaging | 03:20 |
| wgrant | Fixes the top OOPS. | 03:20 |
| mwhudson | lifeless: wow, IFiniteSequence? | 03:20 |
| mwhudson | but ok | 03:20 |
| lifeless | mwhudson: yes, really - its what the z3batch code does | 03:20 |
| mwhudson | lifeless: yes, still looks fine | 03:21 |
| lifeless | mwhudson: so I assume there is an adapter registered for result sets somewhere or other | 03:21 |
| thumper | is the branch scanner running on qastaging? | 03:30 |
| thumper | or do we need to ask? | 03:30 |
| wgrant | I'd ask. | 03:31 |
| thumper | spm: qastaging branch scanner plz | 03:33 |
| spm | thumper: it's not setup to run, is running manually atm | 03:36 |
| thumper | spm: can you please run manually? | 03:36 |
| spm | seems to be working even. /shock horr | 03:36 |
| thumper | spm: I'll be asking again in a few minutes | 03:36 |
| spm | or | 03:36 |
| spm | oh. I didn;t type that clearly. "is running manually atm" means I've kicked off a manual run already | 03:36 |
| spm | 2011-04-11 02:36:50 INFO Adding 479 new revisions. | 03:37 |
| spm | 2011-04-11 02:36:56 INFO Deleting 0 branchrevision records. | 03:37 |
| spm | 2011-04-11 02:36:56 INFO Inserting 34782 branchrevision records. | 03:37 |
| thumper | that isn't the one I wanted... | 03:37 |
| thumper | is it done? | 03:37 |
| spm | not yet | 03:37 |
| thumper | how is qastaging codehosting set up? | 03:38 |
| spm | branch scanner is "cronscripts/scan_branches.py" ? | 03:38 |
| thumper | spm: aye | 03:38 |
| thumper | spm: when you you get your new au losa? | 03:39 |
| spm | thumper: not sure what you mean? it's setup and running on tellurium. lpqastaging.tellurium.canonical.com. | 03:39 |
| wgrant | Less than a month until the new victims. | 03:39 |
| thumper | spm: as in a completely separate hosting area? | 03:40 |
| spm | I'm not sure when they start. | 03:40 |
| wgrant | May 5? | 03:40 |
| wgrant | Something like that. | 03:40 |
| wgrant | spm: ShipIt's finished. Please remove the cronjobs. | 03:40 |
| lifeless | thumper: yes | 03:40 |
| lifeless | thumper: it has its own branches and copies the same set across on restores that stging does | 03:41 |
| thumper | ok | 03:41 |
| thumper | spm: please ping when scan complete | 03:41 |
| * StevenK grumbles loudly at IDS. | 03:44 | |
| StevenK | If you pass in processor families to the package cloner, it will look up every SPPH for the destination distroseries and call .createMissingBuilds() on it. | 03:45 |
| wgrant | Yes? | 03:46 |
| spm | thumper: https://pastebin.canonical.com/45894/ | 03:46 |
| StevenK | Which is *slow* | 03:46 |
| wgrant | Yes. | 03:46 |
| StevenK | This makes me sad. | 03:46 |
| wgrant | createMissingBuilds sucks, and needs to be fixed as the next phase for some timeouts. | 03:47 |
| thumper | spm: very :(( | 03:47 |
| thumper | spm: that is because there was a scan job for a branch not copied to qastaging | 03:47 |
| thumper | spm: and the oops config isn't set for the scanner on qastaging | 03:48 |
| thumper | spm: if I said make all scan jobs as complete, could you do that without sql? | 03:48 |
| StevenK | wgrant: It might be in-scope for us, because calling .createMissingBuilds() on 17,000 SPPHs makes mawson cry. | 03:49 |
| wgrant | StevenK: Sure it's not the populate-archive bug? | 03:49 |
| wgrant | StevenK: It may not be, but getPublishedSources now preloads huge amounts of useless stuff which makes any script using it on thousands of publications completely useless. | 03:50 |
| StevenK | wgrant: lib/lp/soyuz/model/packagecloner.py, _create_missing_builds() | 03:50 |
| StevenK | The package cloner suffers from Underscore Disease. | 03:51 |
| wgrant | Yeah, p-a bug. | 03:51 |
| wgrant | It's still slow, but not that slow. | 03:51 |
| wgrant | Cowboy the patch from https://wiki.canonical.com/IncidentReports/2011-03-29-LP-populate-archive-slow | 03:51 |
| wgrant | spm: Hi, I need a cronjob run on qas. | 03:52 |
| wgrant | 'scripts/process-hwdb-submissions.py -vv', and I'd like the output. | 03:52 |
| StevenK | wgrant: Because eager loading fixes everything. :-( | 03:53 |
| wgrant | StevenK: Yes. | 03:53 |
| lifeless | StevenK: its a key tool | 03:55 |
| lifeless | the problem is that an object model assuming cheap lookups is broken in the real world. | 03:55 |
| spm | thumper: "if I said make all scan jobs as complete, could you do that without sql?" Um. I dunno .but we can use sql on qas? | 03:55 |
| thumper | spm: I'll get back to you shortly | 03:55 |
| spm | np | 03:56 |
| StevenK | lifeless: The problem is the eager loading breaks at least parts of Soyuz. | 03:56 |
| StevenK | s/parts/two parts/ | 03:56 |
| spm | wgrant: do you expect lots of output, or just a little? ie log or screen gab | 03:56 |
| lifeless | StevenK: thats the symptom | 03:56 |
| wgrant | spm: I'm not entirely sure. Might be best to log. | 03:56 |
| spm | okidoki | 03:56 |
| lifeless | StevenK: the problem is that a single api was used when there are different usecases at hand. | 03:56 |
| wgrant | spm: It depends how the DB was when qastaging was restored. | 03:56 |
| wgrant | lifeless: The use-cases were identical. | 03:57 |
| wgrant | lifeless: But now we have a policy of eager loading. | 03:57 |
| wgrant | So they differ. | 03:57 |
| lifeless | wgrant: they weren't really identical, the differentiation was around performance | 03:58 |
| spm | wgrant: ftr: ~/tmp/wgrant-process-hwdb-submissions.log | 03:58 |
| spm | ahh. cronscripts/process-hwdb-submissions.py would work better | 03:59 |
| wgrant | spm: Er, yes, sorry. | 03:59 |
| StevenK | lifeless: The only things that required the eager loading were the callsites that directly impacted on render times. .getPublishedSources() is called from other places, too. | 04:00 |
| spm | wgrant: heh, is cool. it was third time lucky in any event. '/cripts/process...' didn't work either. :-) | 04:00 |
| lifeless | StevenK: it required eager loading because it was making things slower for render times | 04:00 |
| lifeless | StevenK: I agree that other places were negatively impacted | 04:00 |
| spm | wgrant: argh. one sec. will fix. FATAL: Ident authentication failed for user "hwdb-submission-processor" | 04:01 |
| StevenK | Yes, hence my "directly impacted on render times" | 04:01 |
| * spm pulls out the yak clippers | 04:01 | |
| lifeless | StevenK: the function I change directly impacted render times. | 04:01 |
| StevenK | Perhaps we change the internal API of .getPublishedSources() to take a eagerload boolean, and it can return early if it's False (and it defaults to True) | 04:03 |
| StevenK | It's not particularly elegant, but it solves both cases. | 04:03 |
| lifeless | StevenK: sure, thats what we've done elsewhere. | 04:05 |
| lifeless | StevenK: I didn't here because of oversight, not intent | 04:05 |
| lifeless | StevenK: the scripts weren't visible to me when I grepped around quickly, for $whatever reason. | 04:05 |
| spm | wgrant: https://pastebin.canonical.com/45895/ | 04:07 |
| wgrant | spm: Thanks. | 04:07 |
| * StevenK looks for the p-a bug | 04:08 | |
| wgrant | spm: Do you want an RT for killing the shipit cronjobs? Or will the existing shipit cleanup one do? | 04:08 |
| spm | the existing covers it | 04:08 |
| StevenK | wgrant: Hm, does the p-a slowness even have a bug? | 04:09 |
| wgrant | StevenK: Bug #744849 | 04:09 |
| _mup_ | Bug #744849: populate-archive.py unusably slow <Launchpad itself:Triaged> < https://launchpad.net/bugs/744849 > | 04:09 |
| StevenK | Bah, that didn't show up when I searched for populate-archive | 04:10 |
| StevenK | wgrant: Thanks, I'll look at it after lunch. | 04:11 |
| huwshimi | wallyworld: Did you have any luck with that border? | 04:23 |
| wallyworld | huwshimi: yes. all good. i've improved the animations and also provided animation for when the user hits "no". all i need now is some css for the confirmation content and i can submit the mp | 04:24 |
| huwshimi | wallyworld: Is all that pushed to your branch? | 04:24 |
| wallyworld | huwshimi: yes | 04:24 |
| huwshimi | wallyworld: Thanks I'll take a look | 04:25 |
| wallyworld | huwshimi: the mp is also written but on hold so you can see that too if you want | 04:25 |
| wallyworld | huwshimi: sorry, i wasn't aware you were waiting to hear back from me | 04:25 |
| huwshimi | wallyworld: That's ok I just wanted to see how it looked with the bar added | 04:27 |
| thumper | lifeless: https://code.launchpad.net/~thumper/launchpad/fix-unicode-error-in-urlparse/+merge/57103 | 04:30 |
| huwshimi | wallyworld: How about something like this: http://imgur.com/KVM6j | 04:40 |
| wgrant | Do we want "Yes"/"No" rather than "Assign"/"Cancel"? | 04:42 |
| lifeless | no | 04:43 |
| lifeless | assign / do not assign | 04:43 |
| wgrant | Right, or that. | 04:43 |
| lifeless | huwshimi: ^ | 04:43 |
| wgrant | But definitely not "Yes"/"No", | 04:43 |
| lifeless | huwshimi: gnome did a bunch of user testing | 04:43 |
| lifeless | huwshimi: and yes/no prompts are very effective at confusing users | 04:43 |
| wgrant | lifeless: $ACTION/"Cancel" is used everywhere else in LP, so I'm leaning towards that. | 04:43 |
| lifeless | wgrant: the cancel is about as good as No | 04:44 |
| wgrant | It is. | 04:44 |
| lifeless | wgrant: it makes me take a second-glance all the time :( | 04:44 |
| huwshimi | lifeless: wgrant: OK, but that's not what the screenshot was about at all. | 04:44 |
| wgrant | Then there was that infamous HIG-compliant download manager a few years ago... | 04:44 |
| lifeless | huwshimi: heh, what was it about ? | 04:44 |
| lifeless | oh, I see | 04:45 |
| thumper | lifeless: ta | 04:45 |
| lifeless | wallyworld: ^ ^ ^ ^ | 04:45 |
| lifeless | thumper: de nada | 04:45 |
| huwshimi | lifeless: I was just trying to improve some CSS | 04:45 |
| lifeless | huwshimi: yeah, I'm caught up now | 04:46 |
| huwshimi | lifeless: I think it's a fair call though | 04:46 |
| lifeless | wgrant: http://projects.gnome.org/gwget/screenshots.html ? | 04:46 |
| wgrant | lifeless: That's the one. | 04:46 |
| * wallyworld just finished some food | 04:46 | |
| wgrant | But the screenshot is not there any more :( | 04:46 |
| wgrant | https://bugs.launchpad.net/ubuntu/+source/gwget2/+bug/84215/+attachment/30855/+files/Screenshot-gwget.png | 04:47 |
| _mup_ | Bug #84215: Do you want to Cancel or Cancel? <gwget2 (Ubuntu):Fix Released> < https://launchpad.net/bugs/84215 > | 04:47 |
| wallyworld | huwshimi: that screenshot looks pretty good | 04:47 |
| lifeless | wgrant: ROTFL | 04:47 |
| huwshimi | wallyworld: There was a small HTML change. I'll push my changes. Also did you see what lifeless and wgrant were just saying about the buttons? | 04:48 |
| wallyworld | huwshimi: yes. so looks like i'll make it "Assign" / "Do Not Assign" ? | 04:49 |
| wgrant | Sounds good. | 04:49 |
| huwshimi | wallyworld: Actually in this case I'm not sure "Do Not Assign" makes sense. The action that it makes is "go back so I can fix it". | 04:51 |
| lifeless | its a popup right ? | 04:51 |
| huwshimi | lifeless: Yes. | 04:51 |
| wallyworld | huwshimi: yes, you are right. so it should be something like "Choose Again" ? | 04:51 |
| lifeless | wallyworld: sounds good | 04:52 |
| huwshimi | wallyworld: Yeah something like that... | 04:52 |
| wallyworld | huwshimi: thanks for the input btw | 04:52 |
| huwshimi | wallyworld: np | 04:55 |
| huwshimi | wallyworld: Here are my changes: https://code.launchpad.net/~huwshimi/launchpad/assign-non-contributor | 04:56 |
| * wallyworld merges | 04:57 | |
| wallyworld | huwshimi: that css style is used elsewhere. i was just reusing an existing one. i'll make a new one with your style attributes | 04:59 |
| huwshimi | wallyworld: Oh right | 04:59 |
| huwshimi | wallyworld: Yeah, good plan :) | 05:00 |
| wallyworld | :-) | 05:00 |
| lifeless | mwhudson: https://bugs.launchpad.net/storm/+bug/239767 | 05:01 |
| _mup_ | Bug #239767: Negative Indexing on results fails <Storm:New> < https://launchpad.net/bugs/239767 > | 05:01 |
| lifeless | StevenK: I have updated my lazr.batchbavigator branch to fix test failures and use 1.2.4 | 05:01 |
| lifeless | StevenK: do you care to rereview? | 05:01 |
| huwshimi | A review of this would be super great: https://code.launchpad.net/~huwshimi/launchpad/privacy-notification-firefox-753423/+merge/56872 | 05:16 |
| lifeless | jtv: hey, do you have write access on http://wiki.postgresql.org/wiki/Index_Maintenance ? | 05:17 |
| * jtv tries | 05:17 | |
| jtv | Oh, that wiki? | 05:17 |
| jtv | Err | 05:17 |
| lifeless | jtv: if so the first query there is much more useful with 'ORDER BY pg_class.reltuples::bigint' rather than 'order by 2' | 05:17 |
| jtv | If I could remember my login details, maybe. :/ | 05:17 |
| jtv | Why would anyone want to order by 2? | 05:19 |
| lifeless | that uses the second column | 05:19 |
| lifeless | but its pretty printed | 05:19 |
| jtv | Oh, yeah, unsurprisingly I wasn't aware of that feature. | 05:19 |
| lifeless | so it orders 100MB before 2kb | 05:19 |
| lifeless | jtv: old school sql ;P | 05:20 |
| lifeless | jtv: none of these fancy column names | 05:20 |
| jtv | Had to do so much of that before they ever let me touch a database… hundreds of select queries just written out on paper. | 05:20 |
| jtv | Looks like the added the pg_size_pretty later and forgot to update the ORDER BY | 05:21 |
| jtv | lifeless: you'll have better luck in #postgresql :) | 05:22 |
| lifeless | yeah | 05:24 |
| jtv | Where I also have some questions to ask, actually, but I've been too lazy or shy to do it. | 05:32 |
| jtv | Such as: why does the background writer work out of the buffer cache instead of out of the WAL (and so, why do we need dirty bits for committed pages)? | 05:33 |
| jtv | Sure, making it eat from the WAL would make it take longer for pages to get into tables, but so what? Changes are already logged. But I'm guessing that flushing could be more efficient if it weren't driven by eviction policy. | 05:35 |
| lifeless | StevenK: hi | 05:36 |
| StevenK | Damn it, I knew talking would get me on the hook for a review. :-P | 05:36 |
| StevenK | lifeless: Link me | 05:36 |
| lifeless | https://code.launchpad.net/~lifeless/launchpad/bug-752153/+merge/56505 | 05:37 |
| StevenK | lifeless: Which revisions are new, and can you provide a partial diff? | 05:38 |
| lifeless | 12760-> | 05:39 |
| lifeless | isn't lp meant to do incremental diffs | 05:39 |
| wgrant | lifeless: yes, but it's disabled because they're slightly broken. | 05:40 |
| wgrant | IIRC they had excessive mode changes. | 05:40 |
| lifeless | StevenK: http://bazaar.launchpad.net/~lifeless/launchpad/bug-752153/revision/12762?remember=12759&compare_revid=12759 | 05:40 |
| wgrant | But it was enabled for a few days, so it's disablement probably counts as a regression. | 05:40 |
| StevenK | I wonder how I can hide an argument from the API | 05:40 |
| lifeless | StevenK: give it a default value | 05:41 |
| lifeless | StevenK: and don't list it in the export parameters list | 05:41 |
| wgrant | StevenK: Which arg? For getPublishedSources? | 05:41 |
| StevenK | Right, so I'm fine. | 05:41 |
| StevenK | wgrant: Yup | 05:41 |
| wgrant | StevenK: As lifeless says, make sure it has a default and don't list it in @operation_paramters | 05:41 |
| wgrant | +e | 05:41 |
| StevenK | wgrant, lifeless: http://pastebin.ubuntu.com/592452/ | 05:42 |
| StevenK | lifeless: You're ripping out a lot of code from lp.app.browser.root, can you explain a little context? | 05:43 |
| lifeless | StevenK: that was the copied code that was fugly | 05:43 |
| lifeless | StevenK: since I had to touch lazr.batchnavigator more, I refactored to let it be deleted. | 05:43 |
| lifeless | see the comment with the pylint supressor | 05:43 |
| StevenK | Right | 05:44 |
| StevenK | Why self.default_size = 20 and then right after 'return 20' ? | 05:44 |
| lifeless | StevenK: the function needs to set both | 05:44 |
| lifeless | StevenK: thats explained in the docstring in the base class | 05:45 |
| StevenK | lifeless: But if you return self.default_size, it only needs to be changed in one place? | 05:45 |
| lifeless | StevenK: 1 line apart, and this is shorter. | 05:45 |
| wgrant | wallyworld: Could you use an API call instead of BugContributorView? | 05:46 |
| StevenK | Okay, it makes me grumble, but it looks good. | 05:46 |
| lifeless | StevenK: thanks | 05:46 |
| lifeless | next up, to teach lazr.restful to allow custom IRangeFactory | 05:46 |
| wallyworld | wgrant: i considered that. i went with the view because the result of the call was related to getting data for display, a json dict of values | 05:47 |
| wgrant | wallyworld: Don't you already have the person and pillar names? | 05:48 |
| lifeless | that should so totally be an API, but lazr.restful doth not make it easy. | 05:49 |
| wgrant | lifeless: Oh? | 05:49 |
| wallyworld | wgrant: nope. not in the view | 05:49 |
| wallyworld | lifeless: yes. hence the view :-) | 05:49 |
| lifeless | wgrant: it wants to return typed objects only | 05:49 |
| wgrant | lifeless: It'll happily return an untyped dict. | 05:49 |
| wgrant | Soyuz does it in a few places. | 05:49 |
| wgrant | It's not pretty, but it works fine. | 05:49 |
| lifeless | wgrant: oh? I just recall jml headbutting making that work here and on the list in the past | 05:50 |
| wgrant | wallyworld: The picker must already have the person displayname, and surely the task table knows the pillar displayname somewhere? | 05:50 |
| lifeless | wgrant: whats the necessary dance ? | 05:50 |
| wgrant | lifeless: Right, you can't return a dict of entries. | 05:50 |
| wgrant | lifeless: They'll just end up as strings instead. | 05:50 |
| wallyworld | wgrant: that's internal to the picker. the user of the picker only has the person uri | 05:50 |
| wgrant | But if you leave the return type undeclared and just return a dict, the client will get it and just JSON decode it. | 05:51 |
| lifeless | wgrant: cool | 05:51 |
| wgrant | wallyworld: Hmm, that's pretty terrible. Not easily fixable to return the whole object? I imagine that could be generally useful. | 05:52 |
| wgrant | Anyway, if you really can't refactor the machinery to let you get at the existing cached objects, this can easily be an API namedop, and that'd probably be better than manual JSON encoding and content-type hackery. | 05:53 |
| wallyworld | wgrant: we don't have the whole person object. the picker has a vocab with terms and that's it | 05:53 |
| wgrant | :( | 05:53 |
| wallyworld | wgrant: my first implementation was via a named op - had to modify client.js slightly to allow sync calls - but i had trouble with lazr restful | 05:55 |
| wallyworld | wgrant: can you poin tme to the soyez example? | 05:55 |
| wgrant | wallyworld: Synchronous calls are never OK. | 05:55 |
| wgrant | They block the browser UI in !Chrome. | 05:55 |
| lifeless | jtv: Can I sanity check something with you | 05:55 |
| * jtv seems an odd choice for sanity | 05:55 | |
| jtv | but yes, you can try | 05:55 |
| lifeless | jtv: did you see my sketched fact table for bugtags | 05:56 |
| wallyworld | wgrant: i need the validation call lthe block otherwise it all falls into a heap | 05:56 |
| jtv | No | 05:56 |
| wgrant | wallyworld: :/ We really really really want to avoid using sync anywhere. | 05:56 |
| lifeless | jtv: ah. So, I've sketched a fact table out for bugtags, maintained with triggers I expect, and I can't get it out of my head. | 05:56 |
| jtv | lifeless: "fact table"? | 05:57 |
| lifeless | jtv: http://en.wikipedia.org/wiki/Fact_table | 05:57 |
| jtv | thx | 05:57 |
| lifeless | jtv: the centre table in a star schema | 05:57 |
| jtv | lifeless: are you saying you've been looking at the same problems I wrote about yesterday? | 05:57 |
| wallyworld | wgrant: hmmm. from memory that will make this change very hard to deliver without really fucking with the picker internals :-( i'll have a look | 05:57 |
| lifeless | jtv: all week | 05:57 |
| lifeless | jtv: as has wgrant | 05:57 |
| jtv | ah! then sorry for the duplication | 05:58 |
| jtv | or noise, or whatever | 05:58 |
| lifeless | jtv: more eyeballs good | 05:58 |
| jtv | yeah, I could do with some better ones | 05:58 |
| lifeless | jtv: with timeouts, I do a sweep each day and make sure they are reported on https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout | 05:58 |
| lifeless | jtv: with the pageid from the oops summary in the bug title | 05:58 |
| wgrant | wallyworld: It's particularly cool in Firefox, since the XUL runs in the same thread as page JS. | 05:59 |
| lifeless | jtv: this particular one had not had the analysis updated in the bug :( - so looking there wouldn't have helped you know that folk were caring | 05:59 |
| wgrant | wallyworld: So a synchronous call will actually freeze the browser. | 05:59 |
| lifeless | jtv: but I like that you analysed it - good stuff | 05:59 |
| wallyworld | wgrant: well that blows. | 05:59 |
| jtv | lifeless: well I knew folks would care, but I thought maybe this was the outcome of a recent round of work. And since it was a holiday, I didn't bother looking very far. :) | 05:59 |
| jtv | Anyway, about that fact table..? | 05:59 |
| wgrant | wallyworld: Although it's possibly better now, and should be even better in 5. | 05:59 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/getpublishedsources-too-eager/+merge/57107 | 06:00 |
| lifeless | jtv: anyhow, my question is, if one has an aggregate cached in a lookaside table, - which my volume column is, is it concurrency safe in postgresql (with repeated reads, which is I think the level we run at) to maintain that via triggers | 06:00 |
| wallyworld | wgrant: seems like a hell of a lot of work for the sake of removing one minor sync call | 06:00 |
| StevenK | lifeless: Can haz dropped timeout? | 06:01 |
| lifeless | e.g. a trigger that on inserts/deletes into BugTag updates the running total for that tag in the fact table | 06:01 |
| jtv | lifeless: you don't get "repeated read" as such in postgres | 06:01 |
| lifeless | or will, if two people insert a reference to the same bug tag at the same time, the counter only go up by one, when it should go up by two | 06:01 |
| lifeless | StevenK: no | 06:01 |
| jtv | lifeless: you get "read committed" as the only ansi-standard isolation level | 06:01 |
| lifeless | StevenK: we've got search timeouts happening | 06:01 |
| lifeless | StevenK: e.g. https://bugs.launchpad.net/bugs/+bugs?field.searchtext=Ubuntu&search=Search+Bug+Reports&field.scope=all&field.scope.target= | 06:02 |
| wgrant | wallyworld: Isn't the picker infrastructure already highly asynchronous? What's wrong with chaining another callback? | 06:02 |
| lifeless | StevenK: and the tags portlet is right on the edge of going boom | 06:02 |
| lifeless | StevenK: given its memcache cached, if it stops working, the timeouts won't increase a little... | 06:02 |
| lifeless | StevenK: they will increase massively. | 06:02 |
| lifeless | StevenK: so, we should get that fix from wgrant in place; then we can lower the timeout | 06:03 |
| wgrant | Yeah, I'll have that finished tonight. | 06:03 |
| jtv | lifeless: if you use read-committed for this, I think you'll lock the aggregate (which doesn't need to be problematic if you update very late). In serializable, you may avoid that but take the occasional serialization failure. | 06:04 |
| lifeless | jtv: right, so s/repeated read/whatever level we run at/ | 06:04 |
| jtv | serializable, I think. | 06:04 |
| jtv | Hmm this has gone through changes—don't trust me on this. | 06:04 |
| wallyworld | wgrant: possibly nothing. my knowledge of the picker code is still not perfect and i couldn;t see how to easily do it. i'll take another look. when i last tried, the default save action happended in parallel with the validation | 06:04 |
| lifeless | jtv: yah, and our retry-machinery catches serialiable failures and retries | 06:04 |
| lifeless | jtv: I'll cross reference with stub | 06:04 |
| jtv | lifeless: there may be call for a separate bit of infrastructure there… | 06:05 |
| jtv | "I'm done, but if you could please add these numbers to these cached aggregates I'd be most grateful." | 06:05 |
| lifeless | jtv: the big point though is that this can answer the portlet for anonymous users with only 10 rows read, and for logged in users with 10 + 10 * group membership [if the planner is real smart] | 06:06 |
| jtv | If we can accept a tiny inconsistency window, the infrastructure could do it in a separate transaction—and only take the serialization errors there, without re-doing the request. | 06:06 |
| lifeless | jtv: we could, and I'm happy for us to have that, but I think we can tolerate the few retries with existing infrastructure for now - shorter path to getting the primary win | 06:06 |
| jtv | lifeless: some of these issues are very similar to what we had with translations. One thing we did there was to update aggregates right away, but also have a background process check for and fix any discrepancies. | 06:07 |
| wallyworld | wgrant: if you are interested https://code.launchpad.net/~wallyworld/launchpad/multicheckboxwidget-unescaped-items/+merge/57108 | 06:07 |
| wgrant | wallyworld: Will the item always have a displayname? I guess if not then the first callsite can fix it properly. | 06:08 |
| wgrant | As long as it breaks instead of being insecure. | 06:08 |
| wallyworld | wgrant: most if not all things we care about do afaik | 06:09 |
| wgrant | StevenK: How many callsites actually need the eager loading? | 06:09 |
| wgrant | StevenK: It should probably be off by default, I think. | 06:09 |
| StevenK | wgrant: I was being cautious | 06:09 |
| wgrant | lifeless: Could you mentor https://code.launchpad.net/~wallyworld/launchpad/multicheckboxwidget-unescaped-items/+merge/57108? | 06:10 |
| wallyworld | wgrant: the sort of things we display in pickers etc all have displaynames so it's a pretty safe assumption | 06:10 |
| wgrant | StevenK: Why does that direction deserve caution? | 06:10 |
| wgrant | wallyworld: Yup. | 06:10 |
| StevenK | wgrant: And if it's off by default, then the API doesn't get it. | 06:10 |
| wgrant | StevenK: @call_with(eager_load=True) | 06:10 |
| * wallyworld goes back to hacking picker javascript | 06:10 | |
| StevenK | wgrant: Looking at other callsites. | 06:13 |
| wgrant | StevenK: Thanks. It seems to mostly be tests and a few things that use it to check if something is published, none of which need preloading. | 06:14 |
| jtv | lifeless: I don't see any concurrency hazards with what you're doing, at any isolation level, but you're introducing a write lock on the row in the fact table. | 06:15 |
| StevenK | wgrant: Er, then why was it added? Surely at least one of the callsites needs itl. | 06:15 |
| wgrant | StevenK: The API and probably one or two UI callsites. | 06:16 |
| wgrant | StevenK: Check the rev that added it. | 06:16 |
| wgrant | It'll reference a bug. | 06:16 |
| lifeless | jtv: yeah, understood | 06:16 |
| lifeless | jtv: I think its simplest to start with triggers and move to async IFF the contention is a problem. | 06:17 |
| lifeless | jtv: other than the bug import scripts, I don't see it being an issue - bug mail being async already | 06:17 |
| lifeless | IMBW | 06:17 |
| jtv | lifeless: that makes sense. As long as we know that we'll recognize that if it happens. | 06:17 |
| lifeless | $when the sky falls in, lifeless broke it | 06:18 |
| wgrant | lifeless: Does http://paste.ubuntu.com/591153/ still perform adequately? It's 9s on DF. | 06:18 |
| StevenK | wgrant: The linked bug only references the API. | 06:20 |
| lifeless | Total runtime: 36958.990 ms | 06:20 |
| lifeless | Total runtime: 3903.161 ms | 06:20 |
| lifeless | Total runtime: 3803.285 ms | 06:20 |
| lifeless | wgrant: ^ | 06:21 |
| wgrant | lifeless: Hmm. | 06:21 |
| wgrant | StevenK: Must only be the API, then. | 06:21 |
| lifeless | wgrant: we can get spm to test on prod if you like | 06:21 |
| lifeless | wgrant: staging is mid-restore so not exactly at its best | 06:21 |
| wgrant | Not really. Need to get a realistic query first. | 06:21 |
| lifeless | wgrant: do you mean 'authenticated' | 06:22 |
| lifeless | wgrant: or that you want to do better ? | 06:22 |
| wgrant | lifeless: And ideally with official tags in the same query. | 06:22 |
| StevenK | wgrant: Changes pushing, I'll prod you when the diff is updated. | 06:22 |
| lifeless | kk | 06:22 |
| lifeless | wgrant: coalesce sort ? | 06:22 |
| wgrant | lifeless: Possibly. I'm trying a UNION'd WITH first. | 06:23 |
| wgrant | see how it works... probably not well. | 06:23 |
| wgrant | But obvious solutions first. | 06:23 |
| StevenK | wgrant: Diff updated. | 06:26 |
| wgrant | StevenK: thanks, will look in a sec. | 06:26 |
| lifeless | wgrant: I can't see a comment from you on https://code.launchpad.net/~wallyworld/launchpad/assign-non-contributor/+merge/55869 | 06:27 |
| wallyworld | lifeless: i think that's the wrong one | 06:28 |
| wallyworld | lifeless: https://code.launchpad.net/~wallyworld/launchpad/multicheckboxwidget-unescaped-items/+merge/57108 | 06:28 |
| lifeless | wallyworld: sshh I was being crafty | 06:28 |
| wgrant | lifeless: http://paste.ubuntu.com/592461/ | 06:28 |
| wgrant | lifeless: Could you try that on (qa)s? | 06:28 |
| lifeless | Total runtime: 4327.931 ms | 06:28 |
| lifeless | Total runtime: 3828.393 ms | 06:28 |
| wgrant | Sounds OK, then. | 06:29 |
| lifeless | cold, hot | 06:29 |
| wgrant | Separate queries are far worse. | 06:29 |
| lifeless | ah, because official tags don't have privacy | 06:29 |
| wgrant | Hm? | 06:29 |
| wgrant | This doesn't have privacy yet. | 06:29 |
| lifeless | yeah it does | 06:29 |
| lifeless | the private check | 06:30 |
| wgrant | Well, yes, but it doesn't do authenticated users. | 06:30 |
| lifeless | sure | 06:30 |
| lifeless | anyhow | 06:30 |
| wgrant | The officialbugtag stuff has nothing to do with privacy. | 06:30 |
| lifeless | shipit | 06:30 |
| wgrant | Don't ever say that word again. | 06:30 |
| lifeless | shiiiiiiiiiiiiiiiiiiiiiiiiiiiipit | 06:30 |
| jtv | wgrant: did you see my email about the bugtag count query? I had it at 2s or so. | 06:31 |
| lifeless | jtv: what db server? | 06:31 |
| jtv | staging | 06:31 |
| jtv | After that it gets harder, unfortunately. | 06:32 |
| wgrant | lifeless: Could you mentor https://code.launchpad.net/~stevenk/launchpad/getpublishedsources-too-eager/+merge/57107? | 06:36 |
| wgrant | jtv: Hmm, what improvements did you make over lifeless'? | 06:36 |
| jtv | wgrant: I haven't compared. Unaware that he was working on it, I played around with it a bit yesterday. | 06:36 |
| lifeless | wgrant: no, I approved it already | 06:37 |
| wgrant | lifeless: Oh, so you did. | 06:37 |
| StevenK | wgrant: Thanks, ec2'ing | 06:38 |
| jtv | wgrant: ah, I see that he followed up to my email. One of my optimizations was to use inner joins instead of outer joins. This saved a second on staging, but he says it won't help as much on "beefier hardware." | 06:38 |
| jtv | Not sure why that would be. | 06:39 |
| wgrant | The 3.5s query already uses inner joins :( | 06:40 |
| lifeless | jtv: first thing we did :) | 06:40 |
| lifeless | jtv: I had thought you were testing on dogfood | 06:40 |
| jtv | Did a bit of that as well, tbh. | 06:41 |
| lifeless | jtv: I've found that the left join/inner join plan cost vs actual cost difference is ~0 on prod | 06:41 |
| jtv | Why would that be? | 06:41 |
| lifeless | didn't dig terribly deeply sorry | 06:43 |
| lifeless | except when the plan is dramatically different (and it is sometimes) | 06:43 |
| jtv | Seems strange though that this query would work out faster on staging than on production. | 06:45 |
| lifeless | jtv: I've been testing on staging too | 06:45 |
| lifeless | jtv: for added weird value | 06:45 |
| lifeless | jtv: I don't have direct prod access | 06:45 |
| lifeless | jtv: prod has different tuning parameters of course, vs staging - at 4 times the memory :) | 06:46 |
| jtv | Oh. Used to be the same. | 06:46 |
| jtv | That'll make it hard to tune effectively for production. I'd really like that plan logging feature for timeouts. | 06:47 |
| jtv | Or oopses in general, perhaps. | 06:47 |
| lifeless | jtv: same | 06:47 |
| jtv | So we can use ++oops++ to check for flukes. | 06:47 |
| jtv | Can't we ask one of the maintenance squads to do it? | 06:47 |
| jtv | Or the TA? | 06:48 |
| lifeless | yes, it does make predicting a little harder; I tend to have a losa check once I'm happy on staging | 06:48 |
| lifeless | jtv: its a matter of triage | 06:48 |
| lifeless | right now, the biggest analytic problem is that api oopses have no timeline | 06:48 |
| lifeless | a regression | 06:48 |
| poolie | o/ jtv | 06:58 |
| lifeless | whereartthoustub | 07:02 |
| lifeless | arrrrgh | 07:22 |
| wgrant | Oh? | 07:24 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/739051 | 07:24 |
| _mup_ | Bug #739051: Product:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739051 > | 07:24 |
| henninge | good morning | 07:24 |
| henninge | And good day to you guys over there on the other side ... ;-) | 07:25 |
| lifeless | hi henninge | 07:25 |
| lifeless | wgrant: see the query. | 07:25 |
| wgrant | Morning henninge. | 07:25 |
| henninge | Can I ask for a review, please? | 07:26 |
| henninge | https://code.launchpad.net/~henninge/launchpad/devel-744204-escaping-soyuz-base | 07:26 |
| wgrant | henninge: Looking. | 07:26 |
| henninge | javascript, quite simple | 07:26 |
| henninge | oh, that was the branch url. nm | 07:26 |
| henninge | https://code.launchpad.net/~henninge/launchpad/devel-744204-escaping-soyuz-base/+merge/56978 | 07:26 |
| jtv | hi poolie | 07:31 |
| poolie | hi | 07:32 |
| wgrant | henninge: Done. | 07:33 |
| wgrant | lifeless: Still around for mentoring? | 07:34 |
| lifeless | sure | 07:34 |
| henninge | wgrant: thanks! | 07:35 |
| wgrant | lifeless: henninge's MP just above, if you could. | 07:35 |
| henninge | wgrant: seriously? I can have whitespaces before dots? | 07:35 |
| henninge | also, I did not realized the YUI methods return the node. Thanks. | 07:36 |
| lifeless | henninge: you can in python too | 07:36 |
| wgrant | henninge: Yup. | 07:36 |
| lifeless | henninge: e.h. '[] . reverse()' | 07:36 |
| henninge | oh! | 07:36 |
| wgrant | . can't begin an identifier, so it's OK. | 07:36 |
| henninge | cool, learn something new every day ;) | 07:37 |
| henninge | so '.' really is more like a binary operator | 07:37 |
| spiv | lifeless: or even '[ ] . reverse ( )' for maximum ugly! | 07:37 |
| lifeless | spiv: you forgot the \r\n | 07:38 |
| rvba | wgrant: Hi! I guess you marking my bugs as qa-ok is due to the fact that I'm blocking the rollout and you know my developments are protected by the feature flag anyway ... right? | 07:45 |
| StevenK | Except that r12786 is marked qa-basd | 07:46 |
| StevenK | *qa-bad | 07:46 |
| jtv | hey rvba—isn't it very early for you? | 07:46 |
| rvba | jtv: not really, 8:46 | 07:46 |
| rvba | StevenK: indeed | 07:46 |
| rvba | just saw that | 07:46 |
| wgrant | rvba: I checked that they didn't break anything on DF. | 07:47 |
| wgrant | rvba: As for the qa-bad one, the fix should be on qastaging right around now. | 07:47 |
| wgrant | I guess it's being slow because of the staging restore :/ | 07:48 |
| rvba | wgrant: appart from the one that you marked qa-bad ... I was in the process of trying to qa them on DF myself ... but I needed to upload a few bogus packages to properly test them. | 07:48 |
| * wallyworld off to pick up new puppy, back later | 07:48 | |
| LPCIBot | Project windmill build #161: FAILURE in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill/161/ | 07:48 |
| wallyworld | wgrant: the assign-non-contrib mp now uses an api call. now i just need to sort of the async stuff | 07:49 |
| poolie | wallyworld, i liked your video | 07:49 |
| wgrant | wallyworld: Great! | 07:50 |
| wallyworld | poolie: yeah, it was a learning exercise for me. i'm still new to yui | 07:50 |
| poolie | wallyworld, when it checks people who already have bugs assigned, that includes closed bugs? | 07:50 |
| wallyworld | wgrant: i basically just reverted to an earlier version and andded some tests | 07:50 |
| rvba | wgrant: is a fix for the portlet display itself or did you add a protection using the feature flag? | 07:50 |
| wallyworld | added | 07:50 |
| wgrant | wallyworld: lazr.restful didn't stab you? | 07:51 |
| wgrant | rvba: It's behind the feature flag for now. | 07:51 |
| wgrant | rvba: It's not clear what fixing the portlet display entails. | 07:51 |
| wallyworld | wgrant: nope. i thought it would. when i say reverted, i also added some extra stuff to include the person and pillar names. | 07:51 |
| rvba | wgrant: ok | 07:51 |
| wallyworld | so it's all good | 07:51 |
| wgrant | wallyworld: Ah, right. | 07:52 |
| wallyworld | wgrant: previously the version with the api cal ljust returned true/false without all the other detail | 07:52 |
| wgrant | lifeless: How can I select columns from a With in Storm? | 07:52 |
| wgrant | lifeless: Everywhere else seems to use the With in a condition :( | 07:52 |
| lifeless | uhm | 07:53 |
| lifeless | I think I did this in my latest with patch | 07:53 |
| wgrant | I'm not sure it's possible :( | 07:53 |
| lifeless | or perhaps its what gustavo is asking for | 07:53 |
| lifeless | BranchRevision does it | 07:53 |
| === Ursula__ is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Guest38069 | ||
| wgrant | lifeless: Hmm. Maybe I'll have to define a fake class. | 07:55 |
| wgrant | It looks like it :( | 07:55 |
| lifeless | wgrant: this is bugtag? | 07:56 |
| henninge | Hm, were did the inline diffs in comments on MPs go? | 07:56 |
| lifeless | wgrant: just select columns | 07:56 |
| lifeless | wgrant: Alias(SQL("counts.foo"), "bar") | 07:56 |
| lifeless | wgrant: or some such | 07:56 |
| wgrant | lifeless: Can you do that in a findspec? | 07:57 |
| lifeless | sure | 07:57 |
| StevenK | lifeless: I also came to a conclusion over the weekend. You pushed back at me a little about making request-daily-builds a garbo job -- given the fun I've had with p-s-c, I'm glad I didn't. | 08:09 |
| lifeless | StevenK: So the garbo now parallelises | 08:10 |
| lifeless | StevenK: And will be getting more work put into it | 08:11 |
| StevenK | lifeless: It still gets blocked for 5.5 hours per day. | 08:11 |
| lifeless | StevenK: thats tunableloop that does it, and its configurable per loop | 08:11 |
| lifeless | StevenK: all the tunable loops should get a timeslice every hour, guaranteed | 08:12 |
| lifeless | if they aren't, its a but | 08:12 |
| lifeless | bug* | 08:12 |
| StevenK | lifeless: But they get blocked due to slony madness? | 08:12 |
| lifeless | StevenK: they get blocked by a policy knob | 08:13 |
| lifeless | StevenK: which says 'if this loop will write a lot of rows, running it during e.g. backup will permanently bloat the table and makeit run slowly' | 08:13 |
| StevenK | lifeless: The logs disagree, but I hestitate to paste them. | 08:13 |
| lifeless | StevenK: loops like psc should just tune that | 08:13 |
| lifeless | StevenK: file a bug then | 08:13 |
| lifeless | StevenK: we need to have a solid platform to do things with easily. | 08:14 |
| lifeless | jtv: does serializable ever block on reads ? | 08:28 |
| jtv | lifeless: not that I can think of—actually the locking in serializable is the same as in read-committed by the way. | 08:28 |
| jtv | There's a detailed listing of lock types in the pg documentation. | 08:28 |
| lifeless | k | 08:29 |
| lifeless | jtv: I'm looking at https://bugs.launchpad.net/launchpad/+bug/739051 | 08:29 |
| _mup_ | Bug #739051: Product:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739051 > | 08:29 |
| * jtv looks | 08:29 | |
| lifeless | jtv: which has an 11 second query, that takes 700ms on all three dbs in prod + similar on staging | 08:29 |
| lifeless | though its gross that we're doing a fti search | 08:30 |
| jtv | so what makes it an 11-second query? | 08:30 |
| lifeless | + a %foo% | 08:30 |
| lifeless | jtv: thats the million dollar question | 08:30 |
| * jtv shakes fist at openid | 08:30 | |
| jtv | a 404 and a search form, just the things I expected from following a pair of automatically-generated oops links | 08:31 |
| jtv | lifeless: wild guess… fast-changing table in there? Stats go stale occasionally, query reverts to conservative plan with lots of seq scans? | 08:35 |
| lifeless | 4 of the 5 timeouts are on the query | 08:36 |
| lifeless | the last is high cpu | 08:36 |
| lifeless | 22839 hits on the page | 08:36 |
| jtv | It's reported as high CPU, but could this be one of those extreme db timeouts where the query isn't logged and so the time isn't counted as query time? | 08:37 |
| lifeless | it may be an overloaded appserver | 08:37 |
| lifeless | jtv: we don't have any of those | 08:37 |
| jtv | Used to. | 08:37 |
| lifeless | jtv: partial queries are reported properly now | 08:37 |
| lifeless | jtv: https://lp-oops.canonical.com/oops.py/?oopsid=1926H1059#statementlog is the cpu one | 08:37 |
| lifeless | jtv: you can see the gap | 08:38 |
| lifeless | I think this was a crashing appserver | 08:38 |
| lifeless | B E G H | 08:38 |
| lifeless | all 4-threaded ones | 08:38 |
| jtv | Yup, I see the gap | 08:38 |
| lifeless | accounting for all the timeouts | 08:38 |
| lifeless | I think the slow queries are the python code within the 'run the query' getting time starved | 08:39 |
| jtv | That'd explain why the time seems to go arbitrarily into DB or non-DB time. | 08:41 |
| jtv | Makes me wonder though: why relatively consistent delays and why specifically in this one place? | 08:41 |
| wgrant | We see that on BugTask:+index a lot. | 08:41 |
| adeuring | good morning | 08:42 |
| jtv | hi adeuring | 08:42 |
| adeuring | hi jtv! | 08:43 |
| lifeless | I will ping mthaddon about progress on removing those servers | 08:44 |
| jtv | Thanks for pushing through that long-desired change btw. | 08:44 |
| lifeless | jtv: we had a bunch of servers on wampee crash out earlier today | 08:45 |
| lifeless | jtv: rss up at 1GB, nonresponsive | 08:46 |
| lifeless | jtv: my pleasure, like all things takes time | 08:46 |
| wgrant | Deploy time, yay. | 08:46 |
| lifeless | we can't rule out actual plan trouble | 08:47 |
| lifeless | but the 22K successful renders | 08:47 |
| lifeless | make me doubt that that its anything other than a sick appserver | 08:47 |
| lifeless | so what we need to figure out is how to detect and eviscerate such appservers in advance (assuming the 2-thread config can still run into trouble) | 08:48 |
| jtv | Well like I said, it's possible for a query to be planned differently while stats are out of date. Could be a canary for vacuums falling behind. (I think vacuum is where the stats are updated). | 08:49 |
| StevenK | wgrant: Err, in r12792 you merged in the FF stuff -- however, one of them says tal:condition="features/soyuz.derived-series-ui.enabled" and the other has tal:condition="request/features/soyuz.derived-series-ui.enabled" | 08:50 |
| lifeless | all palladium/potassium/gandwana - the old appservers | 08:50 |
| wgrant | StevenK: 'features' is defined in base-layout-macros | 08:51 |
| wgrant | StevenK: So you can only use 'features' directly in a top-level template. | 08:51 |
| jtv | wgrant, StevenK: question about publish-distro… when publish-ftpmaster wants to process only security updates, it uses the script's -s option to indicate the security suites. But not on the partner archive! Doesn't partner have security suites? | 08:57 |
| lifeless | stub: hi | 08:57 |
| stub | yo | 08:57 |
| lifeless | stub: 10 / 1 MaloneApplication:+bugs | 08:58 |
| lifeless | stub: I think we may have index bloat again already :( | 08:58 |
| stub | Bah. I'll check my shiny new report. | 08:58 |
| lifeless | stub: how are you checking for it ? | 08:58 |
| lifeless | stub: ooh is it online ? | 08:58 |
| stub | I'm about to look :-) Should be | 08:59 |
| stub | For the master at least. I need to set it up for the slaves. | 08:59 |
| lifeless | stub: are there instructions for regenerating indices for the losas ? [ | 09:00 |
| lifeless | https://lp-oops.canonical.com/oops.py/?oopsid=1926D1311#longstatements | 09:01 |
| stub | No. Its something I'll need to do manually. Not sure if I can automate it - parts have to be done outside transactions so needs someone who can workout how to back things out if things go screwy. | 09:01 |
| wgrant | jtv: Partner only has the release pocket. | 09:01 |
| lifeless | stub: if you can document it, then more folk could step through if needed, even if you're on leave / sick | 09:01 |
| lifeless | stub: which is my main concern - higher bus factor | 09:02 |
| jtv | wgrant: so security updates in partner go into the release pocket? | 09:02 |
| wgrant | jtv: Yes. | 09:02 |
| jtv | stub: he means tuk-tuk factor (he doesn't speak Thai) | 09:02 |
| stub | Yes, but how do I document how to back out from an unknown state due to an unforeseen screwup? | 09:02 |
| lifeless | stub: you don't | 09:02 |
| lifeless | stub: but you can document the risks you know about, the things that would make you go hmmm | 09:03 |
| jtv | wgrant: thanks… and once we start releasing the debug archive, that will have security suites again right? | 09:03 |
| stub | Right. So I need to do it, or someone else who understands enough to do it such as our 3rd party support. | 09:03 |
| wgrant | jtv: Yes, but they're not security-critical. | 09:03 |
| lifeless | stub: sure; I mean the way I'd approach it is build a new index concurrently with a different name; then drop the old index | 09:04 |
| jtv | wgrant: so the criterion for expediting security updates would be "everything in the security pocket on primary, everything at all in partner, and none in debug." | 09:04 |
| lifeless | which would require a single short lock on the table | 09:04 |
| jtv | wgrant: a suite was… <archive>-<pocket>? | 09:04 |
| wgrant | jtv: Probably nothing at all in partner, but either way. | 09:04 |
| wgrant | jtv: suite = (distroseries, pocket) | 09:05 |
| stub | Right. So I guess the failure there is the index not building, which can be documented how to recover. | 09:05 |
| wgrant | But in practise it's really (archive, distroseries, pocket) | 09:05 |
| stub | Of course, with the right reports we never need that process because we catch the problems proactively. | 09:05 |
| lifeless | stub: right | 09:05 |
| * stub tries to work out where the dbr is being generated from atm | 09:05 | |
| lifeless | ~lpqateam | 09:05 |
| lifeless | crontab | 09:05 |
| jtv | wgrant: thanks… this is turning out to be a nasty piece of hard-coding. | 09:06 |
| jtv | wgrant: it would be a lot simpler if I could leave partner out of the expedited security updates. So if you say I can, I will. | 09:06 |
| stub | losaping: Can you please update the Launchpad tree on devpad for the ~lpqateam? | 09:06 |
| stub | ECHANNEL | 09:07 |
| lifeless | stub: you can sudo to lpqateam I think | 09:07 |
| lifeless | stub: if you can't, I can | 09:07 |
| wgrant | jtv: Please do. | 09:07 |
| jtv | \o/ | 09:07 |
| jtv | wgrant: I had another question… is the distscopy version of dists ever used for anything at all besides this script? ISTM we could rsync the current dists to it _before_ moving it to a new place. Just to narrow down the horrible-awkward-directory-shuffle-state window for failures a little. | 09:14 |
| StevenK | wgrant: Have you filed a bug about that issue? | 09:14 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge | https://code.launchpad.net/launchpad-project/+activereviews | ||
| wgrant | jtv: I don't know of anything else that uses it. | 09:15 |
| wgrant | StevenK: I have a half filled form... does that count? | 09:15 |
| StevenK | Haha | 09:16 |
| wgrant | Bug #757248 | 09:19 |
| _mup_ | Bug #757248: poppy-sftp's signature checking relies on long-term survival of a directory in /tmp <poppy> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/757248 > | 09:19 |
| StevenK | wgrant: Excellent, thanks | 09:19 |
| === Ursinha-afk is now known as Ursinha | ||
| jtv | wgrant: while we're thinking about this… if nothing uses the distscopy version of dists, why the ฟัก don't we run publish-distro on it in-place and simplify the directory shuffle in the publish-ftpmaster script? | 09:25 |
| * jtv starts diagram to illustrate | 09:25 | |
| wgrant | jtv: No idea :/ | 09:26 |
| wgrant | Probably roughly "because someone thought that was a good idea 2005" | 09:27 |
| wgrant | in 2005. | 09:27 |
| jtv | wgrant: current → http://people.canonical.com/~jtv/publish-ftparchive-dists.png | 09:30 |
| wgrant | bigjools: Morning. | 09:30 |
| jtv | wgrant: proposed → http://people.canonical.com/~jtv/simplified-publish-ftparchive-dists.png | 09:30 |
| jtv | hi bigjools | 09:30 |
| bigjools | hello | 09:30 |
| wgrant | bigjools: Did you know that cocoplum's /tmp pruner considers poppy-sftp's gpg.conf to be a nice snack? | 09:30 |
| bigjools | wgrant: wtf is gpg.conf doing there? | 09:31 |
| wgrant | bigjools: GPGHandler creates a GNUPGHOME in /tmp, with the configured keyserver. | 09:31 |
| wgrant | bigjools: So it gets pruned, and poppy-sftp can no longer see any keys! | 09:31 |
| wgrant | Fun for all. | 09:31 |
| bigjools | GNUPGHOME should be set to the right place, I remember telling a losa to do that | 09:32 |
| wgrant | Hmm? | 09:32 |
| wgrant | GPGHandler overrides GNUPGHOME when it's initialised. | 09:32 |
| wgrant | Setting it in poppy-sftp's env will do no good. | 09:32 |
| wgrant | It will be clobbered. | 09:32 |
| bigjools | that's cracj | 09:33 |
| maxb | no it's quite sane really - encapsulate the needed setup in the code rather than mandating external setup | 09:33 |
| wgrant | It's just not very helpful for daemons. | 09:34 |
| bigjools | it's not mandating anything, it should be an override | 09:42 |
| bigjools | so it's rather insane in fact | 09:42 |
| bigjools | wgrant: did you sort it out? | 09:42 |
| wgrant | bigjools: We've restored gpg.conf for now. | 09:43 |
| wgrant | bigjools: It will happen again, though. | 09:43 |
| wgrant | This week some time. | 09:43 |
| bigjools | so it needs a code change I suppose | 09:44 |
| wgrant | Yeah. I'm not sure what should be done. | 09:45 |
| bigjools | we need to stop gpghandler using /tmp | 09:46 |
| bigjools | simples | 09:46 |
| jml | hello from millbank | 09:58 |
| jml | product team is here / huw | 09:58 |
| lifeless | \o/ | 10:01 |
| bigjools | jtv: did you work out what distscopyroot is for? | 10:15 |
| bigjools | and did wgrant see those diagrams? | 10:15 |
| jtv | bigjools: as far as I can make out from the script, all it does is keep the "alternate copy" of dists. | 10:15 |
| jtv | Yes, I showed him the pictures. | 10:15 |
| jtv | He can't think of anything else that distscopy might be used for. | 10:15 |
| bigjools | jtv: so we have three copies of the indexes... | 10:16 |
| jtv | Two. But they take on 4 different paths. | 10:16 |
| jtv | 3 each. | 10:16 |
| jtv | They alternate. | 10:16 |
| bigjools | so distscopyroot contains the indexes from the previous run | 10:17 |
| jtv | So through one script run, each of these directories is renamed 4 times to assume each of those 4 paths, and they end up back where they started. | 10:17 |
| jtv | Yes. | 10:17 |
| bigjools | and we rsync to it at the start of each run | 10:17 |
| jtv | Yes. | 10:17 |
| jtv | It's an Ouroboros. | 10:17 |
| bigjools | can't see a problem with the new method | 10:17 |
| bigjools | bless you | 10:17 |
| jtv | I wasn't sneezing, I was referring to the mythical snake that eats its own tail. | 10:18 |
| jtv | It's also reminiscent of Heinlein's short story, All You Zombies. | 10:18 |
| bigjools | jtv: the only difference now is that distscopyroot can get overridden before a successful run | 10:20 |
| jtv | overridden? | 10:20 |
| bigjools | with the old method it was only changed when the script completed | 10:20 |
| bigjools | successfully | 10:20 |
| jtv | Or unsuccessfully. | 10:20 |
| bigjools | really? | 10:20 |
| jtv | If it aborts prematurely, dists.new is moved back there. | 10:20 |
| bigjools | interesting | 10:21 |
| bigjools | I wonder if that was a bug! | 10:21 |
| bigjools | I can't see any other reason to have dists.new | 10:21 |
| wgrant | It's not really a bug. | 10:21 |
| wgrant | The second copy is only a time saver. | 10:21 |
| wgrant | It doesn't matter if it is broken. | 10:21 |
| jtv | The rsync should take care of any broken crap in there. | 10:21 |
| wgrant | Worst case the rsync will take a bit longer next time. | 10:21 |
| bigjools | it depends on why someone wanted a copy of the indexes from the last run | 10:21 |
| wgrant | bigjools: Because dists isn't regenerated from scratch each time, we need to work in a copy of it. | 10:22 |
| wgrant | Because d-i images are big, we can't recopy each time. | 10:22 |
| bigjools | I know. .. | 10:22 |
| wgrant | So a second copy is kept, and brought up to date each time. | 10:22 |
| bigjools | but the way it's done is weird | 10:23 |
| wgrant | Oh? | 10:23 |
| bigjools | jtv: I think your change is ok, FWIW. It doesn't seem to do anything differently | 10:23 |
| bigjools | wgrant: having a backup the previous run's indexes may have been desirable | 10:24 |
| bigjools | backup of* | 10:24 |
| wgrant | bigjools: It has a special codepath for moving it back before publication has finished, so it was intended that it may not always be a valid copy of the indices. | 10:25 |
| jtv | Hmm | 10:26 |
| bigjools | wgrant: my point was, that could have been a bug | 10:26 |
| bigjools | despite the intentions | 10:26 |
| wgrant | It seems fairly deliberately. | 10:26 |
| wgrant | Mm. | 10:26 |
| wgrant | Maybe. | 10:26 |
| bigjools | who knows, that script is a pile of crap | 10:26 |
| bigjools | but it's been like it for many years so JFDI | 10:26 |
| wgrant | Let's hope we can soon say it *was* a pile of crap. | 10:26 |
| jtv | I wonder if this doesn't mean that we can improve turnaround time of security updates further by doing the rsync at the end of the previous run. That way, its latency is out of the critical path for getting the fixes out. | 10:26 |
| wgrant | jtv: No. | 10:27 |
| wgrant | jtv: We don't want to push that frequently. | 10:27 |
| wgrant | It's unclear whether expedited security processing is desirable in the first place. | 10:27 |
| wgrant | THis predates s-i-s. | 10:27 |
| jtv | It's in the spec. | 10:27 |
| jtv | s-i-s? | 10:27 |
| wgrant | security-in-soyuz | 10:27 |
| wgrant | Back when -security was synced from a dak instance. | 10:28 |
| bigjools | wgrant: this was done *after* s-i-s | 10:28 |
| bigjools | and yes it's desirable | 10:28 |
| jtv | And even if it weren't the spec is newer yet and specifies expedited security updates. | 10:28 |
| bigjools | the spec's pretty old :) | 10:28 |
| jtv | Well, "less ancient yet" | 10:29 |
| bigjools | I wrote it with Celso about 2.5 years ago | 10:29 |
| jtv | Anyway, I'll just focus on the simpler structure then. | 10:29 |
| bigjools | cool, thanks for delving into that jtv | 10:29 |
| * jtv loves to see complexity melt away | 10:29 | |
| jtv | This means no more broad cleanup in a "finally" or "atexit." | 10:30 |
| bigjools | \o/ | 10:32 |
| jtv | bigjools: what in publish-ftpmaster exactly produces the Sources.* files? Is it a-f, or publish-distro, or something else? | 11:08 |
| bigjools | jtv: a-f for ubuntu, publish-distro for PPAs | 11:08 |
| jtv | So a-f in this case. Thanks. Almost there with the cleanup, I hope. | 11:09 |
| bigjools | woohoo | 11:09 |
| jtv | Oh grumble. What is it that runs a-f? | 11:09 |
| bigjools | publish-distro | 11:09 |
| jtv | So my question was wrong. | 11:09 |
| bigjools | heh | 11:09 |
| jtv | Curses. Something in publish-distro doesn't seem to like the new location. | 11:30 |
| bigjools | jtv: using -R ? | 11:32 |
| jtv | Yes. | 11:32 |
| bigjools | odd | 11:32 |
| jtv | It's not generating the Sources files, far as I can tell. But no hint of why. | 11:32 |
| wgrant | jtv: Checked apt.conf? | 11:33 |
| wgrant | It's generated in ftparchive.py, and is a bit bad. | 11:33 |
| jtv | No… where would I find it though? | 11:33 |
| === henninge is now known as henninge-lunch | ||
| bigjools | wgrant: need to bounce an idea off you | 11:39 |
| wgrant | bigjools: Sure. | 11:39 |
| bigjools | wgrant: some of the derived distros need to work pretty much like PPAs | 11:40 |
| bigjools | I think this can be as easy as changing the sources.list sent to the builders | 11:40 |
| wgrant | Yeah. | 11:41 |
| bigjools | if we have an archive flag, "overlay" or somesuch | 11:41 |
| bigjools | then the initialisation phase will just include the small subset of packages needed | 11:42 |
| bigjools | so it sounds sane? | 11:42 |
| wgrant | Just change the archive dependency calculator to include the extra archive, and sources.list and retry-depwait will magically work. | 11:42 |
| bigjools | yup | 11:43 |
| jtv | Ohhh this is infuriating. publish-distro fails to produce Sources.* in foo-distscopy/dists but does work if I mv foo-distscopy/dists dists.new ; publish-distro ; mv dists.new foo-distscopy/dists | 11:43 |
| wgrant | jtv: a-f may require it to be within archiveroot. | 11:43 |
| wgrant | Or our config of a-f. | 11:44 |
| jtv | It's in archiveroot, I think, just not within distsroot. | 11:44 |
| wgrant | 'foo-distscopy' is a sibling of the 'foo' archiveroot, right? | 11:45 |
| * jtv checks | 11:45 | |
| jtv | Err yes it is | 11:45 |
| jtv | Damn ".." in paths… | 11:46 |
| jtv | Using different names works as well. So it does seem to be a matter of location. | 11:46 |
| jtv | wgrant: I'd be very interested to know why publish-distro can't work outside the archive root, but I'm not too confident that I can find out today. :( | 11:56 |
| jtv | Certainly nothing seems to be mentioning ".." explicitly. | 11:56 |
| wgrant | jtv: It shouldn't be publish-distro... probably a-f or our config of it. | 11:57 |
| jtv | Maybe it's relative softlinks that break? | 11:57 |
| wgrant | I hope not. | 11:58 |
| wgrant | It's possible... but unlikely. | 11:58 |
| jtv | See diskpool.py: creates relative symlinks, but I moved the depth of the directory in the tree. | 12:01 |
| jtv | Changed its depth, I mean. | 12:01 |
| wgrant | Indices should go nowhere near diskpool. | 12:01 |
| jtv | That's a relief, perhaps. | 12:04 |
| deryck | Morning, all. | 12:06 |
| === jtv is now known as jtv-afk | ||
| LPCIBot | Project windmill build #162: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill/162/ | 13:02 |
| === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: henninge, benji | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === henninge-lunch is now known as henninge | ||
| benji | henninge: I'm going to do some of the reviews in active-reviews; none are claimed, are you activly working on any of them? | 13:26 |
| henninge | Hi benji! | 13:26 |
| henninge | benji: I am working on Huw's (the oldest in the list) | 13:26 |
| benji | ok, I'm glad I asked, I was about to start on that one | 13:27 |
| === almaisan-away is now known as al-maisan | ||
| henninge | ;-) | 13:30 |
| henninge | benji: I'll claim it now | 13:30 |
| === al-maisan is now known as almaisan-away | ||
| benji | thanks | 13:30 |
| === almaisan-away is now known as al-maisan | ||
| deryck | adeuring, can you join me in mumble for a second? Just to mic check before the standup. | 13:44 |
| adeuring | deryck: sure | 13:44 |
| deryck | thanks! | 13:44 |
| wgrant | wallyworld___: Thanks for fixing that up. | 13:45 |
| wgrant | Although there is a conflict now :( | 13:45 |
| wallyworld___ | wgrant: yeah just saw it. am fixing | 13:45 |
| wallyworld___ | wgrant: i'm annoyed with myself that i had myself convinced that there was an issue with the async approach. well there was originally but it got fixed along the way and i didn't realise | 13:47 |
| wgrant | wallyworld___: It's often hard to see that oneself :) | 13:47 |
| wallyworld___ | wgrant: yeah, especially when you've seen an issue and don't go back and revisit it later after making changes | 13:48 |
| Ursinha | wgrant, are we suppose to use milestones or are we getting rid of that? | 13:51 |
| Ursinha | supposed | 13:51 |
| wgrant | Ursinha: lifeless wants to stop. | 13:52 |
| Ursinha | wgrant, but we're not stopping yet | 13:53 |
| Ursinha | ? | 13:53 |
| wgrant | Ursinha: Well, now might be a good time, rather than fixing it to point at 11.05 instead... but probably best for lifeless to confirm that. So set it to 11.05 for now? | 13:53 |
| Ursinha | wgrant, yeah, I'll do that now and talk to him late | 13:54 |
| Ursinha | r | 13:54 |
| Ursinha | :) | 13:54 |
| wallyworld___ | wgrant: merge conflict fixed | 13:57 |
| wgrant | wallyworld___: Thanks. Will rereview in the morning, unless you really want it now. | 13:57 |
| wallyworld___ | wgrant: nope. morning is good | 13:58 |
| deryck | henninge, ping for standup | 14:02 |
| deryck | henninge_, ping for standup | 14:03 |
| henninge_ | deryck: coming | 14:03 |
| bigjools | wgrant: steve was saying something about you saying you knew how to make createMissingBuilds quicker? | 14:07 |
| wgrant | bigjools: I knew about the thing making IDS an order of magnitude slower than it needed to be (which StevenK has since fixed), and I have some ideas on optimising createMissingBuilds, but nothing revolutionary. | 14:08 |
| bigjools | ok, thanks | 14:08 |
| jcsackett | henninge, benji: can i get a review of https://code.launchpad.net/~jcsackett/launchpad/api-wants-questionset/+merge/57023 | 14:16 |
| benji | jcsackett: sure; I'm doing one at the moment, but if it's not claimed when I'm done then I'll do it then. | 14:17 |
| jcsackett | thanks, benji. :-) | 14:17 |
| abentley | deryck: Many or all of those failure were PEBKAC. How do I run the YUI tests specifically? | 14:38 |
| deryck | abentley, $BROWSER $PATH_TO_FILE, e.g. firefox lib/lp/app/javascript/test_foo.html | 14:40 |
| abentley | deryck: no, all of them. | 14:40 |
| deryck | ah | 14:40 |
| deryck | abentley, ./bin/test -cvvt test_yuitest --layer=WindmillLayer | 14:40 |
| abentley | deryck: cool. | 14:41 |
| deryck | abentley, substituting the app-specific windmill layers if you only want some subset. | 14:41 |
| wallyworld | deryck: too bad about the windmill tests being turned off again. i haven't had a chance to look. have you any more info? | 14:43 |
| deryck | wallyworld, no, I just haven't had a chance myself either. Did Natty upgrade and some pain there and 360 reviews. | 14:44 |
| deryck | wallyworld, hope to look late today or tomorrow. | 14:44 |
| * deryck is getting *very* frustrated with Windmill again | 14:44 | |
| wallyworld | deryck: yeah, natty upgrade pain for me too. let's touch base again in a few days | 14:45 |
| deryck | wallyworld, sounds good. I'm away W-F this week, if all goes well :-) | 14:45 |
| wallyworld | deryck: cool. most likely next week then :-) | 14:45 |
| deryck | indeed | 14:45 |
| === al-maisan is now known as almaisan-away | ||
| === salgado is now known as salgado-lunch | ||
| abentley | deryck: Now landing my JS work. | 15:13 |
| deryck | abentley, awesome! Thanks | 15:13 |
| abentley | deryck: And failed out with a merge conflict :-( | 15:14 |
| deryck | oh the joys! | 15:26 |
| * deryck misses the xchat blinking icon in Natty | 15:26 | |
| jml | gary_poster: hi | 15:35 |
| gary_poster | hey jml | 15:35 |
| jml | gary_poster: on https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/FeatureReviewNotes, it says "unsubscribe in anger will be done" for Wednesday | 15:35 |
| jml | gary_poster: what do you mean by "done" there? | 15:35 |
| gary_poster | jml, yes, that was apparently optimistic :-/ | 15:35 |
| jml | gary_poster: I had assumed so :) | 15:36 |
| gary_poster | jml, that was the only bad usage of "done" AFAIK. I had intended it to mean coded. | 15:36 |
| gary_poster | jml, I have a pending question of two for you... | 15:36 |
| gary_poster | one of them is the email from gmb | 15:36 |
| gary_poster | about a bug I can dig up | 15:36 |
| jml | gary_poster: if a programmer tells me that an egg will be boiled in three minutes from now, I mentally increase that to six hours :) | 15:37 |
| gary_poster | :-) | 15:37 |
| jml | gary_poster: will look up that email | 15:37 |
| gary_poster | the other is that I should give you an update on unsubscribe in anger expectations, but I maybe should wait on that one until tomorrow or Wed, when we will have more of that infrastructure in place. | 15:38 |
| gary_poster | thank you | 15:38 |
| gary_poster | jml, I wondered if it would be easier to convey the crux of gmb's email (titled "Bug 424849, batched notifications, fun and games, etc.") orally. If you think so, I'm happy to Skype/mumble briefly. | 15:40 |
| _mup_ | Bug #424849: Launchpad should batch attachment notification emails <lp-bugs> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by gmb> <apport (Ubuntu):Invalid> < https://launchpad.net/bugs/424849 > | 15:40 |
| jml | gary_poster: the main thing I don't get is why fixing bug 31586 would make it possible to batch multiple commented attachments. | 15:41 |
| _mup_ | Bug #31586: Malone comments are sent in email and forge the address of the person who filed them <email> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/31586 > | 15:41 |
| gary_poster | jml (I'm against that approach for a couple of reasons but...) it would help because then you could batch up *all* the comments on a particular bug. So, solution 1 would let us batch comments/attachments from the same person for the same bug, and solution 2 lets us batch comments/attachments from the same bug--it should produce even less email. | 15:44 |
| jml | oh, I see. | 15:47 |
| jml | gary_poster: sorry, it took me a while to see the obvious, that the email has to come from someone :) | 15:47 |
| gary_poster | :-) | 15:47 |
| jml | gary_poster: multitasking is the mindkiller. | 15:47 |
| gary_poster | heh, too true | 15:47 |
| jml | gary_poster: how much work are we looking at if we take option 1? | 15:50 |
| gary_poster | jml, we are guessing one developer, one week, Maybe two devs, 3 days. We really try not to make you have to inflate our guesses. :-) The change itself should be relatively simple, a day-ish, but touching email sending can sometimes affect other parts of LP, so we are adding in time for problems of that nature. | 15:52 |
| sinzui | jcsackett: do you have a few minutes to mumble? | 15:58 |
| jml | gary_poster: ok. I think we should take option 1 then. | 15:58 |
| gary_poster | jml, ack. I'll put it on the board. Thank you! | 15:58 |
| jml | gary_poster: np. | 15:59 |
| jcsackett | sinzui: sure. | 16:06 |
| === salgado-lunch is now known as salgado | ||
| === deryck is now known as deryck[lunch] | ||
| === henninge_ is now known as henninge | ||
| henninge | benji: I assume you claimed whatever you are working on? | 17:13 |
| adeuring | deryck[lunch]: could you have another look at https://code.launchpad.net/~adeuring/launchpad/bug-746460/+merge/56840 ? | 17:26 |
| gary_poster | henninge or benji, I have a small-ish JS branch for you. https://code.launchpad.net/~gary/launchpad/bug750561/+merge/57195 | 17:26 |
| henninge | gary_poster: here! | 17:27 |
| gary_poster | :-) cool thanks | 17:27 |
| adeuring | ...or henninge, could you have a look at https://code.launchpad.net/~adeuring/launchpad/bug-746460/+merge/56840 ? | 17:28 |
| henninge | adeuring: I just accepted gary_poster's but I guess you are closer to EOD. I'll have a look at how big it is. | 17:29 |
| adeuring | henninge: ok, np | 17:29 |
| * gary_poster is closer to lunch...and hungry, too! | 17:30 | |
| gary_poster | (that means nothing but silliness, in case it's not clear) | 17:30 |
| deryck[lunch] | adeuring, looks fine to me. I would ask henninge or abentley for a second opinion on that one line removal in lib/lp/translations/tests/test_pofile.py.... | 17:33 |
| deryck[lunch] | adeuring, I admit that I don't know the consequences of that either. | 17:33 |
| adeuring | deryck[lunch]: yeah ;) | 17:33 |
| adeuring | henninge, abentley: It's a small request ;) | 17:34 |
| henninge | already looking at it | 17:34 |
| === beuno is now known as beuno-lunch | ||
| henninge | adeuring: wow, didn't know about multiple "for" loops in list comprehension ... | 17:40 |
| adeuring | henninge: erm.. where did you find this? (can't remember anything like that... ;) | 17:41 |
| henninge | adeuring: I just saw you only moved so you probably didn't notice. | 17:41 |
| henninge | + >>> [hoary_package] = [ | 17:41 |
| henninge | + ... package for series in view.series_batch.batch | 17:41 |
| henninge | + ... for package in series.packagings | 17:41 |
| henninge | + ... if package.distroseries.name == 'hoary'] | 17:41 |
| adeuring | yeah, looks interesing ;) | 17:42 |
| henninge | http://docs.python.org/tutorial/datastructures.html#list-comprehensions | 17:42 |
| henninge | deryck[lunch], adeuring: This is the missing text: | 17:48 |
| henninge | + Change upstream link | 17:48 |
| henninge | + Remove upstream link | 17:48 |
| henninge | adeuring: does that fit with the new permissions? | 17:48 |
| adeuring | henninge: well, I can add it back, but it does not have any effect.... | 17:49 |
| henninge | Those two represent the edit and delete icons. | 17:49 |
| adeuring | well, I would have to modify the test slightly | 17:49 |
| henninge | hm? | 17:49 |
| henninge | adeuring: no, that's not what I mean. | 17:49 |
| henninge | adeuring: is the missing of the icons expected? | 17:49 |
| henninge | the way the test is now. | 17:50 |
| henninge | If so, all is well. | 17:50 |
| adeuring | henninge: ah, the ellipis stuff? that's expected | 17:50 |
| henninge | adeuring: yes, that is what the ellipsis represented. | 17:50 |
| adeuring | henninge: and thanks for spottings the real difference ;) | 17:51 |
| henninge | well, it's what deryck[lunch] asked for ... ;-) | 17:51 |
| adeuring | henninge: there is and odd change in test_pofile. That's our main concern | 17:51 |
| henninge | oh, right | 17:52 |
| henninge | mixed that up | 17:52 |
| henninge | adeuring: that one looks like a copy&paste error. Thanks for fixing it. | 17:58 |
| bigjools | night everyone | 17:58 |
| adeuring | henninge: THANKS FOR FIGURING OUT WHAT WAS GOING ON ;) | 17:58 |
| === Ursinha is now known as Ursinha-afk | ||
| * adeuring should remove the caps-lock key... | 18:00 | |
| henninge | adeuring: r=me on the incremental diff. | 18:08 |
| adeuring | henninge: cool, thanks! | 18:08 |
| === deryck[lunch] is now known as deryck | ||
| === Ursinha-afk is now known as Ursinha | ||
| === beuno-lunch is now known as beuno | ||
| benji | henninge: did I claim a review you were already doing? (the garbo logging one) | 18:39 |
| henninge | benji: I had just started when gary and abel asked. So no doubled work. | 19:12 |
| henninge | benji: but it was unclaimed at the time. | 19:12 |
| benji | henninge: sorry about that, I'll have to be more careful | 19:14 |
| henninge | np | 19:14 |
| henninge | gary_poster: still lunching? ;) | 19:14 |
| gary_poster | no henninge :-) | 19:14 |
| henninge | gary_poster: I'd like to see your branch in action. Can you give me a URL on dev? | 19:15 |
| gary_poster | henninge, sure. It will involve feature flags. I'll get you a pastebin with details. | 19:15 |
| henninge | gary_poster: I already copied the feature flags from production if those are the ones needed. | 19:16 |
| gary_poster | henninge, ok, well, here are the details anyway :-) http://pastebin.ubuntu.com/592749/ | 19:18 |
| abentley | henninge / benji, could you please review https://code.launchpad.net/~abentley/launchpad/fix-dummy-translations/+merge/57208 | 19:19 |
| benji | abentley: I'm finishing up a review now, so one of us will get it shortly. | 19:20 |
| abentley | benji: great, thanks. | 19:20 |
| henninge | gary_poster: ah yes, I can see it ;) | 19:22 |
| gary_poster | :-) cool | 19:22 |
| * henninge remembers that Saturday was international day of Astronomy ... | 19:23 | |
| henninge | I think it was international | 19:23 |
| dobey | henninge: i think every day is a day of astronomy. :) | 19:39 |
| henninge | yeah! | 19:39 |
| gary_poster | henninge, FWIW, this is the follow-on branch to the one you are looking at. https://code.launchpad.net/~gary/launchpad/bug750561-2/+merge/57216 . It is very similar. | 19:47 |
| gary_poster | I can ask someone else to do it though, I expect it is your EoD already? | 19:48 |
| henninge | gary_poster: yes, I will stop working after this. | 19:48 |
| gary_poster | cool | 19:48 |
| henninge | gary_poster: This bit looks interesting but I don't know what it does. | 19:48 |
| henninge | http://paste.ubuntu.com/592764/ | 19:48 |
| gary_poster | henninge, this is the machinery I mentioned in the MP that adds the ability of our LPClient test stub to halt execution. That lets the test see what the state of things looks like after a call has been made to, say, named post, but before the named post has a response and calls the success or failure callback. | 19:51 |
| gary_poster | You resume the success or failure callback by calling .resume on the stubbed function/method/whatever you want to call it. | 19:51 |
| gary_poster | (And generally, that code is the heart of the LPClient test stub/mock, letting you specify for named_post and patch whether you want them to succeed or fail, and what arguments they should send back; and later letting you check the calls and arguments that it received) | 19:53 |
| lifeless | moin | 20:05 |
| lifeless | statik: are we on today? | 20:07 |
| henninge | gary_poster: thanks for the explanations. r=me | 20:09 |
| === henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | https://code.launchpad.net/launchpad-project/+activereviews | ||
| gary_poster | thank you henninge! | 20:12 |
| gary_poster | benji, short-ish one for you. | 20:13 |
| gary_poster | https://code.launchpad.net/~gary/launchpad/bug750561-2/+merge/57216 | 20:13 |
| benji | gary_poster: k | 20:14 |
| gary_poster | thank s | 20:14 |
| benji | gary_poster: review done | 20:31 |
| gary_poster | cool thanks | 20:35 |
| lifeless | sinzui: ping - bug 753306 | 20:44 |
| _mup_ | Bug #753306: mailman doesn't shut down cleanly <canonical-losa-lp> <Launchpad itself:Triaged> < https://launchpad.net/bugs/753306 > | 20:44 |
| sinzui | That looks hard | 20:44 |
| lifeless | sinzui: tom has added a note to it about what the shutdown script runs | 20:45 |
| sinzui | That does not look like anything to do with launchapd | 20:45 |
| lifeless | sinzui: I'm figuring you probably know what it should run | 20:45 |
| lifeless | sinzui: strictly speaking its not, but its part of our environment, and not an upstream script or issue | 20:45 |
| sinzui | I know the pipeline. We have a nice test that shows we reordered it | 20:46 |
| sinzui | I think the issue here is that I think mailman waits for all the handlers/pipelines to complete what they are doing before shutdown is complete | 20:46 |
| lifeless | barrrrrry! | 20:49 |
| lifeless | sinzui: so, what command *should* the losas be running to trigger a shutdown, and how long should they budget to wait | 20:50 |
| lifeless | sinzui: oh, good thought bringing barry in. I'll get my butt out now :) | 20:50 |
| sinzui | lifeless: I think I can make changes that barry recommends. He wrote the mailman-lp startup code. He may point out we lost something in a revision and advise me to put it back | 20:52 |
| jcsackett | thanks for the review, benji. | 20:57 |
| benji | my pleasure | 20:57 |
| LPCIBot | Yippie, build fixed! | 21:05 |
| LPCIBot | Project windmill build #163: FIXED in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill/163/ | 21:05 |
| === benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
