| lifeless | StevenK: is https://lpci.wedontsleep.org/ still the jeknins? | 00:23 |
|---|---|---|
| lifeless | StevenK: I don't see an attached executor | 00:24 |
| StevenK | lifeless: That's because I haven't done it yet because I was noming | 00:32 |
| lifeless | StevenK: ah kk | 00:33 |
| StevenK | lifeless: Your key has been added | 00:35 |
| StevenK | lifeless: ubuntu@23.22.38.59 | 00:36 |
| StevenK | lifeless: I've not updated xvfb did you want to hack that in before we kick off a build? | 00:37 |
| lifeless | sure | 00:37 |
| lifeless | win: $ lxc-ls | 00:39 |
| lifeless | lptests | 00:39 |
| lifeless | lptests | 00:39 |
| lifeless | two for the price of one | 00:39 |
| StevenK | Haha | 00:39 |
| lifeless | StevenK: ah, lxc-start is still running | 00:39 |
| lifeless | lptests setup still happening ? | 00:39 |
| StevenK | No ... | 00:40 |
| lifeless | the android-in-magazine thing is kindof cool | 00:40 |
| lifeless | ok, well the base is running | 00:40 |
| lifeless | so I'll just use that | 00:40 |
| lifeless | StevenK: whats the password for jenkins, do you know ? | 00:42 |
| lifeless | StevenK: doesn't seem to have passwordless sudo within the container | 00:42 |
| StevenK | It ought to | 00:42 |
| lifeless | jenkins@lptests:~$ sudo apt-get install xvfb | 00:42 |
| lifeless | [sudo] password for jenkins: | 00:42 |
| StevenK | It certainly does outside the container | 00:42 |
| StevenK | lifeless: And it doesn't have one, the user is created with --disabled-password | 00:43 |
| lifeless | StevenK: I am confuse | 00:44 |
| lifeless | StevenK: how does lpsetup install stuff within it then ? | 00:44 |
| StevenK | I have no idea how lpsetup does its thing | 00:44 |
| lifeless | anyhow I've edited the file from outside | 00:45 |
| lifeless | so xvfb-run is fixed | 00:45 |
| lifeless | should I stop the container ? | 00:45 |
| StevenK | Yeah, let's do that and I'll kick off a build | 00:45 |
| lifeless | done | 00:45 |
| StevenK | and done | 00:45 |
| lifeless | what concurrency did you use ? | 00:51 |
| StevenK | 4 | 00:51 |
| lifeless | hmm | 00:51 |
| StevenK | That hasn't changed at least | 00:51 |
| lifeless | lxc-ls shows 8 | 00:51 |
| lifeless | I detect a bug in lxc-ls | 00:52 |
| lifeless | ls /var/lib/lxc/ | 00:52 |
| lifeless | lptests lptests-temp-1FaKWwb lptests-temp-c8jcW0W lptests-temp-qoZ6ncr lptests-temp-wbvIQLE | 00:52 |
| lifeless | $ | 00:52 |
| StevenK | testr run --parallel --concurrency=4 | 00:52 |
| lifeless | yeah | 00:52 |
| lifeless | I know | 00:52 |
| lifeless | check out lxc-ls on the executor though :P | 00:52 |
| StevenK | Haha | 00:52 |
| StevenK | lxc has bugs? I'm SHOCKED | 00:52 |
| StevenK | lifeless: It could be once is for the container and another to show its running? | 00:53 |
| lifeless | argh | 00:55 |
| lifeless | cp's should really be cp dest source | 00:55 |
| lifeless | cp -t . <- awkward | 00:56 |
| StevenK | Hah | 00:56 |
| lifeless | StevenK: 'ps fax | grep python.*load-list | grep -v resume-layer | awk '{ print $14 }' | xargs cp -t .' | 00:56 |
| lifeless | StevenK: captured the lists being executed. | 00:56 |
| StevenK | You can't get that from the temp directory inside workspace/devel? | 00:57 |
| abentley | lifeless, StevenK: I know little, but read this post that said "The lxc-list command lists anything that’s a directory in /var/lib/lxc": http://jonathancarter.org/2012/09/29/llxc-my-little-python3-lxc-based-project/ | 00:57 |
| StevenK | Ah ha! | 00:58 |
| StevenK | raise LocationError(subject, name) | 00:58 |
| StevenK | LocationError: (None, 'branch_type') | 00:58 |
| lifeless | abentley: it also looks in cgroups | 00:58 |
| lifeless | abentley: and the mount table - its just a shell script if you want to look at it, it is AFAICT just confused by the unionfs going on. Or something like that. | 00:59 |
| abentley | lifeless: So far, I haven't used lxc. Tried to set up juju-on-lxc last week, ran into some glitch with zookeeper. | 01:00 |
| lifeless | abentley: ah, so yeah - juju-on-lxc does things more differently than juju-on-openstack, for instance, which I find odd. | 01:00 |
| lifeless | abentley: lxc on its own is pretty nice, and lpsetup does a decent job of configuring it. | 01:03 |
| lifeless | wgrant: / StevenK: I think a 'here is how I did it' post to the -dev list might be useful for folk. | 01:03 |
| StevenK | lpsetup needs a -y :-( | 01:03 |
| wgrant | lifeless: Once we've actually done it, yeah :) | 01:03 |
| lifeless | the new shiny stuff hasn't been socialised nearly enough. | 01:03 |
| wgrant | lifeless: Unrelatedly, I'd like to basically abolish the explicit slave/master store selectors from normal code. | 01:05 |
| wgrant | Do you see any reason to keep them? | 01:05 |
| wgrant | A few places explicitly use a slave store for searching, but that seems pretty pointless. | 01:05 |
| lifeless | I haven't done an audit but the idea sounds fine to me | 01:06 |
| lifeless | I agree that forcing a slave for searching is unnecessary | 01:06 |
| wgrant | lifeless: Thanks. | 01:09 |
| wgrant | If basically everything uses the policy's default store, then we can avoid terrible fallback hacks in the DB policies. | 01:10 |
| wgrant | Plus code gets shorter | 01:10 |
| wgrant | eg. a lot of scripts use IMasterStore everywhere | 01:10 |
| wgrant | When scripts always default to the master anyway | 01:10 |
| wgrant | wallyworld_: Looks like you may have broken the build | 01:11 |
| wgrant | But that's impressively few test failures considering what you've done. | 01:11 |
| wallyworld_ | iy passed ec2 | 01:11 |
| wallyworld_ | it | 01:12 |
| wallyworld_ | hmmm | 01:12 |
| wallyworld_ | looking | 01:12 |
| wgrant | http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/83/steps/shell_9/logs/summary | 01:12 |
| wallyworld_ | i can click that myself you know | 01:14 |
| wgrant | Yeah, but it's like a buildbot bookmark and 3 clicks away | 01:14 |
| wallyworld_ | i already had bb open to monitor the build | 01:16 |
| wgrant | Ahh | 01:16 |
| StevenK | wgrant: Do you know about the code.simplified_branches_menu.enabled FF ? | 01:16 |
| wgrant | StevenK: It's been on for everyone for more than a year, I'm pretty sure | 01:16 |
| wgrant | It can probably be removed. | 01:16 |
| StevenK | Yeah | 01:17 |
| StevenK | Lets do that | 01:17 |
| wgrant | Even better if you remove the view code but forget the model stuff, so I can delete it myself later :P | 01:18 |
| StevenK | Hah | 01:21 |
| StevenK | I don't think this includes any model code | 01:21 |
| === matsubara is now known as matsubara-afk | ||
| StevenK | wgrant: PersonBranchesMenu makes me sad. It has these link properties and they're so generically named that I can't tell if they're used | 01:29 |
| StevenK | wgrant: So if a method returns a link a template still has to reference it? I can't any results for '/owned' | 01:35 |
| wgrant | StevenK: Most of the time | 01:36 |
| wgrant | StevenK: But sometimes entire menus are probably rendered | 01:36 |
| StevenK | This is PersonBranchesMenu and I want to destroy more code | 01:36 |
| wgrant | Delete them and see what breaks, perhaps | 01:37 |
| StevenK | 6 files changed, 66 insertions(+), 180 deletions(-) | 01:45 |
| StevenK | I think I've deleted enough to make up for I added | 01:45 |
| StevenK | wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/skip-private-dev-focus/+merge/127622 | 02:02 |
| LPCIBot | Project devel build #1105: STILL FAILING in 1 hr 28 min: https://lpci.wedontsleep.org/job/devel/1105/ | 02:13 |
| StevenK | That's wallyworld_'s fault too | 02:15 |
| wallyworld_ | StevenK: this is where I think some pragmatism is needed with the LOC thing - your branch combines 2 totally unrelated changes just for the sake of artificially reducing LOC when really 2 branches would have been better, and now it makes it harder to review because you have to constantly ask what unit of work the various parts of the diff are for | 02:52 |
| wgrant | The LoC policy doesn't say anything about single branches being LoC-negative. | 02:54 |
| wallyworld_ | i know | 02:54 |
| wgrant | That would be perfectly acceptable as two separate branches | 02:54 |
| lifeless | it explicitly avoids that in fact | 02:54 |
| wallyworld_ | which i why i questioned it | 02:54 |
| wgrant | So there's no pragmatism required :) | 02:55 |
| wallyworld_ | well, that's my bias coming through | 02:55 |
| StevenK | I can delete the MP and blow them apart | 02:55 |
| wallyworld_ | if a better solution requires slightly more zLOC, then so be it | 02:55 |
| wallyworld_ | LOC should be a secondard consideration, always | 02:55 |
| wallyworld_ | secondary | 02:56 |
| wgrant | Sure | 02:56 |
| wgrant | But in most cases there's an easy win | 02:56 |
| wallyworld_ | StevenK: that would be great if you could | 02:56 |
| * StevenK stops glaring daggers at LibrarianFormatter | 02:56 | |
| lifeless | StevenK: ok, so what I'm doing to reproduce is this: | 02:59 |
| lifeless | cd /home/jenkins/launchpad/lp-branches/workspace/devel/ | 02:59 |
| lifeless | jenkins@ip-10-218-67-147:~/launchpad/lp-branches/workspace/devel$ sudo /usr/local/bin/lp-setup-lxc-test lptests /home/jenkins/.ssh/id_rsa --load-list /home/jenkins/runs/tmpzqc6_R > ~/runs/stream 2>~/runs/stream_err | 02:59 |
| lifeless | using the captured load-list | 02:59 |
| lifeless | which contained one of the tests that got spewed to https://lpci.wedontsleep.org/job/devel/1105/console | 02:59 |
| lifeless | StevenK: when it completes, if the stream is corrupt, we'll have reproduction. | 03:00 |
| StevenK | Nice | 03:00 |
| lifeless | StevenK: if it isn't, we'll need to keep trying harder. | 03:00 |
| lifeless | Once we have reproduction, then I'll start on trimming down the size neede dto trigger the failure: first delete all the tests that ran *after* the corruption (allowing 2- or 3 to stay for buffer flushing just-in-case) | 03:01 |
| lifeless | then delete all the tests before it, leaving enough to trigger the fail | 03:01 |
| lifeless | rinse and repeat - binary search needed for some of these 'delete all the' bits. | 03:01 |
| wgrant | wallyworld_: Why don't we just restrict +bugs and searchTasks to users with launchpad.View? | 03:01 |
| lifeless | because every alteration will permute things | 03:01 |
| wgrant | Or zope.Public for public artifacts. | 03:01 |
| wgrant | wallyworld_: Unauthorized is the correct exception to raise; it triggers the 403 page like any other forbidden page | 03:02 |
| wgrant | We don't need a more user-friendly message than that. | 03:02 |
| wallyworld_ | wgrant: no, what's there in the mp is restoring existing behaviour which i broke with the ff removal | 03:02 |
| wgrant | Or if we do, then we need it generally. | 03:02 |
| wgrant | wallyworld_: Right, but is it valuable existing behaviour? | 03:03 |
| wallyworld_ | yes | 03:03 |
| wgrant | Oh, is this the "this information is not shared with you" thing? | 03:03 |
| wgrant | That we added recently? | 03:03 |
| wgrant | for LimitedView? | 03:03 |
| wallyworld_ | it was specifically asked for during disclosure development | 03:03 |
| wgrant | Right, that makes more sense | 03:03 |
| wgrant | Not actual sense | 03:03 |
| wallyworld_ | yes, the "this info is no shared " thing | 03:03 |
| wgrant | But more :) | 03:03 |
| * wallyworld_ doesn't want to speculate on the usefulness of the feature, just implementing what's been asked for | 03:04 | |
| wgrant | r=me | 03:04 |
| wgrant | Sure | 03:04 |
| wallyworld_ | thank you | 03:04 |
| wgrant | I just thought it was probably some terrible ancient thing | 03:04 |
| wallyworld_ | fair enough :-) | 03:05 |
| wgrant | And terrible ancient things that I don't know about can usually be deleted without anyone noticing. | 03:05 |
| wallyworld_ | the recent bb breakage was me attempting to fix the failing test | 03:05 |
| wallyworld_ | so i neutered the test to get bb going | 03:05 |
| wgrant | Right, I saw you'd dropped the +bugs team check thingy | 03:05 |
| wallyworld_ | and then provided the proper fix | 03:05 |
| lifeless | StevenK: general design rule testr honours is to expose data / state so folk can go digging :) | 03:06 |
| StevenK | But not quite enough data in this case | 03:07 |
| lifeless | StevenK: what would you like added ? | 03:09 |
| lifeless | /usr/bin/python 27917 jenkins 0r FIFO 0,8 0t0 18555269 pipe | 03:14 |
| lifeless | seems saner | 03:14 |
| lifeless | /usr/bin/python 27917 jenkins 1w FIFO 0,8 0t0 18555270 pipe | 03:14 |
| lifeless | /usr/bin/python 27917 jenkins 2w FIFO 0,8 0t0 18555271 pipe | 03:14 |
| lifeless | so the xvfb-run fix is intact | 03:14 |
| wallyworld_ | wgrant: installing the cert works great for chrome but now ff constantly complains about (Error code: ssl_error_bad_cert_domain) even if i add an exception. any idea? | 03:38 |
| StevenK | lifeless: Merely pointing out that testr does not provide quite enough state or data to be able to tell what's leaking | 03:38 |
| lifeless | StevenK: but it does, AFAICT | 03:38 |
| lifeless | StevenK: I mean, I'm doing this because I've lots of experience and I have the time atm | 03:39 |
| lifeless | StevenK: but there was nothing hidden that would make it hard to reproduce | 03:39 |
| lifeless | no need for a debugger, for instance. | 03:39 |
| lifeless | or extra print statements | 03:39 |
| lifeless | StevenK: I mean, clearly its going wrong :P | 03:40 |
| StevenK | wallyworld_: https://code.launchpad.net/~stevenk/launchpad/skip-private-dev-focus/+merge/127629 should be more to your liking | 03:45 |
| StevenK | wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-simplified-branch-ff/+merge/127630 | 03:48 |
| wallyworld_ | StevenK: bit of a nitpick on line 52 - s/an/a | 03:49 |
| StevenK | Ah yes. It made sense before I added 'private' in :-) | 03:49 |
| wallyworld_ | StevenK: so thst i understand, will self.branch be None if the user cannot see the devfocus branch? | 03:50 |
| StevenK | wallyworld_: Yes, I won't paste the code block, but the development_focus_branch property will only return the branch if the user has permission to see it. In the cases there is no devfocus or it's invisible, it returns None. | 03:53 |
| wallyworld_ | StevenK: right, and this is the self.branch attribute used in external_visible? | 03:54 |
| StevenK | wallyworld_: Right, self.branch backs onto self.development_focus_branch | 03:54 |
| wallyworld_ | ok, thanks | 03:54 |
| wallyworld_ | r=me | 03:55 |
| StevenK | wallyworld_: I'll push up that nitpick before landing too | 03:56 |
| wallyworld_ | StevenK: and now you get to close a second bug :-) | 03:56 |
| wallyworld_ | since there are 2 x mp | 03:56 |
| wgrant | wallyworld_: Which domain are you going to? | 03:57 |
| wallyworld_ | wgrant: bugs.launchpad.dev | 03:57 |
| StevenK | wallyworld_: Which second bug? | 03:57 |
| wallyworld_ | now works without complain in chrome | 03:58 |
| StevenK | Very tempted to just Won't Fix bug 393407 | 03:58 |
| wallyworld_ | StevenK: the one you raise for removing the feature flag | 03:58 |
| _mup_ | Bug #393407: PPA doesn't allow signed contributed builds <feature> <lp-soyuz> <ppa> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/393407 > | 03:58 |
| StevenK | wallyworld_: Bleh | 03:58 |
| wgrant | wallyworld_: Does the Firefox cert error show the right cert? | 03:58 |
| wgrant | It's possible you're fighting with SNI and losing, or something like that | 03:58 |
| wallyworld_ | hmm. not sure, let me look | 03:58 |
| wallyworld_ | wgrant: it's labelled as "Invalid Certificate" when i use ff to get the cert from the error screen. not sure how to know what the right one is | 04:01 |
| wallyworld_ | wgrant: i actually ran the entire rf-setup-certs.sh script once, but it complained about an invalid file or dir so i just ran the last 2 lines and that seemed to work | 04:03 |
| wallyworld_ | which it did for chrome | 04:03 |
| StevenK | wgrant: I wonder if bug 583392 is fixed now | 04:04 |
| _mup_ | Bug #583392: IntegrityError raised setting a branch for a project series. <branches> <easy> <lp-code> <oops> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/583392 > | 04:04 |
| wgrant | wallyworld_: Try adding the cert to Firefox's certstore manually, I guess. | 04:05 |
| wgrant | StevenK: It appears to be, indeed. | 04:07 |
| lifeless | ok, it reproduced on that one stream | 04:11 |
| lifeless | now to divide and conquer | 04:11 |
| lifeless | cp tmpzqc6_R{,.orig} | 04:11 |
| lifeless | and delete all but the 50 or so tests before the glitch | 04:11 |
| lifeless | stream_err has only this: | 04:12 |
| lifeless | less stream_err | 04:12 |
| lifeless | Warning: Permanently added '10.0.3.8' (RSA) to the list of known hosts. | 04:12 |
| lifeless | kill: 186: No such process | 04:12 |
| lifeless | Stopping lxc | 04:12 |
| lifeless | and a blank line | 04:12 |
| wgrant | Hm | 04:12 |
| wgrant | Did someone disable qastaging updates? | 04:12 |
| lifeless | it can mess things up, but there is so little of it, and its all (AFAICT) outside of the xvfb-run anyhow, which is why xvfb-run isn't directly griefing us | 04:12 |
| lifeless | s/directly/frequently/ | 04:12 |
| lifeless | StevenK: http://paste.ubuntu.com/1257313/ list of tests | 04:13 |
| StevenK | lifeless: Nice | 04:15 |
| lifeless | StevenK: and for tracking progress https://bugs.launchpad.net/launchpad/+bug/1060616 | 04:26 |
| _mup_ | Bug #1060616: subunit stream corruption with jenkins test runs <Launchpad itself:Triaged> < https://launchpad.net/bugs/1060616 > | 04:26 |
| StevenK | lifeless: So, thanks for filing that, but not another critical :-( | 04:26 |
| lifeless | StevenK: https://bugs.launchpad.net/launchpad/+bug/1060616/comments/1 | 04:31 |
| _mup_ | Bug #1060616: subunit stream corruption with jenkins test runs <Launchpad itself:Triaged> < https://launchpad.net/bugs/1060616 > | 04:31 |
| wallyworld_ | wgrant: got it working. had to convert the x509 cert for chrome to a pkcs12 one for firefox. i have no idea about all this stuff | 04:31 |
| lifeless | StevenK: now that we have an unadulterated stream, we can see pretty clearly whats fucked up | 04:31 |
| StevenK | Indeed | 04:32 |
| lifeless | I'll file a testr bug about making it easier to get said stream. | 04:32 |
| wgrant | wallyworld_: Hm, Firefox should be able to import plain x509 too | 04:32 |
| wallyworld_ | wgrant: it didn't seem to give me that option, only pkcs12 | 04:33 |
| wallyworld_ | i tried to import the x509 and it complained | 04:33 |
| wallyworld_ | at least it all works now, and the other ff lp.dev issue is gone now too | 04:34 |
| lifeless | StevenK: so this is critical, because if it breaks on buildbot it will equally badly and mysteriously. | 04:34 |
| wgrant | wallyworld_: Ah, were you trying to import into the Personal section? | 04:34 |
| * wallyworld_ shrugs | 04:34 | |
| wgrant | that needs a private key too, so it requires PKCS#12 | 04:34 |
| wallyworld_ | yes, looks like i was | 04:34 |
| wgrant | Servers/Authorities should work with x509 | 04:35 |
| wallyworld_ | ok, will try that next time it breaks | 04:35 |
| StevenK | lifeless: Indeed | 04:37 |
| wgrant | "USN-1551-1 fixed vulnerabilities in Thunderbird. The new package caused a | 04:38 |
| wgrant | regression in the message editor and certain performance regressions as | 04:38 |
| wgrant | So it wasn't just me! | 04:38 |
| wgrant | well. This update fixes the problems." | 04:38 |
| lifeless | StevenK: its worse than I thought: | 04:52 |
| lifeless | see comment 2 | 04:52 |
| StevenK | Wheee | 04:55 |
| wgrant | That's normal | 04:57 |
| wgrant | If the subprocess dies, the rest of the layer goes with it. | 04:57 |
| wgrant | And the parent often doesn't notice. | 04:57 |
| StevenK | There's a bug for that | 04:57 |
| StevenK | Subprocess death unheeded by parent or so | 04:58 |
| wgrant | Right | 04:58 |
| lifeless | well | 04:59 |
| lifeless | so the question is | 04:59 |
| lifeless | is python failing to process a finally: | 04:59 |
| lifeless | or is something else fubared | 04:59 |
| wgrant | Which test is it dying on? | 04:59 |
| wgrant | Probably something that uses webkit | 05:00 |
| lifeless | wgrant: lib/lp/code/javascript/tests/test_productseries-setbranch.html and lp/testing/tests/test_yuixhr_fixture_facet | 05:00 |
| wgrant | Ah yes | 05:00 |
| wgrant | So it is | 05:00 |
| wgrant | So it'll be segfaulting. | 05:00 |
| wgrant | You can reproduce that easily | 05:00 |
| lifeless | so, subunit layer, it may make sense to have a 'close off the stream no matter what' escape clause | 05:00 |
| wgrant | It usually happens when run outside xvfb-run, though | 05:00 |
| lifeless | which the parent could use | 05:01 |
| lifeless | however | 05:03 |
| lifeless | need to determine first how the parent-child stuff works | 05:04 |
| lifeless | it may be that the parent is just being stupid and not reporting a close when it knows already | 05:04 |
| lifeless | StevenK: so, you know now whats wrong - webkit fuckage | 05:04 |
| lifeless | StevenK: and I have the data on how the system was failing, so can reproduce externally. | 05:04 |
| StevenK | Then why doesn't buildbot fall over into a screaming heap? | 05:05 |
| lifeless | its webkit isn't segfaulting | 05:05 |
| lifeless | (duh) | 05:05 |
| StevenK | But why not? :-( | 05:05 |
| wgrant | Run it manually | 05:05 |
| lifeless | dunno | 05:05 |
| wgrant | You might get a GTK error | 05:05 |
| StevenK | And I'm curious what is causing it to SEGV | 05:06 |
| wgrant | It normally segfaults because there's no X | 05:06 |
| lifeless | nothing on stderr | 05:06 |
| wgrant | But the xvfb-run should sort that out | 05:06 |
| StevenK | Right | 05:06 |
| wgrant | gdb :) | 05:06 |
| lifeless | indeed | 05:06 |
| lifeless | start an ephemeral container | 05:06 |
| lifeless | ssh into it | 05:06 |
| lifeless | run one xvfb-run bash | 05:06 |
| lifeless | run gdb python --args -- bin/test lp/testing/tests/test_yuixhr_fixture_facet | 05:07 |
| lifeless | (or thereabouts) | 05:07 |
| wgrant | Yep | 05:07 |
| StevenK | lifeless: You're still on the executor, are you going to try that? | 05:07 |
| wgrant | The stacktraces tend to be reasonably self-explanatory, fortunately. | 05:08 |
| lifeless | StevenK: no | 05:10 |
| StevenK | Aww | 05:11 |
| lifeless | StevenK: a) cynthia time, b) I'm pursuing the test reporting side of it, to make future runs less likely to fail in this mysterious manner | 05:11 |
| lifeless | StevenK: daylight saving kicked in here last weekend, we're 3 hours out atm | 05:11 |
| lifeless | StevenK: https://bugs.launchpad.net/subunit/+bug/1060628 | 05:12 |
| _mup_ | Bug #1060628: cannot 'fix' a subunit stream that may be corrupted <subunit:Triaged> < https://launchpad.net/bugs/1060628 > | 05:12 |
| StevenK | lxc-start -n lptests will start the ephemeral container? | 05:13 |
| lifeless | StevenK: no | 05:13 |
| wgrant | lxc-start-ephemeral | 05:13 |
| lifeless | StevenK: lxc-start-ephemeral -d -n lptests | 05:13 |
| wgrant | lxc-start -n lptests will start the real container | 05:13 |
| lifeless | StevenK: so you can ssh in and not have the awful console emulator | 05:13 |
| StevenK | root@ip-10-218-67-147:~# lxc-start-ephemeral -d -n lptests | 05:15 |
| StevenK | getopt: invalid option -- 'n' | 05:15 |
| StevenK | And the usage message isn't very helpful either | 05:15 |
| lifeless | oh blah, | 05:15 |
| wgrant | -o maybe? | 05:15 |
| wgrant | I can't remember | 05:15 |
| wgrant | May just be a positional arg | 05:15 |
| StevenK | -o orig is in the usage | 05:16 |
| lifeless | yes | 05:16 |
| lifeless | -o lptests | 05:16 |
| lifeless | I was remembering base container startup | 05:16 |
| StevenK | A consistent UI is a bad UI | 05:16 |
| lifeless | this isn't inconsistent | 05:16 |
| wgrant | Back in my day it only had positional args, and we liked it. | 05:16 |
| lifeless | because you wouldn't be naming it | 05:16 |
| lifeless | it got 'fixed' | 05:17 |
| StevenK | Bleh, and I run right into the 'jenkins has a password?' thing :-( | 05:18 |
| lifeless | muhhaha | 05:18 |
| * StevenK forcibly edits the lxc's sudoers | 05:19 | |
| StevenK | jenkins@lptests-temp-k0hHY4M:~$ sudo apt-get install gdb | 05:23 |
| StevenK | Reading package lists... Done | 05:23 |
| wgrant | stub: Do you recall if there was a reason for translations-export-to-branch to do its search on the slave DB? | 05:23 |
| wgrant | It then casts the branch up to a master object to write to it | 05:23 |
| wgrant | Which seems odd. | 05:23 |
| StevenK | jenkins@lptests-temp-k0hHY4M:~$ xvfb-run bash | 05:24 |
| StevenK | xvfb-run: error: Xvfb failed to start | 05:24 |
| * StevenK grumbles | 05:24 | |
| wgrant | It does like its helpful error messages | 05:24 |
| wgrant | Beware, 'tis a hideous shell script | 05:24 |
| StevenK | Yes, and I'm trying to avoid bash -x | 05:24 |
| stub | wgrant: Sounds like one I would have nagged about because of performance and/or long running transactions | 05:30 |
| * StevenK stabs xvfb-run | 05:30 | |
| stub | wgrant: IIRC it had long running transactions, and when fixing that it was easy to switch it to using the slave for most of the work too. | 05:31 |
| lifeless | wgrant: that was avoiding lock driven bloat on the master | 05:31 |
| wgrant | The thing is the DB work is really really trivial | 05:31 |
| wgrant | Hmm | 05:31 |
| lifeless | wgrant: but without slony the bloat impact happens no matter what slave you are reading from | 05:31 |
| lifeless | so without slony there is no benefit to that jumping around | 05:31 |
| wgrant | It's the only remaining case of things that need to write querying from the slave store | 05:31 |
| stub | wgrant: Yeah, but if you look sideways at a Storm object at the wrong time it gets refreshed from the DB and suddenly you have a new, open transaction sitting idle. | 05:31 |
| stub | jtv did the fixup IIRC, I might be mistaken for the rationale. | 05:32 |
| wgrant | It's used the slave store since the script first landed in the tree | 05:33 |
| stub | But the basic principal of 'thou shalt use a slave instead of the master whenever possible' still applies. | 05:33 |
| stub | Excellent. We should do more of that. | 05:33 |
| wgrant | Should we? | 05:34 |
| wgrant | The DB load from the two things that do that is miniscule. | 05:34 |
| wgrant | And it's a fair bit of added complexity | 05:34 |
| stub | Yes, the master isn't horizontally scalable. | 05:35 |
| stub | Why is it complex? | 05:35 |
| stub | I suspect it is complex because it is bending over backwards to ensure a transaction doesn't get held open while doing possibly lengthy operations, like anything to do with importing or exporting pofiles or anything to do with bzr. | 05:36 |
| wgrant | Well, most things are very well served by just using their policy's default store | 05:37 |
| wgrant | We have a lot of code that uses IMasterStore/ISlaveStore/IMasterObject unnecessarily. | 05:37 |
| stub | Yeah, but something like exporting translations you can say 'this always uses the slave store' because we never care that the information is up to date. | 05:38 |
| stub | The scripts policy could encode this, but other callers to the code don't get that policy. | 05:39 |
| stub | Do we care now if things are a little out of date? | 05:42 |
| wgrant | Mmm | 05:44 |
| wgrant | I'm trying to think of a cleaner way to do the slave fallback. Currently you get a slave object that's actually connected to the master, which is a bit ugly. | 05:48 |
| wgrant | Because we need master->slave fallback to some extent. | 05:48 |
| wgrant | Though I guess if I get a fake-slave object and keep it around over a connection reset, it could end up reattached to a real slave | 05:52 |
| wgrant | Our Storm object lifetimes are sometimes a little odd | 05:52 |
| wgrant | stub: Does our postgres config log statement timeouts? | 06:02 |
| stub | Yes | 06:03 |
| wgrant | https://oops.canonical.com/oops/?oopsid=OOPS-b01fe5e323fdcb85e9bfda27beca4466 | 06:03 |
| wgrant | Is it easy enough to find out the second that the final statement there was terminated? | 06:03 |
| wgrant | Since it took 24 seconds | 06:03 |
| wgrant | I suspect the delay is on the Python side | 06:04 |
| wgrant | But I'd like to know for sure | 06:04 |
| wgrant | Since this goes back to the random delays we see sometimes that can't all be explained by GIL contention | 06:04 |
| StevenK | wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/assertion-review-token/+merge/127639 | 06:04 |
| wgrant | They usually exhibit themselves as very long DB queries | 06:04 |
| stub | From my POV, there is nothing wrong with ISlaveStore returning a Store connected to the master db. However, the Zope adapter mechanics require that IFoo(bar) return an object that provides the IFoo interface. | 06:05 |
| wgrant | Oh, it actually checks? | 06:05 |
| stub | I've thought of making all objects that provide IMasterStore also provide ISlaveStore | 06:05 |
| stub | I think it does in some cases? All cases? I forget the details | 06:05 |
| wgrant | I guess having the slave store connected to the master DB isn't too bad, but it might be useful to log the current connection string somewhere. | 06:06 |
| stub | We don't need to use the adapter spelling. It was the nicest spelling that met our needs at the time. | 06:06 |
| wgrant | Currently in OOPSes we log whether it was master or slave, which can be helpful for diagnosing slowness. | 06:06 |
| wallyworld_ | StevenK: i'll pass since i'm not fully across the subtlties of the oauth stuff | 06:07 |
| wgrant | I'll look in a sec | 06:07 |
| StevenK | wallyworld_: Pft. It's subtle as a housebrick to the face. | 06:08 |
| stub | We need to, at a minimum, switch from using dbname to dbname+hostname. Full connection string might be too noisy in some contexts. | 06:08 |
| wallyworld_ | StevenK: not really, there's subtle changes to the error handling and flow | 06:08 |
| wallyworld_ | and i don't know what might break | 06:09 |
| stub | Our statement sanitation code isn't hiding the integer id in that oops | 06:09 |
| wgrant | stub: We might just want to log timeline events on reconnection, and at connection start. | 06:09 |
| stub | Doesn't want to handle function calls | 06:09 |
| wgrant | The request started at 21:26:56 | 06:09 |
| wgrant | The fatal query should have started about 2 seconds after that | 06:10 |
| wgrant | And terminated between 5 and 23 seconds after that. | 06:10 |
| wgrant | I'm interested whether it was 5 or 23. | 06:10 |
| stub | <lpnet55@launchpad_prod:25567> 2012-10-01 21:27:22 UTC ERROR: canceling stateme | 06:14 |
| stub | nt due to statement timeout | 06:14 |
| stub | <lpnet55@launchpad_prod:25567> 2012-10-01 21:27:22 UTC STATEMENT: UPDATE Bug SET heat=calculate_bug_heat(1047345), heat_last_updated=CURRENT_TIMESTAMP AT TIME ZONE 'UTC' WHERE Bug.id = 1047345 | 06:14 |
| wgrant | Hm | 06:14 |
| stub | I'm seeing some odd replication stuff around that time, may be unrelated | 06:14 |
| wgrant | So did postgres sit on it for 20s too long, or did we delay sending it for ages. | 06:14 |
| wgrant | I wonder | 06:14 |
| stub | We can't tell now | 06:15 |
| wgrant | Indeed. | 06:15 |
| wgrant | StevenK: You can't really just convert all AssertionErrors into notifications... | 06:16 |
| wgrant | StevenK: And you can't just str() or unicode() things. | 06:16 |
| wgrant | stub: Thanks for poking. | 06:17 |
| wgrant | Could be Python, pgbouncer, or postgres :( | 06:18 |
| StevenK | wgrant: So I can convert the 5 AssertionError's in the model into OAuthValidationError or something ? | 06:19 |
| wgrant | StevenK: Something like that. There may already be a relevant exception,. | 06:19 |
| StevenK | Not that I can see. | 06:20 |
| lifeless | wgrant: could also be TCP | 06:22 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1257370/ | 06:23 |
| StevenK | lifeless: There. Fixed. ^ | 06:23 |
| bigjools | god I hate dpkg | 06:24 |
| bigjools | once you get a bug in a postinst you're screwed | 06:25 |
| wgrant | lifeless: Shhh, I only blame TCP when I want elmo to investigate | 06:25 |
| wgrant | It's not at that stage yet :) | 06:25 |
| wgrant | bigjools: What sort of bug? | 06:25 |
| bigjools | it hangs | 06:25 |
| wgrant | Oh good | 06:26 |
| StevenK | bigjools: That's when you edit /var/lib/dpkg/info/foo.postinst :-P | 06:26 |
| bigjools | package removal fails, reconfigure fails...everything bloody fails! | 06:26 |
| bigjools | StevenK: yes, that's what I do :/ | 06:26 |
| bigjools | ctrl-c not working either | 06:26 |
| StevenK | Ctrl-\ ? | 06:27 |
| StevenK | ctrl-c is SIGINT, ctrl-\ is SIGQUIT | 06:27 |
| StevenK | bigjools: Failing that, ctrl-z ; bg ; kill -9 ? | 06:28 |
| bigjools | oh GREAT. now the kernel bug that disconnects usb devices hit me. no mouse | 06:28 |
| * bigjools ragequit | 06:28 | |
| wgrant | StevenK: How formy is it? | 06:28 |
| StevenK | wgrant: EPARSE | 06:28 |
| wgrant | StevenK: Redirecting to the success page and adding a notification to say that it failed is somewhat unpleasant. | 06:28 |
| wgrant | Is it close enough to a form that you can display an error message on it? | 06:29 |
| wgrant | Rather than a notification? | 06:29 |
| StevenK | Not really | 06:29 |
| StevenK | There are no fields | 06:29 |
| StevenK | We show 6 buttons and a lot of text | 06:29 |
| bigjools | StevenK: kill -9 after searching for all the processes that apt-get started yeah :/ it's hanging on a very innocuous prerm ... | 06:30 |
| StevenK | wgrant: I can redirect to '/' or something if you wish? | 06:30 |
| StevenK | '~' might work too | 06:30 |
| wgrant | StevenK: I'm not sure. | 06:31 |
| wgrant | Redirecting to the callback is definitely wrong | 06:31 |
| wgrant | Redirecting to anything and displaying a pretty blue success notification for failure is also a little wrong. | 06:31 |
| StevenK | So we should continue to OOPS? :-) | 06:31 |
| wgrant | No, ideally we'd display an error message. | 06:32 |
| wgrant | Not just redirect with successful failure | 06:32 |
| StevenK | wgrant: So what about response.addErrorNotification ? | 06:37 |
| wgrant | StevenK: That might be an acceptable compromise. | 06:39 |
| wgrant | It's probably easiest. | 06:39 |
| StevenK | wgrant http://pastebin.ubuntu.com/1257382/ | 06:39 |
| wgrant | StevenK: Sounds more reasonable. I don't think we use the term "request token" anywhere else in the UI, though. I'd try to find a better term by looking at the existing template. | 06:40 |
| StevenK | What about 'token' ? | 06:41 |
| StevenK | wgrant: request token is already shown for the token.permission == OAuthPermission.UNAUTHORIZED case? | 06:43 |
| wgrant | StevenK: Isn't that the response to +access-token, which is given to the client, not the user? | 06:43 |
| StevenK | I have no idea | 06:45 |
| StevenK | Hm, I can think OAuthBase can die a quick death | 06:49 |
| StevenK | Replace OAuthNonce.getStore with IMasterStore | 06:49 |
| wgrant | I might mean IStore | 06:50 |
| wgrant | s/I/You/ | 06:51 |
| wgrant | IMasterStore should be used only sparingly. | 06:51 |
| StevenK | It uses MASTER_FLAVOR | 06:51 |
| StevenK | So ... | 06:51 |
| wgrant | So do a lot of things | 06:51 |
| wgrant | A lot of things are wrong :( | 06:51 |
| StevenK | And it has a comment saying "We want all OAuth classes to be retrieved from the master flavour. | 06:52 |
| wgrant | Webservice requests always end up on the master today. | 06:52 |
| wgrant | Mmm | 06:52 |
| wgrant | I guess leave it. OAuthNonce will hopefully die soon anyway. | 06:52 |
| StevenK | Ah | 06:52 |
| StevenK | wgrant: So 'request token' is good enough, or you object? | 06:52 |
| wgrant | The template doesn't mention tokens at all. | 06:54 |
| wgrant | But I can't think of much better | 06:54 |
| StevenK | Neither | 06:54 |
| StevenK | And it's for an erorr that shows up what, once a week? | 06:54 |
| wgrant | Anyway, you also might want to inhibit the callback | 06:59 |
| StevenK | wgrant: Good point. That change is pushed. | 07:04 |
| StevenK | wgrant: Can haz approval, or you still object? :-) | 07:12 |
| wgrant | StevenK: Done | 07:14 |
| StevenK | Blink. How did I miss that. I even re-indented that block. :-( | 07:15 |
| adeuring | good morning | 07:51 |
| wgrant | Hm | 08:10 |
| wgrant | I think there's an infinite loop in the dominator | 08:10 |
| wgrant | Oh, or it's a transaction conflict... | 08:11 |
| wgrant | Heh, yes | 08:11 |
| wgrant | Evil massive Soyuz doctests | 08:11 |
| wgrant | StevenK: You have test failures | 08:13 |
| StevenK | My testfix fixed all of them bar one, too. Sigh. | 08:28 |
| wgrant | 10 files changed, 6 insertions(+), 1053 deletions(-) | 08:42 |
| StevenK | Nice | 08:43 |
| wgrant | aka. burning soyuz for fun and profit | 08:46 |
| wgrant | As a precursor to making us not suck at transactions. | 08:47 |
| czajkowski | wgrant: StevenK wallyworld_ can one of you please look at https://answers.launchpad.net/launchpad/+question/209658 | 09:25 |
| wallyworld_ | czajkowski: i'm somewhat clueless when it comes to such email issues sadly :-( | 09:26 |
| adeuring | StevenK: could you have another look at my MP? | 09:27 |
| czajkowski | wallyworld_: it's now baffling | 09:27 |
| czajkowski | I got him to add his key to LP | 09:27 |
| czajkowski | but still having issues | 09:27 |
| wallyworld_ | czajkowski: curtis i think has knowledge in this area | 09:28 |
| wallyworld_ | he should be online soon | 09:28 |
| StevenK | adeuring: r=me | 09:42 |
| adeuring | StevenK: thanks | 09:42 |
| === mpt_ is now known as mpt | ||
| wgrant | StevenK: Hm, which LoC counter did you use to determine you had more credit than me? | 11:45 |
| wgrant | StevenK: I'm well ahead of everyone on 1-month, 6-month, 12-month and 18-month intervals. | 11:46 |
| wgrant | By 'bzr high-scores' | 11:46 |
| mgz | now now wgrant, no need to boast :) | 11:46 |
| jelmer | wgrant: where does 'bzr high-scores' live? | 11:48 |
| wgrant | jml's bzr-damage, probably | 11:48 |
| wgrant | Yeah | 11:49 |
| cjwatson | high-scores since r14780 (loc-contributions' default) is 1) William, 2) Curtis, 3) me, 4) Aaron, 5) Steve | 11:51 |
| wgrant | Hm, loc-contributions seems to hate me | 11:54 |
| cjwatson | Might be counting DB patches differently | 11:55 |
| wgrant | Yeah | 11:55 |
| wgrant | I merge db-stable a lot, so it might count them against me | 11:55 |
| cjwatson | Yeah, quite possible | 11:55 |
| wgrant | Whereas high-scores might just count each rev individually | 11:55 |
| cjwatson | When I was writing loc-contributions I found both got things wrong in different ways | 11:58 |
| wgrant | Yeah | 11:58 |
| cjwatson | If high-scores does as you say, I expect it will miscount branches which were merged from devel before landing | 11:58 |
| cjwatson | Which I reckoned was a commoner case | 11:59 |
| wgrant | Hm, it may | 12:00 |
| StevenK | wgrant: loc-contributions for me says -3500 or so, and like -1200 for you | 12:01 |
| StevenK | Last I checked | 12:01 |
| StevenK | I'm approaching cjwatson :-) | 12:01 |
| cjwatson | Curtis still has me beat | 12:04 |
| cjwatson | Though if I can get some ops time next week to deploy another PCJ runner or similar, I can flush a big negative queue then ... | 12:05 |
| wgrant | Indeed. | 12:05 |
| StevenK | cjwatson: There's a bunch of criticals you get to close too, which is nice. | 12:06 |
| StevenK | wgrant: Don't you get to close bug 624078 now? | 12:16 |
| _mup_ | Bug #624078: soyuz-set-of-uploads.txt has unnecessary tests that are tricky to remove <lp-soyuz> <tech-debt> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/624078 > | 12:16 |
| StevenK | In truth, soyuz-set-of-uploads.txt should just die in a large fire | 12:16 |
| czajkowski | cjwatson: will you be doing more LP work next cycle ? | 12:16 |
| cjwatson | Not as much | 12:16 |
| cjwatson | Probably bits here and there | 12:17 |
| czajkowski | will be running 2 more LP clinics at uds so hopefully we can get more pople to scratch their itches | 12:17 |
| StevenK | cjwatson: You're still going to destroy delayed copies? | 12:17 |
| wgrant | StevenK: Indeed, forgot to reference it in the commit message. | 12:18 |
| cjwatson | StevenK: Yes | 12:19 |
| cjwatson | Blocked on removing the synchronous path from Archive:+copy-packages, which is blocked on a bit more PCJ running capacity so that they're more responsive | 12:19 |
| StevenK | I've been looking forward to delayed copies dying a slow and horrible death. | 12:19 |
| cjwatson | But nothing hard at this point | 12:19 |
| StevenK | Removing the synchronous path closes at least two criticals. Possibly a third. | 12:20 |
| StevenK | Death of delayed copies is another one or two. | 12:20 |
| cjwatson | And nearly 1500 LOC. | 12:20 |
| wgrant | Aha | 12:22 |
| xnox | czajkowski: hmm.... I have a few new small bugs I'd like to tackle. But since you need LOC to land those, maybe you can do a clinic on gaining LOC credit? | 12:23 |
| wgrant | loc-contributions indeed implicates me in db-stable merges | 12:23 |
| wgrant | And, even better, it actually double-counts me for about 2000 lines where I did both the merges | 12:23 |
| wgrant | Excluding those gets me to -4500 | 12:23 |
| jelmer | bleh, bzr high-scores doesn't like ghosts | 12:23 |
| wgrant | Sadly cjwatson still beats me | 12:24 |
| cjwatson | xnox: Mine has been gained from (a) rewriting scripts as API facilities and removing the scripts (hard to duplicate) (b) removing completely useless unused stuff (c) rewriting doctests as unit tests | 12:24 |
| czajkowski | xnox: people will land them if asked and they approve of the fixes | 12:24 |
| czajkowski | but yes it could be brought up in the clinics | 12:24 |
| cjwatson | (b) just requires finding them; (c) isn't a reliable source but there is a vast mine of crappy doctests to refactor | 12:25 |
| xnox | =)))) lolz | 12:25 |
| StevenK | But don't be scared away by LOC. Nothing says the removal has to come first. | 12:25 |
| xnox | StevenK: not scared. Just playing the game ;-) | 12:25 |
| StevenK | And if your change provides a maintaince benefit, lifeless or flacoste may grant an LOC exception. | 12:26 |
| xnox | nah, I'd rather have fun with LOC. I was trying to do that with ubiquity a little bit, as self discipline. | 12:26 |
| StevenK | xnox: So please, don't just groan about LOC, *talk* to us about it. | 12:27 |
| mgz | killing doctests is always good. | 12:27 |
| StevenK | I enjoy killing doctests | 12:27 |
| StevenK | Soyuz has too many of them | 12:27 |
| StevenK | cjwatson, wgrant and myself have helped drop the number | 12:27 |
| wgrant | Hm | 12:28 |
| wgrant | We have 10 Fix Committed criticals | 12:28 |
| * wgrant curses sprints | 12:28 | |
| * StevenK does QA for his oauth fix the easy way | 12:30 | |
| StevenK | (Leaving a browser window hanging for >2 hours) | 12:30 |
| === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugs: ~300 | ||
| deryck | rick_h_, are you back today? | 13:32 |
| czajkowski | sinzui: so what's your favourite kinda cake :) | 14:33 |
| sinzui | Chocolate with coconut and pecan frosting. | 14:50 |
| * sinzui might make that for lunch | 14:50 | |
| czajkowski | sinzui: nobody seems tobe able to work this out, so it falls I'm afraid to you. https://answers.launchpad.net/launchpad/+question/209658 | 14:51 |
| czajkowski | I sorted out webops folks yesterday with a curly wurly cake :) | 14:52 |
| sinzui | czajkowski, Looks like a malformed signature per | 14:55 |
| sinzui | https://answers.launchpad.net/launchpad/+question/147254 | 14:55 |
| sinzui | and | 14:55 |
| sinzui | https://answers.launchpad.net/launchpad/+question/86235 | 14:55 |
| sinzui | czajkowski, I think steve complete borked his setup be removing his keys and possibly changing his client | 14:55 |
| slank | czajkowski: yes, that was delicious. thank you! | 14:55 |
| czajkowski | slank: :) | 14:56 |
| sinzui | czajkowski, the common cause of this (also seen in signing the CoC) is that the part after | 14:56 |
| sinzui | -----BEGIN PGP SIGNATURE----- | 14:56 |
| sinzui | got wrapped | 14:56 |
| sinzui | or lost characters. | 14:56 |
| czajkowski | how does one lose characters | 14:56 |
| czajkowski | :s | 14:56 |
| sinzui | It could be a copy+paste error of his client wrapped the message before sending it | 14:57 |
| sinzui | bad copy or bad correction of a wrap will loose characters | 14:57 |
| czajkowski | nods | 14:58 |
| czajkowski | ok | 14:58 |
| czajkowski | sinzui: 2 more things, 1) commericla renewals I've had 2 mails sent to the RT about them, I would expect they would get an email notification to renew and a link in that where to go and pay ? No? | 14:59 |
| sinzui | czajkowski, I think we can tell steve that email clients are often the problem. I use shitehawk because it does signing properly with PGP/MIME | 14:59 |
| czajkowski | 2nd thing will send to pm as it ha sa link | 14:59 |
| czajkowski | sinzui: fair enough, not seen this issuebefore | 15:00 |
| czajkowski | thank you though | 15:00 |
| czajkowski | I shall send the cake :p | 15:00 |
| sinzui | czajkowski, the emails do not contain the link because the link it not to launchpad. | 15:01 |
| czajkowski | ah so how do they find where to go to renew ? | 15:01 |
| sinzui | the email correctly state that the user must visit the project page and follow the instruction to renew | 15:02 |
| abentley | sinzui: product_licenses_modified sends mail to the logged-in user. Is this correct? Wouldn't it make more sense to send it to the product owner or something? I noticed because I called createProduct with UnauthenticatedPrincipal logged in. | 15:02 |
| sinzui | which is purchase from a non-canonical site, then wait 30 to 300 minutes, then apply the voucher that took forever to get to Lp | 15:03 |
| sinzui | abentley, it sends it the the maintainer, not the logged in user...the emails are created by a job once a day | 15:03 |
| abentley | sinzui: I have a traceback that indicates otherwise. | 15:04 |
| sinzui | abentley, the case you are reporting is a different email, and yes, that could use the maintainer | 15:04 |
| sinzui | czajkowski, we have seen a lot of projects fail to renew because the company set a person as the maintainer, then they left the company. | 15:06 |
| sinzui | We will state that we think users should never maintain projects owned by commercial organisations | 15:06 |
| abentley | sinzui: http://pastebin.ubuntu.com/1258172/ | 15:19 |
| sinzui | abentley, yes, I understand. You can change the method to use the product.owner, but you may still need to update the that specific email to know about the registrant because the owner might know know he owns the project | 15:27 |
| abentley | sinzui: s/know know/not know ? | 15:32 |
| sinzui | abentley, you are correct | 15:33 |
| abentley | sinzui: Okay, cool. | 15:33 |
| sinzui | abentley, I have a bug I was thinking of fixing on friday to make czajkowski and my days easier | 15:34 |
| * czajkowski hugs sinzui | 15:34 | |
| sinzui | I think I need to edit that subscriber method | 15:34 |
| sinzui | So I will find update the code to use the maintainer. | 15:35 |
| abentley | sinzui: Okay, cool. I'll work around it in my test. | 15:37 |
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| abentley | deryck: I'm the OCR (which I just noticed is an anagram for orc). Could you please review https://code.launchpad.net/~abentley/launchpad/limit-product-info-types/+merge/127814 | 17:55 |
| deryck | heh | 17:55 |
| deryck | abentley, sure. | 17:55 |
| abentley | deryck: Thanks. | 17:56 |
| deryck | np! | 17:56 |
| abentley | deryck: For my next task, I was thinking of "Private project creation should enable appropriate apps". | 17:57 |
| deryck | abentley, sounds great, thanks! | 17:57 |
| abentley | deryck: There's currently a policy that if the license is Other/Proprietary, you get PROPRIETARY bugs/branches. I'd like to change it so bug/branch/blueprint policy follows product.information_type. | 17:59 |
| deryck | abentley, that sounds right. | 18:00 |
| abentley | deryck: And I guess the other part is disabling Answers? | 18:00 |
| deryck | abentley, indeed. I had forgot about that. | 18:01 |
| abentley | deryck: Cool. | 18:01 |
| deryck | abentley, r=me for the MP. | 18:08 |
| abentley | deryck: thanks. | 18:08 |
| deryck | abentley, I just found a bug in project registration. the js hides the license choice for you, but only selects proprietary/other and leaves the description blank, which raises form validation errors. | 18:18 |
| abentley | deryck: I don't follow. | 18:20 |
| abentley | deryck: I am seeing a "There is 1 error." message with no obvious error, though. | 18:21 |
| deryck | abentley, when you select Proprietary information type, the js code hides the license stuff and automatically sets the license to "other/propretary" | 18:21 |
| deryck | abentley, yeah, I believe that's because the form needs the extra "description" field for "other/proprietary" filled in, but it's now hidden. | 18:22 |
| deryck | abentley, toggle it back to public, and select other, and you can see the option to fill in that field, which I did, toggled back to proprietary and the form will submit. | 18:23 |
| deryck | abentley, however, I don't think the save step actually sets the information_type. | 18:23 |
| abentley | deryck: Is this on qastaging? It looks like information_type isn't selectable there. | 18:23 |
| deryck | abentley, I'm doing it locally. with the appropriate flag enabled. | 18:23 |
| deryck | I really thought info type was saved. could of sworn I checked that already. | 18:24 |
| abentley | deryck: I don't see a description area for other/proprietary on qastaging. | 18:24 |
| deryck | hmmm | 18:25 |
| deryck | abentley, weird, I do. | 18:26 |
| deryck | abentley, if I click "other/proprietary" then the text area expands open. | 18:26 |
| abentley | Yeah, I don't get a text area, just the three checkboxes. | 18:27 |
| deryck | weird. | 18:28 |
| deryck | I wonder what's different about you. | 18:28 |
| deryck | abentley, FWIW, I'll fix project creation to save info type now. | 18:29 |
| * deryck branches | 18:29 | |
| abentley | deryck: I get the same behaviour on chromium and firefox. | 18:31 |
| deryck | abentley, do you see any errors in either browser's console? | 18:32 |
| abentley | deryck: Not in firefox... | 18:33 |
| abentley | deryck: Not in chromium. | 18:34 |
| abentley | deryck: (firefox actually has some CSS errors) | 18:35 |
| deryck | hmm, weird. | 18:35 |
| deryck | abentley, I'm stumped. I have no idea why you wouldn't see it. I've tried on 4 browsers across 2 laptops now and works fine for me. | 18:35 |
| abentley | deryck: So, if I choose proprietary, then submit, the error page has a license description text box. | 18:37 |
| abentley | deryck: But the initial page doesn't. | 18:37 |
| deryck | oh weird, abentley. It errors for me, with no text box. But I get the text box normally when information_type is public. | 18:38 |
| deryck | so I'm reversed of you. | 18:38 |
| abentley | deryck: I didn't understand you properly. I expected the text area to be shown when I clicked the "Other choices" expander, but it's actually shown when clicking "other/proprietary". | 18:41 |
| deryck | abentley, ah, ok. So we had a language fail then. IRC communication failure, sorry. What you're seeing is correct, and also what I'm seeing. | 18:42 |
| deryck | abentley, the text area should not appear until you actually click the "other/proprietary" checkbox. | 18:43 |
| abentley | deryck: My fail. And yes, that's the behaviour locally and on qastaging for me. | 18:43 |
| deryck | ok, cool. | 18:43 |
| deryck | one less bug to sort out. :) | 18:43 |
| abentley | deryck: So we've still got the problem that the license description is mandatory but not filled in. | 18:44 |
| abentley | deryck: When auto-selected by information_type. | 18:44 |
| deryck | abentley, exactly. and in looking for where to fix the saving of information_type, I just found the spot to fix this. | 18:44 |
| deryck | I tired to break rick_h_ of short, crazy variable names when we paired in Auburn, but I see he's still at is. :P | 18:45 |
| deryck | at it, rather | 18:45 |
| abentley | :-) | 18:46 |
| rick_h_ | deryck: I've tried! What did I short cut on? and sorry for the bug. I meant to chat with you about how to handle that with the wiring up of the field and see if we should put some standard text there. | 19:06 |
| deryck | rick_h_, no worries. :) and I can't decide if license_cont reads license_continue or license_container :) | 19:07 |
| deryck | you could even have gone with license_div and stayed short but clear :) | 19:08 |
| rick_h_ | deryck: well it's not the license div, it's the container of the license div :) | 19:08 |
| deryck | so license_div_div is still better than license_cont ;) | 19:08 |
| rick_h_ | but point noted. I'll work to unwire the cont/container abbrev | 19:09 |
| abentley | deryck: I'm not sure if it makes sense to require a description of other/proprietary. (In tests, I sometimes put "mine, all mine!") | 19:09 |
| deryck | abentley, I was adding "Launchpad 30-day trial commerical license" to not have to change too much. | 19:11 |
| deryck | it's in js, so nothing else changes. | 19:11 |
| abentley | deryck: There's an argument that if Project.information_type is set to EMBARGOED, the branch/bug/spec policies should be PROPRIETARY, not EMBARGOED_OR_PROPRIETARY, just to be cautious. What do you think? | 19:22 |
| deryck | abentley, I need to think on that. and about to host TL call. let me come back to that question shortly. | 19:25 |
| abentley | deryck: okay. | 19:26 |
| deryck | abentley, coming back to your question, I think that makes sense. Though I'd guess if people use embargoed for a project, they mean to go public later. Just guessing. | 19:59 |
| deryck | abentley, rather than the other-level-of-proprietary that it's used for in PES. | 19:59 |
| abentley | deryck: If you're PES, you would set information_type=Embargoed to share milestones and productseries, but I don't know if they want to. | 20:01 |
| abentley | deryck: I wonder if it'll be a problem that branches are associated with productseries? | 20:02 |
| deryck | abentley, hmm, could be. | 20:04 |
| deryck | abentley, so let's just keep it embargoed == embargoed_or_proprietary for now. for consistency, and we can adjust as we get feedback. | 20:05 |
| abentley | deryck: Okay. | 20:05 |
| sinzui | jcsackett, how goes your attachment branch? | 20:28 |
| jcsackett | sinzui: i have discovered it is far more complicated than i thought. care to chat? | 20:28 |
| sinzui | okay. I just wrote a test case for apport/blobs and attachments. | 20:29 |
| sinzui | my concern was new bugs though | 20:29 |
| lifeless | sinzui: hi | 20:30 |
| lifeless | sinzui: did that log rotate fix get applied to LP? | 20:30 |
| sinzui | No. we discussed patching Lp yesterday...then aggressively upstreaming the fix | 20:31 |
| deryck | abentley, I have to go now for a birthday party for my little one tonight. But I have a branch for review for those bugs, if you don't mind reviewing in my absence. | 20:44 |
| deryck | abentley, if not, I can get it later tonight from someone when I'm back. | 20:44 |
| abentley | deryck: sure. | 20:44 |
| deryck | abentley, awsome, thanks! https://code.launchpad.net/~deryck/launchpad/actually-save-info-type-on-project-create/+merge/127863 | 20:45 |
| deryck | be back later on to finish up milestones/series. | 20:46 |
| === abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~300 | ||
| sinzui | jcsackett, Bug #174794 | 21:05 |
| _mup_ | Bug #174794: Uploading file with Internet Explorer uses full path name <ie> <lp-foundations> <oem-services> <Launchpad itself:Triaged> < https://launchpad.net/bugs/174794 > | 21:05 |
| lifeless | StevenK: so lets get jenkins going today | 22:22 |
| lifeless | owww ugh | 22:30 |
| lifeless | the zope subprocess stuff is heinous | 22:30 |
| lifeless | its not semantic at all | 22:31 |
| lifeless | also, look at runner.py, | 22:34 |
| lifeless | " | 22:34 |
| lifeless | # Display results in the order they would have been displayed, had the | 22:34 |
| lifeless | # work not been done in parallel. | 22:34 |
| lifeless | " | 22:34 |
| * lifeless isn't sure what to make of that | 22:34 | |
| sinzui | wallyworld_, the broken approve/decline js related to Bug #271697 and I think you get to close Bug #120357 and maybe this in now invalid Bug #629291 | 22:47 |
| _mup_ | Bug #271697: Javascript for approving / declining nominations is confusing <bug-nomination> <confusing-ui> <javascript> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/271697 > | 22:47 |
| _mup_ | Bug #120357: Improve the accept/decline/nochange column on +nominations <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/120357 > | 22:47 |
| _mup_ | Bug #629291: Missing column borders after expanding nominate <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/629291 > | 22:47 |
| wallyworld_ | ok | 22:47 |
| lifeless | oh man, more bugs. | 22:57 |
| lifeless | StevenK: wgrant: so I'm not going to file a bug for this, but the zope runner will corrupt a subunit stream if it gets keyboardinterrupt/memoryerror/systemexit | 23:04 |
| lifeless | because it doesn't use finally: around outputing completing for layers. | 23:04 |
| lifeless | you might want to address that if you have cause to touch it. | 23:04 |
| lifeless | gary_poster: another FYI^ | 23:04 |
| wgrant | The zope runner generally just fails pretty terribly if it gets a keyboardinterrupt, yeah | 23:05 |
| wgrant | The subprocess stuff is all a tad fragile | 23:05 |
| lifeless | I'd like to get us totally away from it | 23:08 |
| lifeless | just needs elbow grease | 23:08 |
| StevenK | lifeless: Okay, creating a executor | 23:28 |
| lifeless | StevenK: I have one hour to help you out | 23:29 |
| StevenK | That's disappointing, because that's how long it will take to bring up the executor | 23:30 |
| StevenK | I failed with xvfb yesterday | 23:30 |
| lifeless | I have a 4pm flight | 23:36 |
| lifeless | 2:30 at the airport | 23:36 |
| lifeless | 1:30 leave here | 23:36 |
| lifeless | its 12:36 | 23:36 |
| StevenK | lifeless: Ah, so you're coming to help in person? :-P | 23:39 |
| wgrant | StevenK: Does ec2 hate your simplified branch menu branch? | 23:43 |
| StevenK | It did, yes | 23:44 |
| StevenK | FAILED (id=0, failures=31, skips=37) | 23:44 |
| wgrant | Anything terrible? | 23:44 |
| StevenK | linkdata = method() | 23:44 |
| lifeless | StevenK: if you want to come up to gosford with me, sure. | 23:44 |
| StevenK | TypeError: 'LinkData' object is not callable | 23:44 |
| StevenK | wgrant: Most failures are caused by that | 23:45 |
| wgrant | Ah | 23:45 |
| StevenK | So I need to work out WTF | 23:45 |
| StevenK | lifeless: Gosford? That's no fun | 23:45 |
| lifeless | StevenK: http://miller.emu.id.au/pmiller/codecon/2012/index.html | 23:46 |
| lifeless | StevenK: wgrant: anyhow, since zope.testrunner would need a massive overhaul to detect corrupt streams at source and fix, my hack-in workaround seems to be whats needed. I've queued that up to do, which will improve robustness in this sort of failure mode in future. | 23:47 |
| StevenK | lifeless: So I still need to figure out why webkit SEGvs? | 23:48 |
| wgrant | Right, the probable segfault is the big issue | 23:52 |
| wgrant | You can often reproduce in bin/py pretty easily | 23:52 |
| wgrant | Often just by importing it... | 23:52 |
| StevenK | It would be nice to get xvfb working | 23:52 |
| lifeless | StevenK: apt-get install didn't work ? | 23:53 |
| StevenK | lifeless: Running xvfb on the executor inside LXC did not | 23:54 |
| lifeless | StevenK: in what way didn't it work ? | 23:54 |
| StevenK | It didn't start and didn't give any helpful hints as to why that was. | 23:54 |
| StevenK | I thought these properties were supposed to return Link(...) :-( | 23:56 |
| StevenK | Oh, no. It wants to call it | 23:56 |
| StevenK | FAILED (id=1, failures=4 (-27), skips=2) | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!