[00:00] Ah, ls-lR is done in Python, not with run-parts, so we could parallelise that without too much work. [00:00] For values of "done in Python" including "Python that calls horrible self.executeShell", yes [00:01] Well, yes, but the stuff under run-parts is opaque to us. [00:01] So this is probably better :) [00:01] * cjwatson wishes this at least used the subprocess module, but there you go [00:02] Oh, it uses os.system!? [00:02] Ew. [00:02] This is brand new code, too. [00:02] Ah [00:02] This won't just load an external program and run it; the command [00:02] line goes through the full shell treatment including variable [00:02] substitutions, output redirections, and so on. [00:02] Not the best of justifications, but at least it's something. [00:03] The only real justification I can see is that it logs something you can copy and paste as shell, but given how little of Launchpad that applies to I don't think that's much of an excuse [00:03] It would probably be better for the caller to just do it itself using subprocess and kill that abstraction [00:04] Indeed. [00:05] Anyway; the ideal management-level justification for me would be if this work let us run the publisher every 30 minutes, or at least brought us substantively closer to that [00:05] Yep. [00:06] (Since the driver for this is Kate and Rick pointing out that the image build pipeline is much longer than it ought to be) [00:06] I think we'd get some runs in if we added a :32 run right now. But not all of them. [00:07] You would have got at most three extra runs from that today [00:07] There we go, much better logging now. [00:07] * wgrant watches. [00:07] Well, I suppose the publisher might have been a bit quicker with less to do, so maybe slightly more [00:08] We'll have some better numbers in 20 minutes :) [00:09] Yep, definitely more useful again now [00:18] hi all [00:18] lifeless: i posted a conceptual bmp diff spam suppression patch [00:18] - is it approximately right? [00:19] - should i bother persisting? i hate giving up, but sometimes things turn out not to be drive by [00:19] Oh, damn it all. The PersonFormatterAPI calls is_valid_person everytime [00:21] poolie: an actual fix no? [00:21] * StevenK waits for failfan to build [00:21] yes, this (tries to) make the job retry a bit later [00:22] so an actual fix along the lines we discussed [00:22] https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/79351 [00:23] thats grewat [00:23] I'm not really here today [00:23] ah yes, there we go, 3:01 for ls-lR [00:24] but if you haven't had a review tomorrow, I will look at it [00:24] ok [00:24] (I'm taking leave to help w/cynthia wednesdays, + was up @ 4am finishing amqp stuff [00:24] it's not passing its tests and it probably needs some new ones [00:24] that's good; that's bad :)- [00:24] I'm OCR, but poolie has invited me out to lunch and I have to leave in 5 minutes. [00:24] wgrant: so what time is this call ? [00:24] yeah i was just going to remind you [00:24] hooray for lunch [00:25] mwhudson: could you have a look at the diff in the last comment of https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/79351 [00:25] * StevenK looks up address [00:26] st leonards station [00:26] lifeless: When he gets back :) [00:26] walk out of the station (there's only one gate), look right, there it is [00:27] poolie: Right -- I was about to ask you. The address looked familiar so I was going to ask "That's the building the station is in, isn't it?" [00:27] yep [00:27] poolie: the diff doesn't trigger any particular thoughts in me [00:28] ok :) [00:28] poolie: i don't know if anything actually respects max_retries, but i'm very out of date there [00:30] ok [00:30] i might leave it for today [00:30] rebooting, biab [00:30] thanks anyhow [01:38] hi lifeless. Do you want to put mailman out of our misery? [01:38] It has been slow lately :( [01:38] mhonarc is not happy with ubuntu-x-swat. [01:38] I think we should disable it for that archive. [01:38] sinzui: I think we should do a detailed plan for front-ending it [01:39] sinzui: I think its a small project, done well, but I don't know enough of the ins and outs to predict WTF's [01:39] lifeless, you mean mhonarc? [01:40] lits. [01:40] lists. [01:40] lifeless, I can post my insane hack to the lp-dev list for everyone to ponder alternates. I think mustache make my insane json suggesting more palatable. [01:41] whats your insane hack ? [01:41] sinzui: I think there are multiple things to solve at once; we can call it 'refactoring to make it easy to do the intended work' :) [01:42] sinzui: slow archiving, poor branding and integration, poor privacy experience, private list archives being inaccessible [01:45] yes, those are all things that I thought could be solved by making mhonarc a json-encoded message server. I think we might also ask though is do we want a simpler mechanism to store and retrieve mbox message data? Messages could be places in a db, or we build a mbox server from other tools [01:46] AIUI generating the mboxes is cheap because you write to the end [01:46] I'd imagined that mailman would call an archive that injects the message into some kind of DB. [01:46] That isn't mbox. [01:46] wgrant: thats what mhonarc is, isn't it ? [01:46] wgrant: (in an SOA model) [01:46] Well, some kind of DB that doesn't then slowly generate static pages. [01:47] right, thats what the change to json is about [01:47] curtis and I have discussed this before [01:47] So it would generate static JSON instead? [01:47] I think the time is right to do it, rather than layering headaches on headaches, for lists. privacy [01:47] wgrant: yes, and stop the crazy rewriting of big lists [01:48] wgrant, yes, static fast data that the the Lp app can parse and linkify user and bugs [01:48] How do you plan to avoid rewriting but still generate static JSON? [01:48] but putting messages in a db is better for at least two use cases. Searching, and deleting/redacting messages [01:49] And cheapness of updating. [01:49] mhonarc has an excellent mechanism to resurrect and present confidential data to everyone [01:50] Indeed. [01:51] wgrant, I wasn't planning to avoid rewriting. mhonarc does a lot of re writing now because we have the indexes set to reverse. Once a list has more than a page of messages, adding a message causes a rewrite of all indexes and most message :) [01:51] Yes. [01:52] If it's in a DB with a service serving dynamic JSON, that problem goes away. [01:52] I was thinking of using natural indexes and letting lp reverse the MM index data [01:52] But my hack is predicated on keeping mhonarc, and writing embarrassing PERL. [01:53] wgrant: so, there are two orthogonal things [01:53] I would be happier keeping messages in something I could confidently hack and search. [01:53] wgrant: a) better interface for LP - LP templates, json backend etc. [01:53] wgrant: b) better archiver implementation - cassandra etc etc [01:54] wgrant: a) with mhonarc generating forward indices rather than reverse, + json -> will solve nearly all our performance and ops issues [01:54] wgrant: giving us time to do b), or even advocate for someone else to do it for us :) [01:54] sinzui: I'm very keen to contain scope [01:55] sinzui: I think search should be done by inserting into solr-or-similar and querying that from LP [01:55] lifeless, importing and exporting data has been a blocker for list adoption. Users cannot easily migrate to Lp, nor can we give them the data for analysis. I could not answer statiks questions about monthly list volume for example [01:55] sinzui: I presume mhonarc makes that hard? [01:55] It's db is a perl hash :) [01:55] sinzui: aka yes ;) [01:56] sinzui: do you agree that its better to do two projects than one: sort out the interface, then sort out the now-contained evil ? [01:58] lifeless, yes [01:58] sinzui: cool [01:59] sinzui: do you think sorting out the interface [switch to LP templates + jason backend, *perhaps* do something about mbox [e.g. store in librarian]] is a better way to tackle the privacy banner than e.g. copying templates onto the mhonarc install ? [01:59] (better meaning cheaper-over-all-including-cost-of-maintenance) [02:03] I think making mhonarc serve JSON via hack and teaching LP to retrieve the data provides a lot of options. Importing/exporting mboxes might be easier in Lp. I am just not certain. export is easier, but import is still hard because we need to register all the email addresses [02:04] lifeless, wgrant: my hack idea assumes I can always make proper JSON to describe the message. I think that means hacking in perl :) [02:05] I am sure someone has done that, but It also feels like the time I was asked to write a multiple-part post decoded in vb because ASP did not support it, when every modern web server tool kit does [02:06] sinzui: did you have minions^Wsquad members then ? [02:06] odd when I last work with perl I had minions. [02:09] lifeless, I think the answer might be to extend https://launchpad.net/mmm-archive-manager to do the serialisation task to minimise mhonarc's part in our victory [02:13] sinzui: perhaps that should be part of launchpad-project? [or is it personal? I dunno...] [02:14] sinzui: anyhow, extending that makes as much sense as anything to me [02:14] I wrote it on my own time and I believe it works with Ubuntu list archives too [02:15] I have no objection to how its done ... and don't know enough to seriously compare implementation approachs at this level [02:15] sinzui: before you halt() tonight, I wanted to talk about private teams [02:15] yes. I asked wgranta about that. I want to talk about it [02:16] when is good? [02:19] sinzui: [02:20] now if you like [02:21] cool! [02:21] skynet ? [02:22] skype? [02:22] yes [02:22] <- tired, so the pathetic sense of humour is rolled out :> [02:26] lifeless, are you ready to talk? [03:29] sinzui: Are you still around? [03:40] wgrant: Ahh, just thinking about it, does your obsolete hackage allow us to kill bug 740584? [03:40] <_mup_> Bug #740584: Build lacks a corresponding source publication < https://launchpad.net/bugs/740584 > === jtv changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 273 [05:02] wgrant: I'm off for food, but meanwhile, would appreciate your thoughts on this! http://paste.ubuntu.com/712840/ === jtv is now known as jtv-eat [05:04] jtv-eat: So, when I said that it should be refactored, it was meant to just be a first step. [05:04] But it was instead treated as the final step. [05:04] What we want to here is not defined. [05:04] And probably not possible in the current model. [05:04] s/to/to do/ [05:23] wgrant: Ahh, just thinking about it, does your obsolete hackage allow us to kill bug 740584? [05:23] <_mup_> Bug #740584: Build lacks a corresponding source publication < https://launchpad.net/bugs/740584 > [05:24] StevenK: No. [05:25] Will that destroy most of the problematic packages? [05:25] It will remove some files from disk. [05:25] It doesn't affect the builds not having publications, however. [05:25] wgrant: thanks for looking into this. Does your response mean that you found nothing wrong with my guesses that the problem is in notify() and that the unwanted recipient is the maintainer? [05:26] jtv-eat: I think that treating this as an isolated problem is probably missing a better solution [05:26] jtv-eat: We need to think about who actually wants failure notifications. [05:26] And then work out how to implement that. [05:26] I think it'll need some restructuring before we can do _anything_ with it. [05:26] Right. [05:26] As I said, StevenK's refactoring was meant to be a preliminary step in the DD build notification work. [05:26] But... well, we saw what happened :) [05:26] The current code seems fairly effective when it comes to obscuring the requirements. [05:27] It used to be far worse. [05:27] But yes. [05:32] * jtv-eat really goes off to eat === _mup__ is now known as _mup_ [05:39] does anyone know off hand how to ask lp if my credentials are still valid? [05:39] i guess just do any request [05:42] ... but not all of them seem to actually check it [05:44] poolie: Some may be cached? [05:45] no, apparently 'GET /1.0/' doesn't check the oauth tokens [05:45] s/tokens/stuff [05:45] is it a bug? [05:48] https://bugs.launchpad.net/launchpad/+bug/877913 - not urgent [05:48] <_mup_> Bug #877913: GET api.launchpad.net/1.0/ doesn't check OAuth validity < https://launchpad.net/bugs/877913 > [05:50] so the problem behind bug 877856 is partly that lp.distributions['debian'] does not cache the resulting object [05:50] <_mup_> Bug #877856: makes many pointless object reference api calls < https://launchpad.net/bugs/877856 > [05:50] seems like it could ; i don't know why not [05:54] wallyworld_: Do you happen to recall when the JS API client started returning Entrys instead of plain JSON dicts? [05:54] It caused bug #830676 [05:54] <_mup_> Bug #830676: PPA AJAX build status indicators don't update properly

< https://launchpad.net/bugs/830676 > [05:55] wgrant: not sure. it may have been before i first worked with any of that stuff, since i only recall it being Entry [05:56] wallyworld_: Let me just check the build history of our excellent, thorough JavaScript test suite. [05:56] wgrant: is this doing a patch from the client? [05:56] revno: 11451 [merge] [05:56] timestamp: Thu 2010-08-26 16:32:27 +0100 [05:56] message: [05:56] [r=jtv][ui=none][bug=308198][for=foxxtrot] Make Collection contain [05:56] proper Entry's. [05:56] Surely it hasn't been broken for a year... [05:57] that does seem right though, since as i said, it was always Entry when I looked at it [05:57] and i started in 08 last year [05:58] wgrant i was wondering if we should have some kind of semaphore to limit outstanding requests from jubany to lp [05:58] so we can ramp up the concurrent threads when they're busy doing non-lp work [05:59] poolie: That would probably be the right way to do things. === almaisan-away is now known as al-maisan [06:00] poolie: api.launchpad.net/1.0/ is served by Apache, at least for some Accept headers. [06:00] ah, for performance [06:01] so it's almost wontfix? [06:01] eg. the WADL is served at that URL with some obscene Content-Type, and that's direct from Apache. [06:01] I think so. [06:01] yeah, insane Vary header [06:01] and it's zope not apache that's checking oauth [06:02] Yep [06:06] wallyworld_: Ah, found it. [06:06] do tell [06:06] At least I think. [06:06] 13303.10.6 [06:06] Just over a month before the bug. [06:07] * wgrant tests. [06:07] at least that's not a year [06:07] Heh [06:08] Yep, that was it. [06:20] jtv-eat: Could you please review https://code.launchpad.net/~wgrant/launchpad/bug-830676/+merge/79772 upon your return? [06:21] perhaps i should actually change lplib to optionally return slightly stale objects from cache [06:21] not a lot of point having a cache otherwise [06:22] poolie: lplib objects are not cachable beyond deploys anyhow [06:23] I think caching beyond the freshness lifetime would likely lead to bugs - and a cache is plenty useful even if stale objects are never returned :) [06:23] to avoid transferring the body? [06:24] hm, what do you mean by 'freshness lifetime'? [06:24] I thought we must-revalidate [06:25] if you mean the http lifetime, then they do not seem to last even that long [06:25] wgrant, we don't actually send must-revalidate, but the behaviour is as if the application is always asking for it [06:25] Ah [06:26] basically what i'm saying is: i don't know if all applications want must-revalidate always on [06:26] perhaps if they fetched an object a second ago they'd be happy to get it back from cache === al-maisan is now known as almaisan-away [06:27] "publication.distro_series.name.lower()" does a round trip [06:27] headdesk [06:28] every time you call it [06:30] Ah, and jubany is in the DC, so instead of being hilariously slow it just DoSes us. [06:30] lolz. [06:31] to get back the string 'sid' or something of course [06:31] Yep [06:44] ok this is much better now [06:50] Excellent. [07:40] good morning [08:20] jtv-eat, hi, I wonder if you could take a look at https://code.launchpad.net/~danilo/launchpad/bug-817398/+merge/79571 when you are done eating, you'll probably like the branch (or at least, what's it fixing :)) === almaisan-away is now known as al-maisan [08:23] danilos: Heh, and so the hackish launchpad.Edit grows a third instance... [08:37] wgrant, yeah, I first started off with removeSecurityProxy in the buildd manager code, but that ain't any less hacky :) changing all the interfaces is even more fun, so I avoided that too === jtv-eat is now known as jtv === al-maisan is now known as almaisan-away [09:06] jtv, hey-hey, I hope food hasn't killed you :) === almaisan-away is now known as al-maisan [09:14] heh [09:46] danilos: hi, sorry, bit busy. Gotta do wgrant's first. [09:46] Mine's pretty tiny :) === al-maisan is now known as almaisan-away [10:37] I was just going to say how I've got another one in the queue for jtv === danilos changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: danilos (lunching) | Critical bugtasks: 273 [10:57] hah. Nice quote on topic :) [11:05] nigelb: although it could be misconstrued in *so* many ways [11:05] easy to shoot your foot... check [11:06] preferred choice of terrorists... check [11:06] bigjools: I was actually thinking about "easy to shoot your foot" myself :) [11:27] danilos: I have a short-ish branch for your pleasure when you get back from lunch, TIA. === almaisan-away is now known as al-maisan === danilos changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: danilos (lunching) | Critical bugtasks: 273 [11:42] bigjools, "short-ish"? you mean just a bit over 600 lines? :) === danilos changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: danilos | Critical bugtasks: 273 [11:48] bigjools, does "overriding" ddebs mean they will end up in the PPA directly? if so, will that affect allocated storage space? [11:56] bigjools, fwiw, the branch is good as it is, i.e. it looks like it does the "overriding" of pocket/section/blah-blah well, and the tests "prove" it; the question above remains mostly for my own curiosity === jtv is now known as jtv-afk [12:34] danilos: hi, back from lunch myself [12:34] danilos: overriding means that the component/section/priority is set [12:35] bigjools, so nothing but that? (otp, btw) [12:35] the ddebs need to be in lockstep with the debs like that, otherwise they won't get superseded properly [12:35] noep [12:35] nope, even [12:35] ok, cool, thanks [12:35] np [12:35] thanks for the review [12:35] yw [13:08] Morning, all. [13:10] morning deryck [13:11] danilos: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/custom-bugs-listings-search-form-tweaks/+merge/79812 ? [13:16] wallyworld_, hi, I reviewed https://code.launchpad.net/~wallyworld/launchpad/delete-bugtasks-1324/+merge/79541 and have a few questions in the MP; if you don't understand something, please let me know [13:17] danilos: thanks, will look [13:17] adeuring, sure, would you like to return the favour by looking at https://code.launchpad.net/~danilo/launchpad/bug-877179/+merge/79781? :P (no diff either, that seems broken :/) [13:17] danilos: sure, I'll look [13:18] adeuring, I'll also grant you the "last review Danilo will officially do as OCR" title, fwiw :) [13:18] ;) === danilos changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 273 [13:21] danilos: fair point about admin. i think that should be added. the store.flush() is definitely required for tests to ensure flags passed into the constructor are visible. for prod, i don't think it's needed but as you say, likely not an issue [13:22] the feature flag in the permission check - i'm not sure where else to put it. i'll need to think about it [13:23] wallyworld_, well, generally one would put it around the code that is feature flagged; i.e. in delete method instead, instead of failing with Unauthorized, it could fail with IAmNotAMethodYouMustBeDrunk() exception or something :) [13:24] danilos: sure. i understood the requirements to be that if the fflag were not on, it was to be treated as 'unauthorised' hence the implementation [13:25] ok, maybe a NotImplementedError, but I ain't sure really what's the "right thing" to do, I just dislike this ;) if you can't come up with anything nice, just leave it as is [13:25] (though, I like the YouMustBeDrunk exception for this) [13:26] wallyworld_, if those were the requirements, then fine, keep it as is (I don't like the requirements, but hey, life is tough) [13:26] :-) np. it's definitely a fair question. also, with the tests and the fflag stuff, the fflag will be going away (soon hopefully) hence i thought it ok to "double up" so to speak [13:26] i'll confirm the requirements in case i have misunderstood [13:26] which is not unprecedented :-) [13:27] i do like your suggested exception class :-) [13:28] i've had a few glasses of wine so am already half way there :-D [13:28] wallyworld_, as for tests, sure, keep them as is, but don't forget to remove the feature flags then :) [13:28] will do :-) i'm about to remove all the feature flags for the picker enhancements \o/ [13:29] wallyworld_, cool, great to hear that! [13:29] :-) [13:30] i'll think about tests for conjoined bugtasks [13:30] thanks [13:30] wallyworld_, sorry for being such a PITA, but you got to know me already :) [13:30] a pre impl talk showed the code base doesn't really place any significance on them though [13:30] no, not a pita. i really appreciate the input [13:31] wallyworld_, yeah, if so, then ignore me on that point, I just wanted some confirmation (you did mention the pre-imp with lifeless in the MP I believe) [13:31] shows you have taken the time to think about the code [13:32] or that I am good at coming up with things which resemble arguments about code, yes [13:32] i talked with wgrant about the conjoined tasks in particular. he showed me how the gui/code now doesn;t care if a conjoined master/slave is there or not [13:33] wallyworld_, ah right, lifeless raised the issue, you talked it over with wgrant, which means you are pretty well covered :) [13:33] i would prefer to be challenged rather than a simple +1. that's the best way to avoid base code :-) [13:33] s/base/bad [13:34] yeah, if those guys make a mistake, it's pretty rare :-) [13:34] i'll add a note to the mp so that sinzui can see what we discussed when he looks at it [13:38] hey benji, I decided to sit down and fix that keyring corruption thing in launchpadlib, and blow me if it's not happening any more .... ! [13:39] you can't make this stuff up [13:39] bigjools: heh, that's life for you [13:40] benji: I'm trying to work out exactly what the keyring was doing to the credential string in the first place. Maybe it was a bug in the kwallet and it's now fixed. Hmph. [13:42] danhg is here and rockin' like Dokken [13:42] I sure am [13:43] Dokken... not heard them for ages [13:44] * bigjools welcomes danhg to the public channel too [13:44] Hey danhg! [13:48] Hello! danhg [13:53] welcome danhg [14:02] allenap, ping [14:02] deryck: pong [14:03] allenap, hey man! :) Did I hear correctly that you're looking into the ssh errors with test runs, that are supposed to be avoidable on Natty? [14:04] deryck: Not ssh errors, but database errors. Are you getting ssh errors too? Gulp. [14:04] deryck: The problem I'm working on is that some disconnections are not being detected as such and are bubbling up. [14:04] allenap, oh, sorry, no. I thought that's what they were. abentley is blocked running tests locally with these errors, I believe. [14:05] abentley, what allenap reports there is what you're seeing? [14:05] deryck: I'm waiting on reviews from Storm people. I'll go and hussle for them now. [14:05] allenap, thanks! abentley is seeing this on Natty, too, so he's completely blocked landing some stuff. [14:06] assuming we're talking about the same issue :) [14:06] deryck: I've heard that the problem does not manifest in ec2, and mbp said tests run fine in a Lucid schroot. The latter only takes a few minutes to get set-up. [14:07] So that's a workaround for now. [14:07] ah, that's nice. [14:07] danilos: r=me [14:07] abentley, ^^ Lucid schroot FTW? :) [14:08] adeuring, thanks, I am still on yours (sorry for taking so long, had a call in the meantime) [14:08] danilos: np [14:13] deryck, allenap: I am experiencing the SSL connection has been closed unexpectedly [14:14] I knew there was an "ss" in there :) [14:14] abentley: Yes, that's the badger. [14:16] abentley, deryck: I'm sorry a fix has taken so long to be ready. Mainly it's been hard to replicate in tests, and I'm now blocked on reviews. [14:16] deryck: I have natty and maverick vms. I haven't been using schroots. [14:19] deryck: I suspect that it was broken by recent changes to launchpad-dependencies. I can try my maverick vm without upgrading, but having stale packages can itself be a problem. [14:21] danI just noticed that the cover letter was quite nonsensical. I added a hopefully better readable comment... [14:29] adeuring, yeah, I kind of read it as random notes you were making for yourself, so other than figuring roughly what the branch is about, I didn't rely on them too much :) [14:29] adeuring, anyway, r=me with a few superficial comments :) [14:29] danilos: thanks! [14:29] adeuring, btw, you can edit the MP as well, fwiw :) [14:29] adeuring, (no need to add a comment) [14:30] danilos: ah, right! next time, then ;) [14:32] adeuring, and then nobody can tell ;) [14:32] ;) [14:49] deryck: This branch has sorting, ajax and caching enabled: lp:~abentley/launchpad/cache-batches [14:49] deryck: If you branch off it, please merge only it, not devel, to avoid criss-cross merges. [14:50] wallyworld_, btw, I don't think the way you introduced security adapter is sufficient: in my reading, it modifies the launchpad.Admin privilege for BugTask to match the launchpad.Delete privilege, but does not really allow admins to do the delete [14:52] wallyworld_, your test is not really testing what I thought it should (i.e. log in as admin@canonical.com and not someone holding a contextual launchpad.Admin permission [like target owner]) [14:52] wallyworld_, (or better yet, login_celebrity('admin')) [14:58] deryck: maverick had bugs related to pgbouncer files being missing. Trying a schroot now... [15:03] abentley, ok, cool. === abentley changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 273 === beuno is now known as beuno-lunch === al-maisan is now known as almaisan-away [15:47] deryck: lucid schroot seems like a rather awful option, as it leaves me with the encrypted version of my home directory, and will have port conflicts with my system daemons. [15:56] abentley, hmm, yeah, yuck. I'm not a schrod user so don't have much to offer in advice. [15:57] schroot even :) === deryck is now known as deryck[lunch] === matsubara is now known as matsubara-lunch [16:30] bigjools: about bug 877122, the API syncing was a new feature, but it used to be that all packages had debdiffs and now they don't, so wouldn't that be a regression? [16:30] <_mup_> Bug #877122: Packages synced through the API are not producing debdiffs < https://launchpad.net/bugs/877122 > [16:32] micahg: it's not a regression if this feature never had that :) The old syncing did it of course. I have scheduled it to be fixed soon tjough, don't worry [16:32] though* [16:34] bigjools: ok, it is a regression in functionality for Ubuntu though, thanks for getting it scheduled === beuno-lunch is now known as beuno === deryck[lunch] is now known as deryck === matsubara-lunch is now known as matsubara [18:14] hey guys, when do things fixed in launchpad stable, show up on production? [18:36] dobey: http://lpqateam.canonical.com/qa-reports/deployment-stable.html [18:37] ah, interesting. thanks maxb [18:40] dobey: IIUC, once something goes green there, the remaining steps are for someone on the Launchpad team to ask for a deployment to happen, and for it to be actioned by losas - so fairly soon, subject to working days, etc. [18:42] maxb: sure. just wondering when my bug will be fixed in production since jtv's branch landed :) [18:48] mpt: an observation: your 'what should happen' entries in bugs are very close to 'shoulds' [18:49] lifeless, they are. It's the describing the problem first that's the important thing. :-) [18:49] Maybe I could use "What I expected:" instead [18:51] mpt: Or 'one way I would not have been surprised:' :) [18:52] mpt: I guess my point is to open the solution space out [19:26] I suppose folks know that launchpad login service is unhappy? [19:26] org.openid4java.discovery.yadis.YadisException: 0x706: GET failed on https://login.launchpad.net/+openid : 503:HTTP/1.1 503 Service Unavailable [19:30] mtaylor: grah. Thats login.ubuntu.com. I'll go poke folk === almaisan-away is now known as al-maisan [19:34] mtaylor: fixed [19:34] mtaylor: sso is having some flakiness issues this week [19:34] lifeless: ++ [19:34] mtaylor: its escalated but not understood yet [19:34] (theories abound, proof is tricky) [19:38] lifeless: distributed systems are hard [19:38] lifeless: btw - it's still broken [19:39] lifeless: https://jenkins.openstack.org [19:39] mbarnett: ^ [19:39] mbarnett: ah you know, nvm [19:39] mtaylor: cascading trouble [19:40] yay! [19:40] * mtaylor loves trouble [20:16] * mbarnett doesn't always break things, but when he does he breaks them all. === abentley changed the topic of #launchpad-dev to: Launchpad should be engineered like an AK-47 | Performance Tuesday! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 273 === al-maisan is now known as almaisan-away [21:15] hi people [21:16] I'm looking for a "stock" presentation for "intro to launchpad" [21:16] is there one around somewhere? [21:16] We have a growing team, and some don't really understand launchpad, so I'm doing a presentation next week to cover the basics [21:30] in unrelated news, launchpad's roles for managing (in various senses) projects make no sense to anyone