[00:43] <lifeless> jkakar: On Wed, 2009-12-02 at 17:36 -0700, Jason Earl wrote:
[00:43] <lifeless> Gordon Tyler <gordon@doxxx.net> writes:
[00:43] <lifeless> >
[00:43] <lifeless> > > lp:~doxxx/bzr/bzrmeta-ignore
[00:43] <lifeless> > >
[00:43] <lifeless> > > This is the first stage of my branch converting .bzrignore to
[00:43] <lifeless> > > .bzrmeta/ignore. It does not have any backwards-compatibility handling
[00:43] <lifeless> > > of .bzrignore which is the next stage I will be tackling. All tests
[00:43] <lifeless> > > pass and I've updated the docs except the non-English stuff.
[00:43] <lifeless> > >
[00:43] <lifeless> > > If .bzrignore exists and 'bzr ignore blah' is used to add an ignore
[00:43] <lifeless> > > pattern, should it add it to the existing .bzrignore or should it
[00:43] <lifeless> > > convert the .bzrignore to .bzrmeta/ignore and add the new pattern to
[00:43] <lifeless> > > that?
[00:43] <lifeless> >
[00:43] <lifeless> > This seems like a pretty simple question to me.  If you use the existing
[00:43] <lifeless> > .bzrignore file, then old clients will continue to work.  If you convert
[00:43] <lifeless> > the existing .bzrignore file to .bzrmeta/ignore, then old clients will
[00:43] <lifeless> > stop working.
[00:43] <lifeless> >
[00:43] <lifeless> > Using the .bzrignore file if it exists means that projects can migrate
[00:43] <lifeless> > to the new structure on their own terms.  New projects will end up with
[00:43] <lifeless> > the proper .bzrmeta file, and existing projects can migrate as the need
[00:43] <lifeless> > arises.  If a particular project wants to allow older clients then
[00:43] <lifeless> > someone simply has to create the proper .bzrignore file (once) and
[00:43] <lifeless> > everyone is happy.
[00:43] <lifeless> >
[00:44] <lifeless> > Jason
[00:44] <lifeless> >
[00:44] <lifeless> >
[00:44] <lifeless> >
[00:44] <lifeless> oh, fail.
[00:44]  * lifeless is very very sorry
[00:44] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
[00:44]  * lifeless also hates firefox for not selecting properly
[00:44] <lifeless> jkakar: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
[00:44] <mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
[00:44] <mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
[00:47] <jkakar> lifeless: Thanks!
[00:48] <lifeless> I had forgotten the details. I'm posting a couple of updates there.
[01:28] <maxb> oh dear. I guess rollout didn't go so well :-/
[01:31] <mwhudson> "just" delayed, i think
[01:32] <spm> prep had lots of issues. lots of lessons learned, so for all the badness, it's bad in a positive outcomes way.
[08:03] <jml> lifeless, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419691
[08:03] <mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419691>
[08:24] <adeuring> good morning
[09:09] <mrevell> morning
[09:14] <jml> good morning
[09:21]  * jml would like to write a computer program
[09:27] <bigjools> jml: I have plenty waiting, and my rates are very unreasonable
[09:30] <jml> bigjools, sadly, I have wiki pages to edit first
[09:30] <bigjools> jml: what an exciting life you lead in London!
[09:30] <wgrant> He'll be back with us soon!
[09:31] <bigjools> wgrant: BTW wellington is a go.
[09:31] <bigjools> did someone contact you?
[09:31] <wgrant> bigjools: Not yet, unless they were very spammy.
[09:31]  * wgrant checks filters.
[09:31] <bigjools> it would have been from Marianna
[09:32] <bigjools> perhaps you should contact her and ask for booking agent details
[09:32] <bigjools> anyway, I have a call, bbiab
[10:15] <jml> will bzr-svn imports be in this rollout?
[10:33] <wgrant> gmb: Intriguing. I'm trying that bug import, and it worked the first time on both my local system and an ec2 instance. But a 'make schema' and retry later, and it fails as you said...
[10:33] <gmb> Oh ho... that's very weird.
[10:34] <gmb> wgrant: ... And thinking about it, I didn't do a make schema before testing it on the machine where it worked.
[10:34] <wgrant> gmb: Hrmhrm.
[10:34] <wgrant> 'WTF' comes to mind.
[10:34] <gmb> Indeed.
[10:34]  * wgrant kills all clients, drops the DB, and makes schema.
[10:35] <gmb> Let me just get this branch on the review queue and then I can take a proper look at this weirdness.
[10:36] <wgrant> Thanks.
[10:54] <wgrant> gmb: Oh. It does some crazy bug number map caching thing. That explains the issue here.
[10:54] <wgrant> Once I kill that file, it works perfectly.
[10:58] <gmb> wgrant: Ah, okay. What's weird is that when I encountered the problem I was running without a cache.
[10:58] <gmb> Unless it creates one on the sly and doesn't tell me...
[10:58] <wgrant> gmb: It does.
[10:58] <gmb> Hah.
[10:58] <gmb> Beautiful.
[10:59] <wgrant> Make sure you get the latest version of the file, or you'll get a couple of errors.
[10:59] <gmb> wgrant: Yep, I'm up-to-date there.
[10:59] <gmb> Jeeesus, make schema takes ages on this machine.
[11:00]  * gmb really needs something with a bit of punch
[11:02] <deryck> Morning, all.
[11:05] <wgrant> gmb: David and I are looking through it now, but it all seems to have worked properly.
[11:05] <gmb> wgrant: Excellent. I'll move straight onto the ec2 bit then.
[11:05] <gmb> Save me wasting time waiting for make schema to complete.
[11:06] <wgrant> gmb: What's the purpose of the ec2 test?
[11:06] <gmb> wgrant: Well, actually, that's a fair point :)
[11:06] <gmb> Habit.
[11:06] <gmb> Is all it is.
[11:06] <gmb> wgrant: so, scratch that, I'll get it on staging today.
[11:33] <wgrant> gmb: Great, thanks.
[12:53] <jml> what's the correct query to do to get the current development series for Ubuntu?
[12:53] <maxb> Can someone raise a LOSA? http://bazaar.launchpad.net/<anything> is broken - redirects to LP root
[12:57] <mrevell> mthaddon, around? ^^^^^^
[12:58] <salgado> mthaddon is on leave, and the LOSAs from the US should not be around yet
[12:58] <salgado> elmo, ^
[12:59] <mrevell> thanks salgado
[13:07] <vila> Sorry to arrive late in the game but is there any estimate for bazaar.launchpad.net come-back ?
[13:11] <maxb> We seem to be lacking in UK LOSAs. It might have to wait until the US wakes up.
[13:12] <vila> maxb: thanks
[13:13]  * jml posts a note to launchpadstatus
[13:16] <jml> let's escalate this thing properly, eh
[14:32] <vila> looks like  http://bazaar.launchpad.net is back
[14:45] <matsubara> stub, Chex, gary_poster, rockstar, bigjools, danilo_, sinzui, allenap: LP production meeting in 15 min @ #launchpad-meeting
[14:46] <sinzui> matsubara: Can we add an agenda item to the meeting. gary_poster, bigjools, danilos, and myself as in another meeting at the same time. It would help if the production meeting could be held an hour later
[14:47] <matsubara> sinzui, sure thing. I'll add it to the proposed items section and we can discuss.
[14:48] <danilos> matsubara, thanks :)
[15:31] <jml> beuno, thanks! next time please also update identi.ca/launchpadstatus.
[15:31] <beuno> jml, will do
[15:32] <henninge> sinzui: ping
[15:33] <sinzui> Hi henninge
[15:34] <henninge> sinzui: FYI, I have a branch ready to land that adds three-column-list to style-3-0.css
[15:34] <henninge> ;-)
[15:34] <henninge> sinzui: first file in this mp: https://code.edge.launchpad.net/~henninge/launchpad/bug-425583-languages/+merge/15594
[15:35] <sinzui> henninge: I wonder if we can use that on the root pages then remove the old 3 column markup
[15:37] <henninge> sinzui: I don't see what you mean.
[15:38] <henninge> two/three-column-list only works well with elements of equal height.
[15:38] <sinzui> The root pages have  3 column layouts that use float right and float left
[15:39]  * sinzui has a branch that removed 1100 lines from the CSS
[15:39]  * henninge reviewed it (or part of it?)
[15:40] <henninge> sinzui: root pages are pages like https://answers.edge.launchpad.net/ ?
[15:40] <sinzui> yes
[15:40] <sinzui> We never developer a 3.0 design for them
[15:40] <sinzui> The tour button is 1.0
[15:41] <sinzui> beuno: would prefer that the counts be higher on the page as we show on other 3.0 pages
[15:41] <henninge> which counts?
[15:42] <sinzui> look at the footer of that page
[15:42] <henninge>  1312134 strings in 19148 translation templates
[15:42] <henninge> 289 languages, 43469 translators and 32 translation groups
[15:42] <henninge> oh!
[15:42] <henninge> "higher on the page"
[15:42] <henninge> not "counts be higher" ...
[15:42] <henninge> :-D
[15:43] <sinzui> English sucks
[15:43] <beuno> sinzui, in what page?
[15:43] <henninge> too few commas ....
[15:44] <sinzui> beuno: https://answers.edge.launchpad.net/ has counts at the bottom of the page as an after thought
[15:44] <sinzui> The icons are hacked in that page too, the sprite has better spacing
[15:45] <beuno> argh
[15:45] <beuno> https://pastebin.canonical.com/25324/
[15:45] <beuno> (when hitting code.lp.net
[15:45] <beuno> )
[15:45] <henninge> beuno: got it too, and on translations
[15:45] <beuno> sinzui, counts on those top level pages seem to be on the bottom
[15:45] <sinzui> yes, 1.0 style
[15:46] <beuno> sinzui, I think the counts are fine on the bottom
[15:47] <sinzui> okay
[15:47] <beuno> I'd like them formatted the same way as the homepage
[15:47] <beuno> salgado cooked up a formatter
[16:34] <asabil> hi again
[16:35] <asabil> is there a list of the cron jobs that I need to have running in order to run launchpad properly ?
[17:39] <mpt> beuno, hi, is there a scalable version of the PPA icon?
[17:44] <beuno> mpt, hi. I think not, because it had to be pixeled in the end
[17:44] <beuno> let me search though
[17:44] <mpt> beuno, it would be nice if we could use it for PPAs in the Ubuntu Software Center too
[17:45] <beuno> mpt, 64x64 too small?
[17:46]  * beuno is pinging the designer who do it
[17:46] <mpt> beuno, oh, it wasn't you?
[17:46] <mpt> hm, this would require signing Canonical Contributor Agreement
[17:46] <mpt> beuno, unless they have already
[17:46] <beuno> mpt, I didn't do the pixel-munging, no
[17:46] <beuno> mpt, we contracted out the work
[17:46] <beuno> we own it
[17:46] <mpt> ah, great
[17:46] <mpt> anyway, I have to leave now, back in an hour or so
[17:52] <mwhudson> morning
[17:52] <mwhudson> jml: you around?
[17:53] <bigjools> mwhudson: he's on the way to the airport
[17:53] <bigjools> and morning!
[17:55] <mwhudson> bigjools: hello!
[17:56] <bigjools> did you read my reply to your email?
[17:56] <mwhudson> bigjools: i just did
[17:56] <mwhudson> bigjools: it seems i was only confusing on one minor point this time :-)
[17:57] <bigjools> well that's an improvement :)
[17:57] <bigjools> I have to go for food now but I'll be back later
[17:57] <mwhudson> bigjools: to do with buildstate
[17:57] <mwhudson> ok
[17:58] <mrevell> back later to check up on the roll-out, if I can, if not see you tomorrow.
[17:58] <bigjools> bbiab
[19:07] <sinzui> beuno: I have a plan to give karma to all the project maintainers during my weekends this month. 1) Extend structural subscriptions to include project lifecycle event. 2) ensure that events are published, give karma for the important events
[19:09] <beuno> sinzui, you have my blessing and admiration for it. Make sure you blog about it, there's quite a few project owners who feel they should be getting more karma for being the maintainer of the project
[19:09] <sinzui> getting more...they get NONE
[19:09] <beuno> right, so it's easy to give them more!  :)
[19:10] <sinzui> I am very aware of the bug that lets someone get more karma then me when I have slaved by weekends to make a wonderful too
[19:11] <beuno> sinzui, if you need any UI, let me know and I will weekend it as well
[19:11] <sinzui> beuno: I may take you up on that. I need to extend the structural subscription page (which only shows bugs)...
[19:12] <mwhudson> jml: jabber gave you away
[19:14] <sinzui> beuno: We could do something interesting on the structural subscription page, like show that there is a notification level for bugs: Nothing, lifecycle, metadata, and comments
[19:18]  * beuno looks up the current page
[19:18] <mpt> beuno, any luck finding a vector PPA icon?
[19:18] <beuno> mpt, it's in your inbox
[19:18] <mpt> oh excellent
[19:18] <mpt> thanks very much beuno
[19:19] <beuno> y'er welcome mpt
[19:20] <beuno> sinzui, so the current structural subscription is done via de bug index page. Would we add it on the overview as well?
[19:20] <beuno> move it more towards "project subscription"?
[19:23] <sinzui> beuno: intellectronica landed a nice update that ensures that the structural subscription link appears correctly for most of the objects on the over view page.
[19:24] <sinzui> beuno: The edit page says, bugs, but that is a label. We set it to bugs because that is all that it shows
[19:24] <sinzui> I may need to ad the link to objects that I want to subscribe to, but do not have bugs.
[19:29] <bac> hi sinzui.  for the snapshot bug we've talked about product.branches.  i'm confused as to where it comes from.  it isn't in the interface and i don't think it should be in the model.  do you know anything about it?
[19:30] <sinzui> bac: The problem I faced was a year ago. The attr may have been removed from the interface since then. I think I must have because private branches (branch visibility) requires a method
[19:30] <sinzui> s/I think I must/I think IT must/
[19:31] <bac> sinzui: i've removed it from the model and 'test -vvm lp.registry -t product' passes
[19:31] <sinzui> umm
[19:31] <sinzui> well
[19:31] <bac> sinzui: i think it is a leftover
[19:31] <sinzui> I wonder if anything uses it
[19:32] <bac> sinzui: i can't find anything.
[19:32] <sinzui> Nothing obviously uses it in python or template
[19:34] <sinzui> bac: the only use I suspect is 'context/branches' in branch-listing.pt
[19:36] <bac> sinzui: and i'll be that is an oversight
[19:36] <bac> bet
[19:39] <sinzui> bac: I think you are right. I do not see an tests in code for product.branches
[19:39] <sinzui> I see that potemplate still thinks it has a calendar
[19:41] <sinzui> Who wants to remove schoolbell and links to the calendar that was removed fore the release of 1.0
[19:44] <bac> sinzui: in branch-listing.pt the context is an IBranchBatchNavigator not an IProduct, so that's not affected
[19:45] <sinzui> I think then that problem has passed
[19:46] <bac> great.  de-crufting now
[19:53] <mpt> bigjools, I have a question about the Release files in PPA
[19:54] <bigjools> mpt: shoot
[19:54] <mpt> bigjools, <http://www.debian.org/doc/manuals/repository-howto/repository-howto#release> says "Label: Some label adequate for the packages or for your repository."
[19:54] <mpt> bigjools, but <http://ppa.launchpad.net/yorba/ppa/ubuntu/dists/karmic/Release> for example simply has "Label: Ubuntu"
[19:55] <mpt> bigjools, should it perhaps be the display name of the person/team that owns the PPA instead?
[19:56] <mpt> bigjools, e.g. "Label: Yorba"
[20:01] <bigjools> mpt: sorry phone went off
[20:01] <bigjools> let me look
[20:01] <mpt> ok
[20:03] <bigjools> mpt: it could be changed I guess
[20:04] <mpt> bigjools, the reason I ask is that for the Ubuntu Software Center, we want to show a nice display name for each PPA
[20:04] <bigjools> heh, you're very trusting of display names set by users then :)
[20:04] <mpt> bigjools, and (I'm assuming) it would be easier if we could just get that from the Release file we've already read, rather than using the Launchpad API to get the archive's display name
[20:05] <mpt> but showing "Ubuntu" as the name of every PPA wouldn't be so great
[20:05] <bigjools> mpt: it's a trivial change to make if that's what you want, file a bug and I'll get it sorted
[20:06] <bigjools> I've seen some pretty awful display names mind
[20:06] <mpt> bigjools, users need to add PPAs manually in the first place, so I don't think it's a big deal
[20:06] <mpt> though I'm willing to be persuaded otherwise
[20:06] <mpt> bigjools, display names of PPAs?
[20:07] <bigjools> yeah
[20:07] <mpt> Any examples you remember?
[20:07] <bigjools> not off hand, just really short crpytic stuff
[20:07] <mpt> hm
[20:07] <mpt> maybe it appearing like that in the USC will be a forcing function to get them to make the names sensible
[20:07] <mpt> or maybe it won't
[20:08] <bigjools> https://edge.launchpad.net/ubuntu/+ppas?name_filter=
[20:08] <bigjools> see there
[20:08] <wgrant> bigjools: LP doesn't even suggest a possibly correct value any more.
[20:08] <wgrant> So users have no idea what to put.
[20:08] <bigjools> yep
[20:09] <bigjools> "PPA for wangker".... awesome
[20:10] <mpt> If we can't trust the display name the maintainer provides, there isn't anything else we could use, really
[20:10] <bigjools> mpt: do you have plans to inclide all PPAs?
[20:10] <bigjools> or only reviewed ones?
[20:10] <mpt> We could use "PPA for {owner}", but that fails in the case of multiple PPAs
[20:10] <mpt> bigjools, only ones the user has added.
[20:10] <bigjools> mpt: heh we've been through that before, we set the title to "PPA named X for <owner>"
[20:11] <wgrant> And then created keys with those names :(
[20:11] <mpt> bigjools, I guess the Release Label: should actually be set to the PPA display name
[20:12] <bigjools> it should be yeah
[20:12] <mpt> ok, I'll report a bug for that.
[20:12] <bigjools> but I think we need more than that
[20:12] <bigjools> Something like Launchpad PPA "<displayname>"
[20:13] <mpt> By v4, users should be getting software from PPAs without knowing either what Launchpad is or what PPAs are
[20:14] <mpt> This is just a tiny step along that path, but putting either "Launchpad" or "PPA" in the display name would be something we'd eventually have to go back on I think
[20:15] <mpt> However, all PPAs will have the PPA icon to distinguish them from official Ubuntu or Canonical archives
[20:16] <mpt> We have "LP-PPA-" in the Origin: header
[20:16] <bigjools> that's for pinning
[20:17] <mpt> Well maybe, but it would also tell us that it's a PPA, even if the URL didn't
[20:28] <mpt> bigjools, reported bug 492077. Thanks for your answers.
[20:28] <mup> Bug #492077: Release file for PPA contains nondescript "Label: Ubuntu" <Soyuz:New> <https://launchpad.net/bugs/492077>
[20:28] <bigjools> np
[20:29] <mwhudson> bigjools: what build state precedes FULLYBUILT or FAILEDTOUPLOAD ? that's all i'm confused over
[20:29] <bigjools> mwhudson: NEEDSBUILD
[20:31] <wgrant> BUILDING, you mean?
[20:33] <bigjools> err, yes :)
[20:33] <bigjools> but technically I was still right :)
[20:34] <wgrant> True.
[20:35] <mwhudson> "immediately precedes" :)
[20:38] <wgrant> bigjools: Is dogfood going to come alive again at some point?
[20:38] <wgrant> Would be nice to test out the 3.0 stuff on something production-like soonish.
[20:39] <bigjools> wgrant: very soon, the restore finished and subsequent upgrade is done now I looked at my screen session
[20:39] <wgrant> bigjools: Ooh, finally.
[20:39] <wgrant> How long did it end up taking?
[20:39] <bigjools> 17 days
[20:40] <wgrant> Ouuuch.
[20:40] <bigjools> will be qucker next time
[20:40] <bigjools> maybe a week .... :/
[20:40] <bigjools> I'll remember to restore into a tmp db first so I can drop the old one and rename the restored one
[20:40] <wgrant> Good idea.
[20:50] <james_w> wgrant: hi. By any chance have you ever used getPublishedSources for Debian?
[20:51] <ajmitch> 17 days seems to be unusably long
[20:52] <bigjools> \o/ dogfood lives
[20:52] <ajmitch> yay
[20:53] <wgrant> james_w: I have used it occasionally, but not for anything regular.
[20:53] <wgrant> james_w: Why?
[20:54] <wgrant> bigjools: Excellent.
[20:54] <bigjools> ajmitch: yeah there was a bug in the restore script but it will be considerably shorter next time
[20:54] <james_w> wgrant: just wanted a sanity check that it actually worked :-)
[20:54] <wgrant> james_w: Assuming that you're querying for stuff that gina likes, sure.
[20:54] <james_w> I'm investigating why it never seems to do what it does for Ubuntu
[20:54] <wgrant> bigjools: Speaking of gina, it seems to be not picking up some stuff in squeeze properly.
[20:54] <bigjools>  /o\
[20:54] <wgrant> It picks the same source up in sid, but doesn't catch the testing migration.
[20:55] <james_w> yeah, I reassigned a bug the other day that looked like that
[20:56] <wgrant> james_w: boost1.40, wasn't it?
[20:56] <ajmitch> the one that I filed?
[20:56] <james_w> yeah, that was it
[20:57] <wgrant> Actually, I wonder if the mirror is just out of date.
[20:57] <ajmitch> bug 491193
[20:57] <mup> Bug #491193: Debian import of boost1.40 out of date <Launchpad itself:New> <https://launchpad.net/bugs/491193>
[20:57] <wgrant> Because lots of new sid stuff isn't there either.
[20:57] <bigjools> gar
[20:57] <wgrant> (eg. dpkg)
[20:57] <bigjools> 3.0 formats?
[20:58] <ajmitch> most of this stuff isn't, I know boost1.40 isn't
[20:58] <bigjools> k
[20:58] <bigjools> I'll check the logs tomorrow
[20:58] <bigjools> admins are a tad busy at the moment
[20:58] <wgrant> Ah.
[20:58] <wgrant> dpkg seems to now be 3.0, so that explains that.
[20:59] <wgrant> Gaaah.
[20:59] <bigjools> ?
[20:59] <wgrant> dpkg >= 1.15.5 is itself 3.0 (native)
[21:00] <wgrant> Already.
[21:00] <wgrant> So that explains the lack of dpkg imports.
[21:00] <bigjools> ha
[21:00] <james_w> it ran about 5 hours ago and imported ['augeas', 'emacs-goodies-el', 'gtkhtml3.14', 'lxsession', 'mpdtoys'] apparently
[21:01] <wgrant> james_w: Is anything new in squeeze, though?
[21:01] <ajmitch> augeas was only uploaded to sid today, so that part is up to date
[21:03] <james_w> 'xfce4-power-manager' is new in squeeze in the last 60 hours
[21:03] <james_w> plus a few more
[21:22] <barry> sinzui: ping
[21:22] <sinzui> hi barry
[21:23] <barry> sinzui: hi.  you're going to love this.
[21:23]  * sinzui waits for the message that we need to keep moderation
[21:23] <barry> sinzui: bug 409588 is ready.  it's probably a substantive 20 characters or so change.  2325 line diff
[21:23] <barry> sinzui: lots of deletions though
[21:23] <sinzui> ha ha
[21:23] <barry> sinzui: lots of test repair
[21:24] <sinzui> send it to me
[21:24] <barry> sinzui: you are the man
[21:24] <sinzui> barry: what is the delete to add ratio?
[21:25] <barry> sinzui:  22 files changed, 312 insertions(+), 1003 deletions(-)
[21:26] <sinzui> \o/
[21:26] <barry> sinzui: it might be a little bit before i get the merge proposal pushed.  just watch your email.
[21:26] <sinzui> I am available most hours of the day
[21:48]  * thumper afk for a bit
[22:03] <barry> sinzui: mp send.  i hate to do this to you, but i'm away early today.  ping me tomorrow morning with any questions.  good luck!
[22:04] <sinzui> barry: np
[22:22] <james_w> anyone know of any changes in the way launchpadlib/wadllib handle the case of the method?
[22:22] <james_w> I'm seeing caching broken, apparently because wadllib uses "return self.tag.attrib.get('name').lower()" for the method
[22:23] <james_w> and httplib2 only checks against upper case method names
[22:23] <james_w> so it invalidates the cache every time because the method isn't a GET
[22:23] <james_w> however, I don't know why this would have changed on this machine
[22:24] <james_w> because I don't think the packages have been upgraded
[22:27] <sinzui> james_w: I do not see any changes for the current milestone: https://edge.launchpad.net/launchpad-foundations/+milestone/3.1.11
[22:27] <sinzui> or any bugs in launchpadlib about this
[22:28] <james_w> I can't work out what has changed
[22:28] <james_w> I'm pretty sure the cache used to work
[22:28] <sinzui> no api bugs reported in launchpad-foundations either
[22:28] <sinzui> could this by a change from python 2.4 to 2.5?
[22:30] <james_w> ah, good question
[22:31] <wgrant> But isn't this a client-side issue?
[22:32] <lifeless> no, lp is slow so a cache is a must :P
[22:32] <sinzui> wgrant: I assume it should be, but the wadl is not on the client
[22:32] <sinzui> so as james_w asks, maybe the wadl file changed
[22:34] <wgrant> Uhoh.
[22:34] <james_w> no, not a 2.4/2.5 issue
[22:34] <james_w> this machine was always 2.5 default it seems
[22:34] <james_w> so, the wadl has methods specifed as GET
[22:35] <james_w> but when you use a NamedOperation it is lower cased
[22:35] <ajmitch> rollout delayed again?
[22:35] <james_w> this is passed down to httplib2, which doesn't uppercase it, but compares with GET
[22:35] <sinzui> ajmitch: the rollout yesterday wa aborted
[22:36] <ajmitch> sinzui: So I saw, what broke?
[22:37] <sinzui> james_w: named ops have certainly been problematic for my work, but I do not see any changes to them recently (me watches for fixed)
[22:37] <sinzui> ajmitch: The switch to read-only did not work on all machines.
[22:39] <james_w> actually, I don't think it's a regression
[22:39] <james_w> I think it's never worked
[22:40] <james_w> I just only noticed now as I recently added a lot more code that would use operations that weren't cached
[22:40] <sinzui> james_w I think  I agree.
[22:40] <james_w> simple test case: http://paste.ubuntu.com/334146/
[22:40] <james_w> create /tmp/cache
[22:40] <james_w> run that
[22:41] <lifeless> anyone around that knows how the oauth support is glued into httplib requests?
[22:41] <james_w> and then you won't have a file in /tmp/cache with "ssss" in the name as you should
[22:41] <lifeless> I mean, I can check the code, but pointers appreciated.
[22:41] <james_w> lifeless: in launchpadlib?
[22:41] <lifeless> I want to use an oauth ticket to support screen scraping a non-lp oauth protected site.
[22:41] <lifeless> james_w: no
[22:41] <lifeless> or rather ys
[22:41] <sinzui> There may be some justification to not cache, but an explicit cached arg may help
[22:42] <lifeless> yes I want to know how its glued to gether in lplib, so that I can use it from python to do non lplib things
[22:43] <james_w> lifeless: class OAuthSigningHttp(RestfulHttp):
[22:43] <james_w> in launchpad.py in the launchpadlib code base
[22:43] <james_w> RestfulHttp is in lazr.restfulclient, it's a subclass of Http from httplib2
[22:44] <james_w> overrides _request to add the signing headers, then calls the super
[22:44] <sinzui> lifeless: I do not think you need lplib. It is reading you mozilla cookies and passing that info in your requests. The login is automatic if you have authenticated/set-access-privs for the script.
[22:45] <lifeless> sinzui: I don't quite follow, how would python get at mozilla cookies?
[22:45] <sinzui> the lib is reading your filesystem
[23:02] <james_w> https://code.edge.launchpad.net/~james-w/lazr.restfulclient/fix-caching/+merge/15635
[23:03] <james_w> not nice that that is the fix, but it works
[23:04]  * james_w goes back to working around the issue by only ever calling each method once
[23:34]  * mwhudson lunches