[00:02] <krkhan> in testing layer, after creating a bugattachment with factory.makeBugAttachment, i get 404 whenever i try to access the attachment's url
[00:07] <krkhan> that is, doing just a = self.factory.makeBugAttachment and then accessing a.data.read() results in a lookuperror
[00:15] <kb9vqf> Anyone have recommendations for an OpenID server that will work with a local installation of Launchpad?
[00:38] <thumper> krkhan: that is because the attachment is stored in the librarian
[00:38] <thumper> krkhan: which is a different process
[00:38] <thumper> krkhan: so the local transaction needs to be committed for the librarian to see it
[00:38] <thumper> kb9vqf: I just use the local test openid server
[00:40]  * thumper afk for lunch
[00:54] <spm> configs question: we have a script: scripts/process-accepted.py which is oops'ing. and then failing to write said oops as it's going to the wrong place; which is then aborting the shell script it's running from. Q, how do I find which config stanza I need to fix for that specific script *only*? I've found the master it's inheriting from ftpmaster/launchpad-lazr.conf but that controls a bunch of semi-related things I don't want to break. ???
[00:54] <wgrant> rockstar: Hi.
[00:55] <krkhan> thumper: how do i commit the local transaction?
[00:56] <krkhan> thumper: nvm. transaction.commit. thanks a bunch for the quick help :)
[00:57] <rockstar> wgrant, can you take a look at this: https://code.edge.launchpad.net/~rockstar/launchpad/fix-buildds/+merge/26990
[01:00] <wgrant> rockstar: Good description, good patch.
[01:00] <rockstar> wgrant, yeah, I awoke to find shit all over me this morning.
[01:00] <rockstar> :)
[01:01] <wgrant> Sorry -- I would have submitted a branch myself, but exams are eating lots of time at the moment.
[01:01] <wgrant> Ah, so it was recipe builds that killed everything over the weekend?
[01:01] <rockstar> wgrant, yea, but it's not your job..  :)
[01:01] <rockstar> wgrant, yup, we're assuming this is why.
[01:01] <poolie> hi all
[01:01] <rockstar> wgrant, so do you feel like this fixes the bug you reported (I'll test as well, but you know this better than I do)
[01:03] <wgrant> rockstar: I believe it does. I'll fire buildd-manager up and get a build through.
[01:03] <wgrant> Although fixing this right now may not be a good idea.
[01:03] <wgrant> Since it means the master will start crashing instead of the slave.
[01:03] <rockstar> wgrant, yeah, I tried to do it locally, and my launchpad chroot shit the bed twice, so I tried to test on dogfood, but I don't really have access to it.
[01:03] <wgrant> Bug 587113
[01:03] <mup> Bug #587113: BuildBase result handling broken <Soyuz:Triaged by michael.nelson> <https://launchpad.net/bugs/587113>
[01:04] <wgrant> OK, I'll test locally.
[01:04] <poolie> that's vivid :)
[01:04] <rockstar> wgrant, why will the master start crashing?
[01:04] <wgrant> rockstar: The big model refactor last master broke the master's handling of completed recipe builds.
[01:04] <wgrant> (the bug I referenced above)
[01:04] <wgrant> But we can at least test that the slave works.
[01:14] <rockstar> wgrant, wait, so this isn't going to be able to be cherry picked to production?
[01:14] <wgrant> rockstar: Unless we get noodles' master fix in quickly too, no.
[01:15] <wgrant> But that fix should't be too big.
[01:15] <rockstar> wgrant, hm, I'll chat with noodles about that tomorrow then.
[01:16] <wgrant> For now, can't you just disable the recipe UI?
[01:16] <rockstar> wgrant, that's what we did.
[01:16] <wgrant> Ah, good.
[01:16] <rockstar> wgrant, but we would like to be testing recipes through edge this whole cycle.
[01:16] <rockstar> We've found that dogfood is a terrible place to be testing recipes
[01:17] <wgrant> Hmmm, production appservers need a CP before that can happen.
[01:17] <wgrant> Bug #587110
[01:17] <mup> Bug #587110: Need fmt:link for SourcePackageRecipeBuild <recipe> <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/587110>
[01:18] <wgrant> What's wrong with dogfood?
[01:18] <wgrant> Besides being dogfood?
[01:18] <rockstar> wgrant, can you compile this into a mail to the list.
[01:18] <rockstar> wgrant, we ran recipes through dogfood and it went well.  As soon as they got into edge, they just became a pain.
[01:19] <wgrant> rockstar: Well, all of this broke during week 3.
[01:19] <wgrant> Every one of these bugs.
[01:24] <wgrant> rockstar: As expected, the recipe build works fine with your branch merged, and then the master has a fit.
[01:24] <wgrant> So your branch is good.
[01:24] <rockstar> wgrant, okay, so there are three needed cherry picks before we can re-enable recipes, correct?
[01:25] <wgrant> 1) Your buildd branch to all of the buildds -> lamont
[01:25] <wgrant> 2) noodles master fix, which is yet to be written -> cesium
[01:25] <wgrant> 3) The SPRB fmt:link -> production appservers
[01:26] <rockstar> wgrant, okay, I'm compiling a this in an email to the list then.
[01:26] <wgrant> Thanks.
[01:26] <rockstar> wgrant, no, thank you for the help.
[01:27] <wgrant> I was able to get them going 1.5 weeks ago with those three changes.
[01:27] <wgrant> And it probably hasn't broken much since then.
[01:27] <wgrant> (although my master fix was a hack)
[01:41] <wgrant> rockstar: Is it known that the distroseries are in an arbitrary order on +request-builds?
[01:41] <rockstar> wgrant, for recipes?
[01:41] <wgrant> rockstar: Yes.
[01:42] <rockstar> wgrant, I think abentley had some issue with ordering by distroseries, but I don't remember what it was.
[01:42] <rockstar> But there was method to the madness.
[01:43] <wgrant> I really wish dogfood was less omgslow.
[01:49] <rockstar> wgrant, and that the buildmanager was actually running?
[01:50] <wgrant> rockstar: Well, I don't care much about that.
[01:50] <wgrant> I was hoping to log in and check if the distroseries were in any obvious order.
[01:50] <wgrant> But it turns out you can't log in either.
[01:50] <wgrant> And editing a recipe would probably time out, too...
[01:51] <rockstar> wgrant, yeah, dogfood is Soyuz's baby...
[02:17] <jml> james_w, you are maybe asleep now, but http://mumak.net:8080/job/txrestfulclient/
[02:27] <spm> hey jml, how's the big M doing?
[02:36] <thumper> spm: what? McDonalds?
[02:36] <rockstar> wgrant, technically bug# 587110 doesn't need to be cherry picked, because the UI is not enabled on production.
[02:36] <mup> Bug #587110: Need fmt:link for SourcePackageRecipeBuild <recipe> <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/587110>
[02:36] <spm> thumper: heh, close. Tho I believe Montréal is more accurate. ??
[02:46]  * rockstar shudders at McDonald's...
[03:00] <wgrant> rockstar: Erm, well.
[03:00] <wgrant>  /builders will start crashing if an SPRB gets dispatched.
[03:00] <rockstar> wgrant, ?
[03:00] <wgrant> So the index views themselves are disabled too?
[03:01] <rockstar> wgrant, well, the views are available, but in the words of abentley, "if you url hack, you get to keep both pieces"
[03:01] <rockstar> There are no links to those views though.
[03:02] <wgrant> OK. Maybe we should cherrypick a special fmt:link that doesn't actually generate a link.
[03:02] <rockstar> wgrant, sigh, I hadn't thought about that.
[03:02] <rockstar> wgrant, please reply to the my email about that.
[03:03] <wgrant> rockstar: Your third point has a hanging "This does"
[03:03] <rockstar> wgrant, gimme a break, it's 2000 here.  :)
[03:04] <wgrant> Heh.
[03:04] <wgrant> Was there anything important omitted?
[03:07] <wgrant> Replied, anyway.
[04:14] <jml> spm, Montreal is great
[05:54] <lifeless> jml: are you on leave now ?
[07:28] <noodles775> Hi ppl
[08:15] <adeuring> good morning
[09:09] <bigjools> hello world
[09:10] <wgrant> Morning.
[09:11] <mwhudson_> morning
[09:11] <bigjools> hi guys
[09:11] <bigjools> how's the service station mwhudson? :)
[09:11] <mwhudson> bigjools: terrible
[09:11] <mwhudson> the fire alarm went off at about 01:30 last night
[09:12] <bigjools> I looked on google maps and it's in. the. middle. of. nowhere!
[09:12] <mwhudson> yeah
[09:12] <mwhudson> you thought dolce la hulpe was isolated?
[09:12] <wgrant> It was in a forest!
[09:12] <wgrant> Is this even worse?
[09:12] <mwhudson> yes
[09:12] <wgrant> HOW!?
[09:14] <mwhudson> wgrant: it's a travel hotel, with a mcdonalds next door and about 5km from anywhere
[09:16] <wgrant> Oh.
[09:17] <wgrant> Awesome.
[09:18] <cody-somerville> There is a bloody handprint above my bed.
[09:18] <wgrant> ... that is concerning.
[09:51] <bigjools> cody-somerville: lol
[10:58] <deryck> Morning, folks.
[11:03] <noodles775> When using codehosting locally, I'm trying to push a branch for a user I've created, but it's trying to authenticate as sabdfl... can someone point me in the right direction? http://pastebin.ubuntu.com/446558/
[11:20] <wgrant> noodles775: You have an old ~/.ssh/config.
[11:20] <wgrant> rf-setup used to put an extra stanza in there.
[11:21] <noodles775> Thanks wgrant.
[11:36] <bilalakhtar> Hi there, people. Can anyone tell me what does this line mean in https://dev.launchpad.net/Running/Schroot "Don't rm -rf /chroot/karmic-lp, because this will descend into /chroot/karmic-lp/home and delete your actual home directory!"?
[11:36] <bilalakhtar> Sorry I am a newbie when i comes to chroots
[11:36] <bilalakhtar> sorry have to go
[12:15] <noodles775> wgrant: still around? I've got failed SPRecipeBuilds going through properly (ie. log gets appended, etc.). The log shows they're failing with "bzr: ERROR: no such option: --append-version". I assume I need to make sure the buildd has a newer version of bzr-builder?
[12:16] <wgrant> noodles775: Right, you need to steal a new bzr-builder from production.
[12:16] <wgrant> Or add the right sources.list entries to the config option.
[12:17] <wgrant> Either steal from the prod configs, or download and upload from https://edge.launchpad.net/~launchpad/+archive/bzr-builder-dev
[12:17] <noodles775> Yep, doing so now. Thanks.
[12:33] <bilalakhtar> Hi there, noodles775 is it possible to run lp on a computer already running LAMP? (apache2-mpm-prefork)
[12:34] <bilalakhtar> Rocketfuel-setup runs apt-get install apache2-mpm-worker. This removes php
[12:35] <noodles775> bilalakhtar: I've not tried.
[12:36] <bilalakhtar> noodles775: What apache module does launchpad use? mod-python or cgi?
[12:37] <wgrant> Neither.
[12:38] <wgrant> It's mostly proxied.
[12:38] <bilalakhtar> wgrant: proxied?
[12:38] <wgrant> It mostly uses mod_proxy.
[12:38] <wgrant> Apache does not run the actual application.
[12:38] <wgrant> prefork should be fine, if you are PHP-inclined.
[12:39] <bilalakhtar> wgrant: oh. Thanks. I will modify the line in rocketfuel-setup so that it tries to install prefork, which is actually installled. thanks
[13:22]  * bigjools finds the problem why PPAs are not getting deleted and groans
[13:46] <bilalakhtar> Hi people, I am confused aboout which branch should I download to begin hacking. db-devel or devel? I just want to make a minor change (no db change). Acoording to the wiki, I should work on devel, but it is said "db-devel is default stacking branch". What should I do?
[13:50] <beuno> bilalakhtar, go for devel
[13:50] <bilalakhtar> beuno: And stack on db-devel?
[13:51] <beuno> bilalakhtar, yes
[13:51] <bilalakhtar> beuno: then merge with devel?
[13:51] <beuno> don't worry about the stacking
[13:51] <beuno> it's not important
[13:51] <beuno> use devel, propose merging into devel
[13:51] <beuno> ignore db-devel
[13:51] <bilalakhtar> beuno: Last question: I am not using rocketfuel. I am manually downloading db-devel right now. I installed apache and lp-developer-deps. Now, what should I do about locations.conf?
[13:52] <beuno> I think locations.conf is a convenience to push branches
[13:53] <bilalakhtar> beuno: What should I set it to, if I want to take advantage of the "convenience"?
[13:53] <lifeless> nothing
[13:53] <lifeless> you're worrying about a bunch of automatic details
[13:53] <lifeless> don't
[13:53] <lifeless> just follow the wiki :)
[13:53] <bilalakhtar> thanks, beuno and lifeless
[13:55] <bilalakhtar> beuno and lifeless: What is bzr pqm-submit? Is it necessary to run that as well when proposing merge? Or proposing via lp web UI is enough?
[13:55] <lifeless> bilalakhtar: just run bzr lp-propose
[13:56] <lifeless> pqm-submit is used by folk with commit-to-devel privileges
[13:56] <bilalakhtar> lifeless: ahha, a new plugin. Is it the same as proposing via web?
[13:56] <lifeless> yes
[13:56] <lifeless> not a new plugin, its built in
[13:56] <bilalakhtar> lifeless: thanks
[13:56]  * bilalakhtar is bumming around with the code :)
[14:08] <bilalakhtar> beuno: running bzr branch lp:launchpad/devel is stacking on the devel branch. is it fine?
[14:12] <bilalakhtar> hehe, most of the people here are lp-ers
[14:12] <bilalakhtar> I mean members of ~launchpad team
 running bzr branch lp:launchpad/devel is stacking on the devel branch
[14:21] <maxb> That is meaningless/impossible. The act of branching locally can't stack on a remote launchpad branch
[14:48] <bilalakhtar> maxb: I cannot run link-external-sourcecode. The problem is that the sourcecode folder is empty. What to do?
[14:49] <maxb> The sourcecode folder should not be empty if you've successfully completed rocketfuel-setup
[14:50] <bilalakhtar> maxb: I didn't use rocketfuel only.
[14:51] <maxb> If you do not, then you are responsible for reading it through carefully and doing what it would have done
[14:51] <bilalakhtar> maxb: ok, now I will use it. Many probs are coming thanks.
[14:51] <maxb> I do not run rocketfuel either
[14:51] <maxb> But I do treat it as a reference document
[14:53] <deryck> So what's the rule for using memcached in tal and testing?
[14:53] <deryck> Cache and move on, trusting the memached testing itself?
[14:54] <deryck> gary_poster, have any thoughts there ^^ ?
[14:56] <gary_poster> deryck: yes, a few thoughts.  So, first of all, there's a bug on making testing easier.  I could find it; the gist is that we should be able to verify that memcache is working, and there's an idea on what that spelling might be.
[14:56] <gary_poster> That probably should be pretty easy to do but we haven't gotten around to it yet
[14:57] <deryck> ok, np.  I do understand.
[14:57] <gary_poster> So, looking into that is an option.  However, meanwhile, depending on what you are doing, there may be some other approaches for testing this second.
[14:58] <gary_poster> In particular, curtis wanted to show that one snippet (with memcache sharing characteristic X) was used for one situation, and another was used in another (with characteristic Y).
[14:59] <gary_poster> He did that with simple comments in the code that actually didn't have too much to do with memcache except by convention.
[14:59] <deryck> gary_poster, yeah, I saw Curtis' test but it seemed to be just testing html comment.  but I guess that does ensure that the right caching is in effect.
[14:59] <deryck> right
[14:59] <deryck> I guess that would work for me.
[15:00] <deryck> gary_poster, and normal page tests are run outside cache, right?  So adding caching has no effect on those tests?
[15:01] <gary_poster> OK.  Let me find the bug for improving memcache testing, and then maybe you can add your example there so we can change it when we add the better testing story.  Normal page tests are run outside cache: actually, I think memcached is available and running
[15:01] <adiroiban> noodles775: do you have time to discuss an Firefox/HTML-accesskey issue affecting bug 359180?
[15:02] <gary_poster> deryck: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/586466 FWIW
[15:02] <mup> Bug #586466: Testing tal cache states could be easier <Launchpad Foundations:Triaged by stub> <https://launchpad.net/bugs/586466>
[15:02] <noodles775> adiroiban: in 0.5hr or so?
[15:02] <noodles775> Will you still be around?
[15:02] <adiroiban> noodles775: yep. we can also do it tomorrow ...no hurry
[15:03] <adiroiban> I just wanted to schedule it
[15:03] <stub> pagetests use memcache
[15:03] <deryck> gary_poster, you say memcached is available and running.  Does it affect tests then?  i.e. if I fetch a page that is cached, do some work, and then want to verify a cached section, should the test fail?
[15:03] <deryck> stub, ^^
[15:04] <noodles775> adiroiban: today is good, I'm just finishing something off.
[15:04] <gary_poster> deryck: AIUI, yes, it affects tests.  That is certainly the intent.
[15:04] <deryck> ah, ok.
[15:04] <stub> memcached affects tests. You might need to clear the cache if you need changes to be visible - there is a helper on MemcacheLayer I think to do that easily
[15:05] <deryck> that works perfectly for me and my concerns then.  Thanks, gary_poster and stub.  And many thanks for this work from you guys, too! :-)
[15:05] <gary_poster> cool :-)
[15:06]  * deryck plans to cache liberally over the next couple months
[15:07] <stub> deryck: And use the slave db liberally too.
[15:07] <stub> deryck: I'd like to see all bug searches hitting the slave instead of the master - they are pretty heavy weight.
[15:07] <deryck> stub, right.  That's a good point.
[15:07]  * deryck makes reminder note to discuss with team
[15:08] <stub> lib/canonical/launchpad/doc/db-policy.txt goes over how to install a db policy to make the slave a default for a section of code, or just ISlaveStore(Bug).find(...) to be explicit.
[15:08] <bigjools> db-policy.txt ROCKS
[15:09] <deryck> note made
[15:14] <bigjools> lifeless: is lp-propose a new bzr command?  I don't have it.
[15:17] <jml> lifeless, I am.
[15:26] <noodles775> adiroiban: ok, ready when you are.
[15:26] <adiroiban> noodles775: ok. I start working on keyboard shortcuts for Launchpad translations page
[15:26] <adiroiban> and I went for Shift+Alt+KEY
[15:27] <adiroiban> as they are also used for HTML Access key
[15:27] <adiroiban> and thinking that Web browser will not overlap with them
[15:28] <adiroiban> I have implemented them using YUI3 key events and Chromium / Webkit family is fine
[15:28] <adiroiban> but in Firefox, if there is no HTML Access key on the page, Shift+Alt+Key will behave as Alt+Key
[15:28] <noodles775> Great!
[15:28] <noodles775> (except for the last bit :) ).
[15:28] <adiroiban> and instead of performing the YUI3 event
[15:29] <adiroiban> it will pop up a menu
[15:29] <adiroiban> as I workaround, I found out that if I add an empty <a accesskey=F> in the page
[15:29] <adiroiban> Firefox will not popup the menu
[15:29] <adiroiban> and will trigger the YUI3 event
[15:30] <adiroiban> and I would like to ask you if this is an acceptable workaround
[15:30] <adiroiban> or there are other side effect for this solution
[15:30] <adiroiban> or do you have other ideas for implementing it
[15:30] <noodles775> adiroiban: could it not be a feature if it was for a skip to content-type link?
[15:31] <adiroiban> noodles775: I lost the conversation... what is a feature?
[15:31] <noodles775> Have I understood correctly: you're asking if it would be acceptable to add a default access key to all pages (ie. the base template) so that FF won't pop up the window?
[15:32] <adiroiban> yes. that what I was asking.
[15:33] <adiroiban> but it will requre an „blind” access key for each keyboard shortcut
[15:33] <noodles775> So, couldn't that be combined with providing a "skip-to-content" link with an access key (eg. http://diveintoaccessibility.org/day_11_skipping_over_navigation_links.html )
[15:33] <noodles775> OK, I'm not sure what you mean by a blind access key.
[15:34] <adiroiban> a blind accesskey is just a tag like <a accesskey=KEY/>
[15:34] <adiroiban> it will not be a proper anchor
[15:34] <adiroiban> as it does not have a name
[15:35] <noodles775> But why couldn't it be a proper anchor if it was providing useful functionality (but not displayed) as in the above link?
[15:36] <adiroiban> because the YUI3 event is doing more than just focusing a link
[15:37] <adiroiban> adding an Skip to content accesskey will not solve this problem
[15:38] <adiroiban> as we need an accesskey for each YUI3 key event
[15:38] <adiroiban> and the accesskey should not have an attached ID or name
[15:40] <adiroiban> noodles775: to demonstrate the behaviour, go to https://translations.edge.launchpad.net/ubuntu/lucid/+source/ubiquity/+pots/ubiquity-debconf/de/+translate using Firefox
[15:40]  * noodles775 opens FF
[15:40] <adiroiban> and while the focus is on the first translation field (it should be auto focused)
[15:41] <adiroiban> press Shift+Alt+F (if you are using FF in English)
[15:41] <adiroiban> if you are repeating these steps in Chromium, the Search field will be focused
[15:41] <adiroiban> but in Firefox it opens the File menu
[15:41] <noodles775> (as does simply ALT-F)
[15:41] <adiroiban> yes
[15:42] <noodles775> Which is the first translation field? (It didn't seem to auto focus...)
[15:42] <noodles775> nm... I wasn't logged in with FF, so no fields :)
[15:43] <adiroiban> ah
[15:43] <adiroiban> yes
[15:43] <adiroiban> you need to log in
[15:45] <noodles775> OK, and you say that can be avoided specifically by adding *one* dummy <a accesskey=KEY/> to the template?
[15:45] <adiroiban> one dummy for *each* YUI3 event
[15:45] <noodles775> ah... OK, now it's clearer.
[15:45] <noodles775> hrm.
[15:48] <adiroiban> do you know other ways for solving this problem
[15:48] <noodles775> Nope, but I'm just reading atm.
[15:49] <adiroiban> Ctrl+Key, Alt+Key and Shift+Ctrl events are already well established in browsers menus
[15:50] <adiroiban> and I think that Ctrl+Alt is used by the window managers
[15:57] <noodles775> adiroiban: ok, another point where I'm confused: why not add a valid anchor with a valid access key for each?
[15:58] <adiroiban> HTML accees key actions can only focus or activate (depending on the browser) a link
[15:58] <adiroiban> in the translations page we have Shift+Alt+C
[15:58] <bilalakhtar> People, How bug is the launchpad branch? I have been downloading it from an hour. Its more than 100MB by now
[15:58] <adiroiban> which triggers a javascript function
[15:59] <noodles775> adiroiban: yes, but I was hoping that the YUI code would override that if present?
[16:00] <bilalakhtar> *big
[16:00] <adiroiban> also, for some access key there is no associated anchor
[16:00] <noodles775> But ok, it makes more sense now, and no I don't know of a better option (nor can I find one). If you add the empty ones to your template only I wouldn't see it as an issue. When you've got the MP, please ping me with it, as I'd be keen to play with it a bit.
[16:01] <adiroiban> noodles775: another option is overwriting Ctrl+KEY
[16:01] <adiroiban> I have tested with Chromium and Firefox
[16:02] <adiroiban> and it looks like Ctrl+Key events are first passed to javascript and only if not handled there
[16:02] <adiroiban> they are triggering menu actions
[16:02] <noodles775> aha, seems quite standard (at least, gmail keyboard shortcuts use it)
[16:02] <adiroiban> yes... but user will no longer have access to their shortcuts
[16:02] <noodles775> Is there any drawback to Ctrl+Key? Why weren't they the original option?
[16:02] <adiroiban> like Ctrl+C
[16:02]  * noodles775 reads bug again.
[16:04] <adiroiban> noodles775: list of keyboard shortcuts in other web apps http://mashable.com/2007/06/29/keyboard-shortcuts/
[16:05] <adiroiban> noodles775: the main reason for using Shift+Alt was to avoid overlapping with other key shortcuts
[16:06] <adiroiban> and Ctrl+Key are widely usind in browsers
[16:09] <adiroiban> also afaik IE 7.0 will not allow the overiding of Ctrl+P, Ctrl+O and Ctrl+F .... maybe there are more restrictions
[16:13] <noodles775> adiroiban: OK, I'm tending towards keeping the keys you've got and updating just your template so it also works in FF (adding real accesskeys where possible, but blank otherwise). As this is the first time LP has had accesskeys (I can't see any other egs?), it's probably worth a discussion on the dev list... there may be people on there in a better position to make a more permanent recommendation.
[16:15] <gary_poster> deryck, sinzui: in a fit of pique, I tried for a fix to bug 586466, which gives a test convenience for memcached bits.  I'm running it through ec2 test now to see if my change has any nasty side effects, but otherwise it seemed to work.
[16:15] <gary_poster> Once I get that to pass, I'm going to ask Curtis to review, for several reasons (making sure I'm doing something reasonable with my lpconfig check, for instance, or if he thinks I should be more defensive).
[16:15] <gary_poster> However, as a sort of pre-impl or mid-impl or something, would be happy to get any feedback from you two on the change.  Essentially, if you go to http://bazaar.launchpad.net/~gary/launchpad/bug586466/revision/10964 and look at milestone-views.txt, you will see that, if you are in test or dev modes, the memcached integration will now add comments describing the start (and end) of the cache hit.
[16:15] <gary_poster> Does that look good to you two? 
[16:15] <mup> Bug #586466: Testing tal cache states could be easier <Launchpad Foundations:Triaged by stub> <https://launchpad.net/bugs/586466>
[16:15] <adiroiban> noodles775: I think this is the first place to use accesskeys. I will also send an email to dev list. Thanks! I will let you know when the MP is ready
[16:16] <deryck> gary_poster, oh, wow.  JFDI FTW! :-)  looking at your rev from above now...
[16:16] <gary_poster> :-)
[16:18] <deryck> gary_poster, I like that a lot.  That works for my concerns, too.  It's more explict about whether you've hit cache or not, which is what I wanted.
[16:19] <gary_poster> Great, deryck.  Thank you for looking at it.
[16:22] <deryck> np
[16:23] <sinzui> gary_poster, deryck: remove the end comment or put them before the call. I personally do not think they are needed...it know what purge does. r=me, as deryck said jfdi
[16:23] <gary_poster> sinzui: ack, cool, thank you
[16:26] <sinzui> gary_poster, deryck: My initial landing of cached content was disappointing. I thought my second would also be disappointing, but most of the problems are now gone from the oopses. I will add this tactic to person and teams next
[16:27] <gary_poster> great
[16:27] <deryck> yes, I appreciate your initial work, sinzui.  Makes my use easier.
[16:28] <deryck> and I'm on a memcached onslaught now
[16:31] <sinzui> take a look at the milestone bug task listings. I use two different cache times (which required a macro for the content) to handle stable verses unstable information. eg, cache old comments 6 hours, but cache new ones 10 minutes (so losas can delete them)
[16:54] <noodles775> abentley: I'll include that change in the branch that I'm landing.
[16:54] <abentley> noodles775, tx
[17:01] <noodles775> Night all.
[19:02] <adiroiban> hi. it looks like LP API (https://launchpad.net/+apidoc/devel.html) is not updated together with edge. Is there a way where I can find the revision of the deployed LP API code
[19:19] <jml> adiroiban, https://edge.launchpad.net/+apidoc/devel.html ?
[19:20] <adiroiban> jml: true. stupid me :)
[19:23] <jml> is there a stable ppa for launchpadlib?
[19:24] <dobey> hey guys
[19:25] <dobey> what are the metrics for determining what reviews show up on my launchpad.net/~me/+activereviews page?
[19:27] <beuno> dobey, I think it's "reviews that you can do, or reviews that you have been asked to do"
[19:27] <beuno> the "you can do" part inherits from your teams
[19:27] <jelmer> unfortunately it doesn't include reviews for teams that you are in
[19:27] <beuno> but this is totally out of memory
[19:27] <beuno> ah
[19:27] <beuno> ok
[19:27] <beuno> so that was the plan
[19:27] <dobey> jelmer: didn't it used to?
[19:28] <jelmer> dobey: not that I remember, but I have only been using the +activereviews page since bzr switched to using launchpad for reviews.
[19:28] <dobey> ooh. no more bundle buggy?
[19:29] <jelmer> no, we moved away to launchpad quite a while ago (two years?)
[19:29] <dobey> hmm
[19:30] <beuno> jelmer, a bit under 2 years, when we actually made code reviews usable  :)
[19:30]  * beuno gets nostalgic
[19:31] <dobey> it's definitely less than 2 years, becuase i haven't been at canonical that long yet, and the branches i submitted to bzr had to go to bundle buggy :)
[19:33] <jelmer> time flies, just realized I've been hacking on bzr for almost 5 years now
[19:35] <dobey> heh
[19:43] <mars> gary_poster, want to switch the Windmill test suite back on?  https://code.edge.launchpad.net/~mars/launchpad/re-enable-windmill-ec2-suite/+merge/27077
[19:43] <gary_poster> mars, sure, once LP loads :-P
[19:53] <jml> leonardr, is it deliberate that NamedOperation.__call__ has a variable named "request" that is probably supposed to be a ResponseDefinition instance? (I'm saying that because get_representation_definition is called on it)
[19:59] <leonardr> jml: i think it's probably a RequestDefinition that _contains_ a ResponseDefinition
[19:59] <jml> leonardr, RequestDefinition doesn't have a get_representation_definition method though.
[19:59] <jml> leonardr, it has a representation_definition method :)
[20:06] <kb9vqf> Does Launchpad have something like an admin console where projects and users can be deleted by an administrator?
[20:06] <kb9vqf> This is for a local installation of course ;-)
[20:08] <jml> leonardr, oh, never mind. I'm pulling from an old trunk.
[20:08] <jml> leonardr, sorry for the noise.
[20:09] <leonardr> jml, np
[20:12] <krkhan> for local launchpad, what service_root should i give to the login_with method of launchpadlib?
[20:13] <jml> leonardr, ok, now I have another question :) how come https://bugs.edge.launchpad.net/wadllib/+bug/274074 is marked as fix released, but https://code.edge.launchpad.net/~leonardr/wadllib/fix-bind-to-anon-collection/+merge/24613 isn't merged into wadllib trunk?
[20:13] <mup> Bug #274074: Missing total_size on collections returned by named operations <api> <wadllib:Fix Released by leonardr> <https://launchpad.net/bugs/274074>
[20:14] <leonardr> jml, most likely the code is there but the branch wasn't marked merged for unknown reasons
[20:14] <leonardr> i'm checking
[20:15] <jml> leonardr, thank you
[20:15] <jml> leonardr, fwiw, when I merge the branch into trunk, it changes stuff and makes the failing test that triggered james_w's initial report pass
[20:16] <mars> jml, btw, I have that patch now for zope.testing.  I can push the branch, see if you think it's sane.
[20:16] <jml> mars, thanks.
[20:18] <mars> jml, lp:~mars/zope.testing/fix-subunit-utf8-traceback-reporting
[20:19] <jml> mars, ta. is that related to ec2 land being broken?
[20:20] <mars> jml, that is the cause.  It isn't just ec2 land, it causes the test suite to outright forget previous test failures, so it ends up lying.
[20:20]  * jml nods
[20:20] <Ursinha> sinzui, hi
[20:20] <sinzui> Hi Ursinha
[20:20] <Ursinha> sinzui, I see you landed something that was a testfix and a fix for three bugs at the same time, right?
[20:20] <Ursinha> r10951 on devel
[20:21] <Ursinha> sinzui, problem is tagging script ignores testfixes
[20:21] <sinzui> Ursinha, understood
[20:21] <sinzui> I also had no idea that my testfix would fix a bug I did not know was reported
[20:21] <mars> jml, I don't think it is a stellar fix, but it works, and should be forward-compatible.
[20:22] <jml> mars, that branch wasn't made from lp:zope.testing :)
[20:22] <Ursinha> sinzui, that was unexpected
[20:22] <mars> jml, ?  Says "Created new stacked branch referring to /~ztk-steering-group/zope.testing/trunk"
[20:23] <jml> mars, it'll say that regardless of what you push up.
[20:24] <Ursinha> sinzui, I wonder if that could happen too often that would be worth changing the script's behaviour
[20:24] <mars> jml, looking at the recent revisions on https://code.edge.launchpad.net/~mars/zope.testing/fix-subunit-utf8-traceback-reporting, it still looks right?  Unless lp:zope.testing uses something different?
[20:25] <jml> mars, the fix itself looks good to me (and damn, I wish I felt confident enough to use unit tests when originally contributing the zope support)
[20:25] <leonardr> jml: looks like the branch i thought was lp:wadllib was just a random branch
[20:25] <jml> leonardr, heh
[20:25] <mars> jml, sidnei said it was OK ;)
[20:25] <jml> leonardr, the ~launchpad-pqm owned one?
[20:25] <sinzui> Ursinha, My actions were extraordinary. I do not think it will happen often
[20:26] <Ursinha> sinzui, right
[20:26] <Ursinha> thanks
[20:26] <sinzui> Just knowing is enough for me to ensure they get updated myhand
[20:26] <jml> mars, yeah, there shouldn't be a problem.
[20:26] <leonardr> jml: no, it was something in ~leonardr/wadllib
[20:26] <sinzui> by hand
[20:26] <mars> jml, and lp:zope.testing points to https://code.edge.launchpad.net/~ztk-steering-group/zope.testing/trunk - still OK I would think
[20:27] <jml> mars, yeah, it's ok, it's just that you can't merge one branch into the other with bzr
[20:27] <jml> mars, which isn't a big deal, because it'll be applied as a text patch in svn anyway :)
[20:27] <mars> jml, oh, you mean I didn't use svn!  Right.  Nope, I figured lifeless did it, so it must get through the contributor process somehow
[20:28] <jml> mars, no, I just mean that when I try to merge your branch into my local copy of lp:zope.testing, bzr tells me there's no common ancestors.
[20:28] <leonardr> jml, should be fixed now
[20:28] <jml> ahh
[20:28] <mars> jml, ok, that's weird
[20:28] <jml> mars, lp:zope.testing has changed since I last pulled.
[20:28] <jml> mars, my bad
[20:29] <mars> no problem
[20:29] <jml> leonardr, thanks! was the latest wadllib release based on the actual trunk?
[20:29] <leonardr> the latest wadllib release was based on my oddball branch. but since i think i'm the only one who's ever modified wadllib, it should contain all the latest code
[20:30] <jml> leonardr, good to know. Also, do you know if there's a stable PPA?
[20:31] <leonardr> jml: not to my knowledge
[20:32] <jml> leonardr, thanks.
[20:35] <kb9vqf> Does Launchpad have something like an admin console where projects and users can be deleted by an administrator?
[20:35] <kb9vqf> This is for a local installation of course ;-)
[20:36] <mars> kb9vqf, log in as an administrator, visit the project or user page and hit the "Administer Foo" link in the upper-right.  There is no central page for doing so.
[20:36] <kb9vqf> OK, thanks
[20:36]  * kb9vqf is still learning...
[20:37] <kb9vqf> second question: How do I promote a standard user to administrator status?
[21:26] <krkhan> i have exported a method for Bug in lp.bugs.model.bug, it is accessible from lp.bugs.model.bug.Bug but it doesn't show up in lp_operations of the lazr Entry. any ideas what i'm doing wrong?
[21:27] <krkhan> leonardr: ping
[21:27] <leonardr> krkhan, does it show up in /+apidoc/devel.html in your local launchpad?
[21:29] <leonardr> how did you export it? typically exporting happens on the interface level
[21:29] <leonardr> if you give me a link to your branch i can take al ook
[21:29] <krkhan> leonardr: i exported it this way: http://bazaar.launchpad.net/~inspirated/launchpad/bug-findAttachment/revision/10937
[21:29] <krkhan> let me check apidoc
[21:30] <krkhan> leonardr: no. it doesn't show up in apidoc
[21:30] <leonardr> ok, so it's not published in the wadl, so lazr.restful doesn't really think it's published
[21:31] <krkhan> how do i publish it in wadl?
[21:32] <leonardr> once lazr.restful recognizes what you're trying to do, it will show up in the wadl, and launchpadlib and apidoc will pick it up from there
[21:34] <krkhan> that's what i'm stuck at :-( why isn't lazr.restful picking up what i'm trying to do. i've tried reading implementation of other read operations which do show up and i don't see anything different
[21:38] <leonardr> it also looks ok to me
[21:48] <mars> sidnei, ping
[21:48] <sidnei> mars, aye
[21:49] <mars> Hi sidnei, just wondering if there is anything I need to do in the way of copyright assignment before or after submitting code to zope.testing?
[21:51] <sidnei> mars, oh, good one. there's a contributor agreement that you have to sign to get commit access. i could checkin the patch for you though, since i signed the contributor agreement.
[21:52] <mars> sidnei, well, the patch is in bzr, so I guess you would have to land it for me anyway :)
[21:52] <sidnei> true
[21:52] <mars> sidnei, ok, I'll prep a merge proposal then
[21:54] <leonardr> krkhan, afaict an adapter is being generated for your new method
[21:55] <leonardr> i put a breakpoint in the lazr.restful egg, in declarations.py#generate_operation_adapter
[21:55] <leonardr>    if "Attachments" in method.__name__:
[21:55] <leonardr>     import pdb; pdb.set_trace()
[21:55] <leonardr> you can try it yourself
[21:55] <leonardr> if you don't make any progress i'll come back to it tomorrow
[22:10] <jkakar> leonardr: Thanks for looking at my fake-launchpad branch!
[22:10] <jkakar> leonardr: Your comments look very sensible.  I need to digest them a bit, but will respond tomorrow.
[22:10] <mars> sidnei, https://code.edge.launchpad.net/~mars/zope.testing/fix-subunit-utf8-traceback-reporting/+merge/27086
[22:10] <jkakar> leonardr: Also, totally agree that this should ideally live in restfulclient and also that FakeResource is doing too much...
[22:11] <jkakar> leonardr: I was basically discovering the way the WADL and launchpadlib itself works as I went, so I'm not surprised that someone with clue about them see that the design I've come up with has problems.  Thanks for explaining them, I'm happy to work on fixes based on your suggestions.
[22:14] <mars> jml, you may be interested in this: https://code.edge.launchpad.net/~mars/zope.testing/fix-subunit-utf8-traceback-reporting/+merge/27086
[22:14] <krkhan> leonardr: indeed, both canBeNominatedFor (example read operation that works) and findAttachments pass through generate_operation_adapter. so lazr.restful is seeing the method too but it still isn't getting exported. anyways, will ask you tomorrow then
[22:14] <thumper> morning
[22:14] <mars> morning thumper
[22:15] <sinzui> bac, are you really online?
[22:23] <bac> sinzui: i am now
[22:24] <sinzui> bac: I think there are 4 or more bugs about bug field descriptions and documentation. I think we should fix these this week in a single branch
[22:25] <bac> sinzui: sounds good
[22:26] <sinzui> I can find the bugs, but I think it is best we commit to reviewing all the fields so that they are consistent. I think doing this will help us define what we intend to do with the new forms
[23:28] <krkhan> leonardr: fwiw, i'm also noticing that changing the method names in IBug interface doesn't affect anything in the apidoc
[23:51] <jml> what's bugtask.date_left_new mean?