| huwshimi | StevenK: Sorry, I'm just trying to look at a couple of things. What appears on the recipient_subscriptions_url and ppa_url pages? I can see from the test what those urls translate to, I would just like to see an example of those pages. | 00:11 |
|---|---|---|
| huwshimi | StevenK: I'm mostly trying to see the difference between those pages | 00:13 |
| lifeless | wgrant: so... | 00:13 |
| wgrant | lifeless: It's now Invalid. There are other bugs for the build notification issues. | 00:14 |
| wgrant | lifeless: (which should have been a critical part of DDs, but nobody in the squad thought about it) | 00:14 |
| huwshimi | StevenK: Ah actually I figured it out. | 00:16 |
| lifeless | wgrant: can you confirm my comment on bug 47353 | 00:19 |
| _mup_ | Bug #47353: give-back-loop detection would be desireable <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/47353 > | 00:19 |
| huwshimi | StevenK: I know you haven't touched this, but shouldn't the 'recipient_subscriptions_url' link to be to: https://launchpad.net/~huwshimi/+archivesubscriptions/(id)/+index instead of the generic list of *all* the archives (I assume we can be smart enough to do that)? | 00:20 |
| lifeless | sinzui: I believe bug 50894 should be fix released | 00:25 |
| _mup_ | Bug #50894: Can't change the distribution for a distro package bug report <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/50894 > | 00:25 |
| lifeless | sinzui: and have you seen bug 52656 in the context of disclosure? | 00:27 |
| _mup_ | Bug #52656: Reports that bug contacts have been subscribed when they haven't <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/52656 > | 00:27 |
| lifeless | sinzui: also! bug 52915 - wallyworld_'s work should fix-release that, no ? | 00:27 |
| _mup_ | Bug #52915: Reassigning a private bug to a different product doesn't notify either the new product maintainer or security contact <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/52915 > | 00:27 |
| lifeless | sinzui: perhaps not, but close to it. Or something. | 00:28 |
| wallyworld_ | lifeless: i don't think it will but i can add it to my todo list | 00:28 |
| lifeless | wallyworld_: I'd check with sinzui but it seems awfully close to 'easy' now. | 00:28 |
| wallyworld_ | +1 yes | 00:28 |
| lifeless | wgrant: is bug 54773 still relevant? | 00:35 |
| _mup_ | Bug #54773: Dry run on process-accepted isn't always dry <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/54773 > | 00:35 |
| wgrant | s/process-accepted/Soyuz/ s/always/often/ | 00:35 |
| lifeless | and hah - isn't bug 55030 a dupe ? | 00:36 |
| _mup_ | Bug #55030: Binary domination removes arch-all binaries too soon <lp-soyuz> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/55030 > | 00:36 |
| lifeless | (sorry to be dragging you into this, but these bugs are sparse on symptoms) | 00:36 |
| wgrant | lifeless: 55030 would be the original, I assume... | 00:36 |
| wgrant | But I think there is a modern dupe which has been escalated. | 00:37 |
| wgrant | Right. | 00:37 |
| lifeless | and bug 55520 | 00:38 |
| _mup_ | Bug #55520: Extend the package-driven approach to Domination & JudgeSupersed <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/55520 > | 00:38 |
| lifeless | a work item with no context. \o/ | 00:38 |
| wgrant | I *think* that refers to the pushing of lots of publishing code into SPPH.publish. | 00:39 |
| wgrant | But that bug has long been a mystery. | 00:39 |
| lifeless | bug 55521 is even more useful | 00:40 |
| _mup_ | Bug #55521: Benchmark DeathRow procedure <lp-soyuz> <soyuz-publish> <Launchpad itself:Invalid> < https://launchpad.net/bugs/55521 > | 00:40 |
| wgrant | Yeah, because we know how fast it is. "not" | 00:40 |
| wgrant | lifeless: Hmm, I'm pretty sure there's an RT for that bug you said there was an RT for. | 00:41 |
| wgrant | https://rt.admin.canonical.com/Ticket/Display.html?id=43780 | 00:41 |
| lifeless | wgrant: echan :P | 00:41 |
| lifeless | oh good | 00:42 |
| lifeless | I just failed at search | 00:42 |
| lifeless | wgrant: is 60190 fixed ? | 01:03 |
| wgrant | Bug #60190 | 01:03 |
| _mup_ | Bug #60190: Misleading email when uploads are UNAPPROVED <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/60190 > | 01:03 |
| wgrant | I think it is fixed. | 01:04 |
| wgrant | I'm pretty sure modern emails say "Waiting for approval" in the subject. | 01:04 |
| lifeless | sinzui: would like your thoughts on bug 56650, i fyou are still around. | 01:16 |
| _mup_ | Bug #56650: Restrictions on milestone editing should be dropped <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/56650 > | 01:16 |
| * StevenK waits for buildout | 01:16 | |
| * StevenK looks for a private bug on qas | 01:16 | |
| StevenK | wgrant: Do you happen to have one handy? | 01:17 |
| lifeless | wgrant: so, bug 54773 - is --dry-run wanted for soyuz? | 01:18 |
| _mup_ | Bug #54773: Dry run on process-accepted isn't always dry <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/54773 > | 01:18 |
| lifeless | wgrant: or was it all yagni ? | 01:18 |
| lifeless | wgrant: and did I ask you about bug 47353 ? | 01:20 |
| _mup_ | Bug #47353: give-back-loop detection would be desireable <lp-soyuz> <soyuz-build> <Launchpad itself:Triaged> < https://launchpad.net/bugs/47353 > | 01:20 |
| wgrant | StevenK: Bug #1234 should be private still. | 01:21 |
| _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 > | 01:21 |
| wgrant | lifeless: Most of our scripts have a dry-run option, but a lot of them don't work. | 01:22 |
| wgrant | lifeless: I don't know what we want to do with them. | 01:22 |
| wgrant | I commented on 47353 an hour ago. | 01:22 |
| lifeless | ah thanks | 01:22 |
| StevenK | Oh, ouch | 01:27 |
| StevenK | It *isn't* a timeout | 01:27 |
| StevenK | ProgrammingError: column branch.transitively_private does not exist<br /> LINE 1: ...agename, Branch.stacked_on, Branch.target_suffix, Branch.tra...<br /> ^<br /> <br /> | 01:27 |
| StevenK | WALLYWORLD!! | 01:27 |
| StevenK | wallyworld_: ^ | 01:29 |
| wallyworld_ | StevenK: context? | 01:30 |
| lifeless | qastaging hasn't had the column added | 01:31 |
| lifeless | not wallyworlds fault | 01:31 |
| wallyworld_ | lifeless: i was told that db patch had been rolled out? | 01:31 |
| lifeless | process failure with fastdowntime; it should have been applied to qastaging too | 01:31 |
| wgrant | Hah. | 01:31 |
| wallyworld_ | or at least i thought it was | 01:31 |
| wgrant | I just independently asked for that in #-ops. | 01:31 |
| wgrant | Seeing just such an OOPS myself. | 01:31 |
| mwhudson | lifeless: so i can rollback or i can fix the new problem | 01:33 |
| lifeless | mwhudson: rollback | 01:33 |
| mwhudson | lifeless: is there a command line for that? | 01:33 |
| wgrant | It's not landed yet, is it? | 01:33 |
| lifeless | bzr merge -r x..before:x; bzr commit; bzr push; bzr lp-land --rollback x | 01:33 |
| mwhudson | it might still be in ec2 actually | 01:34 |
| wgrant | I see the rollback in 14011 | 01:34 |
| wgrant | And nothing since. | 01:34 |
| lifeless | mwhudson: kill the instance | 01:34 |
| wgrant | Kill the instance. | 01:34 |
| mwhudson | ok done | 01:34 |
| mwhudson | hooray for a slow test suite | 01:34 |
| wgrant | Oh, bah, I was looking at the wrong rollback. We can't deploy for a while. | 01:34 |
| lifeless | blame the software why don't you | 01:34 |
| lifeless | see | 01:34 |
| wgrant | Because the rollback was landed 5 hours after I asked :/ | 01:34 |
| lifeless | 'hooray that ec2 is so slow' | 01:35 |
| lifeless | is what I would say | 01:35 |
| wgrant | wallyworld_: We need to roll back your garbo job, too. | 01:35 |
| wgrant | wallyworld_: We can't deploy that until the triggers are in place. | 01:35 |
| wallyworld_ | wgrant: why? | 01:35 |
| wallyworld_ | wgrant: the garbo job doesn't need the triggers | 01:36 |
| wgrant | wallyworld_: Because the job only touches branches where transitively_private is NULL, right? | 01:36 |
| wallyworld_ | yes | 01:36 |
| wgrant | And the trigger isn't there to keep transitively_private consistent once it is set. | 01:36 |
| wallyworld_ | yes | 01:36 |
| wgrant | So the job is going to be setting stuff which then gets out of date. | 01:36 |
| wgrant | And is never corrected. | 01:36 |
| wallyworld_ | yes, i think that's the case sadly | 01:37 |
| wgrant | Can you revert it, please? | 01:37 |
| lifeless | there is an alternative | 01:37 |
| wallyworld_ | or we could get the triggers deployed | 01:37 |
| poolie | hi all | 01:37 |
| wallyworld_ | which is what i was counting on | 01:38 |
| lifeless | set the transitive field to null when updating private | 01:38 |
| wgrant | wallyworld_: We can't do that until friday night. | 01:38 |
| lifeless | wallyworld_: its /never/ safe to land code with a db dependency in devel before that dependency is in production. | 01:38 |
| lifeless | wallyworld_: it needs to be a hard rule, because the timelines for deploys are so radically different | 01:38 |
| wallyworld_ | lifeless: it wasn't intentional. i had a few branches on the go and got mixed up about the order | 01:39 |
| lifeless | wallyworld_: no worries | 01:39 |
| StevenK | nigelb has been hitting that, he wants to drop a column, but we haven't deployed the code that stops using it everywhere. | 01:39 |
| lifeless | wallyworld_: I'm trying to be really clear about how this stuff hangs together, at the risk of telling folk to suck eggs. | 01:40 |
| lifeless | StevenK: reverse case, but yes. | 01:40 |
| wgrant | Damn, buildbot is still only half-way through. | 01:40 |
| lifeless | StevenK: this is why finishing RFWTAD is so important | 01:40 |
| wallyworld_ | lifeless: i know the rules, it was a scheduling mistake | 01:40 |
| lifeless | wallyworld_: cool :) | 01:40 |
| lifeless | wallyworld_: like I said, just erroring on clarity atm cause its so new for everyone | 01:40 |
| wgrant | wallyworld_: So, you're reverting that in the next hour or so? | 01:40 |
| wallyworld_ | yes | 01:40 |
| wallyworld_ | wgrant: should i mark as qa bad first? | 01:41 |
| wgrant | qa-bad bad-commit-XXX | 01:41 |
| wgrant | Land with --rollback=XXX | 01:41 |
| wgrant | And lp-land, don't ec2 land. | 01:41 |
| wallyworld_ | where xxx is the rev nr? | 01:41 |
| wgrant | Yep. | 01:41 |
| wallyworld_ | what happened with qas and the column? | 01:42 |
| StevenK | But that is seperate from what is blocking my QA, right? | 01:42 |
| wallyworld_ | i thought the patch to add the column had been deployed everywhere? | 01:42 |
| StevenK | Waiting on a LOSA/completion. | 01:42 |
| wgrant | StevenK: It's the same rev, but qastaging needed the patch anyway. | 01:42 |
| wgrant | wallyworld_: qastaging doesn't automatically do DB upgrades. | 01:42 |
| StevenK | TBH, I think that needs fixing | 01:42 |
| wgrant | wallyworld_: Mostly to catch stuff landing on devel with DB patches that aren't on prod. | 01:42 |
| wallyworld_ | sure, but it thought a downtime would do it | 01:43 |
| wgrant | wallyworld_: But it also made me notice your rev. | 01:43 |
| wgrant | wallyworld_: downtime does the minimal possible. | 01:43 |
| StevenK | I'm sick of qas having a DB that is months behind | 01:43 |
| wgrant | wallyworld_: Which is applying a patch to production. | 01:43 |
| wallyworld_ | it's no good on prod if it's not on qas :-( | 01:43 |
| wgrant | wallyworld_: We should probably apply to qastaging immediately afterwards, but the timing is terrible and the last couple of downtimes have been.. chaotic. | 01:43 |
| wallyworld_ | sure. we need to fix the process cause folks will land devel code that will break qas | 01:44 |
| wallyworld_ | if qas != prod | 01:44 |
| wgrant | Well. | 01:44 |
| wgrant | OTOH if we leave it manual, it means that lifeless and I are more likely to notice revs like this one. | 01:44 |
| wgrant | StevenK: DB restores and upgrades are largely unrelated, FWIW. | 01:47 |
| wgrant | Anyway, I am wandering off for a while. | 01:47 |
| wgrant | wallyworld_: Please land that revert ASAP. | 01:47 |
| wallyworld_ | sure, have to save some work first | 01:47 |
| wgrant | Confused... | 01:47 |
| wgrant | Oh, IDE people. | 01:48 |
| wgrant | lol | 01:48 |
| wgrant | :) | 01:48 |
| mwhudson | wgrant, lifeless: can you be paranoid over https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/+merge/76493 once more? | 01:48 |
| wallyworld_ | no, not ide. | 01:48 |
| wallyworld_ | i use a single sandbox that i bzr switch between | 01:48 |
| wallyworld_ | no ide required to do a rollback | 01:48 |
| wallyworld_ | at least i can debug without editing source code :-P | 01:49 |
| wgrant | mwhudson: That's not landing again until it's been aggressively tried locally, but it looks more sensible now. And is even tested. Thanks. | 01:49 |
| mwhudson | wgrant: it was tested before | 01:50 |
| wgrant | Ah, that was one of the tests you inverted the order of? | 01:50 |
| wgrant | I only noticed the TeamScope ones. | 01:50 |
| mwhudson | just with the controller constructed and the request set up in the wrong order | 01:50 |
| wgrant | But that's the only scope I knew was broken, so maybe I wasn't looking for the others. | 01:50 |
| wgrant | Ah | 01:50 |
| mwhudson | wgrant: do you know of any tricks for testing feature rules locally? | 02:04 |
| poolie | mwhudson, locally in what sense? | 02:04 |
| mwhudson | other than grep for a feature flag check in a template and try to make it happen | 02:04 |
| poolie | on lp.dev interactively? | 02:04 |
| mwhudson | poolie: yes, lp.dev | 02:04 |
| lifeless | mwhudson: visit /+feature-rules | 02:05 |
| poolie | and look at the comment at the bottom of all html pages | 02:05 |
| mwhudson | poolie: ah cool | 02:05 |
| lifeless | mwhudson: better | 02:07 |
| lifeless | mwhudson: thanks! | 02:08 |
| mwhudson | wgrant: well, i've done positive and negative tests for pageid: and team: scopes | 02:11 |
| mwhudson | obviously default still works | 02:11 |
| mwhudson | and i'm not sure server scope really makes sense in lp.dev? | 02:11 |
| mwhudson | i guess i can change the config to make it look like edge | 02:11 |
| lifeless | server.beta IIRC | 02:11 |
| lifeless | or something | 02:11 |
| poolie | .dev i think | 02:11 |
| mwhudson | lifeless: ah you seem to be right | 02:11 |
| mwhudson | yeah .beta | 02:12 |
| poolie | we could add a /+feature-test form that lets you evaluate random stuff | 02:12 |
| StevenK | wgrant: bug 1234 on qas is public | 02:13 |
| _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 > | 02:13 |
| poolie | lifeless, do you want to talk about our qbr some time | 02:13 |
| lifeless | sure | 02:25 |
| nigelb | lifeless: Hey! Sorry, about the late reply. I was trying to understand errorlog.py the other day and I was stuck a bit. | 02:29 |
| lifeless | no worries | 02:35 |
| lifeless | I have to pop out for a few, if yo uwant to chat in ~20 I'd be delighted to do so | 02:36 |
| nigelb | Cool! | 02:36 |
| lifeless | wgrant: any comment on bug 117557 ? | 02:36 |
| _mup_ | Bug #117557: Nascent Upload code doesn't check properly for bad distroseries <lp-soyuz> <soyuz-upload> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/117557 > | 02:36 |
| nigelb | I'll grab coffee by then and boot into the right computer. | 02:36 |
| wgrant | lifeless: "aaaaaaaa" | 02:37 |
| wgrant | lifeless: NascentUpload is pretty bloody awful. | 02:37 |
| wgrant | lifeless: Probably still valid. | 02:37 |
| StevenK | wgrant: qa-ok | 02:38 |
| wgrant | StevenK: Thanks, but it's sorta irrelevant now :/ | 02:38 |
| StevenK | Indeed :-( | 02:39 |
| lifeless | nigelb: okies | 03:01 |
| nigelb | lifeless: gimme 2 mins. My laptop with launchpad is booting :) | 03:01 |
| lifeless | still? wow... | 03:02 |
| nigelb | Well, I made coffee in between, etc | 03:02 |
| lifeless | :P | 03:02 |
| lifeless | YHBT HAND HTH | 03:02 |
| jtv | wgrant: permanent gina domination looks good on dogfood… deleted a frightening number of sid packages, but the remaining number matches the number I see in Sources.gz. | 03:06 |
| wgrant | jtv: Yep, saw that on the bug. Excellent news. | 03:07 |
| jtv | Unfortunately there's a qa-bad in the way. | 03:07 |
| wgrant | jtv: Less excellent news, however, is that it still seems to be running very slowly on production... and script-monitor isn't alerting about it. | 03:07 |
| wgrant | 3 qa-bads, actually. | 03:07 |
| wgrant | Just two of them are already deployed. | 03:07 |
| jtv | wgrant: 3!? I only see 1 qa-needstesting & 1 qa-bad. | 03:08 |
| wgrant | jtv: Like I say two of them are already deployed. There are three rollbacks that need to come through buildbot and qastaging before we can deploy :/ | 03:08 |
| jtv | We'll have to see whether the slow runs are really a concern after (1) the transitional code is gone and (2) the initial deletions have been done. | 03:08 |
| wgrant | Yeah. | 03:09 |
| wgrant | I'm more worried that we're not getting alerts about it. | 03:09 |
| lifeless | its doing shorter transactionw now right ? | 03:09 |
| jtv | Muchly. | 03:09 |
| lifeless | cool | 03:09 |
| jtv | wgrant: I had to leave before we could discuss my p-d-r suggestion yesterday. Is it correct that the main worry is hidden long-standing dependencies on ancient librarian files? | 03:10 |
| wgrant | jtv: No, that was the first p-d-r issue. This one is probably pool files. | 03:13 |
| jtv | The reaper deletes those as well? | 03:14 |
| lifeless | huwshimi: do you think bug 126684 is still relevant ? | 03:15 |
| _mup_ | Bug #126684: Style sheet is overly complex <css> <lp-web> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/126684 > | 03:15 |
| nigelb | lifeless: okay, coffee by my side, and work computer turned off. | 03:18 |
| nigelb | In other news, a colleague deleted a library from production server because "it was not being used" | 03:19 |
| nigelb | I had to put out a fire today morning for that one :) | 03:19 |
| lifeless | win | 03:20 |
| nigelb | totally! | 03:21 |
| nigelb | Okay, couple of things - 1) What all information do I log? | 03:21 |
| lifeless | everything you can get except the session cookie | 03:21 |
| lifeless | errorlog.py is mostly irrelevant to you btw | 03:22 |
| lifeless | s/mostly/entirely/ | 03:22 |
| nigelb | Oh. | 03:22 |
| nigelb | Gah. | 03:23 |
| nigelb | I'll get error message, URL, line number as get parameters into js-oopsd | 03:23 |
| nigelb | I suppose I can also get a timestamp based on when I get the request | 03:23 |
| nigelb | lifeless: 1) More embarassingly, I don't see where in errorlog.py the oops is actually written to file. | 03:31 |
| nigelb | I'm guessing that's the bit I can take away from launchpad's oops handling | 03:31 |
| lifeless | nigelb: sorry | 03:40 |
| lifeless | EBABY | 03:40 |
| lifeless | nigelb: all the oops stuff is in python-oops, python-oops-wsgi, python-oops-datedir-repo etc | 03:40 |
| nigelb | ah | 03:41 |
| nigelb | I could just be using those libs.. | 03:41 |
| lifeless | s/could/will be/ | 03:42 |
| nigelb | Right. :) | 03:42 |
| lifeless | for instance, http://bazaar.launchpad.net/~lifeless/+junk/gpgverify/view/head:/gpgverify/main.py#L87 | 03:43 |
| lifeless | parses and configures a datedir repo | 03:43 |
| lifeless | then runs the app (a web.py thing, I suggest using wsgiref - it will be cleaner) | 03:44 |
| lifeless | see the various project README's and pydocs for more info | 03:44 |
| lifeless | what you need will be: | 03:44 |
| lifeless | one repo | 03:44 |
| lifeless | two configs - one for received js oopses, one for oopses from your wsgi app itself | 03:44 |
| lifeless | oops_wsgi wrapped around your app for the latter | 03:45 |
| lifeless | and explicit use of the former for the ks oopses | 03:45 |
| nigelb | *js | 03:46 |
| lifeless | that thing | 03:46 |
| nigelb | okay, so I need to read up on python-oops-wsgi and python-oops-datedir-repo | 03:47 |
| lifeless | and python-oops :P | 03:47 |
| lifeless | remind me tomorrow and I'll put a full project skeleton, and a sketch, together fo ryou | 03:48 |
| nigelb | aren't these projects by Canonical/Launchpad? | 03:48 |
| lifeless | so you can focus on the interesting stuff | 03:48 |
| nigelb | okay! | 03:48 |
| lifeless | nigelb: they are, recently extracted from the LP code base | 03:48 |
| nigelb | Yeah, I thought so ) | 03:48 |
| nigelb | :) | 03:48 |
| nigelb | wallyworld_: Hey, around? | 03:49 |
| wallyworld_ | nigelb: yep | 03:49 |
| nigelb | wallyworld_: The other day we were talking about overriding default styles for certain forms for the +editemails form that was fixing | 03:49 |
| wallyworld_ | we were | 03:50 |
| nigelb | Do you have an example to point me at? | 03:50 |
| wallyworld_ | just a sec | 03:50 |
| nigelb | I want to get those small bugs of my list :) | 03:50 |
| wallyworld_ | nigelb: lp/code/templates/branch-macros.pt | 03:51 |
| wallyworld_ | but only if it is truly a one-off | 03:51 |
| wallyworld_ | it really should be in styles-3-0.css | 03:52 |
| nigelb | Hrm, I could put it in styles--3.0.css | 03:52 |
| wallyworld_ | nigelb: and i'd check with huwshimi since he is looking at this sort of stuff and trying to fix what we've done badly in the past | 03:53 |
| nigelb | Add an ID, grab it in css. override. | 03:53 |
| nigelb | Cool, okay. | 03:53 |
| wallyworld_ | nigelb: so, in other words, we've done certain things in the past with respect to css but it may not be the right way now | 03:54 |
| nigelb | heh, I'll talk to him. | 03:54 |
| wallyworld_ | cool. thanks | 03:54 |
| wallyworld_ | best to try and avoid creating more tec hdebt :-) | 03:54 |
| nigelb | especially when I'm trying to fix tech debt :P | 03:55 |
| wallyworld_ | lol | 03:55 |
| wallyworld_ | nigelb: it may be that what was done in branch-macros.pt is ok, but better to ask | 03:55 |
| wallyworld_ | just to be sure | 03:55 |
| nigelb | Personally, I dislike CSS going anywhere other than style.css most of the time. | 03:56 |
| nigelb | <-- fan of semantic web | 03:56 |
| wallyworld_ | yep | 03:59 |
| jtv | wgrant: the reaper deletes pool files as well then? | 04:05 |
| wgrant | jtv: That is the entire purpose of the reaper. | 04:05 |
| jtv | wgrant: and so the great fear is that we might reap files there that we shouldn't? | 04:06 |
| wgrant | Yes. | 04:07 |
| jtv | I gag at the thought, but perhaps we could have a look at atimes to see if we might get lucky with the number of files that we need to worry about? | 04:08 |
| jtv | If we have atimes, of course. | 04:08 |
| wgrant | No. | 04:08 |
| jtv | No we don't have atimes, or no we can't look at them? | 04:08 |
| wgrant | You are aware that there are some hundreds of Ubuntu mirrors, right? :) | 04:09 |
| jtv | Ah those. | 04:09 |
| jtv | And we can't sample atimes from those? | 04:10 |
| jtv | Or do the files get read in the mirroring process? | 04:10 |
| jtv | Won't help with internal access, but could eliminate one source of problems? | 04:13 |
| jtv | I don't suppose we could stop files that we think can be reaped from being mirrored? | 04:24 |
| micahg | wgrant: re bug 137448, I seem to have the option to change everything | 04:24 |
| _mup_ | Bug #137448: New UI is confusing and counter inuitive for changing affected package <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/137448 > | 04:24 |
| wgrant | micahg: You can't change the package or distribution inline -- you have to know to open the expander. | 04:25 |
| wgrant | micahg: It used to be that clicking on the package name opened the expander. | 04:25 |
| wgrant | Same with status/importance. | 04:26 |
| wgrant | Before AJAX. | 04:26 |
| micahg | ah, right | 04:26 |
| wgrant | But now you can click on status/importance to change them inline, so nobody knows about the expander. | 04:26 |
| huwshimi | wallyworld_: Hey | 04:44 |
| wallyworld_ | huwshimi: yello. was going to ping you later :-) | 04:44 |
| huwshimi | wallyworld_: Would you like to wait? | 04:44 |
| huwshimi | wallyworld_: Or is now ok? | 04:44 |
| wallyworld_ | huwshimi: is it ok if i ping you in an hour or so? i'm just finishing a branch | 04:45 |
| huwshimi | wallyworld_: Of course! I'm in no hurry | 04:45 |
| wallyworld_ | huwshimi: thanks. how's the bub? | 04:45 |
| jtv | wgrant: how soon do we need the question about the safety of pool-reaping resolved? | 04:46 |
| wgrant | undef | 04:46 |
| huwshimi | wallyworld_: Doing great. Started smiling on the weekend! | 04:46 |
| nigelb | Hey, what are the branch portlets which show statistics? I can't find any. | 04:46 |
| wallyworld_ | huwshimi: we all laugh at you :-P | 04:46 |
| huwshimi | wallyworld_: It's true | 04:47 |
| StevenK | wallyworld_: Wah! There are multiple pretty-overlays on a bug page! | 04:47 |
| nigelb | what the.... | 04:47 |
| nigelb | I can now hide comments? | 04:47 |
| wallyworld_ | StevenK: yes! hence the advice in the mp to do stuff relative to a specific content box or by id :-P | 04:48 |
| wgrant | nigelb: No, that's a display bug to do with memcached. | 04:48 |
| * StevenK hides nigelb's last comment | 04:48 | |
| wgrant | WIll be fixed in a few hours. | 04:48 |
| nigelb | wgrant: AH | 04:48 |
| nigelb | StevenK: lol | 04:48 |
| nigelb | Can someone help me with bug 656941 | 04:48 |
| _mup_ | Bug #656941: Portlets on branch list pages disclose information on private branches <lp-code> <privacy> <Launchpad itself:Fix Released by nigelbabu> < https://launchpad.net/bugs/656941 > | 04:48 |
| nigelb | I can't reproduce the bug. | 04:49 |
| StevenK | wallyworld_: It's fine for +subscriptions, but there are like four for a bug page | 04:49 |
| nigelb | Wait. Fix Released. | 04:49 |
| wallyworld_ | it's fine until someone adds another one :-) | 04:49 |
| StevenK | id="yui_3_3_0_1_13166655391282262" | 04:50 |
| StevenK | Handy. | 04:50 |
| StevenK | wallyworld_: ^ ? | 04:57 |
| wallyworld_ | StevenK: that's a defualt generated one. you need to tie the overlay to a specific content box or look for it relative to another dom element | 04:58 |
| StevenK | Can I pass an id to the constructer? | 04:58 |
| wallyworld_ | StevenK: for our widgets, we tend to create content box divs with an id named after the property | 04:58 |
| wallyworld_ | StevenK: see picker_patcher | 04:58 |
| wallyworld_ | the contentBox is passed in from memory | 04:59 |
| wallyworld_ | we construct the content box with the id we pass in | 04:59 |
| wallyworld_ | i could be a bit off on the details | 04:59 |
| StevenK | http://pastebin.ubuntu.com/694948/ | 04:59 |
| StevenK | Those are the first elements of <body> | 05:00 |
| wallyworld_ | what are those overlays used for? | 05:01 |
| wallyworld_ | whicu ui elements? | 05:01 |
| StevenK | A bunch of them are for bug task editing | 05:02 |
| StevenK | The first one is the one I want, but how the frack do you *tell* that :-) | 05:02 |
| wallyworld_ | they may be tied to an Activator | 05:02 |
| wallyworld_ | are the overlays shown when the user clocks on a link, or a little sprite? | 05:02 |
| StevenK | Yes | 05:03 |
| wallyworld_ | what's the js module? | 05:03 |
| StevenK | bug_subscription_portlet | 05:04 |
| wallyworld_ | StevenK: it looks like a single overlay is created when the user clicks on a link, and then destoyed after the ajax call. so those other ones must be from elsewhere | 05:06 |
| wallyworld_ | what's the html inside one of them? | 05:07 |
| StevenK | Obviously | 05:07 |
| StevenK | The first three all start with a div with class content_box_container | 05:07 |
| wallyworld_ | i take it you just want to grab the overlay created by the bug sub portlet and ignore these other ones? | 05:10 |
| StevenK | Right | 05:10 |
| wallyworld_ | and the overlay comes up centred on the page i think? | 05:12 |
| wallyworld_ | which means it is not bound to a node,which means we can't get at it that way\ | 05:12 |
| wallyworld_ | StevenK: one way is to add a css class to the overlay node after it is created eg "bug-subscription-overlay" and do a Y.one('.bug-subscription-overlay') | 05:13 |
| wallyworld_ | that may be the easiest at the moment | 05:14 |
| wallyworld_ | StevenK: or you could even set the id of the node but i'm not sure if that's kosher | 05:15 |
| wallyworld_ | .me needs coffee | 05:26 |
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| poolie | hi wallyworld_ | 06:02 |
| poolie | could you finish off https://code.launchpad.net/~xaav/loggerhead/export-tarball/+merge/66408 some time? | 06:02 |
| wallyworld_ | poolie: hi. stupid oneiric killed my net connection. :-( | 06:02 |
| poolie | i had a bit of trouble with that a while ago | 06:02 |
| wallyworld_ | poolie: the ball is in lifeless's court | 06:02 |
| wallyworld_ | he needs to +1 it | 06:03 |
| wallyworld_ | but then he went and had a kid :-) | 06:03 |
| wallyworld_ | i'll remind him again | 06:03 |
| poolie | why does he need to +1 it? | 06:03 |
| wallyworld_ | poolie: cause i don't feel i have enough knowledge in that area to be sure it's all ok to land | 06:04 |
| wallyworld_ | i'm happy to land it once it's said to be ok | 06:04 |
| poolie | well, i think your last comment is reasonable: | 06:04 |
| poolie | > Given the number of eyeballs that have already seen this mp, it looks ok to me apart from some small lint issues. I can fix those and then land this mp. | 06:05 |
| poolie | so..? | 06:06 |
| poolie | i think we should at least let xaav know what's happening | 06:06 |
| poolie | and ideally actually finish it | 06:06 |
| poolie | would it help if i rereview it or get one of my guys to? | 06:07 |
| wallyworld_ | poolie: i just want to be 100% sure given all the back and forth that has happened on the mp | 06:07 |
| wallyworld_ | poolie: anyone who feels they have enough knowledge to say it's good is fine by me | 06:07 |
| wallyworld_ | i agree that it should be finished, it's taken way too long :-( | 06:07 |
| poolie | well | 06:09 |
| * wallyworld_ sighs. unity is very naughty today. just crashed again :-( | 06:09 | |
| poolie | so let's make a plan | 06:10 |
| wallyworld_ | ok | 06:10 |
| poolie | i don't want to block on robert in particular, because obviously he has very little spare time | 06:10 |
| poolie | and he has read it, and he hasn't specifically asked to get a rereview afaik | 06:10 |
| wallyworld_ | i don't think so either. i'm scared about anything to do with exporting/publishing, and it's had a lot of iterations, is all | 06:12 |
| wallyworld_ | greater potential for breakage therefore | 06:12 |
| poolie | how about if i ask john to read it; he's touched this | 06:12 |
| wallyworld_ | sure. if he can +1 it, i'll land it tomorrow :-) | 06:12 |
| poolie | and then perhaps you could do the lint fixes and run it up in lp.dev and see if it obviously breaks? | 06:12 |
| wallyworld_ | ok | 06:13 |
| poolie | and if that works, could you shepard landing and deploying it? | 06:14 |
| wallyworld_ | of course | 06:15 |
| wallyworld_ | huwshimi: can we mumble tomorrow morning? i've been hamstrung by software issues for a bit this arvo :-( | 06:16 |
| huwshimi | wallyworld_: Of course. | 06:17 |
| wallyworld_ | thanks. i'll ping you after our standup, around 9:30ish | 06:17 |
| wallyworld_ | huwshimi: so you've seen the managing disclosure mockups? | 06:18 |
| huwshimi | wallyworld_: No I haven't actually | 06:18 |
| wallyworld_ | huwshimi: ok. i'll email them. they're some screenshots done in balsamic | 06:19 |
| huwshimi | wallyworld_: OK thanks | 06:19 |
| wallyworld_ | and we need to provide some interactive proof of concepts | 06:19 |
| lifeless | huwshimi: do you think bug 126684 is still relevant ? | 06:24 |
| _mup_ | Bug #126684: Style sheet is overly complex <css> <lp-web> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/126684 > | 06:24 |
| huwshimi | lifeless: I'll take a look, might need a few minutes to investigate. | 06:27 |
| lifeless | no worries | 06:28 |
| lifeless | its an old css bug | 06:28 |
| lifeless | I figure its very relevant to some of your recently noted things | 06:28 |
| huwshimi | lifeless: The css classes it mentions at the start don't exist any more, there are now only three XXXs (which seem to have decent comments), I'm not sure what the conflicting columns is about, !important is still used 9 times (but I don't know if they are required), I'm not sure about the IE6 rules and most of the styles at the end of the stylesheet are there because of refactoring (with comments). sinzui has done some | 06:34 |
| huwshimi | pretty large refactoring since this bug was reported. | 06:34 |
| huwshimi | lifeless: My hunch is that the bug report is no longer useful as it is. If someone has the ability to figure out if the remaining issue are still valid they would probably be better as individual bug reports | 06:36 |
| === stub1 is now known as stub | ||
| === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugs: 256 - 0:[#########]:256 | ||
| adeuring | good morning | 08:01 |
| jtv | wgrant: an irony just struck me. ow! | 08:30 |
| jtv | In future, if a superseded source package in Release still has binary publications active, don't we just want to keep the source package active for the release's lifetime? New domination would let us do that. | 08:32 |
| stub | bigjools, wgrant: Is process-death-row.py fragile or interruptable from a fastdowntime deploy point of view? | 08:51 |
| wgrant | stub: Interruptible. | 08:51 |
| stub | wgrant: Is buildd-retry-depwait fragile? | 08:55 |
| wgrant | stub: No. | 08:55 |
| wgrant | buildd-manager and publish-ftpmaster and publish-distro are about it. | 08:56 |
| wgrant | Mm, process-upload too, but we disable that before and it doesn't run for long, so it's never come up. | 08:56 |
| === al-maisan is now known as almaisan-away | ||
| stub | wgrant: My next question was process-accepted :-) | 08:58 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | Mmm. Not really. It's not ideal if it's interrupted, but it's safe unless that happens while it's half-way through publishing a custom upload that is then rejected by an archive admin before the next run. | 09:00 |
| stub | wgrant: That unless makes it sound fragile (shut it down before a fastdowntime db update) | 09:01 |
| wgrant | stub: Yes, but it's so incredibly unlikely. But it's normally quick and we haven't run into it before, so you can probably add it to the fragile list and nobody will ever notice. | 09:02 |
| wgrant | So if you're doing a mass dbuser change, might as well do that one too. | 09:02 |
| wgrant | (I'd almost prefer we accept the minute fallout from an interrupted run, rather than have it disrupt a fastdowntime, but it's unlikely to do either...) | 09:03 |
| stub | I'm doing them. Just flagging the necessary ones in the fragile list at the same time. I added process_accepted with a comment explaining it is fast and likely to not need shutting down. | 09:04 |
| wgrant | Ah, great. Thanks. | 09:04 |
| stub | wgrant: We could improve this with cronscripts.ini or losas pushing out crontab updates before the deploy, but that is out of the scope I'm looking at. But the idea solution (per Bug #845407 metabug) is of course to not need to do that at all. | 09:06 |
| _mup_ | Bug #845407: soyuz is not fast-downtime friendly <canonical-losa-lp> <fastdowntime> <Launchpad itself:Triaged> < https://launchpad.net/bugs/845407 > | 09:06 |
| wgrant | stub: Indeed. | 09:06 |
| wgrant | stub: But transactionality when dealing with a filesystem tree that's exposed to Apache is non-trivial, probably requiring model change. | 09:06 |
| stub | We just need two-phase commit with PostgreSQL and the archive on the filesystem. trivial. | 09:06 |
| wgrant | Yep. | 09:07 |
| wgrant | Well, we could do it on Windows. | 09:07 |
| wgrant | But yeah. | 09:07 |
| stub | We could generate a filesystem on demand from a transactional backend like PostgreSQL... | 09:08 |
| stub | If we used fuse to mount it, we wouldn't even need to reengineer that much.. | 09:08 |
| wgrant | Diskless archives are meant to do that. | 09:08 |
| wgrant | But, well, they've been planned for 5 years. | 09:08 |
| lifeless | wgrant: can't do it on windows | 09:11 |
| lifeless | wgrant: the needed apis are not exposed. | 09:11 |
| lifeless | wgrant: ceph of btrfs however.. | 09:11 |
| wgrant | lifeless: Hm? TxF works fine, even with MSDTC. | 09:12 |
| bigjools | lifeless: hows the python-oops-twisted coming along? | 09:12 |
| wgrant | Only supported on >= Vista, though, so maybe after your time. | 09:12 |
| lifeless | wgrant: ah yea | 09:12 |
| wgrant | (TxF == Transactional NTFS) | 09:13 |
| stub | So we deploy on Vista. I think the licences are going cheap at the moment. | 09:13 |
| lifeless | wgrant: it doesn't talk about the consistency model | 09:13 |
| lifeless | wgrant: I could well believe atomic commits but inconsistent reads | 09:14 |
| wgrant | Possibly, but that's fine for process-accepted :P | 09:14 |
| lifeless | it == wikipedia | 09:14 |
| lifeless | oh process accepted? it can do the bzr thing easily | 09:14 |
| lifeless | ah it does - nice - 'An application can use TxF to preserve the integrity of data on disk caused by unexpected error conditions and help resolve concurrent file-system user scenarios by isolating your changes from others while the changes are being made.' | 09:16 |
| stub | Could bazaar be used to maintain all the generated files? We don't need to put the whole archive in a tree as moving files in and deleting them can be done atomically, but the generated stuff could be done and committed to a branch elsewhere and then pulled into the live tree served by Apache. | 09:18 |
| stub | I guess we wouldn't need bazaar for that - just symlinks and rsync | 09:21 |
| lifeless | right | 09:26 |
| lifeless | or a directory pivot | 09:26 |
| bigjools | lifeless: hows the python-oops-twisted coming along? | 09:43 |
| lifeless | bigjools: I didn't get anything done today :( | 09:44 |
| lifeless | bigjools: but I expect to wrap it up tomorrow | 09:44 |
| bigjools | lifeless: you're 300% late on your estimate :) | 09:44 |
| lifeless | I am | 09:44 |
| bigjools | can I help with anything? | 09:45 |
| lifeless | nah | 09:45 |
| lifeless | well, you could, but the handoff would probably be ~= to doing it myself | 09:45 |
| lifeless | so i don't think its useful | 09:45 |
| bigjools | ok I'll just keep nagging | 09:46 |
| lifeless | fair enough too | 09:48 |
| bigjools | :) | 09:48 |
| stub | rvba: https://code.launchpad.net/~stub/launchpad/distinct-db-users/+merge/76535 is a simple one | 10:06 |
| rvba | stub: Okay. | 10:07 |
| adeuring | rvba, allenap: fancy another review? https://code.launchpad.net/~adeuring/launchpad/bug-739052-10/+merge/76540 | 10:12 |
| rvba | adeuring: Sure, I'll add it to my queue. | 10:12 |
| adeuring | rvba: thanks! | 10:12 |
| === al-maisan is now known as almaisan-away | ||
| cjwatson | wgrant,stub: indeed I'm not sure we've ever manually rejected a custom upload, FWIW | 10:52 |
| === matsubara-afk is now known as matsubara | ||
| wallyworld_ | wgrant: dumb question for you | 11:40 |
| wgrant | wallyworld_: Sure. | 11:41 |
| wallyworld_ | what's wrong with bzr push lp://staging/~wallyworld/+junk/foo --stacked-on lp://staging/lp-production-configs | 11:41 |
| wallyworld_ | 'InvalidURL', 'Invalid url supplied to transport: "bzr+ssh://bazaar.staging.launchpad.net/+branch/lp-production-configs": no supported schemes | 11:41 |
| wgrant | wallyworld_: --stacked-on initially didn't work for LP. I'm not sure if it does now. | 11:41 |
| wgrant | Also, staging probably doesn't have data in lp:lp-production-configs. | 11:42 |
| wallyworld_ | wgrant: i want to test the trigger to maintain the transitivel_private column, so would like to create a branch stacked on a private one | 11:42 |
| wallyworld_ | or at least be able to manipulate the privacy status of a branch | 11:42 |
| wgrant | wallyworld_: You probably need to ask a LOSA to help you with that tomorrow. | 11:43 |
| wallyworld_ | ok. sad that we can't test such things ourselves :-( | 11:43 |
| wgrant | In a post-Disclosure world we may be able to. | 11:44 |
| wallyworld_ | hope so | 11:44 |
| wallyworld_ | it will be quite easy to test if i get someone just run run a bit of sql actually | 11:45 |
| wgrant | True. | 11:45 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | wallyworld_: Still around? | 11:56 |
| jtv | jcsackett: are you Q/A'ing your expander branch? | 12:20 |
| jcsackett | jtv: sure; hadn't gotten notice that it had been tagged qa-needstesting. | 12:21 |
| jtv | jcsackett: then you know now. :) I'm asking because it's one of 2 blockers for something that's getting a bit urgent. | 12:22 |
| jcsackett | jtv: no worries; taking a look now. | 12:22 |
| jtv | Thanks. | 12:22 |
| jcsackett | jtv: mine is qa-ok. good luck hunting down the other blocker. :-) | 12:26 |
| jtv | Thanks jcsackett! | 12:27 |
| jtv | The other, interestingly, is your reviewer sinzui. Any idea where he is? | 12:27 |
| jcsackett | jtv: it's a bit before the start of the work day here. i imagine he is doing the wake up breakfast dealing with kids thing? | 12:28 |
| jtv | I suppose. Thanks. | 12:28 |
| jcsackett | you only got me b/c i was reading the news on my pc when you pinged. :-P | 12:28 |
| jtv | I was waiting to pounce. | 12:29 |
| jtv | Any twisted experts here? I'm looking at some suspicous code of this shape: | 12:32 |
| jtv | d1 = make_deferred() | 12:32 |
| jtv | d.addCallback(f1) | 12:32 |
| jtv | Correction: | 12:32 |
| jtv | d = make_deferred() | 12:32 |
| jtv | d.addCallback(f1) | 12:32 |
| jtv | d.addCallback(f2) | 12:33 |
| jtv | And f1 seems to create its own deferred and add callbacks to it. | 12:33 |
| jtv | But I don't see anything that would guarantee that f1's own deferred will complete before f2 is called. | 12:33 |
| jml | jtv: does f1 retun its deferred? | 12:35 |
| jml | return, rather. | 12:35 |
| jml | jtv: because if it does, then that Deferred has to fire & have its callback chain complete before f2 is called | 12:37 |
| jtv | It does not return its deferred, afaics. | 12:38 |
| jml | jtv: if it doesn't, then there is no guarantee whatsoever. Well, unless f1 is using Deferreds in an explicitly synchronous way, which is rare but not unheard of. | 12:38 |
| jml | e.g. | 12:38 |
| jtv | (I'm simplifying greatly; it's pretty complicated in reality so there's also the risk of getting the call tree wrong) | 12:38 |
| jml | def f1(x): | 12:38 |
| jml | d = defer.succeed(x * 2) | 12:38 |
| jml | d.addCallback(this_gets_called_immediately) | 12:39 |
| jml | return d | 12:39 |
| jml | (pardon the IRC indentation) | 12:39 |
| jml | jtv: as a general rule, if a function gets a Deferred, it ought to return a Deferred. | 12:40 |
| jml | jtv: if you want, I can take a quick look at the real code. | 12:41 |
| jtv | What kind of “barrier” should I look for in the code? What could be in there to ensure that the nested Deferred completes before the outer one moves on to its own next callback? | 12:41 |
| jtv | I don't think the real code lends itself to a quick look, but I just posted an overview on bug 717969. | 12:42 |
| _mup_ | Bug #717969: storeBuildInfo is sometimes ineffective <boobytrap> <buildd-manager> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/717969 > | 12:42 |
| jtv | It's about one page of call tree, and I haven't figured out a good way of representing the data chain in there yet. | 12:42 |
| jtv | I may do that separately. | 12:42 |
| jtv | I added a /!\ marker where the nested Deferred seems to be created. | 12:43 |
| jtv | I'm not entirely sure it is yet; all I know about that so far is that a proxy has its callRemote called. | 12:44 |
| jml | jtv: I don't understand the question. Return the Deferred? | 12:44 |
| jml | jtv: otherwise, there's no way of ensuring | 12:45 |
| * jml frowns | 12:46 | |
| jml | the buildmanager really, really needs to have the db stuff separated out so it can be called in deferToThread and so transaction boundaries are crystal clear. | 12:47 |
| jml | jtv: working up the stack now. | 12:50 |
| wgrant | Ahh, didn't see it being discussed over here. | 12:50 |
| jtv | jml: can't judge the first part of that statement but agree with the clarity bit. Do we even have anything to guarantee, really guarantee, that we're not interleaving unrelated bits of job management in one transaction? | 12:50 |
| jml | jtv: not that I saw. other than that historically people have been urged to be careful with changing the locations of commit() | 12:51 |
| jtv | wgrant: why were you afraid? We're too far apart for immediate physical harm, and plenty of time before the next meeting to get a restraining order. | 12:51 |
| jtv | jml: be careful where you put those deck chairs… hey look at that pretty iceberg! | 12:52 |
| jtv | I've been staring at this for too long. I'm getting silly. | 12:52 |
| jml | jtv: OK. | 12:53 |
| jml | jtv: so, everything from BuilderSlave.status up is returning any Deferred it creates. | 12:53 |
| jtv | I believe so, yes. | 12:53 |
| jtv | I'm not sure where _that_ Deferred comes from exactly. | 12:53 |
| jml | t.web.xmlrpc | 12:53 |
| jml | jtv: so, you can rely on that deferred to fire before any call site proceeds to its next callback | 12:54 |
| jtv | How does that follow? | 12:54 |
| jml | jtv: http://twistedmatrix.com/documents/current/core/howto/defer.html | 12:55 |
| jtv | Read that one… which bit? | 12:55 |
| jml | http://twistedmatrix.com/documents/current/core/howto/defer.html#auto12 | 12:56 |
| jml | "If you need one Deferred to wait on another, all you need to do is return a Deferred from a method added to addCallbacks. Specifically, if you return Deferred B from a method added to Deferred A using A.addCallbacks, Deferred A's processing chain will stop until Deferred B's .callback() method is called; at that point, the next callback in A will be passed the result of the last callback in Deferred B's processing chain at the time." | 12:56 |
| jtv | Ahh | 12:56 |
| jml | or see my comments at 12:37-38 UTC | 12:57 |
| jtv | That makes more sense now, thanks. | 12:57 |
| jml | basically, without that behaviour, we might as well be passing around callback functions. | 12:58 |
| jtv | Ah, my backtrace wasn't extensive enough to cover the place where the nested deferred ended up being returned. | 13:00 |
| jtv | It's somewhat hidden in a place that creates yet a third deferred. | 13:00 |
| jtv | Which it returns, instead of the original. Hang on. | 13:00 |
| jtv | Shouldn't matter, I think. | 13:01 |
| jtv | jml: very glad to have your help, by the way. | 13:13 |
| jml | np | 13:14 |
| jtv | I did find one place (close to where things have been known to go wonky) where a callback returns None. | 13:21 |
| jml | jtv: where's that? | 13:22 |
| jtv | buildfarmjobbehavior.py, line 108. | 13:22 |
| jtv | It's one of those “should never happen” cases. | 13:22 |
| jml | jtv: even so, it won't matter | 13:22 |
| jml | jtv: callbacks can return normal values as well as Deferreds | 13:22 |
| jml | jtv: and that code path doesn't do any async operations | 13:23 |
| jml | jtv: so no ordering problems. | 13:23 |
| jtv | This is mind-bending stuff. :) | 13:24 |
| jml | jtv: yeah, but once you've bent it, it all makes sense. | 13:25 |
| jtv | This is what I fear the most. | 13:25 |
| jtv | jml: timing and implementation aside, is it a valid abstraction to think of returning a Deferred from a callback as a tail call—“finish all this work before you consider me done”? | 13:31 |
| jml | jtv: umm. I guess so. I tend to think of any Deferred returned from any function (callback or no) as a thing that will fire when it's completely done. | 13:34 |
| jtv | jml: but presumably merely returning a Deferred from a regular function has no special powers? It may seem a pedantic point but since I'm trying to hunt down a mysterious bug, I can't really assume that everything has been done by safe rules. | 13:35 |
| jtv | If a non-callback returned a Deferred that wasn't being kept anywhere, I suppose it would trigger “whenever.” | 13:36 |
| jml | jtv: it has no powers, right. Essentially, when one is returned in a callback, addCallbacks is called on it. | 13:36 |
| * jtv frowns | 13:37 | |
| jtv | Not on whatever Deferred was being executed in the call site? | 13:38 |
| jml | jtv: so yeah, if a non-callback returned a Deferred, and nothing was addCallback or addErrbacked to it, then it would trigger whenever (assuming the Python process hung around long enough) | 13:38 |
| jtv | In this case it probably would… I'm not particularly expecting this, but it's another thing to watch out for. | 13:39 |
| jml | jtv: I can never remember which way around. | 13:39 |
| jtv | I wish I had some drawing paper handy. | 13:39 |
| jml | but it's pretty logical. might help you to play around with a couple of trivial cases. | 13:39 |
| jtv | In a way it's all just tree traversals. | 13:40 |
| jml | jtv: I've got to go do pair programming now. Good luck. | 13:40 |
| jtv | Thanks for your help! | 13:41 |
| jml | also, this might help: http://mumak.net/stuff/twisted-intro.html | 13:41 |
| jtv | Ack | 13:41 |
| abentley | adeuring: http://code.mumak.net/2011/08/launchpadlib-helper.html | 13:45 |
| === al-maisan is now known as almaisan-away | ||
| rvba | jcsackett: Hi ... are you reviewing today? | 14:04 |
| jcsackett | rvba: yes! thanks for the reminder. i am somewhat off my scehdule today. :-) | 14:04 |
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett, rvba* (allenap) | Critical bugs: 256 - 0:[#########]:256 | ||
| jcsackett | and oh god; there's an 822 line diff and an 1888 one in the queue. :-P | 14:05 |
| jcsackett | rvba: i suppose you might be interested in me taking a look at your branch, eh? | 14:06 |
| rvba | jcsackett: I'm just asking because I've a branch up for review if you're up for it. | 14:06 |
| rvba | hehe | 14:06 |
| jcsackett | rvba: i'm assigning it to me now. | 14:06 |
| rvba | Great, thanks. | 14:06 |
| rvba | jcsackett: The 1888 branch seems to be targeting someone specific to review it. | 14:07 |
| rvba | jcsackett: I'm working on Ian's branch. 1355 lines ... but it's a re-implementation of a work that has been reverted. | 14:08 |
| jcsackett | rvba: ah, thanks for pointing that out. | 14:08 |
| jcsackett | we have had some very large diffs of late, it seems. | 14:08 |
| rvba | Indeed. | 14:10 |
| rvba | sinzui: Hi ... any idea why the diff is still the same even with the prerequisite branch? | 14:19 |
| sinzui | rvba, not really | 14:19 |
| sinzui | rvba, It may be caused by the fact that the first branch was backed out | 14:20 |
| rvba | I've tried to mess around with "-r ancestor:..." and other bzr magic commands but no luck. | 14:20 |
| wgrant | If the first branch is merged already, it's not useful as a prereq. | 14:20 |
| wgrant | I believe it merges the prereq into the target, then merges the proposed branch into that, and takes a diff. | 14:21 |
| wgrant | Rather than diffing from prereq to proposed. | 14:21 |
| jtv | oh, hi sinzui! Is your rollback good for deployment? | 14:25 |
| sinzui | yes | 14:25 |
| sinzui | oh, sorry, I must have missed the qa-ok on that. I did check it more than an hour ago | 14:25 |
| sinzui | fixed | 14:26 |
| jtv | Thanks. | 14:27 |
| jtv | We've got a green Q/A board; I requested a nodowntime rollout. | 14:32 |
| jtv | And now I truly must leave. | 14:33 |
| jcsackett | ciao, jtv. | 14:34 |
| jtv | nn! | 14:36 |
| gary_poster | jcsackett or rvba, https://code.launchpad.net/~gary/launchpad/bug856048/+merge/76597 could use a review | 14:50 |
| gary_poster | please :-) | 14:50 |
| rvba | gary_poster: Let me check the size of this first ;) | 14:51 |
| === salgado is now known as salgado-lunch | ||
| rvba | gary_poster: Nah, just kidding, I'll do it when I'm done with my current review. | 14:52 |
| gary_poster | rvba :-P Yeah that last one was a doozy. This one is pretty short and sweet. Thanks! | 14:52 |
| === salgado-lunch is now known as salgado | ||
| jcsackett | rvba: sorry it took me so long, but i have comments up on your MP. | 15:34 |
| rvba | jcsackett: Okay, let me have a look at your comments. | 15:35 |
| rvba | jcsackett: replied. | 15:40 |
| * deryck goes offline for lunch, back in an hour | 15:43 | |
| jcsackett | rvba: dig, thanks. i replied to your reply, but the gist is r=me. :-) | 15:43 |
| rvba | jcsackett: thanks. | 15:43 |
| jcsackett | rvba: thanks for your patience. | 15:43 |
| rvba | np | 15:45 |
| === rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 256 - 0:[#########]:256 | ||
| === beuno is now known as beuno-lunch | ||
| sinzui | jcsackett, do you have time to mumble? | 16:39 |
| jcsackett | sinzui: sure. | 16:39 |
| === matsubara is now known as matsubara-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === matsubara-lunch is now known as matsubara | ||
| lifeless | morning | 19:06 |
| nigelb | Good morning lifeless | 19:11 |
| abentley | lifeless: morning! | 19:11 |
| nigelb | This should be my cue to sleep. | 19:12 |
| lifeless | abentley: hi:) nigelb: yes | 19:12 |
| nigelb | heh | 19:12 |
| abentley | lifeless: do you know of any tech that for getting logging out of a subprocess in Python? Basically, I'm thinking of serializing the logs, writing them to a pipe, deserializing them. But I can't believe it hasn't already been done. | 19:12 |
| lifeless | hmm | 19:16 |
| lifeless | not offhand. I'm curious what the use case is - testing? | 19:16 |
| lifeless | I mean, isn't stderr often a pipe in a subprocess? | 19:16 |
| abentley | lifeless: Use case is the twisted job runner. | 19:17 |
| abentley | lifeless: I can get stderr out, but I'd rather not-- stderr has a bunch of things I don't want to know about. | 19:17 |
| abentley | lifeless: and Ideally, I'd control the verbosity of the logging in the parent process. | 19:18 |
| lifeless | theres a quirk to be aware of there | 19:19 |
| lifeless | our twisted integration generates oopses when a twisted error is logged (not the python logging module - the twisted.python.log module | 19:19 |
| abentley | lifeless: that sounds like what we do when a normal error is logged. | 19:20 |
| lifeless | it is | 19:20 |
| abentley | lifeless: So the thing is that we don't want to generate the oops twice? | 19:21 |
| lifeless | but intercepting normal error logging and preventing the oops in the subprocess won't intercept the twisted support (which I'm just rewriting now) | 19:21 |
| lifeless | there are two things | 19:21 |
| lifeless | a) we need a unique OOPS prefix, or else multiple concurrent subprocesses will overwrite each others oopses | 19:21 |
| lifeless | b) we wouldn't want to log the OOPS twice | 19:21 |
| lifeless | (and c) - we want the backtrace from inside the subprocess) | 19:21 |
| abentley | a) not a concern for this use case. | 19:22 |
| lifeless | abentley: theres no concurrency? | 19:22 |
| lifeless | abentley: or each job already sets a unique prefix? | 19:22 |
| abentley | lifeless: There's no concurrent subprocesses-- one parent, one child. | 19:22 |
| lifeless | abentley: do the parent and child have differing prefixes? | 19:22 |
| abentley | lifeless: probably not. | 19:23 |
| lifeless | so, thats something to be aware of, datedir-repo is really poor at handling this situation | 19:23 |
| lifeless | I want to move us off of that very soon | 19:23 |
| lifeless | but for now... | 19:24 |
| abentley | lifeless: but the parent waits for the child to complete, so it's unlikely to oops concurrently with the child. | 19:24 |
| lifeless | if the parent receives log entries | 19:24 |
| lifeless | and were to generate oopses on warning-or-above for those entries | 19:24 |
| lifeless | abentley: ah, just picked up on the wording | 19:25 |
| lifeless | abentley: datedir-repo is not unsafe for 'concurrent oopses' its unsafe for 'overlapping processes which both oops once or more' | 19:25 |
| lifeless | abentley: it caches the next id to use, then writes new oopses without checking for collisions, monotonically incrementing ids | 19:25 |
| lifeless | abentley: so if the child oopses once, and the parent oopses after the child finishes, the childs oops will be trashed | 19:26 |
| abentley | lifeless: okay. We can give it a unique oops prefix. | 19:27 |
| lifeless | abentley: if the parent oopses once, starts the child, the child oopses, then the parent oopses after the child finishes - same effect, but the child wouldn't have overridden the parents first oops. | 19:27 |
| lifeless | abentley: thanks. Its a great wart on the oops code, and its caused lots of contortions like this. | 19:27 |
| abentley | lifeless: I don't think my current work makes that situation worse, though. | 19:28 |
| abentley | lifeless: if you're working on the oops code, pretty please, with a cherry on top, can I get the oops ID back if I generate an oops? | 19:28 |
| lifeless | abentley: yes, the new api totally does that | 19:29 |
| abentley | lifeless: thanks. | 19:29 |
| lifeless | abentley: if you're using the ErrorReportingUtility its a little more constrained. Let me see | 19:29 |
| lifeless | raising() returns the oops dict | 19:30 |
| lifeless | so | 19:30 |
| lifeless | report = errorutility.raising(..) | 19:30 |
| lifeless | if report: oopsid = report.get('id') | 19:30 |
| abentley | Cool. | 19:31 |
| lifeless | the errorreportingutility is very web-stack centric, I'd like to let other things stop using it - most/all of the plumbing is in place to permit that, but we need to make non request-based get_request_timeline() support | 19:32 |
| lifeless | have a look a tthe current raising() method in lib/canonical/launchpad/webapp/errorlog.py - that may make it a little clearer | 19:32 |
| abentley | lifeless: anyhow, back to my original question. Is there a better way to do what I'm trying to do here? | 19:34 |
| lifeless | I would - oops in the child, serialise-and-deserialise things to log to the parent, and have some way to log errors in the parent without oopsing. | 19:35 |
| abentley | lifeless: I don't want to oops in the child. | 19:35 |
| lifeless | I don't think there is a better way to ship the logs across | 19:36 |
| lifeless | abentley: one of the things the oops grabs is the backtrace | 19:36 |
| lifeless | abentley: is the child plain ol python or also twisted? | 19:36 |
| abentley | lifeless: I just want the calling process to know that a user error ocurred. | 19:37 |
| abentley | lifeless: But it's not an indication of a programming error. | 19:37 |
| abentley | lifeless: and so the backtrace isn't important, either. | 19:37 |
| lifeless | how do you tell them apart? | 19:38 |
| lifeless | I'm sorry if I'm dragging this offtopic | 19:38 |
| lifeless | I don't mean to | 19:38 |
| abentley | lifeless: if an exceptions's class is listed on JobSubclass.user_errors, it's considered a user error. | 19:38 |
| abentley | lifeless: But I'd really like *all* logging to come across, not just errors. | 19:39 |
| lifeless | sure | 19:39 |
| abentley | right now, the twisted job runner is a bit of a black hole. | 19:39 |
| lifeless | if it were easy to have the child create oopses for non user-errors, would you be happy with it writing the oopses ? | 19:39 |
| lifeless | that would alleviate my concern about the backtrace *when* it matters | 19:40 |
| lifeless | we can still ship all the logs across | 19:40 |
| abentley | lifeless: I already have the child creating oopses for non user-errors. | 19:40 |
| lifeless | ok, great. | 19:40 |
| lifeless | btw you might like to look at errorlog.py's _oops_config.filters - thats an extension point for stopping oopses | 19:41 |
| lifeless | </tangent> | 19:41 |
| lifeless | I can only think of three basic ways this can be done: - an API in the client you can query, writing to a pipe the parent watches, or writing to some known-location the parent can read-back from (e.g. a regular file on disk) | 19:42 |
| lifeless | I think using a pipe is totally fine | 19:42 |
| abentley | lifeless: It seems like such an obvious solution that I'm surprised I can't find an implementation anywhere. | 19:44 |
| lifeless | abentley: I suspect most people just log to a file | 19:44 |
| lifeless | abentley: and/or stderr, and watch that. Full introspection of whats being logged (which a pipe may allow) is rather heavier than most people need | 19:44 |
| lifeless | abentley: I agree that its an obvious implementation for the question 'how do I get all the log entries into a parent process' | 19:46 |
| abentley | lifeless: I guess the desire to do parent-side filtering and handling is what's pulling me that way. | 19:46 |
| lifeless | abentley: yes. I don't understand that desire, but I'm assuming its got good reasons :) | 19:47 |
| abentley | lifeless: At minimum, I want the same verbosity to be used for parent and child logs. | 19:48 |
| lifeless | for clarity - I don't mean to imply its unreasonable or anything, we simply haven't chatted about it. | 19:48 |
| abentley | lifeless: It also seems to make testing easier. | 19:48 |
| lifeless | in the soyuz area we have a similar thing | 19:49 |
| lifeless | there is a process that runs N child processes | 19:49 |
| lifeless | currently its not passing -q / -v down to them, so the verbosities are different | 19:49 |
| lifeless | so +1 on the same verbosities | 19:50 |
| lifeless | abentley: what does it do for testing? | 19:50 |
| abentley | lifeless: Usually when I test that something gets logged, I do it through the python logging mechanism with TestCase.expectedLog | 19:52 |
| lifeless | ok, I can see that helping; OTOH if you're looking from output from a child process when testing the parent code, you are testing 2 layers at once - perhaps it would be better to be testing them seperately? | 19:53 |
| lifeless | the only downside I can see to using a pipe and serialising the logs is that it will have tighter coupling than passing command line parameters around and watching stderr / a file on disk | 19:54 |
| abentley | lifeless: I want to test the integration. I want to prove that logs propagate from child to parent. | 19:55 |
| lifeless | abentley: isn't that partly circular? You want logs to propogate because you need the same verbosity + its easier to test, and you're testing that its easier to test? | 19:55 |
| abentley | lifeless: no, it's not circular. I could test that logs propagate from child to parent if they were logged normally to a pipe instead of serialized. It would just be a matter of getting access to the data that comes across that pipe. | 19:57 |
| lifeless | abentley: so there is another reason to pass logs across, other than what we've already discussed? | 19:58 |
| abentley | I want all the logs related to a job run to end up in the same place. | 19:59 |
| lifeless | ok! | 19:59 |
| lifeless | given that I'd be inclined to just write to a pipe | 19:59 |
| lifeless | and tell the child verbosity via our standard options | 20:00 |
| lifeless | but serialising will work too. The reason I would just write to a pipe is that I think its easier than managing a protocol | 20:00 |
| abentley | lifeless: the subprocess is launched via Ampoule, so we can't use the standard way of specifying verbosity, but I don't think it'll be terribly hard. | 20:03 |
| === matsubara is now known as matsubara-afk | ||
| * jcsackett hates his development environment today. | 20:37 | |
| jcsackett | anyone know how to get rid of the "You may supply --create-prefix to create all leading parent directories." messages on local codehosting pushes? | 20:45 |
| jcsackett | i've had to rebuild my lp stuff and seem to have broken that, and recall wgrant helping me fix it *months* ago. | 20:46 |
| lifeless | incoming | 20:49 |
| jcsackett | lifeless: ? is that related to your earlier convo above, or to me? or some other, third thing? :-P | 20:54 |
| lifeless | jcsackett: medium bug triage ;) | 20:54 |
| jcsackett | lifeless: oh. i see. | 20:55 |
| * jcsackett modifies bug mail filters. | 20:55 | |
| jcsackett | :-P | 20:55 |
| lifeless | mwhudson: where is bug 123880 at ? | 21:08 |
| _mup_ | Bug #123880: Codebrowse needs a custom 502 error page <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/123880 > | 21:08 |
| abentley | mwhudson: Do you know if there's a way in Twisted to forward logging from a subprocess to the parent process? | 21:09 |
| mwhudson | lifeless: no idea, sounds more like a losa task than anything to me? | 21:11 |
| lifeless | sinzui: help on bug 125545 please :) | 21:11 |
| _mup_ | Bug #125545: Language variants should know their parent language <lp-foundations> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/125545 > | 21:11 |
| lifeless | mwhudson: it may even be done... | 21:11 |
| mwhudson | abentley: i'm not sure what that would mean | 21:11 |
| mwhudson | lifeless: yeah, i think the 502 page for codebrowse is fine currently | 21:12 |
| mwhudson | lifeless: so just close it i reckon | 21:12 |
| sinzui | lifeless, we do filtering in python instead of the db because we do not know that en_US is a child of en | 21:13 |
| sinzui | I marked it low | 21:13 |
| lifeless | thanks | 21:13 |
| abentley | mwhudson: A suprocess calls log.err, and the effect is as though log.err was called in the parent process. Presumably by serializing the log messages to a pipe or socket. | 21:16 |
| mwhudson | abentley: ah, i'm not aware of anything like that, no | 21:16 |
| abentley | mwhudson: Cool, thanks. | 21:16 |
| mwhudson | abentley: i notice twisted has a syslog observer http://twistedmatrix.com/documents/10.1.0/api/twisted.python.syslog.html which would be a bit similar to the subprocess side of that i guess | 21:17 |
| lifeless | we use that already (via the oops observer, which I'm redoing :P) | 21:19 |
| sinzui | jcsackett, could you review https://code.launchpad.net/~sinzui/launchpad/valid-targets-0/+merge/76658 if you have time | 21:20 |
| jcsackett | sinzui: i certainly can. | 21:20 |
| mwhudson | ah cool | 21:23 |
| jcsackett | sinzui: r=me. | 21:41 |
| sinzui | thank you | 21:41 |
| === almaisan-away is now known as al-maisan | ||
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256 | ||
| lifeless | wgrant: bug 137448 - really? I thought you fixed that? | 22:17 |
| _mup_ | Bug #137448: New UI is confusing and counter inuitive for changing affected package <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/137448 > | 22:17 |
| lifeless | poolie: if you're still hacking on lp email, bug 138592 would be the bomb to fix | 22:19 |
| _mup_ | Bug #138592: Bug notifications have personal To: header but aren't personal <email> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/138592 > | 22:19 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | whats the oldest version of ie we support ? | 23:40 |
| StevenK | I hope 7, but I suspect 6. | 23:42 |
| lifeless | grah | 23:42 |
| lifeless | yeah | 23:42 |
| lifeless | I wiped that from mmy mind | 23:42 |
| StevenK | Global use of IE6 is hovering around 9%. | 23:45 |
| StevenK | IE8 is 30% or so. | 23:45 |
| StevenK | Whoa. Firefox *2*. 0.16% | 23:46 |
| wallyworld_ | huwshimi: you free now for a chat? | 23:50 |
| === wallyworld_ changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 256 - 0:[#########]:256 | ||
| jelmer | lifeless: are you going through *all* launchpad bugs, or a specific category? | 23:54 |
| huwshimi | wallyworld_: Do you mind if we talk in 10 min? | 23:54 |
| lifeless | jelmer: medium | 23:54 |
| wallyworld_ | huwshimi: sure, ping me when you are ready | 23:54 |
| huwshimi | wallyworld_: Thanks | 23:54 |
| lifeless | jelmer: there is a discussion about possible downgrading high->medium and critical->high. *if* that happens we don't want to 1000 untriaged bugs to the high bucket | 23:55 |
| lifeless | jelmer: there was some talk about a batch move, but I did a sample 75, and many were irrelevant/fixed/dupes or genuinely high; so I suggested we just treat them as untriaged and triage them. | 23:55 |
| lifeless | jelmer: I'm doing 75 a day | 23:55 |
| jelmer | lifeless: ah, makes sense | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!