[00:04]  * mwhudson lunches
[00:07] <bjf> has anyone tried interacting with lpapi from groovy?
[00:29] <thumper> mwhudson: ping me when you want to talk about code import scheduling
[00:29] <thumper> bjf: not that I know of
[00:29] <thumper> bjf: but I don't know everything :)
[00:33] <bjf> thumper, was just curious, looks like a nice language and I've got a bunch of lp work going on
[00:33] <bjf> thumper, it also talks to databases well and I'm doing that as well
[00:33]  * thumper nods
=== bjf is now known as bjf-afk
[00:47] <thumper> grrrr!!!!!
[00:47] <thumper> attachment fail!
=== jamesh_ is now known as jamesh
[01:02] <EdwinGrubbs> thumper, rockstar: can I get a review for the fix of the missing branch sprite?
[01:02] <thumper> yes
[01:04] <EdwinGrubbs> thumper: you can pretty much ignore the changes in the icon-sprites.positioning file since that is autogenerated. https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-521934-missing-sprites/+merge/19454
[01:04] <thumper> ok
[01:15] <thumper> EdwinGrubbs: done
[01:16] <EdwinGrubbs> thumper: thanks
[01:24] <thumper> rockstar: ping
[01:24] <rockstar> thumper, pong
[01:27] <thumper> rockstar: quick call?
[01:27] <rockstar> thumper, sure.
[01:40] <mwhudson> thumper: say 15:30 for a call about code imports?
[01:40]  * mwhudson actually wants to get some programming done
[01:40] <thumper> mwhudson: sure
[02:44] <mwhudson> thumper: i think i've broken the back of the incremental import thing \o/
[02:44] <mwhudson> for git at least
[02:44] <thumper> w00t
[02:44] <thumper> mwhudson: call soon?
[02:45] <mwhudson> thumper: now, or rather in about 1 min, works for me
[02:45] <thumper> ok
[03:05] <mwhudson> thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/497645/comments/2
[03:05] <mup> Bug #497645: code imports should run fewer jobs at once <code-import> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/497645>
[03:08] <mwhudson> https://bugs.edge.launchpad.net/launchpad-code/+bug/510490
[03:09] <mup> Bug #510490: importds and DB authentication <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/510490>
[04:35]  * thumper back after dinner to finish some stuff off
[04:56] <mwhudson> thumper: incremental git imports all but ready for review
[04:56] <mwhudson> (one test needs some love)
[04:56]  * mwhudson EODs
[08:00] <thumper> is anyone else having issues with firebug and firefox?
[08:01] <thumper> as soon as I go inspect element, or click on the bug on the status bar, firefox crashes
[08:01] <stub> I had it crashing as soon as I tried to get to the error console a week or three ago
[08:02] <stub> I think it is still doing it too
[08:02] <thumper> :(
[08:02] <thumper> stub: I bet the answer will be "upgrade to lucid"
[08:03] <noodles775> thumper: depending on what you need, the chromium inspector might do the job too.
[08:03] <thumper> noodles775: chromium has a whole other pile of issues rendering launchpad
[08:06] <thumper> noodles775: chromium doesn't seem to like the css or the cert
[08:06] <thumper> noodles775: know how to tell it to just FJDI and accept that I know what I'm doing?
[08:07] <noodles775> thumper: you can usually just click through it?
[08:07]  * noodles775 runs dev server
[08:07] <thumper> noodles775: I did click through, but I get no css
[08:07] <noodles775> thumper: ah, you're probably looking at a code.lp.dev?
[08:07] <thumper> noodles775: yes
[08:07] <noodles775> look at lp.dev first...
[08:08] <thumper> WTF?
[08:08] <noodles775> Working now?
[08:09] <thumper> yeah
[08:09] <noodles775> Great.
[08:10] <noodles775> thumper: btw, just in case you haven't already, you'll need the chromium-browser-inspector pkg too.
[08:12] <thumper> noodles775: I'm looking at adding a description to the merge proposal (for the first comment)
[08:12] <thumper> noodles775: I now have two multiline JS editors on the one page
[08:12] <thumper> noodles775: it looks interesting...
[08:12] <noodles775> fun!
[08:17] <adeuring> good morning
[08:18] <noodles775> Moin adeuring
[08:18] <adeuring> hi noodles775!
[08:40] <thumper> noodles775: have you talked to jml about the recipe stuff
[08:40] <thumper> ?
[08:40] <noodles775> thumper: not since two days ago.
[08:41] <thumper> noodles775: probably worth scheduling a chat
[08:41] <thumper> noodles775: jml is planning on talking with james_w about the multiple series on Thursday (after lucid code freeze)
[09:08] <mrevell> Morning
[09:25] <jtv> hi mrevell!
[09:25] <mrevell> Hey jtv!
[09:48]  * gmb could've sworn he ran `make schema`; why's combine-css running?
=== salgado-afk is now known as salgado
[10:59] <deryck> Morning, all.
=== mrevell is now known as mrevell-lunch
=== mrevell-lunch is now known as mrevell
=== beuno_ is now known as beuno
=== salgado is now known as salgado-lunch
=== fjlacoste is now known as flacoste
[14:26] <gary_poster> question for someone on code team: I have two branches that were not imported because of sqllite db locks afaict: https://code.edge.launchpad.net/~gary/zc.buildout/system-python-2-bootstrap-changes and https://code.edge.launchpad.net/~gary/zc.buildout/system-python-3-option-cleanup .  I don't see a bug for this.  Should I file one?  Is there a workaround to get my two branches imported?
=== salgado-lunch is now known as salgado
[14:30] <gary_poster> code team, another question: afaict, I cannot make a MP to request a merge from one imported branch to another (that is, I don't see a way to make a MP request for https://code.edge.launchpad.net/~gary/zc.buildout/system-python-1-simple-fixes ).  If that's the case, then I might as well delete these branches anyway.  Am I right?
[14:31] <gary_poster> abentley, rockstar ^^^
=== Ursinha_ is now known as Ursinha
[14:52] <rockstar> gary_poster, import branches cannot be proposed for merge.
[14:52] <rockstar> gary_poster, if in doubt, file a bug.  We can always close it as a dupe.
[14:58] <deryck> allenap, since you're work is really a feature outside of the two on the board, I'm going to take your bugs off the bugs backlog.  just FYI.
[14:58] <allenap> deryck: Okay.
[14:58] <deryck> allenap, you can continue to pull from the story tag until we make bug sync the feature 1 story.
[14:59] <allenap> deryck: Cool. I'm on a skunkworks project ;)
[14:59] <deryck> heh
[14:59] <deryck> indeed.
[14:59] <deryck> allenap, for a day or two anyway ;)
[14:59] <gary_poster> rockstar ack thank you
[15:03] <allenap> deryck: Do you still want a card for bug 282178?
[15:03] <mup> Bug #282178: Make IPerson an IHasBugs and make sure calling searchTasks on it works <api> <ubuntu-qa> <Launchpad Bugs:In Progress by thekorn> <https://launchpad.net/bugs/282178>
[15:03] <deryck> allenap, I do for that, yeah.  As a bugs lane coding task for you, since you're in progress on that for bug fixing.
[15:05] <allenap> deryck: Okay, I think I get it :)
[15:06] <deryck> allenap, the idea is that we have no actual work in progress that isn't accounted for on the board, and the card limit numbers keep us from taking on too much WIP.
[15:06] <deryck> allenap, so if you do work outside the board, it defeats the purpose of the board.
[15:06] <deryck> allenap, but then there's that skunkworks matter, so it's not perfect now. ;)  But we'll get there as we transition to it. :)
[15:07] <abentley> rockstar, gary_poster: I thought import branches could be proposed for merge.  We've seen that with couchdb.
=== EdwinGrubbs_ is now known as EdwinGrubbs
=== salgado is now known as salgado-brb
[15:38] <rockstar> abentley, you can propose for merge against an import branch, but the branch itself can't be a source_branch of the mp.
[15:39] <deryck> flacoste, ping
[15:40] <flacoste> hi deryck
[15:42] <abentley> rockstar, Ah.
[15:49] <allenap> thekorn: I fixed up those test failures: http://paste.ubuntu.com/378410/
=== salgado-brb is now known as salgado
[16:31] <kfogel> noodles775: when you get a chance, UI review on https://code.edge.launchpad.net/~kfogel/launchpad/255868-patches-view-from-bugs-page/+merge/19438  (there are screenshots attached to bug #255868, so you can just look at those if you want to avoid building the branch).
[16:31] <mup> Bug #255868: Project summary page should show links to patches <story-patch-report> <ubuntu-upstream-relations> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/255868>
[16:34] <kfogel> noodles775: use the most recent two screenshots; the ones before that are from a now-abandoned UI
[16:38] <noodles775> kfogel: sorry, I'm EODing now, but either I can do it first thing in the morning, or you could check whether sinzui would like to do the UI review.
[16:38] <kfogel> noodles775: oh, I didn't know sinzui could.  thanks
[16:38] <kfogel> noodles775: will ask him
[16:39] <kfogel> sinzui: when you get a chance, UI review on https://code.edge.launchpad.net/~kfogel/launchpad/255868-patches-view-from-bugs-page/+merge/19438  (there are screenshots attached to bug #255868, so you can just look at the two most recent screenshots there if you want to avoid building the branch).
[16:39] <mup> Bug #255868: Project summary page should show links to patches <story-patch-report> <ubuntu-upstream-relations> <Launchpad Bugs:In Progress by kfogel> <https://launchpad.net/bugs/255868>
[16:39] <noodles775> He's wanting to build up ui-reviews (at least he was, I keep repeating that, tell me if that's not the case anymore sinzui!)
[16:40] <sinzui> noodles775: I do not have a choice. I think UI reviews are hard and stressful, but We really need to do them
[16:42] <noodles775> sinzui: yes, but I mean particularly whether you'd *like* to do them... ie. with the one earlier today, whether you'd prefer if I just did them now that you've built the number of ui reviews that you've done?
[16:43] <noodles775> (I remember you saying that you hadn't been getting any, so I've been specifically defering to you)
[16:44] <sinzui> yes, I certainly was not getting reviews, and I think you should continue asking for my reviews. But what is the criteria for graduation?
[16:46] <noodles775> sinzui: The chat with beuno - I'd hoped that that was what he wanted to chat with you about the other week before he left. Maybe we should ask him, as his last official service to LP :L
[16:48] <beuno> yes
[16:48] <noodles775> :)
[16:48] <beuno> I want to gradtuate sinzui
[16:48] <beuno> if he will let me
[16:50] <sinzui> kfogel: This change looks consistent. I do not have much to say about it. But I have a question about this layout verses the older layout? Do we know if users are seeing this list of reports better than the old position next to the old chart? I think I miss the icons of the past (but not the CVE icon which always looked super scary)
[16:50] <kfogel> sinzui: when you say the "old" layout, do you mean the one formerly tried in this bug for this specific link, or do you mean something about the portlet box?
[16:51] <kfogel> sinzui: (by the way, I reassigned the UI review to you, from michael)
[16:51] <sinzui> I mean the inline information. This list is now 7 long. IT is not as effective as a smaller list.
[16:52] <sinzui> kfogel: Yes I saw
[16:53] <kfogel> sinzui: I mean, yes, it's now increased by one item (but not sure what that has to do with "the old position next to the old chart")...
[16:53] <kfogel> or with icons?
[16:55] <sinzui> kfogel: deryck: I am looking at http://launchpadlibrarian.net/39277302/255868-screenshot-bugs-with-patches-in-project-group-portlet.png We have now reached the magic number of 7 in the box. If we want to add more reports, I think we need to consider breaking the list up. What I am really asking is if there is evidence now that this list is more or less usable than before
[16:56] <kfogel> sinzui: I don't think we have evidence either way yet.  Do we have any strategy for collecting such evidence?
[16:56] <deryck> sinzui, I don't know of any evidence, no.
[16:56] <beuno> sinzui, lets try and have a call today?
[16:56] <sinzui> beuno: okay
[16:57] <deryck> sinzui, but beuno suggested this link in there back at a UDS session. :-)  And nothing was added until now.
[16:57] <kfogel> sinzui: should we consider that a separate question from the UI review of this particular change?  That is, we may want to further break up the portlet box, but that can be a separate question, before or after this change, I think.
[16:57] <sinzui> kfogel: deryck: okay. As it said at the start, the addition is consistent and I think it is good to land. I think though we have exhausted this list as a means to add more reports
[16:57] <deryck> sinzui, agreed
[16:58] <kfogel> sinzui: "But isn't more always better?"
[16:58]  * kfogel ducks
[16:59] <deryck> sinzui, I think we need 3 separate types of filters -- a "me" section, status filters, and other interesting junk. :-)
[16:59] <deryck> they wouldn't all have to be portlets if those use cases were met.
[17:00] <sinzui> deryck: yes, I think that is what I want to see on my project pages. One day we will do that
[17:05] <sinzui> kfogel: I approved the UI, I would approve the code, but I wonder why there is no test for the presence of the link. Is it okay of the link disappears from the page?
[17:07] <kfogel> sinzui: writing test now
[17:07] <kfogel> sinzui: may I submit the code to you for review when the tests are done?
[17:07] <sinzui> okay. show me when you are ready and I will give the code my +1
[17:07] <kfogel> sinzui: I like the pre-approval, thanks :-).
=== beuno is now known as beuno-lunch
[17:12] <kfogel> sinzui: btw, if no patches, it says "0 bugs with patches".  Having the link disappear in the empty case has both advantages and disadvantages; I went with showing it because I thought it's best for the portlet to maintain a consistent size and shape and contents, and for people to see explicitly that there are no bugs with patches rather than wonder if the feature simply stopped working.
[17:14] <sinzui> kfogel: I know that, I wrote the plural macro with bac. I want "0 bugs with patches" to show all the time. Otherwise users need to hunt for that information, wasting time.
[17:15] <kfogel> sinzui: oh, you wrote that macro?  Thanks!  (Don't know if you saw, but I'm using it.)
[17:16] <sinzui> Yes, I saw, which is why I know that "0" is plural without seeing the page.
[17:22] <bac> sinzui: the blueprints did have a portlet on the distroseries-index page but it is conditional
[17:23] <sinzui> bac: I suspected, but since I see lots of blueprints, I think the condition may be smoking crack
[17:23] <bac> ah, right.  yes i'm looking into it
[17:25] <sinzui> bac: I would not spend a lot of time on this. I think latest bugs and blueprints are flawed. I think they should only show items that younger than 3 months
[17:40] <kfogel> sinzui: re testing: I'm trying to use find_portlet() from lib/canonical/launchpad/testing/pages.py.  But it demands the portlet's name, as text between <h2> tags, and in this case the portlet has no name.  Is there some typical way to examine the text in the bugfilters-portlet in a test?
[17:41] <sinzui> do not use find portlet, it is a 1.0 test helper
[17:41] <kfogel> sinzui: oh
[17:41] <kfogel> sinzui: ok :-)
[17:42] <sinzui> kfogel use find_tag_by_id which is good and also faster because you can pass existing soup object
[17:42] <kfogel> sinzui: I'm starting out with page tests, just to see that the right thing happens, but am I right in thinking I'll also need to write a windmill test b/c this portlet is populated with data by a javascript call?
[17:43] <sinzui> no windmill, we just need to see that the link is in the portlet list
[17:44] <kfogel> sinzui: *nod*
[17:44] <kfogel> sinzui: should be done soon then
[17:45] <salgado> rockstar, should I assign bug 514400 to you?
[17:45] <mup> Bug #514400: Make combine-css skip work when it is not needed <Launchpad Foundations:Triaged by salgado> <https://launchpad.net/bugs/514400>
[17:45] <rockstar> salgado, yes.  In fact, I'm making headway on that now.
[17:45] <salgado> cool!
[17:46] <rockstar> salgado, what's weird is that lazr-js has the ability to do this already, but the launchpad Makefile seems to ignore it.
[17:46] <salgado> rockstar, but can we use that even for combine-css or is this something we could use in the jsbuild target only?
=== beuno-lunch is now known as beuno
[18:00] <rockstar> salgado, I'm not sure what you mean.  combine-css and the jsbuild stuff use similar code paths from lazr-js
=== danilos is now known as daniloff
[18:09] <salgado> rockstar, combine-css uses just lazr.js.combo.combine_files()
[18:09] <kfogel> sinzui or anyone: want to play Captain Obvious on my page test?  http://paste.ubuntu.com/378501/
[18:10] <sinzui> find tags by class does not except a soup object.
[18:10] <kfogel> sinzui: *nod* thx
[18:10] <sinzui> kfogel: find_tags_by_class is another helper that should not be used
[18:10] <kfogel> sinzui: oh
=== deryck is now known as deryck[lunch]
[18:11] <kfogel> sinzui: do we mark things as obsolete when we decide they're obsolete, in some way that would get a warning when the thing is used at run time?
[18:11] <sinzui> it is slow, and prone to failure as pages change. We use ids to test
[18:11] <thekorn> allenap, great!
[18:12] <sinzui> kfogel: place a id on any element you want to test.
[18:12] <rockstar> salgado, yeah, so does jsbuild.
[18:12] <rockstar> salgado, well, no, I take that back.  They both use a subclass of lazr.js.build.ComboFile
[18:13] <kfogel> sinzui: so I should change the generated html to be more testable?
[18:13] <sinzui> yes
[18:13] <kfogel> sinzui: ok
[18:13] <kfogel> sinzui: but, oddly, I just got "None" for the portlet, using this code:
[18:13] <kfogel>     >>> def show_bugs_with_patches_from_portlet(contents):
[18:13] <kfogel>     ...     portlet = find_tag_by_id(contents, 'portlet-bugfilters')
[18:13] <kfogel>     ...     print portlet
[18:14] <kfogel> oh
[18:14] <kfogel> duh
[18:14] <kfogel> nm
[18:14] <kfogel> wrong id I ihnk
[18:14] <sinzui> kfogel: in many cases when you are updating a page, you really just want to update the existing story to show what the user seed
[18:14] <kfogel> sinzui: ah -- maybe I should be looking for the existing tests of that portlet, instead of adding a new test to patches-view.txt, then?
[18:14] <sinzui> kfogel: isn't there already a story that verifies the contents of the portlet, and did it fail when you changed the page?
[18:15] <kfogel> sinzui: dunno, am in EC2 right now
[18:15] <kfogel> sinzui: but I'll grep around for it.  thanks for the advice_
[18:16] <kfogel> sinzui: lib/lp/bugs/stories/xx-bugs-statistics-portlet.txt   :-)
[18:16] <sinzui> yep
[18:33] <rockstar> salgado, hi
[18:34] <salgado> hi rockstar
[18:35] <rockstar> salgado, could I call you?
=== EdwinGrubbs is now known as Edwin-lunch
[18:39] <salgado> rockstar, I'm with gary reviewing a branch over on #launchpad-foundations; can it be in, say, 15 minutes?
[18:40] <rockstar> salgado, yes, just ping me when you're done.
[18:40] <salgado> will do
=== gary_poster is now known as gary-lunch
[19:00] <salgado> rockstar, I'm ready now
[19:00] <rockstar> salgado, cool.  Skype?
=== deryck[lunch] is now known as deryck
[19:19] <mwhudson> good morning
[19:34] <adiroiban> hi. the code from lib/lp/services/worlddata is part of registry project?
[19:38] <sinzui> adiroiban: launchpad-foundations
[19:39] <sinzui> salgado: ping
[19:39] <adiroiban> sinzui: thanks
[19:39] <salgado> hi sinzui
[19:40] <sinzui> salgado: I am looking at OOPS-1506G1386 which is a very common occurrence in production. It is caused by an email address that belongs to an account but not a person
[19:41] <sinzui> salgado: validate_action_add_email tries to do the right thing by checking if you own the address, or tells you who owns it. It does in the or case.
[19:41] <salgado> I was looking at that today as well: bug 423447
[19:41] <mup> Bug #423447: Trying to add an email that's already registered as a SSO account but not a person, oopses <oops> <Launchpad Foundations:Triaged by salgado> <https://launchpad.net/bugs/423447>
[19:42] <sinzui> salgado: I am trying to decide how to fix this. I think I need to use ensure person on the email.person *before*  it checks if the person is the current user or someone else
[19:44] <salgado> sinzui, that might create a Person entry for someone who's not a Launchpad user
[19:44] <sinzui> salgado: exactly my concern
[19:46] <sinzui> salgado: This event implies these are the same users, so we need to merge accounts, but we cannot until both accounts has a person, which sounds like a bad design :(
[19:47] <salgado> yeah, that's exactly why I said this is a tricky one in that last comment on the bug report
[19:48] <salgado> we could "merge" accounts, maybe?
[19:49] <sinzui> salgado: yes that sounds right (and lightweight), but we have never exposed an account in traversal. I think we need a new kind of login/authtoken
[19:52] <salgado> sinzui, yes, I think we'd need that, but this might become a non-issue once we split the auth/main databases for real
[19:53] <sinzui> yes
=== gary-lunch is now known as gary_poster
[19:59] <sinzui> salgado: if we do not know how to fix this, we could at least avoid the oops by adding a third condition that states the email address is owned by a email.account.displayname. We provide an action for the user to choose a merge. the action will create the Person for the account and then redirect to +requestmerge
[20:00] <salgado> sinzui, that sounds good to me.  another option would be to change the view that handles ACCOUNTMERGE tokens to create the missing Person, if needed
[20:01] <sinzui> no, that is ugly too. What happens when the user decides that the SSO account is the master, and the current person/account is the dupe?
[20:01] <salgado> since an SSO account is identified by its email address, I don't think that's a problem
[20:02] <salgado> we'd move the email address to the remaining account, so to the user it'd seem as if there ever was just one account
[20:03]  * sinzui ponders if he looses U1 data if his email address goes to an account that has not used U1
[20:03] <kfogel> sinzui: My mods to make that bugs portlet test expect the new stuff don't seem to take effect -- I'm wondering if I'm missing something obvious.  http://paste.ubuntu.com/378578/
[20:06] <thumper> morning
[20:07] <sinzui> salgado: I think adding a 3rd condition and creating the person as needed by ACCOUNTMERGE is a right, but I really do not know who other apps use account, and I wonder is bad things are happening know when we merge persons.
[20:13] <sinzui> kfogel: the output implies that there are more lines to change, or worse, we are over testing the whole portlet.  I see 5 failure *before* the part of the test you changed.
[20:14] <kfogel> sinzui: I'm accustomed to seeing "ghost failures" that precede an actual failure, but what puzzles me is that the change in my branch is minimal (just adds that new line to the portlet), and yet the same test currently passes in db-devel pristine.
[20:14] <adiroiban> when exposing a new interface via LP API, after adding export_as_webservice_entry, should I do any other steps to be listed in +apidoc?
[20:15] <sinzui> kfogel: I think the test failures are legitimate, though I question why everything is tested twice for a story...this looks like state testing that I would do in a unittest.
[20:16] <sinzui> kfogel: You changed the obvious print_portlet_contents calls, but not the print_portlet that often precede the test you changed
[20:17] <kfogel> sinzui: no idea how I missed that.  Thank you for the clear eyes.
[20:18] <kfogel> sinzui: (after a certain point, a lot of similar stanzas start to look the same, sigh)
[20:18] <sinzui> kfogel: this is not a story. it is a bad test, though this is the right place to make your addition.
[20:20] <kfogel> sinzui: sigh.  I want to file an XXX, but... every place I turn (and adeuring confirms this is not unusual) there's something like that, where we all agree it's not ideal and that it should be fixed.  I could have, almost literally, spent my entire day filing XXXs.
[20:23] <sinzui> kfogel: yes. That is why adding to this test is the right thing at this moment. We don't need another note stating the obvious
[20:23] <kfogel> sinzui: :-)
[20:24] <kfogel> sinzui: is it necessary to add a test anywhere expecting a non-zero patches count?
[20:25] <sinzui> Looks like it in this test. I would consider using "..." in places where we really do not want to do duplicate verification
[20:27] <sinzui> adiroiban: no the API is generated from the introspection of the interface
[20:28] <kfogel> sinzui: sorry, didn't understand "Looks like it in this test."  (agree about the ... thing, in the general case)
[20:29] <sinzui> kfogel: this test looks like it really wants you to risk a hand injury repeating uninteresting information
[20:30] <kfogel> sinzui: agreed, but I can use ... to elide that stuff.  My question is, should we also test for a case where there are more than 0 bugs with patches?  If so, I'm tempted to do it in patches-view.txt instead of in xx-bugs-statistics-portlet.txt, but would like your opinion.
[20:30] <sinzui> kfogel: yes, you are right on all points
[20:31] <kfogel> sinzui: cool, thanks for the help.  off to do that now, then will submit to you for review
[20:32] <kfogel> sinzui: is there any way for me to "import" print_portlet() and print_portlet_contents() from that other test, or do I need to move those two methods to some other place first?
[20:32] <kfogel> e.g. ./lib/canonical/launchpad/testing/pages.py
=== Edwin-lunch is now known as EdwinGrubbs
=== salgado is now known as salgado-afk
[20:34] <sinzui> kfogel: you would need to move the two helpers into a module first, then reimport them into a doc test.
[20:35] <adiroiban> sinzui: hm... but it looks like +apidoc/index.html is mapped to lib/canonical/launchpad/apidoc/index.html, and this is a static file. make apidoc is not updating this file.
[20:36] <kfogel> sinzui: (is pages.py (see above) the right module?)
[20:36] <sinzui> adiroiban: make build generates the wadl doc
[20:40] <jtv> adiroiban: your branch has landed
[20:40] <adiroiban> sinzui: thanks. Then something is fishy on my side as after running make build, the wadl files and apidoc/index.html were not updated
[20:40] <sinzui> hmm
[20:41] <adiroiban> jtv: thanks. I'm waiting to hit edge and I will test it
[20:41] <jtv> cool
[20:52] <bac> hi sinzui - you free for a quick call?
[20:57] <adiroiban> jtv: do you have time to answer some questions regarding adding something to the Launchpad API? I have something like this: http://paste.ubuntu.com/378609/
[20:58] <adiroiban> but make apidoc, make build or make run will not update the +apidoc/index.html
[20:58] <sinzui> adiroiban: it does not update, delete it first
[20:59] <jtv> adiroiban: all I can add to what sinzui says is, "hey, great that you're doing that!" :-)
[21:02] <adiroiban> it worked. thanks! Can I add this note to https://dev.launchpad.net/API/ImplementingAPIs ?
[21:12] <sinzui> adiroiban: I think we need to document that trick some where. I think I discovered it as 45 minutes of shouting at my computer
[21:12] <sinzui> bac: I am available now
[21:15] <sinzui> bac: this is the report we are linking to from the new portlet https://edge.launchpad.net/ubuntu/lucid/+needs-packaging
[21:16] <adiroiban> sinzui: I have added a tips and tricks section on ImplementingAPIs wiki page. I put this info togheter with some tips from wgrant to simplify the testing of APIs
[21:17] <wgrant> sinzui: Hm, that view name is suboptimal.
[21:17] <wgrant> "needs-packaging" is a bug tag meaning that some software needs to be packaged.
[21:17] <sinzui> wgrant: rock, file bugs and tell me how to make this work
=== bjf is now known as bjf-afk
[21:20] <rockstar> thumper, this looks much better: https://devpad.canonical.com/~rockstar/floating.png
[21:20] <thumper> rockstar: +1 on that
[21:20] <deryck> Have a nice <whatever-day-part-applies>, all.  I'm out.  cheers.
[21:23] <rockstar> thumper, great.  I'll pass that on to abentley.
[21:36] <mwhudson> thumper: i'm re-requesting mirrors on those brancehs james_w mentioned, i think that'll clear most of the formats up
[21:37] <thumper> mwhudson: cool, I was going to ask;)
[21:37] <james_w> thanks mwhudson
[21:37] <james_w> that's based on what the db thinks fwiw
[21:38] <mwhudson> james_w: ok, that's good to know
[21:38] <mwhudson> (and a good thing to check, i think)
[21:40] <thumper> yeah, if the db thinks it is 2a then the puller and scanner both worked
[21:44] <thumper> mwhudson: we should talk about the recipe stuff some more, perhaps around 1pm?
=== bjf-afk is now known as bjf
[21:47] <mwhudson> thumper: okay
[22:11] <Ursinha> how could I searchTasks using the order_by parameter? I'm trying to order_by date_created and it gives a KeyError
[22:12] <poolie> Ursinha: it's 'datecreated'
[22:12] <Ursinha> poolie: ahhh
[22:12] <Ursinha> poolie: thanks :)
[22:12] <poolie> i found this out by grepping the code :-/
[22:12] <poolie> np, you're welcome
[22:12] <wgrant> I normally work it out by doing an advanced search and looking at the query string.
[22:12] <poolie> i think i tried that
[22:12] <poolie> there might be an intermediate level of mapping
[22:15] <Ursinha> poolie: maybe it would be nice to have a list in the api docs
[22:15] <poolie> i agree
[22:15] <Ursinha> poolie: I'll file a bug
[22:15] <poolie> you could add a tip to the api faq in help.l.n or wherever it is
[22:15] <wgrant> It would be nice if bug search didn't suck, too.
[22:15] <Ursinha> wgrant: :)
[22:16] <poolie> there are some interesting recent bugs in https://bugs.edge.launchpad.net/launchpadlib/+bugs
[22:16] <poolie> mostly 'be faster'
[22:17] <rockstar> thumper, any idea where the launchpad.branches is exposed for launchpadlib?  It thinks getByUniqueName is exposed, but I don't see where.
[22:17] <thumper> rockstar: not really, jml did that bit, but try grep :)
[22:18] <rockstar> thumper, grep doesn't seem to be very helpful.
[22:18] <rockstar> Or maybe it's just too noisy and I need to adjust the squelch on it.
[22:19] <rockstar> Ah, I see now.
[22:22] <thumper> rockstar: where? I didn't see it
[22:23] <Ursinha> poolie: I guess it's somehow bug 256940
[22:23] <mup> Bug #256940: Make it possible to discover enumerated values <launchpadlib :Triaged> <https://launchpad.net/bugs/256940>
[22:24] <thumper> wgrant: ping
[22:24] <rockstar> thumper, IBranch has pass-thru methods for IBranchLookup
[22:24] <rockstar> Unfortunately, it doesn't seem to work.
[22:25] <wgrant> thumper: Hi.
[22:25] <thumper> wgrant: do you know if sourcepackagename is exported anywhere?
[22:25] <thumper> wgrant: I was considering exporting the text of the name from the sourcepackage object
[22:25] <wgrant> thumper: Exporting it is forbidden. Just export a text field.
[22:26] <thumper> wgrant: yes... that is what I ment, but do you know if it is done anywhere yet
[22:26] <wgrant> thumper: See ISourcePackagePublishingHistory
[22:27] <thumper> wgrant: defined where?
[22:27] <wgrant> thumper: lib/lp/soyuz/interfaces/publishing.py
[22:27] <thumper> ta
[22:27] <thumper> wgrant: just wanted to be consistent in naming
[22:27] <wgrant> Good idea.
[22:29] <thumper> fooey
[22:29] <thumper> it is exported but as "name"
[22:29] <thumper> yay (not)
[22:29] <wgrant> Heh.
[22:30] <thumper> oh well, at least I don't need to do that
[22:31] <james_w> there is source_package_name elsewhere I think
[22:31] <thumper> james_w: yeah, on the publishing history that wgrant mentioned
[22:31] <thumper> james_w: I'm just exposing the sourcepackage on the branch
[22:31] <thumper> through the api
[22:32] <james_w> and source_name
[22:32] <james_w> and package_name
[22:32] <james_w> so, clearly you need to pick a new one
[22:33] <thumper> james_w: how about package_source_name?
[22:33] <james_w> unused, good choice!
[22:33] <thumper> w00t
[22:34] <poolie> hello james_w
[22:34] <james_w> hi poolie
[22:34] <poolie> james_w: jam was having some trouble getting import-packages running to test it
[22:34] <poolie> i don't know if he already posted or spoke to you about it
[22:34] <james_w> he has
[22:34] <poolie> k
[22:35] <james_w> I think it's running now, if a little slow for him
=== Ursinha is now known as Ursinha-afk
[23:37] <jml> rockstar, I'm pretty sure the getByUniqueName API works.
[23:37] <rockstar> jml, yes, there was a previous facepalm moment that was not announced on IRC.  :)
[23:38] <jml> rockstar, :)
[23:50] <leonardr> gary, flacoste: the new launchpadlib was packaged and uploaded to debian earlier today