wgrantAh, ls-lR is done in Python, not with run-parts, so we could parallelise that without too much work.00:00
cjwatsonFor values of "done in Python" including "Python that calls horrible self.executeShell", yes00:00
wgrantWell, yes, but the stuff under run-parts is opaque to us.00:01
wgrantSo this is probably better :)00:01
* cjwatson wishes this at least used the subprocess module, but there you go00:01
wgrantOh, it uses os.system!?00:02
wgrantThis is brand new code, too.00:02
wgrant        This won't just load an external program and run it; the command00:02
wgrant        line goes through the full shell treatment including variable00:02
wgrant        substitutions, output redirections, and so on.00:02
wgrantNot the best of justifications, but at least it's something.00:02
cjwatsonThe 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 excuse00:03
cjwatsonIt would probably be better for the caller to just do it itself using subprocess and kill that abstraction00:03
cjwatsonAnyway; 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 that00:05
cjwatson(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
wgrantI think we'd get some runs in if we added a :32 run right now. But not all of them.00:06
cjwatsonYou would have got at most three extra runs from that today00:07
wgrantThere we go, much better logging now.00:07
* wgrant watches.00:07
cjwatsonWell, I suppose the publisher might have been a bit quicker with less to do, so maybe slightly more00:07
wgrantWe'll have some better numbers in 20 minutes :)00:08
cjwatsonYep, definitely more useful again now00:09
pooliehi all00:18
poolielifeless: i posted a conceptual bmp diff spam suppression patch00:18
poolie- is it approximately right?00:18
poolie- should i bother persisting? i hate giving up, but sometimes things turn out not to be drive by00:19
StevenKOh, damn it all. The PersonFormatterAPI calls is_valid_person everytime00:19
lifelesspoolie: an actual fix no?00:21
* StevenK waits for failfan to build00:21
poolieyes, this (tries to) make the job retry a bit later00:21
poolieso an actual fix along the lines we discussed00:22
lifelessthats grewat00:23
lifelessI'm not really here today00:23
cjwatsonah yes, there we go, 3:01 for ls-lR00:23
lifelessbut if you haven't had a review tomorrow, I will look at it00:24
lifeless(I'm taking leave to help w/cynthia wednesdays, + was up @ 4am finishing amqp stuff00:24
poolieit's not passing its tests and it probably needs some new ones00:24
pooliethat's good; that's bad :)-00:24
StevenKI'm OCR, but poolie has invited me out to lunch and I have to leave in 5 minutes.00:24
lifelesswgrant: so what time is this call ?00:24
poolieyeah i was just going to remind you00:24
pooliehooray for lunch00:24
pooliemwhudson: could you have a look at the diff in the last comment of https://code.launchpad.net/~mbp/launchpad/612171-diff-generation-spam/+merge/7935100:25
* StevenK looks up address00:25
pooliest leonards station00:26
wgrantlifeless: When he gets back :)00:26
pooliewalk out of the station (there's only one gate), look right, there it is00:26
StevenKpoolie: 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
mwhudsonpoolie: the diff doesn't trigger any particular thoughts in me00:27
poolieok :)00:28
mwhudsonpoolie: i don't know if anything actually respects max_retries, but i'm very out of date there00:28
pooliei might leave it for today00:30
poolierebooting, biab00:30
pooliethanks anyhow00:30
sinzuihi lifeless. Do you want to put mailman out of our misery?01:38
wgrantIt has been slow lately :(01:38
wgrantmhonarc is not happy with ubuntu-x-swat.01:38
wgrantI think we should disable it for that archive.01:38
lifelesssinzui: I think we should do a detailed plan for front-ending it01:38
lifelesssinzui: I think its a small project, done well, but I don't know enough of the ins and outs to predict WTF's01:39
sinzuilifeless, you mean mhonarc?01:39
sinzuilifeless, 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:40
lifelesswhats your insane hack ?01:41
lifelesssinzui: 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:41
lifelesssinzui: slow archiving, poor branding and integration, poor privacy experience, private list archives being inaccessible01:42
sinzuiyes, 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 tools01:45
lifelessAIUI generating the mboxes is cheap because you write to the end01:46
wgrantI'd imagined that mailman would call an archive that injects the message into some kind of DB.01:46
wgrantThat isn't mbox.01:46
lifelesswgrant: thats what mhonarc is, isn't it ?01:46
lifelesswgrant: (in an SOA model)01:46
wgrantWell, some kind of DB that doesn't then slowly generate static pages.01:46
lifelessright, thats what the change to json is about01:47
lifelesscurtis and I have discussed this before01:47
wgrantSo it would generate static JSON instead?01:47
lifelessI think the time is right to do it, rather than layering headaches on headaches, for lists. privacy01:47
lifelesswgrant: yes, and stop the crazy rewriting of big lists01:47
sinzuiwgrant, yes, static fast data that the the Lp app can parse and linkify user and bugs01:48
wgrantHow do you plan to avoid rewriting but still generate static JSON?01:48
sinzuibut putting messages in a db is better for at least  two use cases. Searching, and deleting/redacting messages01:48
wgrantAnd cheapness of updating.01:49
sinzuimhonarc has an excellent mechanism to resurrect and present confidential data to everyone01:49
sinzuiwgrant, 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
wgrantIf it's in a DB with a service serving dynamic JSON, that problem goes away.01:52
sinzuiI was thinking of using natural indexes and letting lp reverse the MM index data01:52
sinzuiBut my hack is predicated on keeping mhonarc, and writing embarrassing PERL.01:52
lifelesswgrant: so, there are two orthogonal things01:53
sinzuiI would be happier keeping messages in something I could confidently hack and search.01:53
lifelesswgrant: a) better interface for LP - LP templates, json backend etc.01:53
lifelesswgrant: b) better archiver implementation - cassandra etc etc01:53
lifelesswgrant: a) with mhonarc generating forward indices rather than reverse, + json -> will solve nearly all our performance and ops issues01:54
lifelesswgrant: giving us time to do b), or even advocate for someone else to do it for us :)01:54
lifelesssinzui: I'm very keen to contain scope01:54
lifelesssinzui: I think search should be done by inserting into solr-or-similar and querying that from LP01:55
sinzuilifeless, 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 example01:55
lifelesssinzui: I presume mhonarc makes that hard?01:55
sinzuiIt's db is a perl hash :)01:55
lifelesssinzui: aka yes ;)01:55
lifelesssinzui: do you agree that its better to do two projects than one: sort out the interface, then sort out the now-contained evil ?01:56
sinzuilifeless, yes01:58
lifelesssinzui: cool01:58
lifelesssinzui: 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
lifeless(better meaning cheaper-over-all-including-cost-of-maintenance)01:59
sinzuiI 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 addresses02:03
sinzuilifeless, wgrant: my hack idea assumes I can always make proper JSON to describe the message. I think that means hacking in perl :)02:04
sinzuiI 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 does02:05
lifelesssinzui: did you have minions^Wsquad members then ?02:06
sinzuiodd when I last work with perl I had minions.02:06
sinzuilifeless, 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 victory02:09
lifelesssinzui: perhaps that should be part of launchpad-project? [or is it personal? I dunno...]02:13
lifelesssinzui: anyhow, extending that makes as much sense as anything to me02:14
sinzuiI wrote it on my own time and I believe it works with Ubuntu list archives too02:14
lifelessI have no objection to how its done ... and don't know enough to seriously compare implementation approachs at this level02:15
lifelesssinzui: before you halt() tonight, I wanted to talk about private teams02:15
sinzuiyes. I asked wgranta about that. I want to talk about it02:15
lifelesswhen is good?02:16
sinzuinow if you like02:20
lifelessskynet ?02:21
lifeless<- tired, so the pathetic sense of humour is rolled out :>02:22
sinzuilifeless, are you ready to talk?02:26
StevenKsinzui: Are you still around?03:29
StevenKwgrant: 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 <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740584 >03:40
=== 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
jtvwgrant: I'm off for food, but meanwhile, would appreciate your thoughts on this!  http://paste.ubuntu.com/712840/05:02
=== jtv is now known as jtv-eat
wgrantjtv-eat: So, when I said that it should be refactored, it was meant to just be a first step.05:04
wgrantBut it was instead treated as the final step.05:04
wgrantWhat we want to here is not defined.05:04
wgrantAnd probably not possible in the current model.05:04
wgrants/to/to do/05:04
StevenKwgrant: 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 <oops> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/740584 >05:23
wgrantStevenK: No.05:24
StevenKWill that destroy most of the problematic packages?05:25
wgrantIt will remove some files from disk.05:25
wgrantIt doesn't affect the builds not having publications, however.05:25
jtv-eatwgrant: 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:25
wgrantjtv-eat: I think that treating this as an isolated problem is probably missing a better solution05:26
wgrantjtv-eat: We need to think about who actually wants failure notifications.05:26
wgrantAnd then work out how to implement that.05:26
jtv-eatI think it'll need some restructuring before we can do _anything_ with it.05:26
wgrantAs I said, StevenK's refactoring was meant to be a preliminary step in the DD build notification work.05:26
wgrantBut... well, we saw what happened :)05:26
jtv-eatThe current code seems fairly effective when it comes to obscuring the requirements.05:26
wgrantIt used to be far worse.05:27
wgrantBut yes.05:27
* jtv-eat really goes off to eat05:32
=== _mup__ is now known as _mup_
pooliedoes anyone know off hand how to ask lp if my credentials are still valid?05:39
pooliei guess just do any request05:39
poolie... but not all of them seem to actually check it05:42
wgrantpoolie: Some may be cached?05:44
poolieno, apparently 'GET /1.0/' doesn't check the oauth tokens05:45
poolieis it a bug?05:45
pooliehttps://bugs.launchpad.net/launchpad/+bug/877913 - not urgent05:48
_mup_Bug #877913: GET api.launchpad.net/1.0/ doesn't check OAuth validity <api> <oauth> <Launchpad itself:Triaged> < https://launchpad.net/bugs/877913 >05:48
poolieso the problem behind bug 877856 is partly that lp.distributions['debian'] does not cache the resulting object05:50
_mup_Bug #877856: makes many pointless object reference api calls <Ubuntu Distributed Development:In Progress by mbp> < https://launchpad.net/bugs/877856 >05:50
poolieseems like it could ; i don't know why not05:50
wgrantwallyworld_: Do you happen to recall when the JS API client started returning Entrys instead of plain JSON dicts?05:54
wgrantIt caused bug #83067605:54
_mup_Bug #830676: PPA AJAX build status indicators don't update properly <buildd-manager> <critical-analysis> <ppa> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/830676 >05:54
wallyworld_wgrant: not sure. it may have been before i first worked with any of that stuff, since i only recall it being Entry05:55
wgrantwallyworld_: Let me just check the build history of our excellent, thorough JavaScript test suite.05:56
wallyworld_wgrant: is this doing a patch from the client?05:56
wgrantrevno: 11451 [merge]05:56
wgranttimestamp: Thu 2010-08-26 16:32:27 +010005:56
wgrant  [r=jtv][ui=none][bug=308198][for=foxxtrot] Make Collection contain05:56
wgrant        proper Entry's.05:56
wgrantSurely it hasn't been broken for a year...05:56
wallyworld_that does seem right though, since as i said, it was always Entry when I looked at it05:57
wallyworld_and i started in 08 last year05:57
pooliewgrant i was wondering if we should have some kind of semaphore to limit outstanding requests from jubany to lp05:58
poolieso we can ramp up the concurrent threads when they're busy doing non-lp work05:58
wgrantpoolie: That would probably be the right way to do things.05:59
=== almaisan-away is now known as al-maisan
wgrantpoolie: api.launchpad.net/1.0/ is served by Apache, at least for some Accept headers.06:00
poolieah, for performance06:00
poolieso it's almost wontfix?06:01
wgranteg. the WADL is served at that URL with some obscene Content-Type, and that's direct from Apache.06:01
wgrantI think so.06:01
poolieyeah, insane Vary header06:01
poolieand it's zope not apache that's checking oauth06:01
wgrantwallyworld_: Ah, found it.06:06
wallyworld_do tell06:06
wgrantAt least I think.06:06
wgrantJust over a month before the bug.06:06
* wgrant tests.06:07
wallyworld_at least that's not a year06:07
wgrantYep, that was it.06:08
wgrantjtv-eat: Could you please review https://code.launchpad.net/~wgrant/launchpad/bug-830676/+merge/79772 upon your return?06:20
poolieperhaps i should actually change lplib to optionally return slightly stale objects from cache06:21
poolienot a lot of point having a cache otherwise06:21
lifelesspoolie: lplib objects are not cachable beyond deploys anyhow06:22
lifelessI 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
poolieto avoid transferring the body?06:23
pooliehm, what do you mean by 'freshness lifetime'?06:24
wgrantI thought we must-revalidate06:24
poolieif you mean the http lifetime, then they do not seem to last even that long06:25
pooliewgrant, we don't actually send must-revalidate, but the behaviour is as if the application is always asking for it06:25
pooliebasically what i'm saying is: i don't know if all applications want must-revalidate always on06:26
poolieperhaps if they fetched an object a second ago they'd be happy to get it back from cache06:26
=== al-maisan is now known as almaisan-away
poolie"publication.distro_series.name.lower()" does a round trip06:27
poolieevery time you call it06:28
wgrantAh, and jubany is in the DC, so instead of being hilariously slow it just DoSes us.06:30
poolieto get back the string 'sid' or something of course06:31
poolieok this is much better now06:44
adeuringgood morning07:40
danilosjtv-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 :))08:20
=== almaisan-away is now known as al-maisan
wgrantdanilos: Heh, and so the hackish launchpad.Edit grows a third instance...08:23
daniloswgrant, 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 too08:37
=== jtv-eat is now known as jtv
=== al-maisan is now known as almaisan-away
danilosjtv, hey-hey, I hope food hasn't killed you :)09:06
=== almaisan-away is now known as al-maisan
jtvdanilos: hi, sorry, bit busy.  Gotta do wgrant's first.09:46
wgrantMine's pretty tiny :)09:46
=== al-maisan is now known as almaisan-away
danilosI was just going to say how I've got another one in the queue for jtv10:37
=== 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
nigelbhah. Nice quote on topic :)10:57
bigjoolsnigelb: although it could be misconstrued in *so* many ways11:05
bigjoolseasy to shoot your foot... check11:05
bigjoolspreferred choice of terrorists... check11:06
nigelbbigjools: I was actually thinking about "easy to shoot your foot" myself :)11:06
bigjoolsdanilos: I have a short-ish branch for your pleasure when you get back from lunch, TIA.11:27
=== 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
danilosbigjools, "short-ish"? you mean just a bit over 600 lines? :)11:42
=== 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
danilosbigjools, does "overriding" ddebs mean they will end up in the PPA directly? if so, will that affect allocated storage space?11:48
danilosbigjools, 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 curiosity11:56
=== jtv is now known as jtv-afk
bigjoolsdanilos: hi, back from lunch myself12:34
bigjoolsdanilos: overriding means that the component/section/priority is set12:34
danilosbigjools, so nothing but that? (otp, btw)12:35
bigjoolsthe ddebs need to be in lockstep with the debs like that, otherwise they won't get superseded properly12:35
bigjoolsnope, even12:35
danilosok, cool, thanks12:35
bigjoolsthanks for the review12:35
deryckMorning, all.13:08
adeuringmorning deryck13:10
adeuringdanilos: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/custom-bugs-listings-search-form-tweaks/+merge/79812 ?13:11
daniloswallyworld_, 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 know13:16
wallyworld_danilos: thanks, will look13:17
danilosadeuring, 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
adeuringdanilos: sure, I'll look13:17
danilosadeuring, 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
wallyworld_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 issue13:21
wallyworld_the feature flag in the permission check - i'm not sure where else to put it. i'll need to think about it13:22
daniloswallyworld_, 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:23
wallyworld_danilos: sure. i understood the requirements to be that if the fflag were not on, it was to be treated as 'unauthorised' hence the implementation13:24
danilosok, 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 is13:25
danilos(though, I like the YouMustBeDrunk exception for this)13:25
daniloswallyworld_, if those were the requirements, then fine, keep it as is (I don't like the requirements, but hey, life is tough)13:26
wallyworld_:-) 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 speak13:26
wallyworld_i'll confirm the requirements in case i have misunderstood13:26
wallyworld_which is not unprecedented :-)13:26
wallyworld_i do like your suggested exception class :-)13:27
wallyworld_i've had a few glasses of wine so am already half way there :-D13:28
daniloswallyworld_, as for tests, sure, keep them as is, but don't forget to remove the feature flags then :)13:28
wallyworld_will do :-) i'm about to remove all the feature flags for the picker enhancements \o/13:28
daniloswallyworld_, cool, great to hear that!13:29
wallyworld_i'll think about tests for conjoined bugtasks13:30
daniloswallyworld_, sorry for being such a PITA, but you got to know me already :)13:30
wallyworld_a pre impl talk showed the code base doesn't really place any significance on them though13:30
wallyworld_no, not a pita. i really appreciate the input13:30
daniloswallyworld_, 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
wallyworld_shows you have taken the time to think about the code13:31
danilosor that I am good at coming up with things which resemble arguments about code, yes13:32
wallyworld_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  not13:32
daniloswallyworld_, ah right, lifeless raised the issue, you talked it over with wgrant, which means you are pretty well covered :)13:33
wallyworld_i would prefer to be challenged rather than a simple +1. that's the best way to avoid base code :-)13:33
wallyworld_yeah, if those guys make a mistake, it's pretty rare :-)13:34
wallyworld_i'll add a note to the mp so that sinzui can see what we discussed when he looks at it13:34
bigjoolshey 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:38
bigjoolsyou can't make this stuff up13:39
benjibigjools: heh, that's life for you13:39
bigjoolsbenji: 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:40
mrevelldanhg is here and rockin' like Dokken13:42
danhgI sure am13:42
bigjoolsDokken... not heard them for ages13:43
* bigjools welcomes danhg to the public channel too13:44
rvbaHey danhg!13:44
nigelbHello! danhg13:48
james_wwelcome danhg13:53
deryckallenap, ping14:02
allenapderyck: pong14:02
deryckallenap, 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:03
allenapderyck: Not ssh errors, but database errors. Are you getting ssh errors too? Gulp.14:04
allenapderyck: The problem I'm working on is that some disconnections are not being detected as such and are bubbling up.14:04
deryckallenap, oh, sorry, no.  I thought that's what they were.  abentley is blocked running tests locally with these errors, I believe.14:04
deryckabentley, what allenap reports there is what you're seeing?14:05
allenapderyck: I'm waiting on reviews from Storm people. I'll go and hussle for them now.14:05
deryckallenap, thanks!  abentley is seeing this on Natty, too, so he's completely blocked landing some stuff.14:05
deryckassuming we're talking about the same issue :)14:06
allenapderyck: 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:06
allenapSo that's a workaround for now.14:07
deryckah, that's nice.14:07
adeuringdanilos: r=me14:07
deryckabentley, ^^ Lucid schroot FTW? :)14:07
danilosadeuring, thanks, I am still on yours (sorry for taking so long, had a call in the meantime)14:08
adeuringdanilos: np14:08
abentleyderyck, allenap: I am experiencing the SSL connection has been closed unexpectedly14:13
deryckI knew there was an "ss" in there :)14:14
allenapabentley: Yes, that's the badger.14:14
allenapabentley, 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
abentleyderyck: I have natty and maverick vms.  I haven't been using schroots.14:16
abentleyderyck: 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:19
adeuringdanI just noticed that the cover letter was quite nonsensical. I added a hopefully better readable comment...14:21
danilosadeuring, 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
danilosadeuring, anyway, r=me with a few superficial comments :)14:29
adeuringdanilos: thanks!14:29
danilosadeuring, btw, you can edit the MP as well, fwiw :)14:29
danilosadeuring, (no need to add a comment)14:29
adeuringdanilos: ah, right! next time, then ;)14:30
danilosadeuring, and then nobody can tell ;)14:32
abentleyderyck: This branch has sorting, ajax and caching enabled: lp:~abentley/launchpad/cache-batches14:49
abentleyderyck: If you branch off it, please merge only it, not devel, to avoid criss-cross merges.14:49
daniloswallyworld_, 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 delete14:50
daniloswallyworld_, 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
daniloswallyworld_, (or better yet, login_celebrity('admin'))14:52
abentleyderyck: maverick had bugs related to pgbouncer files being missing.  Trying a schroot now...14:58
deryckabentley, ok, cool.15:03
=== 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
abentleyderyck: 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:47
deryckabentley, hmm, yeah, yuck.  I'm not a schrod user so don't have much to offer in advice.15:56
deryckschroot even :)15:57
=== deryck is now known as deryck[lunch]
=== matsubara is now known as matsubara-lunch
micahgbigjools: 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 <derivation> <Launchpad itself:Triaged by redsquad> < https://launchpad.net/bugs/877122 >16:30
bigjoolsmicahg: 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 worry16:32
micahgbigjools: ok, it is a regression in functionality for Ubuntu though, thanks for getting it scheduled16:34
=== beuno-lunch is now known as beuno
=== deryck[lunch] is now known as deryck
=== matsubara-lunch is now known as matsubara
dobeyhey guys, when do things fixed in launchpad stable, show up on production?18:14
maxbdobey: http://lpqateam.canonical.com/qa-reports/deployment-stable.html18:36
dobeyah, interesting. thanks maxb18:37
maxbdobey: 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:40
dobeymaxb: sure. just wondering when my bug will be fixed in production since jtv's branch landed :)18:42
lifelessmpt: an observation: your 'what should happen' entries in bugs are very close to 'shoulds'18:48
mptlifeless, they are. It's the describing the problem first that's the important thing. :-)18:49
mptMaybe I could use "What I expected:" instead18:49
lifelessmpt: Or 'one way I would not have been surprised:' :)18:51
lifelessmpt: I guess my point is to open the solution space out18:52
mtaylorI suppose folks know that launchpad login service is unhappy?19:26
mtaylororg.openid4java.discovery.yadis.YadisException: 0x706: GET failed on https://login.launchpad.net/+openid : 503:HTTP/1.1 503 Service Unavailable19:26
lifelessmtaylor: grah. Thats login.ubuntu.com. I'll go poke folk19:30
=== almaisan-away is now known as al-maisan
lifelessmtaylor: fixed19:34
lifelessmtaylor: sso is having some flakiness issues this week19:34
mtaylorlifeless: ++19:34
lifelessmtaylor: its escalated but not understood yet19:34
lifeless(theories abound, proof is tricky)19:34
mtaylorlifeless: distributed systems are hard19:38
mtaylorlifeless: btw - it's still broken19:38
mtaylorlifeless: https://jenkins.openstack.org19:39
lifelessmbarnett: ^19:39
lifelessmbarnett: ah you know, nvm19:39
lifelessmtaylor: cascading trouble19:39
* mtaylor loves trouble19:40
* mbarnett doesn't always break things, but when he does he breaks them all. 20:16
=== 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
thumperhi people21:15
thumperI'm looking for a "stock" presentation for "intro to launchpad"21:16
thumperis there one around somewhere?21:16
thumperWe have a growing team, and some don't really understand launchpad, so I'm doing a presentation next week to cover the basics21:16
mwhudsonin unrelated news, launchpad's roles for managing (in various senses) projects make no sense to anyone21:30

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!