[00:00] lifeless: Sure. [00:00] skype? [00:00] sec === _mup__ is now known as _mup_ [00:21] wgrant: http://www.salmon-protocol.org/ [02:26] OOPS reports MIA? [02:26] LOL [02:26] Date: Tue, 25 Oct 2011 02:26:19 +0000 (UTC) [02:27] ask and ye shall receive [02:27] Half an hour late :/ [02:38] wallyworld: Ahh, I think I see now why canAdd*Task ignored the current privacy status. [02:38] So that AJAX privacy changes show/hide them? [02:39] wgrant: yes [02:39] but it works either way [02:39] Huh, does it? [02:39] If the bug is public and I make it private by AJAX, the links will not disappear. [02:39] hmmm. maybe not, i've confused myself [02:40] wallyworld: quick question on bugtask deletion [02:40] no, i think it works. if it is private, a css class gets added to the links [02:40] wallyworld: do you guard against deleting the last non-series bug (in a given context) ? [02:40] wgrant: and the css rule then hides those if body.private is true [02:41] A comment explaining this would be handy. [02:41] That the hiding is done through CSS based on body.private. [02:41] lifeless: perhaps not. i guard against deleting the last task [02:41] wallyworld: And if it's not private, then the link class doesn't get added. [02:41] wallyworld: So if I make it private later, the links won't hide until I refresh the page. [02:41] wgrant: ok, i'll add a comment somewhere, perhaps in the tales [02:42] 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] Before you changed it after my suggestion, this worked. [02:42] lifeless: Which data model? [02:42] wallyworld: you cannot create a bug with only series tasks today [02:42] wgrant: ah, that's why i left out the public check [02:42] wgrant: ^ [02:42] lifeless: That's true, but only because our API is terrible. [02:42] wgrant: i'll revert that change [02:42] wgrant: no, and we went round this a fortnight back [02:42] wallyworld: Revert the change, but add comments :) [02:43] wgrant: yes, sure. i knew how it worked but got myself confused [02:43] lifeless: It's true that you can't obtain a bug with only series tasks, but you can create orphaned series tasks. [02:44] wgrant: retargeting a non-conjoined non-series task ? [02:44] lifeless: Right. [02:44] Or through legacy. [02:44] eg. bug #43150 [02:44] <_mup_> Bug #43150: [SRU] maxima frontends fail to connect < https://launchpad.net/bugs/43150 > [02:44] ouch [02:44] so, I'm merely saying that the current UI and docs and queries assume this isn't the case [02:45] We discussed this some months ago, remember? :) [02:45] we've fixed it a bit [02:45] And we agreed that it was reasonable to allow. [02:45] I recall agreeing that it exists and we need to handle it gracefully [02:45] it seems to go against the intent of the conjoined work to encourage it [02:45] 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] lifeless: Which conjoined work? [02:46] wgrant: the original :) [02:46] Disregard that. [02:46] 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] (SRU's) [02:47] 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] That's true. [02:47] i'm all for consistency :-) [02:47] unless there's a really good reason [02:47] We're sitting just before a number of major model reworks. [02:48] wallyworld: tightening the check up a little would aid consistency in the short term. Like I say, I'm torn. [02:48] I don't *know* that we'll get fallout from having the check looser than the rest of the UI/model behaviour [02:48] I don't *know* that its safe either given how few examples of series-less bugs we have [02:51] 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] wallyworld: yes, I said non-series-less bugs [02:51] wallyworld: its not a double negative! [02:51] make a bug on launchpad [02:52] nominate to a series other than trunk [02:52] delete the non-series task leaving only the newly nominated task [02:53] 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:54] s/should/showed [02:54] 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] StevenK: which MP ? [02:54] could someone run bin/test -vvt BranchChangedErrorHandling [02:54] lifeless: https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 [02:54] tell me if it has any test stiplle (unusual output) [02:55] StevenK: ah no, I was noting the abstraction leaks in passing [02:55] StevenK: if there isn't something, there isn't (but perhaps you should create one) [02:55] lifeless: http://pastebin.ubuntu.com/718460/ [02:56] ah good, I haven't messed up the branch [02:56] thanks [02:56] OTOH test noise fail [02:56] Agreed [03:04] grr! [03:04] tests fail in ec2 [03:04] don't fail here. [03:04] * lifeless hates [03:05] isolation fail? [03:05] mwhudson: presumably [03:05] mwhudson: its my use-oops-twisted branch FWIW [03:05] bet it's a thread local :-P [03:06] mwhudson: if by that you mean a utility.... [03:06] mwhudson: then I won't take the bet :) [03:06] heh [03:06] wgrant: Mr OCR, do you feel like reviewing https://code.launchpad.net/~stevenk/launchpad/extend-subscription-check/+merge/80173 ? [03:07] \o/ [03:07] 1173 OOPS-2123ED1193 BugTask:+nominate [03:07] wgrant: i've updated the comments in that branch [03:16] mwhudson: fortunately the culprit is in the previous 100 or so [03:16] mwhudson: \o/ subunit and \o/ --load-list [03:19] mwhudson: testworkermonitorrunnoprocess.test_failure [03:20] 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] mwhudson: IErrorReportingUtility [03:21] mwhudson: utility & global, for the combined win of brain-fuckage [03:21] oh yes [03:23] which isn't isolated by the default machinery [03:23] so reconfiguring that utility -> boom [03:23] was a foot gun by me in the branch, but still. FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU [03:49] How do I get the HTML out of a view? [03:49] view = create_initialized_view() ; html = view() ; I thought? [03:52] StevenK: test_request_daily_build_oops [03:52] What about it? [03:52] StevenK: would you happen to know why it generates two oopses, not one, when it only creates one test recipe ? [03:52] Nope [03:52] ah well, thanks [03:53] I didn't touch that bit of r-d-b [03:53] (another reason why getLastOops causes headaches) [03:54] grr [03:54] 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] really must track that down. its getting tiresome [03:56] lifeless: *Please* [03:58] hah [03:58] it was logging at exception level [03:58] and manually raising [03:58] *fixes* [04:00] lifeless: non-urgent review some time on https://code.launchpad.net/~mbp/testscenarios/module-scenarios/+merge/80287 [04:07] hmm [04:07] I don't think job retries should generate oopses [04:07] still, ESCOPE [04:08] view() is returning "" :-( [04:08] StevenK: It probably relies on being executed inside a METAL template. [04:08] view = create_initialized_view(team, '+index') [04:08] Right, Person:+index can't be used that way. [04:09] ugh, and job running also generates 2 oopses per error [04:09] * lifeless files an XXX [04:10] Just remove the job system [04:10] Please [04:11] wgrant: Thank you for the approve. If you want to help me collapse those two queries into one, that sounds excellent. [04:11] StevenK: Find any bugs that are private and there is a subscription or an assigned task. [04:13] beware over-combining [04:14] e.g. test the performance of separate vs together [04:14] wgrant: If I can't use Person:+index in create_initialized_view(), what should I be doing? [04:19] is bug 871596 really still open? is there any workaround? [04:19] <_mup_> Bug #871596: Not handling administrative shutdown under Oneiric < https://launchpad.net/bugs/871596 > [04:43] Do we have any code for generating thumbnails in Launchpad? [04:44] huwshimi: probably not, depending on what you are meaning [04:47] 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] lifeless: I'm guessing such code probably doesn't exist [04:48] !! [04:49] that'd be nice [04:51] huwshimi: its been written many times :) [04:51] huwshimi: this is a perfect candidate for a separate service, it should be a fairly small amount of work to do it [04:52] huwshimi: librarian for storage, separate link in the bugattachment to the thumbnail, backend to process and upload [04:52] I don't think we're at the volume to need e.g. haystack yet [04:53] brb [04:57] lifeless: (for when you get back) how long might this take (roughly)? A couple of days, a week? [04:59] :) i like your estimation scale [05:01] poolie: If it's outside that scale, it's not ever happening :) [05:02] poolie: actually if it's outside of a couple of days it's probably never happening [05:02] :) [05:02] that was my concern about markdown :) [05:03] i suspect you could write it in under a week but it would take a while to get deployed [05:04] poolie: Wow, you think there's a week's worth of work for the first stage of markdown? [05:04] 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:05] have there been any LEP/feature type things ever done in less than a week? [05:06] poolie: That's pretty depressing really [05:07] huwshimi: week(s) [05:07] lifeless: Ok, sure [05:07] lifeless: That also is very depressing [05:07] huwshimi: you need two schema changes (add field, index it). [05:07] 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 < https://launchpad.net/bugs/878140 > [05:07] huwshimi: then you need a job to walk things that need doing them and do it [05:08] could https://lp-oops.canonical.com/oops.py/?oopsid=2116INBOUNDEMAIL2 have come from that? [05:08] huwshimi: lastly you need the actual image resizing code itself (and I would make it a microservice for reusability) [05:09] lifeless: Ah, so writing the code wouldn't take a week or more, just the whole process? [05:10] huwshimi: yes [05:12] huwshimi: another option is to just serve the whole image and rely on the browser to resize them [05:12] for version 0 [05:12] lifeless: But maybe close to a week for the code? [05:12] poolie: see OopsHandler in the codebase. (short story -yes, warnings -> things we need to see -> OOPS) [05:12] i see, and it logs the last exception? [05:13] yes [05:14] poolie: We could, but that would mean loading some rather large images at times [05:14] yep [05:14] 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:15] 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] huwshimi: then for the index on the column, 4 hours for ec2, 4 hours for buildbot, then apply live [05:16] 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] 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:17] lifeless: ok so like https://code.launchpad.net/~mbp/launchpad/878140-dkim-nxdomain/+merge/80289 ? [05:17] 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] lifeless: So there's no window for actually getting it deployed [05:17] huwshimi: i think it depends a bit how much you want to learn how to write microservices in lp [05:17] etc [05:18] 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] poolie: Well I would want to do it in a useful way, I also don't want to over optimise [05:19] 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:20] 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:25] huwshimi: yes, its hard to find truely small-but-involves-learning things in LP [05:25] :( [05:25] lifeless: haha, yes [05:28] maybe we can quasi-pair on md? [05:28] lifeless: thanks for the review [05:29] would it be easy to add a test saying "this doesn't oops/warn"? [05:33] 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] 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:34] personally, I would hesitate to test this [05:34] poolie: I'm keen to help out if there's a way we can do that [05:35] are you going to uds (i'm not) [05:35] any test here is vulnerable to two forms of skew I think - the oopshandler config, and the actual exception raised. [05:35] perhaps we could spike it for a day or something , maybe next week [05:35] right [05:36] so you'd need to make sure you test deeply enough to insulate from that [05:36] i found it confusing the oops is unclear about whether the exception traceback indicates the program stopped at that point [05:36] to me it certainly does look like it stopped, but apparently it did not [05:36] a bug explaining the confusion would be good [05:37] I think its right to show the tb it did, but not to confuse you [05:37] a bug against which project? [05:37] poolie: No I'm not, I'd be keen for that [05:37] poolie: to start with LP, which is where OopsHandler is [05:38] poolie: and/or python-oops-tools which does the rendering [05:39] poolie: the emit() method on OopsHandler could usefully include the logging level in the message, and whether there was an exception attached [05:40] => cooking [05:43] 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 < https://launchpad.net/bugs/881243 > [05:53] Morning. [05:54] stub: You'll find this entertaining :) [05:54] http://thedailywtf.com/Articles/The-Query-of-Despair.aspx [05:55] nigelb: I just hope an ORM was involved or my remaining faith in humanity will dwindle. [05:56] "legacy" application. [05:56] I doubt if an ORM was involved. [06:57] Who knows about LP's mailing lists? Need help with this question: https://answers.launchpad.net/launchpad/+question/175718 [07:49] wgrant: 2704 lines [07:49] lifeless: :( [07:49] jtv: the mailing list archiver gets rather behind [07:50] lifeless: ? [07:50] 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] Ah, the question [07:50] yes :) [07:50] Thanks for looking into it. “Rather behind” doesn't really cover it in this case though. [07:50] jtv: days isn't uncommon. Its been weeks on occasion [07:50] IIRC the last archived message there was a year old. [07:51] jtv: ah! that may need checking by a losa then on the list in question - check that mailman hasn't blerched itself [07:51] jtv: There are probably logs you can poke at on carob to start with [07:51] Hmm [07:51] s/probably// [07:51] I'll try that, thanks. [07:52] the key thing to know is that mailman handles the mail and forwards it etc [07:52] 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:55] Any chance that it might even be a spam filter? [07:55] wgrant: it could be worse [07:55] wgrant: its mostly mechanical [07:55] jtv: I don't believe so; I would expect no-delivery to list members in that case [07:57] It's only known to be 4 days out of date. [07:57] 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] That's very much within mhonarc-is-slow-and-ubuntu-x-swat-is-huge-so-nevermind territory. [07:58] Indeed, October 21st is the first email since then. [07:58] http://www.mail-archive.com/nunit-dev@lists.launchpad.net/ [08:02] I wonder why the process-mail.log for the 21st seems to be binary garbage. [08:03] That sounds irrelevant. [08:03] mailman doesn't have anything named process-mail.log, AFAIK. [08:03] What are the relevant logs? [08:04] Hallo [08:04] All the mailman logs on forster. [08:06] good morning [08:06] hi mrevell, hi adeuring [08:06] hi jtv [08:06] wgrant: hasn't forster retired? [08:07] What gave you that idea? [08:07] I thought that was the server that loganberry replaced. [08:08] It was. === almaisan-away is now known as al-maisan [08:08] It is no longer the scripts server. [08:08] It continues to be the mailman server, however. [08:08] So I'm looking for scripts/forster/mailman-xmlrpc/ [08:08] No. [08:08] Well, probably not the xmlrpc bit. [08:08] xmlrpc is irrelevant here. [08:09] Okay, what other mailman logs are there? [08:09] The logs from mailman, which are probably somewhere. [08:09] mailman/forster [08:10] Ah, thanks. [08:11] Some timeouts there. === panta_ is now known as panta [08:30] wgrant: also, no more getLastOops [08:30] wgrant: more than makes up for size IMO :) [08:31] poolie: Hey, you guys had a circuit breaker thing for the "should make tea" bug right? [08:32] poolie: Can you link me to that bug if you have it handy? [08:32] bug 795321 [08:32] <_mup_> Bug #795321: udd importer should make tea while launchpad is down < https://launchpad.net/bugs/795321 > [08:32] poolie: Thanks! [08:32] I ended up needed something like this for work :D [08:32] are you going to use it somewhere else? [08:32] oh ok [08:33] Implementing it in bash is going to be loads of fun. [08:37] \o/ [09:26] mrevell, danhg, https://code.launchpad.net/~mbp/launchpad/jobs-link/+merge/80307 [09:26] lifeless: ? [09:27] there is a config setting to put stuff in the footer [09:27] I'd just set that directly on prod [09:27] Can't do links, though. [09:27] I don't think. [09:27] wgrant: I thought it was html it took [09:27] I hope not. [09:28] Anything that I see that takes HTML gets added to my hitlist. [09:29] are you referring to site_message? [09:29] i thought that was meant for "end of the world imminent" [09:29] s//eschaton [09:29] that would be too heavy for this, i think [09:29] all hail our future light cone [09:29] site_message is used on staging/qastaging/dogfood [09:29] To say that changes will be lost. [09:30] It used to be used on edge to say it was running pre-release code. [09:30] It was originally along the top of the page, but was demoted to the bottom for 3.0 [09:30] its tasteful but may not support a link [09:31] anyhow, I have no strong objection, it just seems like something better done in config than in code [09:31] iswym [09:31] otoh there's a fuzzy line between code and config [09:33] lifeless: i was actually wondering about your \hooray emoticon [09:33] was that for me? [09:34] Hi poolie: what am I looking at on that link? [09:34] ah welcome :) [09:34] danhg, We can talk about that on the phone now. It's your first merge proposal. [09:34] you can do your first code review [09:34] poolie: implementing circuit breaker in bash. [09:35] poolie: it was a little ironic [09:35] danhg: mostly if you talk it over with mr that's be good [09:35] don't be too rough on me :) [09:35] night all [09:36] ok [09:36] goodnight === jtv is now known as jtv-afk [09:42] zomg use-oops-twisted landed. [09:42] * lifeless dances the happy dance [09:49] wgrant: thanks for QAing 747558 for me - only just saw my bug mail. [09:51] 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:52] lifeless: The query was wrong. Not sure if that would make much of a difference, though. [09:52] wgrant: yah, table scans R us [09:53] bigjools: That was the ddeb thing? [09:54] Bug #747558 [09:54] <_mup_> Bug #747558: PPAs should create backtracable packages

< https://launchpad.net/bugs/747558 > [09:54] Right. [09:55] wgrant: did you test just the upload changes I made? [09:56] I need to add the copying safeguard and then it's probably ok to release [09:56] but I want to see it working on DF myself [09:56] bigjools: Yeah, I just built a package with some ddebs and checked that the overrides matched. [09:56] cool [09:56] where is it~? [09:56] Didn't try superseding, because I didn't want to sneak concordia away for too long. [09:57] https://dogfood.launchpad.net/~wgrant/+archive/dogfood/+packages <- aalib there [09:57] concordia is still on DF anyway [09:57] Needs process-accepted run, but I checked the BPR overrides in the DB. [09:57] running it === jtv-afk is now known as jtv === jtv is now known as jtv-afk [10:30] bigjools: lolcricket :D [10:30] * nigelb ducks [10:30] (_._) [10:31] hrm, what's that stand for? [10:31] Or should I not be asking :D [10:31] I was mooning you :) [10:31] ha [11:02] nigelb: still laughing? === jkakar_ is now known as jkakar [12:37] hi mrevell [12:38] hey bac [12:55] morning [12:58] Morning, all. [12:59] Morning deryck. === jtv-afk is now known as jtv [13:11] yo mrevell [13:13] allenap: how's that storm bug coming? [13:14] abentley: I've resolved most of the issues; only one very stubborn one remains. [13:15] allenap: oh dear. Anything I can help with? [13:17] 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:18] allenap: Okay. Good luck with it. [13:18] And now I'm not so sure! [13:25] allenap: I hate that. [14:11] flacoste: ping === 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 [14:57] flacoste, hi, I am Danilo from the Linaro team :) [14:59] 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

< https://launchpad.net/bugs/881144 > [14:59] 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) === al-maisan is now known as almaisan-away === beuno is now known as beuno-lunch [16:03] drat. no bigjools. [16:03] I wanted to poke fun at england's cricket team :D === deryck is now known as deryck[lunch] [17:12] * sinzui sends all spam to himself before sending to the user so that he shares their pain === beuno-lunch is now known as beuno [17:16] * sinzui plants face in palm [17:41] sinzui: If you shoot your self in the foot...and then complain... :P === salgado is now known as salgado-lunch [17:42] nigelb, My test went fine [17:42] But I left my name in one of the headers in the real send. [17:43] :) === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck === jcsackett__ is now known as jcsackett [19:53] sinzui: hi [19:53] Hi thumper [19:53] sinzui: how do I get project associations on the stakeholder list? [19:54]