| wgrant | lifeless: Sure. | 00:00 |
|---|---|---|
| lifeless | skype? | 00:00 |
| wgrant | sec | 00:00 |
| === _mup__ is now known as _mup_ | ||
| lifeless | wgrant: http://www.salmon-protocol.org/ | 00:21 |
| wgrant | OOPS reports MIA? | 02:26 |
| wgrant | LOL | 02:26 |
| wgrant | Date: Tue, 25 Oct 2011 02:26:19 +0000 (UTC) | 02:26 |
| lifeless | ask and ye shall receive | 02:27 |
| wgrant | Half an hour late :/ | 02:27 |
| wgrant | wallyworld: Ahh, I think I see now why canAdd*Task ignored the current privacy status. | 02:38 |
| wgrant | So that AJAX privacy changes show/hide them? | 02:38 |
| wallyworld | wgrant: yes | 02:39 |
| wallyworld | but it works either way | 02:39 |
| wgrant | Huh, does it? | 02:39 |
| wgrant | If the bug is public and I make it private by AJAX, the links will not disappear. | 02:39 |
| wallyworld | hmmm. maybe not, i've confused myself | 02:39 |
| lifeless | wallyworld: quick question on bugtask deletion | 02:40 |
| wallyworld | no, i think it works. if it is private, a css class gets added to the links | 02:40 |
| lifeless | wallyworld: do you guard against deleting the last non-series bug (in a given context) ? | 02:40 |
| wallyworld | wgrant: and the css rule then hides those if body.private is true | 02:40 |
| wgrant | A comment explaining this would be handy. | 02:41 |
| wgrant | That the hiding is done through CSS based on body.private. | 02:41 |
| wallyworld | lifeless: perhaps not. i guard against deleting the last task | 02:41 |
| wgrant | wallyworld: And if it's not private, then the link class doesn't get added. | 02:41 |
| wgrant | wallyworld: So if I make it private later, the links won't hide until I refresh the page. | 02:41 |
| wallyworld | wgrant: ok, i'll add a comment somewhere, perhaps in the tales | 02:41 |
| lifeless | wallyworld: hopefully we'll do seriesonlytasks (or decide we won't do that at all), but I think we should, until then, honour the data model | 02:42 |
| wgrant | Before you changed it after my suggestion, this worked. | 02:42 |
| wgrant | lifeless: Which data model? | 02:42 |
| lifeless | wallyworld: you cannot create a bug with only series tasks today | 02:42 |
| wallyworld | wgrant: ah, that's why i left out the public check | 02:42 |
| lifeless | wgrant: ^ | 02:42 |
| wgrant | lifeless: That's true, but only because our API is terrible. | 02:42 |
| wallyworld | wgrant: i'll revert that change | 02:42 |
| lifeless | wgrant: no, and we went round this a fortnight back | 02:42 |
| wgrant | wallyworld: Revert the change, but add comments :) | 02:42 |
| wallyworld | wgrant: yes, sure. i knew how it worked but got myself confused | 02:43 |
| wgrant | lifeless: It's true that you can't obtain a bug with only series tasks, but you can create orphaned series tasks. | 02:43 |
| lifeless | wgrant: retargeting a non-conjoined non-series task ? | 02:44 |
| wgrant | lifeless: Right. | 02:44 |
| wgrant | Or through legacy. | 02:44 |
| wgrant | eg. bug #43150 | 02:44 |
| _mup_ | Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 > | 02:44 |
| lifeless | ouch | 02:44 |
| lifeless | so, I'm merely saying that the current UI and docs and queries assume this isn't the case | 02:44 |
| wgrant | We discussed this some months ago, remember? :) | 02:45 |
| lifeless | we've fixed it a bit | 02:45 |
| wgrant | And we agreed that it was reasonable to allow. | 02:45 |
| lifeless | I recall agreeing that it exists and we need to handle it gracefully | 02:45 |
| lifeless | it seems to go against the intent of the conjoined work to encourage it | 02:45 |
| wallyworld | lifeless: wgrant: so, do i need to make a change to the deletion check? or leave it as is? ie i simply disallow deleting the last task | 02:45 |
| wgrant | lifeless: Which conjoined work? | 02:45 |
| lifeless | wgrant: the original :) | 02:46 |
| wgrant | Disregard that. | 02:46 |
| lifeless | wallyworld: I'm torn, on the one hand there is an escalated bug which would be solved by having non-series-less bugs | 02:46 |
| lifeless | (SRU's) | 02:46 |
| lifeless | wallyworld: on the other hand this will make those bugs unique and inconsistent with the vast majority of the rest of the system | 02:47 |
| wgrant | That's true. | 02:47 |
| wallyworld | i'm all for consistency :-) | 02:47 |
| wallyworld | unless there's a really good reason | 02:47 |
| wgrant | We're sitting just before a number of major model reworks. | 02:47 |
| lifeless | wallyworld: tightening the check up a little would aid consistency in the short term. Like I say, I'm torn. | 02:48 |
| lifeless | I don't *know* that we'll get fallout from having the check looser than the rest of the UI/model behaviour | 02:48 |
| lifeless | I don't *know* that its safe either given how few examples of series-less bugs we have | 02:48 |
| wallyworld | lifeless: so if i create a bug with target=launchpad project, isn't that a series-less bug? product series = trunk may be implied but the BugTask object simply references the project, no? | 02:51 |
| lifeless | wallyworld: yes, I said non-series-less bugs | 02:51 |
| lifeless | wallyworld: its not a double negative! | 02:51 |
| lifeless | make a bug on launchpad | 02:51 |
| lifeless | nominate to a series other than trunk | 02:52 |
| lifeless | delete the non-series task leaving only the newly nominated task | 02:52 |
| wallyworld | ah, ok. i did discuss this with wgrant and he should me how this is now handled in the ui (a recent change) so it was thought that it is ok to procede | 02:53 |
| wallyworld | s/should/showed | 02:54 |
| StevenK | lifeless: You made a comment on an MP of mine yesterday -- I couldn't find anything in my grep'ing, and Curtis couldn't remember anything like that -- happy to be pointed at something. | 02:54 |
| lifeless | StevenK: which MP ? | 02:54 |
| lifeless | could someone run bin/test -vvt BranchChangedErrorHandling | 02:54 |
| StevenK | lifeless: https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 | 02:54 |
| lifeless | tell me if it has any test stiplle (unusual output) | 02:54 |
| lifeless | StevenK: ah no, I was noting the abstraction leaks in passing | 02:55 |
| lifeless | StevenK: if there isn't something, there isn't (but perhaps you should create one) | 02:55 |
| StevenK | lifeless: http://pastebin.ubuntu.com/718460/ | 02:55 |
| lifeless | ah good, I haven't messed up the branch | 02:56 |
| lifeless | thanks | 02:56 |
| lifeless | OTOH test noise fail | 02:56 |
| StevenK | Agreed | 02:56 |
| lifeless | grr! | 03:04 |
| lifeless | tests fail in ec2 | 03:04 |
| lifeless | don't fail here. | 03:04 |
| * lifeless hates | 03:04 | |
| mwhudson | isolation fail? | 03:05 |
| lifeless | mwhudson: presumably | 03:05 |
| lifeless | mwhudson: its my use-oops-twisted branch FWIW | 03:05 |
| mwhudson | bet it's a thread local :-P | 03:05 |
| lifeless | mwhudson: if by that you mean a utility.... | 03:06 |
| lifeless | mwhudson: then I won't take the bet :) | 03:06 |
| mwhudson | heh | 03:06 |
| StevenK | wgrant: Mr OCR, do you feel like reviewing https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 ? | 03:06 |
| lifeless | \o/ | 03:07 |
| lifeless | 1173 OOPS-2123ED1193 BugTask:+nominate | 03:07 |
| wallyworld | wgrant: i've updated the comments in that branch | 03:07 |
| lifeless | mwhudson: fortunately the culprit is in the previous 100 or so | 03:16 |
| lifeless | mwhudson: \o/ subunit and \o/ --load-list | 03:16 |
| lifeless | mwhudson: testworkermonitorrunnoprocess.test_failure | 03:19 |
| mwhudson | i guess the oops system doesn't even store state in thread locals, but on disk instead | 03:20 |
| * mwhudson goes to collect the car after its wof | 03:20 | |
| lifeless | mwhudson: IErrorReportingUtility | 03:20 |
| lifeless | mwhudson: utility & global, for the combined win of brain-fuckage | 03:21 |
| mwhudson | oh yes | 03:21 |
| lifeless | which isn't isolated by the default machinery | 03:23 |
| lifeless | so reconfiguring that utility -> boom | 03:23 |
| lifeless | was a foot gun by me in the branch, but still. FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU | 03:23 |
| StevenK | How do I get the HTML out of a view? | 03:49 |
| StevenK | view = create_initialized_view() ; html = view() ; I thought? | 03:49 |
| lifeless | StevenK: test_request_daily_build_oops | 03:52 |
| StevenK | What about it? | 03:52 |
| lifeless | StevenK: would you happen to know why it generates two oopses, not one, when it only creates one test recipe ? | 03:52 |
| StevenK | Nope | 03:52 |
| lifeless | ah well, thanks | 03:52 |
| StevenK | I didn't touch that bit of r-d-b | 03:53 |
| lifeless | (another reason why getLastOops causes headaches) | 03:53 |
| lifeless | grr | 03:54 |
| lifeless | Launchpad encountered an internal error during the following operation: generating an incremental diff for a merge proposal. It was logged with id OOPS-2124MPJ1. Sorry for the inconvenience. | 03:54 |
| lifeless | really must track that down. its getting tiresome | 03:54 |
| StevenK | lifeless: *Please* | 03:56 |
| lifeless | hah | 03:58 |
| lifeless | it was logging at exception level | 03:58 |
| lifeless | and manually raising | 03:58 |
| lifeless | *fixes* | 03:58 |
| poolie | lifeless: non-urgent review some time on https://code.launchpad.net/~mbp/testscenarios/module-scenarios/+merge/80287 | 04:00 |
| lifeless | hmm | 04:07 |
| lifeless | I don't think job retries should generate oopses | 04:07 |
| lifeless | still, ESCOPE | 04:07 |
| StevenK | view() is returning "" :-( | 04:08 |
| wgrant | StevenK: It probably relies on being executed inside a METAL template. | 04:08 |
| StevenK | view = create_initialized_view(team, '+index') | 04:08 |
| wgrant | Right, Person:+index can't be used that way. | 04:08 |
| lifeless | ugh, and job running also generates 2 oopses per error | 04:09 |
| * lifeless files an XXX | 04:09 | |
| StevenK | Just remove the job system | 04:10 |
| StevenK | Please | 04:10 |
| StevenK | wgrant: Thank you for the approve. If you want to help me collapse those two queries into one, that sounds excellent. | 04:11 |
| wgrant | StevenK: Find any bugs that are private and there is a subscription or an assigned task. | 04:11 |
| lifeless | beware over-combining | 04:13 |
| lifeless | e.g. test the performance of separate vs together | 04:14 |
| StevenK | wgrant: If I can't use Person:+index in create_initialized_view(), what should I be doing? | 04:14 |
| poolie | is bug 871596 really still open? is there any workaround? | 04:19 |
| _mup_ | Bug #871596: Not handling administrative shutdown under Oneiric <build-infrastructure> <librarian> <Launchpad itself:Invalid by allenap> <Storm:In Progress by allenap> < https://launchpad.net/bugs/871596 > | 04:19 |
| huwshimi | Do we have any code for generating thumbnails in Launchpad? | 04:43 |
| lifeless | huwshimi: probably not, depending on what you are meaning | 04:44 |
| huwshimi | lifeless: I'm investigating whether we can show small versions of images that are uploaded to Launchpad (e.g. for images attached to a bug). For that we need some code that resizes and probably caches the image. | 04:47 |
| huwshimi | lifeless: I'm guessing such code probably doesn't exist | 04:47 |
| poolie | !! | 04:48 |
| poolie | that'd be nice | 04:49 |
| lifeless | huwshimi: its been written many times :) | 04:51 |
| lifeless | huwshimi: this is a perfect candidate for a separate service, it should be a fairly small amount of work to do it | 04:51 |
| lifeless | huwshimi: librarian for storage, separate link in the bugattachment to the thumbnail, backend to process and upload | 04:52 |
| lifeless | I don't think we're at the volume to need e.g. haystack yet | 04:52 |
| lifeless | brb | 04:53 |
| huwshimi | lifeless: (for when you get back) how long might this take (roughly)? A couple of days, a week? | 04:57 |
| poolie | :) i like your estimation scale | 04:59 |
| huwshimi | poolie: If it's outside that scale, it's not ever happening :) | 05:01 |
| huwshimi | poolie: actually if it's outside of a couple of days it's probably never happening | 05:02 |
| poolie | :) | 05:02 |
| poolie | that was my concern about markdown :) | 05:02 |
| poolie | i suspect you could write it in under a week but it would take a while to get deployed | 05:03 |
| huwshimi | poolie: Wow, you think there's a week's worth of work for the first stage of markdown? | 05:04 |
| poolie | i think for it to succeed it would have to be tightly scoped so that you could get something done in under a week | 05:04 |
| poolie | have there been any LEP/feature type things ever done in less than a week? | 05:05 |
| huwshimi | poolie: That's pretty depressing really | 05:06 |
| lifeless | huwshimi: week(s) | 05:07 |
| huwshimi | lifeless: Ok, sure | 05:07 |
| huwshimi | lifeless: That also is very depressing | 05:07 |
| lifeless | huwshimi: you need two schema changes (add field, index it). | 05:07 |
| poolie | lifeless: re bug 878140, does logging a warning inherently generate an oops? | 05:07 |
| _mup_ | Bug #878140: process-mail.py failed to resolve dns. Raised NXDOMAIN <dkim> <oops> <Launchpad itself:Triaged by mbp> < https://launchpad.net/bugs/878140 > | 05:07 |
| lifeless | huwshimi: then you need a job to walk things that need doing them and do it | 05:07 |
| poolie | could https://lp-oops.canonical.com/oops.py/?oopsid=2116INBOUNDEMAIL2 have come from that? | 05:08 |
| lifeless | huwshimi: lastly you need the actual image resizing code itself (and I would make it a microservice for reusability) | 05:08 |
| huwshimi | lifeless: Ah, so writing the code wouldn't take a week or more, just the whole process? | 05:09 |
| lifeless | huwshimi: yes | 05:10 |
| poolie | huwshimi: another option is to just serve the whole image and rely on the browser to resize them | 05:12 |
| poolie | for version 0 | 05:12 |
| huwshimi | lifeless: But maybe close to a week for the code? | 05:12 |
| lifeless | poolie: see OopsHandler in the codebase. (short story -yes, warnings -> things we need to see -> OOPS) | 05:12 |
| poolie | i see, and it logs the last exception? | 05:12 |
| lifeless | yes | 05:13 |
| huwshimi | poolie: We could, but that would mean loading some rather large images at times | 05:14 |
| poolie | yep | 05:14 |
| lifeless | huwshimi: the code duration could be a matter of hours, depending on soft things like 'minimum time to get the image resized' and 'do we need parallelisation' | 05:14 |
| lifeless | huwshimi: there is lots of latency in the landing story today: 4 hours for the column through ec2, 4 hours for it through buildbot, then wait for a fastdowntime window. | 05:15 |
| lifeless | huwshimi: then for the index on the column, 4 hours for ec2, 4 hours for buildbot, then apply live | 05:15 |
| lifeless | huwshimi: then for the background job to grab and resize, 4 hours for ec2, 4 hours for buildbot, then wait for a nodowntimedeploy | 05:16 |
| huwshimi | lifeless: I'm really trying to judge whether this is something that I want to do myself. If it was something that I could code in about 2 days that would be an ok use of my time, if it was much longer, probably not | 05:16 |
| poolie | lifeless: ok so like https://code.launchpad.net/~mbp/launchpad/878140-dkim-nxdomain/+merge/80289 ? | 05:17 |
| lifeless | huwshimi: and for the image resizing aspect, depending on whether the dev inlines it (simple but grows the LP codebase) or makes a service (more initial overhead, easier management and tuning thereafter) the same ec2 etc, or the delay with LOSAs to get a new service deployed. | 05:17 |
| huwshimi | lifeless: So there's no window for actually getting it deployed | 05:17 |
| poolie | huwshimi: i think it depends a bit how much you want to learn how to write microservices in lp | 05:17 |
| poolie | etc | 05:17 |
| lifeless | huwshimi: like most things in LP, its going to touch the whole vertical stack: db, deployment, middleware, object model, security rules, interfaces, and thats ignoring whatever template/js changes you want to support the UI | 05:18 |
| huwshimi | poolie: Well I would want to do it in a useful way, I also don't want to over optimise | 05:18 |
| lifeless | huwshimi: I would say, if you're fairly familiar with that vertical stack, then yes, the actual coding aspect could be <= 2 days. If you're not, you'll spend considerable time fumbling and learning (which is perhaps good in its own right) | 05:19 |
| huwshimi | lifeless: Right, so I'm interested in getting to delve into the code base a bit more, I'm not sure building a whole service would be a good thing to start with | 05:20 |
| lifeless | huwshimi: yes, its hard to find truely small-but-involves-learning things in LP | 05:25 |
| lifeless | :( | 05:25 |
| huwshimi | lifeless: haha, yes | 05:25 |
| poolie | maybe we can quasi-pair on md? | 05:28 |
| poolie | lifeless: thanks for the review | 05:28 |
| poolie | would it be easy to add a test saying "this doesn't oops/warn"? | 05:29 |
| lifeless | poolie: sure, you need to use one of the logging test helpers, simulate the situation, and check that nothing was logged at or above WARN | 05:33 |
| lifeless | of course, this is vulnerable to skew, as we're assuming that OOPSHandler won't be given a level= parameter when its added in script setup | 05:33 |
| lifeless | personally, I would hesitate to test this | 05:34 |
| huwshimi | poolie: I'm keen to help out if there's a way we can do that | 05:34 |
| poolie | are you going to uds (i'm not) | 05:35 |
| lifeless | any test here is vulnerable to two forms of skew I think - the oopshandler config, and the actual exception raised. | 05:35 |
| poolie | perhaps we could spike it for a day or something , maybe next week | 05:35 |
| poolie | right | 05:35 |
| lifeless | so you'd need to make sure you test deeply enough to insulate from that | 05:36 |
| poolie | i found it confusing the oops is unclear about whether the exception traceback indicates the program stopped at that point | 05:36 |
| poolie | to me it certainly does look like it stopped, but apparently it did not | 05:36 |
| lifeless | a bug explaining the confusion would be good | 05:36 |
| lifeless | I think its right to show the tb it did, but not to confuse you | 05:37 |
| poolie | a bug against which project? | 05:37 |
| huwshimi | poolie: No I'm not, I'd be keen for that | 05:37 |
| lifeless | poolie: to start with LP, which is where OopsHandler is | 05:37 |
| lifeless | poolie: and/or python-oops-tools which does the rendering | 05:38 |
| lifeless | poolie: the emit() method on OopsHandler could usefully include the logging level in the message, and whether there was an exception attached | 05:39 |
| lifeless | => cooking | 05:40 |
| poolie | lifeless: ok https://bugs.launchpad.net/launchpad/+bug/881243 | 05:43 |
| _mup_ | Bug #881243: oops display doesn't make it clear whether the exception stopped the process <Launchpad itself:Triaged> < https://launchpad.net/bugs/881243 > | 05:43 |
| nigelb | Morning. | 05:53 |
| nigelb | stub: You'll find this entertaining :) | 05:54 |
| nigelb | http://thedailywtf.com/Articles/The-Query-of-Despair.aspx | 05:54 |
| stub | nigelb: I just hope an ORM was involved or my remaining faith in humanity will dwindle. | 05:55 |
| nigelb | "legacy" application. | 05:56 |
| nigelb | I doubt if an ORM was involved. | 05:56 |
| jtv | Who knows about LP's mailing lists? Need help with this question: https://answers.launchpad.net/launchpad/+question/175718 | 06:57 |
| lifeless | wgrant: 2704 lines | 07:49 |
| wgrant | lifeless: :( | 07:49 |
| lifeless | jtv: the mailing list archiver gets rather behind | 07:49 |
| jtv | lifeless: ? | 07:50 |
| lifeless | jtv: I'm not sure if we've got a bug for that yet; moving it to a backend JSON server is the planned approach to fix it | 07:50 |
| jtv | Ah, the question | 07:50 |
| lifeless | yes :) | 07:50 |
| jtv | Thanks for looking into it. “Rather behind” doesn't really cover it in this case though. | 07:50 |
| lifeless | jtv: days isn't uncommon. Its been weeks on occasion | 07:50 |
| jtv | IIRC the last archived message there was a year old. | 07:50 |
| lifeless | jtv: ah! that may need checking by a losa then on the list in question - check that mailman hasn't blerched itself | 07:51 |
| lifeless | jtv: There are probably logs you can poke at on carob to start with | 07:51 |
| jtv | Hmm | 07:51 |
| lifeless | s/probably// | 07:51 |
| jtv | I'll try that, thanks. | 07:51 |
| lifeless | the key thing to know is that mailman handles the mail and forwards it etc | 07:52 |
| lifeless | the list archive is really just another recipient - it queues it up and then rewrites the index page to link it in when it gets to it | 07:52 |
| jtv | Any chance that it might even be a spam filter? | 07:55 |
| lifeless | wgrant: it could be worse | 07:55 |
| lifeless | wgrant: its mostly mechanical | 07:55 |
| lifeless | jtv: I don't believe so; I would expect no-delivery to list members in that case | 07:55 |
| wgrant | It's only known to be 4 days out of date. | 07:57 |
| wgrant | I haven't seen any suggestion that an email was sent to the list between the last one in the archive and October 21st. | 07:57 |
| wgrant | That's very much within mhonarc-is-slow-and-ubuntu-x-swat-is-huge-so-nevermind territory. | 07:57 |
| wgrant | Indeed, October 21st is the first email since then. | 07:58 |
| wgrant | http://www.mail-archive.com/nunit-dev@lists.launchpad.net/ | 07:58 |
| jtv | I wonder why the process-mail.log for the 21st seems to be binary garbage. | 08:02 |
| wgrant | That sounds irrelevant. | 08:03 |
| wgrant | mailman doesn't have anything named process-mail.log, AFAIK. | 08:03 |
| jtv | What are the relevant logs? | 08:03 |
| mrevell | Hallo | 08:04 |
| wgrant | All the mailman logs on forster. | 08:04 |
| adeuring | good morning | 08:06 |
| jtv | hi mrevell, hi adeuring | 08:06 |
| adeuring | hi jtv | 08:06 |
| jtv | wgrant: hasn't forster retired? | 08:06 |
| StevenK | What gave you that idea? | 08:07 |
| jtv | I thought that was the server that loganberry replaced. | 08:07 |
| wgrant | It was. | 08:08 |
| === almaisan-away is now known as al-maisan | ||
| wgrant | It is no longer the scripts server. | 08:08 |
| wgrant | It continues to be the mailman server, however. | 08:08 |
| jtv | So I'm looking for scripts/forster/mailman-xmlrpc/ | 08:08 |
| wgrant | No. | 08:08 |
| wgrant | Well, probably not the xmlrpc bit. | 08:08 |
| wgrant | xmlrpc is irrelevant here. | 08:08 |
| jtv | Okay, what other mailman logs are there? | 08:09 |
| wgrant | The logs from mailman, which are probably somewhere. | 08:09 |
| wgrant | mailman/forster | 08:09 |
| jtv | Ah, thanks. | 08:10 |
| jtv | Some timeouts there. | 08:11 |
| === panta_ is now known as panta | ||
| lifeless | wgrant: also, no more getLastOops | 08:30 |
| lifeless | wgrant: more than makes up for size IMO :) | 08:30 |
| nigelb | poolie: Hey, you guys had a circuit breaker thing for the "should make tea" bug right? | 08:31 |
| nigelb | poolie: Can you link me to that bug if you have it handy? | 08:32 |
| poolie | bug 795321 | 08:32 |
| _mup_ | Bug #795321: udd importer should make tea while launchpad is down <fastdowntime-later> <Launchpad itself:Invalid> <Ubuntu Distributed Development:Fix Released by vila> < https://launchpad.net/bugs/795321 > | 08:32 |
| nigelb | poolie: Thanks! | 08:32 |
| nigelb | I ended up needed something like this for work :D | 08:32 |
| poolie | are you going to use it somewhere else? | 08:32 |
| poolie | oh ok | 08:32 |
| nigelb | Implementing it in bash is going to be loads of fun. | 08:33 |
| lifeless | \o/ | 08:37 |
| poolie | mrevell, danhg, https://code.launchpad.net/~mbp/launchpad/jobs-link/+merge/80307 | 09:26 |
| poolie | lifeless: ? | 09:26 |
| lifeless | there is a config setting to put stuff in the footer | 09:27 |
| lifeless | I'd just set that directly on prod | 09:27 |
| wgrant | Can't do links, though. | 09:27 |
| wgrant | I don't think. | 09:27 |
| lifeless | wgrant: I thought it was html it took | 09:27 |
| wgrant | I hope not. | 09:27 |
| wgrant | Anything that I see that takes HTML gets added to my hitlist. | 09:28 |
| poolie | are you referring to site_message? | 09:29 |
| poolie | i thought that was meant for "end of the world imminent" | 09:29 |
| poolie | s//eschaton | 09:29 |
| poolie | that would be too heavy for this, i think | 09:29 |
| lifeless | all hail our future light cone | 09:29 |
| wgrant | site_message is used on staging/qastaging/dogfood | 09:29 |
| wgrant | To say that changes will be lost. | 09:29 |
| wgrant | It used to be used on edge to say it was running pre-release code. | 09:30 |
| wgrant | It was originally along the top of the page, but was demoted to the bottom for 3.0 | 09:30 |
| lifeless | its tasteful but may not support a link | 09:30 |
| lifeless | anyhow, I have no strong objection, it just seems like something better done in config than in code | 09:31 |
| poolie | iswym | 09:31 |
| poolie | otoh there's a fuzzy line between code and config | 09:31 |
| poolie | lifeless: i was actually wondering about your \hooray emoticon | 09:33 |
| poolie | was that for me? | 09:33 |
| danhg | Hi poolie: what am I looking at on that link? | 09:34 |
| poolie | ah welcome :) | 09:34 |
| mrevell | danhg, We can talk about that on the phone now. It's your first merge proposal. | 09:34 |
| poolie | you can do your first code review | 09:34 |
| lifeless | poolie: implementing circuit breaker in bash. | 09:34 |
| lifeless | poolie: it was a little ironic | 09:35 |
| poolie | danhg: mostly if you talk it over with mr that's be good | 09:35 |
| poolie | don't be too rough on me :) | 09:35 |
| poolie | night all | 09:35 |
| danhg | ok | 09:36 |
| danhg | goodnight | 09:36 |
| === jtv is now known as jtv-afk | ||
| lifeless | zomg use-oops-twisted landed. | 09:42 |
| * lifeless dances the happy dance | 09:42 | |
| bigjools | wgrant: thanks for QAing 747558 for me - only just saw my bug mail. | 09:49 |
| lifeless | wgrant: btw, don't know if you saw but collapsing those private-asset queries into one using joins took it up to 5seconds hot (vs 4ms hot using a union all) | 09:51 |
| wgrant | lifeless: The query was wrong. Not sure if that would make much of a difference, though. | 09:52 |
| lifeless | wgrant: yah, table scans R us | 09:52 |
| wgrant | bigjools: That was the ddeb thing? | 09:53 |
| wgrant | Bug #747558 | 09:54 |
| _mup_ | Bug #747558: PPAs should create backtracable packages <escalated> <ppa> <qa-ok> <Launchpad itself:In Progress by julian-edwards> < https://launchpad.net/bugs/747558 > | 09:54 |
| wgrant | Right. | 09:54 |
| bigjools | wgrant: did you test just the upload changes I made? | 09:55 |
| bigjools | I need to add the copying safeguard and then it's probably ok to release | 09:56 |
| bigjools | but I want to see it working on DF myself | 09:56 |
| wgrant | bigjools: Yeah, I just built a package with some ddebs and checked that the overrides matched. | 09:56 |
| bigjools | cool | 09:56 |
| bigjools | where is it~? | 09:56 |
| wgrant | Didn't try superseding, because I didn't want to sneak concordia away for too long. | 09:56 |
| wgrant | https://dogfood.launchpad.net/~wgrant/+archive/dogfood/+packages <- aalib there | 09:57 |
| bigjools | concordia is still on DF anyway | 09:57 |
| wgrant | Needs process-accepted run, but I checked the BPR overrides in the DB. | 09:57 |
| bigjools | running it | 09:57 |
| === jtv-afk is now known as jtv | ||
| === jtv is now known as jtv-afk | ||
| nigelb | bigjools: lolcricket :D | 10:30 |
| * nigelb ducks | 10:30 | |
| bigjools | (_._) | 10:30 |
| nigelb | hrm, what's that stand for? | 10:31 |
| nigelb | Or should I not be asking :D | 10:31 |
| bigjools | I was mooning you :) | 10:31 |
| nigelb | ha | 10:31 |
| bigjools | nigelb: still laughing? | 11:02 |
| === jkakar_ is now known as jkakar | ||
| bac | hi mrevell | 12:37 |
| mrevell | hey bac | 12:38 |
| thumper | morning | 12:55 |
| deryck | Morning, all. | 12:58 |
| allenap | Morning deryck. | 12:59 |
| === jtv-afk is now known as jtv | ||
| bac | yo mrevell | 13:11 |
| abentley | allenap: how's that storm bug coming? | 13:13 |
| allenap | abentley: I've resolved most of the issues; only one very stubborn one remains. | 13:14 |
| abentley | allenap: oh dear. Anything I can help with? | 13:15 |
| allenap | abentley: I don't think so... but I'll ping if there is something. Thanks. As of about 10 seconds ago I think we might need to move to a newer psycopg2. | 13:17 |
| abentley | allenap: Okay. Good luck with it. | 13:18 |
| allenap | And now I'm not so sure! | 13:18 |
| abentley | allenap: I hate that. | 13:25 |
| thumper | flacoste: ping | 14:11 |
| === matsubara is now known as matsubara-lunch | ||
| === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | Welcome danhg | On call reviewer: gmb | Critical bugtasks: 266 | ||
| danilos | flacoste, hi, I am Danilo from the Linaro team :) | 14:57 |
| danilos | flacoste, asac mentions how there is a very important regression that hits us in https://bugs.launchpad.net/launchpad/+bug/881144, which is time critical; do you think it'd be possible to get someone to look at it today/tomorrow to at least get any idea if we can get some results by Thursday? | 14:59 |
| _mup_ | Bug #881144: field.tags_combinator=ALL gives same results as with ANY <bugs> <regression> <search> <Launchpad itself:Triaged> <Linaro Android:Triaged> <Linaro-Ubuntu:Triaged> < https://launchpad.net/bugs/881144 > | 14:59 |
| danilos | flacoste, if not, perhaps we need to focus on a work-around on our side (we can load bug-by-bug through API and filter stuff out that way) | 14:59 |
| === al-maisan is now known as almaisan-away | ||
| === beuno is now known as beuno-lunch | ||
| nigelb | drat. no bigjools. | 16:03 |
| nigelb | I wanted to poke fun at england's cricket team :D | 16:03 |
| === deryck is now known as deryck[lunch] | ||
| * sinzui sends all spam to himself before sending to the user so that he shares their pain | 17:12 | |
| === beuno-lunch is now known as beuno | ||
| * sinzui plants face in palm | 17:16 | |
| nigelb | sinzui: If you shoot your self in the foot...and then complain... :P | 17:41 |
| === salgado is now known as salgado-lunch | ||
| sinzui | nigelb, My test went fine | 17:42 |
| sinzui | But I left my name in one of the headers in the real send. | 17:42 |
| nigelb | :) | 17:43 |
| === salgado-lunch is now known as salgado | ||
| === deryck[lunch] is now known as deryck | ||
| === jcsackett__ is now known as jcsackett | ||
| thumper | sinzui: hi | 19:53 |
| sinzui | Hi thumper | 19:53 |
| thumper | sinzui: how do I get project associations on the stakeholder list? | 19:53 |
| thumper | sinzui: distro really want it now I told them what it is | 19:54 |
| sinzui | thumper, you need to find stakeholder reps to bring it to the list. | 19:55 |
| lifeless | thumper: Sounds like a handwave rather than a LEP :) [I mean, theres a lot of things it -might- mean] | 20:01 |
| lifeless | thumper: its going to be feature level work I think, which means that the various stakeholders have to all agree its position on the list for it to get scheduled [more or less] | 20:02 |
| thumper | I've been told there hasn't been a stakeholders meeting of 6 months | 20:03 |
| lifeless | the queue already has items in it, and noone has proposed removing them | 20:03 |
| lifeless | the stakeholder process is about prioritisation, not about getting things done more quickly | 20:05 |
| * thumper nods | 20:05 | |
| * thumper goes back to the drawing board | 20:05 | |
| lifeless | [theory being that with consensus about what to do next, we can avoid chopping and changing mid-project, letting us deliver the projects more smoothly and with less defects] | 20:07 |
| sinzui | thumper, I can brief people were we were in 2009. We had a proposal that Mark asked for UI changes to | 20:25 |
| deryck | abentley_, hi. | 20:30 |
| abentley_ | deryck: hi. | 20:30 |
| deryck | abentley_, I see you got mail for the feature branch passing, but not clear on my end if you got the upgrade branch mail also. | 20:30 |
| abentley_ | deryck: No, I didn't get that one. | 20:31 |
| deryck | abentley_, ok, I'll forward to you then. | 20:31 |
| abentley_ | deryck: did you know that {foo: 'bar', baz: 'qux'} is different from {baz: 'qux', foo: 'bar'} in Javascript? Objects used as mappings apparently preserve ordering. | 20:37 |
| * lifeless headdesks | 20:37 | |
| deryck | abentley, are you sure it's the ordering that matters, and not just that js sees two different objects? i.e. how are you testing this? | 20:45 |
| abentley | deryck: I'm producing query strings from a mapping, and the order of the items in the query string matches the order the items are added to the mapping. | 20:46 |
| abentley | deryck: I think I saw this earlier with JSON stringification, too. | 20:48 |
| deryck | abentley, so I'm having a little trouble following the specific example here of how ordering matters, sorry. But.... | 20:51 |
| deryck | abentley, I did know directly comparing the same objects in js won't work. it sees different objects. | 20:52 |
| deryck | abentley, but this is to do with how js creates/sees objects. and you usually just compare properties and values, not object to object. | 20:52 |
| abentley | deryck: {foo: 'bar', baz: 'qux'} => "foo=bar&baz=qux", {baz: 'qux', foo: 'bar'} => "baz=qux&foo=bar" | 20:53 |
| abentley | deryck: So even when you serialize it, you get different values for equivalent mappings. | 20:54 |
| === mpt_ is now known as mpt | ||
| deryck | abentley, you would expect {baz: 'qux', foo: 'bar'} to come out "foo=bar&baz=qux" ? | 20:56 |
| abentley | deryck: I would like a consistent order. I don't have a particular order in mind. | 20:56 |
| deryck | abentley, is this something in the language causing the issue, though? Or in how you're doing the serialization? | 20:58 |
| abentley | deryck: Something in the language is causing the issue, because if mappings were unordered, as in Python, it would be impossible for a serialization to preserve ordering. | 20:59 |
| deryck | abentley, are you doing the serialization yourself or relying on something in yui3? | 21:02 |
| lifeless | abentley: have you seen ordereddict in python 3 ? | 21:04 |
| abentley | deryck: I don't understand why that's relevant, but I'm using something in YUI3, | 21:04 |
| deryck | abentley, I guess it's not relevant. Just curious mostly. | 21:05 |
| abentley | lifeless: No, but I have occasionally encountered situations where that would be useful. | 21:05 |
| deryck | abentley, I guess it's not that shocking to me either because js objects aren't really the same as python dicts, even though they seem similar in ways. | 21:05 |
| abentley | deryck: It was surprising to me, because it's the first language I've encountered that had ordered mappings by default. | 21:07 |
| sinzui | wallyworld_, wgrant, StevenK: Gerald the Gorilla http://www.youtube.com/watch?v=beCYGm1vMJ0 | 22:23 |
| === StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | Welcome danhg | On call reviewer: StevenK | Critical bugtasks: 266 | ||
| * StevenK assumes gmb is no longer reviewing. | 22:44 | |
| StevenK | wgrant: When you have a tick, glance at the query in https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 , lines 51 to 62 | 23:01 |
| wgrant | abentley: Any reason you didn't use IJSONRequestCache for storing the mustache template? | 23:10 |
| wgrant | abentley: Using dumps directly is not safe. | 23:10 |
| wgrant | StevenK: | 23:12 |
| wgrant | tables=( | 23:12 |
| wgrant | Bug, | 23:12 |
| wgrant | Join(BugSubscription, BugSubscription.bug_id == Bug.id)), | 23:12 |
| wgrant | Same with the multi-line where. | 23:13 |
| wgrant | I also find the execute(Union syntax distasteful. | 23:14 |
| wgrant | Particularly since you then have you use .rowcount afterwards. | 23:14 |
| StevenK | wgrant: I've fixed the tables and where. I don't really want to reflow the entire block though. :-/ | 23:21 |
| poolie | jesus team roles are such a mess | 23:21 |
| poolie | how can i find out what access an open team actually has? | 23:22 |
| wgrant | You can't. | 23:23 |
| poolie | yeah that was really a way of saying "i wish i could" | 23:23 |
| wgrant | StevenK: What reflowing are you talking about? | 23:28 |
| wgrant | StevenK: Also, when you raise the exception on line 68, what sort of string does the policy turn into? | 23:29 |
| wgrant | Open? OPEN? | 23:29 |
| StevenK | I think it's 'open' | 23:32 |
| poolie | lifeless: re bug 881237, would it be too tasteless to just catch Exception around the call to dkim | 23:32 |
| _mup_ | Bug #881237: broken dkim key on qq.com causes mail to be dropped <dkim> <mail> <oops> <Launchpad itself:Triaged by mbp> <pydkim:In Progress by mbp> < https://launchpad.net/bugs/881237 > | 23:32 |
| wgrant | Please try to check. | 23:32 |
| poolie | so that random bad input, causing eg a KeyError or ValueError, doesn't result in the mail being dropped | 23:33 |
| StevenK | wgrant: Hold on, I'll do it now. | 23:33 |
| poolie | this is kinda papering over pydkim not handling those things cleanly but perhaps it's good to be defensive | 23:33 |
| wgrant | poolie: Have you read pydkim's code? :) | 23:33 |
| wgrant | s/good/necessary/ | 23:34 |
| poolie | there are no tests | 23:34 |
| wgrant | I agree completely with catching Exception. | 23:34 |
| poolie | presumably because the code has been formally proved to be correct | 23:34 |
| poolie | ok thanks | 23:34 |
| StevenK | Formal proof nothing. LP has taught me that you *NEED* tests. | 23:35 |
| wgrant | Our fork is no longer a several-hundred-line function, and it's more correct and tested, but it's still awful awful. | 23:35 |
| poolie | now that upstream seems to have appeared again perhaps we can push them up | 23:35 |
| wgrant | Indeed, I was surprised to see it on github. | 23:36 |
| * StevenK kills SSO | 23:36 | |
| wgrant | Since we had no response from him for several months. | 23:36 |
| poolie | yeah, but isn't that always the way? | 23:36 |
| poolie | actually doing something yourself prompts others into action | 23:36 |
| StevenK | wgrant: What does it mean when icons in the dock have a green background? | 23:43 |
| wgrant | StevenK: s/dock/Launcher/? | 23:43 |
| StevenK | Right | 23:43 |
| wgrant | It means either that it decided the primary colour of your icon was green, or possibly that your graphics drivers suck. | 23:44 |
| StevenK | Sorry, one icon is green | 23:44 |
| StevenK | And it changes | 23:44 |
| StevenK | wgrant: The text is "The team subscription policy cannot be Open Team because it is subscribed to or assigned to one or more private bugs." | 23:45 |
| wgrant | I guess that's OK. | 23:45 |
| wgrant | We really should s/subscription/membership/ everywhere :( | 23:45 |
| StevenK | If you're happy enough with it, I'll land it. | 23:46 |
| wgrant | Sounds OK. | 23:46 |
| wgrant | wallyworld_: But the action *can* be mostly undone. | 23:48 |
| wallyworld_ | sort of | 23:48 |
| wallyworld_ | i was adhering to the instructions in the bug report | 23:49 |
| wgrant | As it stands, the statement is a lie. | 23:49 |
| wgrant | It says that it will mark the bug as not affecting that target, and this action cannot be undone. | 23:50 |
| wgrant | I can create a counterexample by clicking "Also affects project" | 23:50 |
| wallyworld_ | i think the intent is to make people really sure they want to delete something | 23:50 |
| wallyworld_ | in most all other cases, delete is permanent | 23:50 |
| wallyworld_ | perhaps good to be consistent with the warnings | 23:51 |
| wgrant | In this case the task deletion is permanent. | 23:51 |
| wgrant | The not-affectingness is not. | 23:51 |
| wgrant | The only information that is deleted permanently is metadata that probably <10 people look at. | 23:51 |
| wallyworld_ | you may be best to take it up with the author of the bug report? | 23:52 |
| wgrant | Perhaps. | 23:52 |
| wgrant | sinzui: Still around? | 23:52 |
| wallyworld_ | i don't mind either way what is decided | 23:52 |
| wallyworld_ | so why can't i use the construct <p tal:define="foo context/bar" tal:content="string:${foo}"/> ? it only likes <p tal:content="string:${context/bar}"/> | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!