[00:00] <mwhudson> dhillon-v10: yeah, i'd look for something smaller i think
[00:01] <dhillon-v10> mwhudson: would you be around in like 5 mins. until i find something else?
[00:01] <mwhudson> dhillon-v10: i'll have lunch soon, but i'm around for another 4 hours or so
[00:01] <mwhudson> dhillon-v10: you could try looking at https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=trivial
[00:02]  * mwhudson has lunch now, in fact
[00:10] <dhillon-v10> mwhudson: when you get back, look at this one: https://bugs.edge.launchpad.net/launchpad-code/+bug/294048 it doesn't seem too bad
[00:10] <mup> Bug #294048: Branch name ambiguous in revision feed for a person <feeds> <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/294048>
[00:20] <mwhudson> dhillon-v10: yeah, that looks more suitable
[00:22] <dhillon-v10> mwhudson: and I found another one that is a typo :)
[00:22] <mwhudson> dhillon-v10: even better :-)
[00:24] <dhillon-v10> mwhudson: one question, its a little unrealted, I develop kernel drivers for open-solaris, and we use something called open-grok which is a pretty amazing source-code browser, it can locate almost every instance of a word,struct,function and other stuff easily, I want to use that to index launchpad code, when I do that, is it possible to deploy that to a website, opengrok needs tomcat so what do you think about that
[00:25] <mwhudson> dhillon-v10: it sounds interesting, but i don't think we have tomcat anywhere so i don't think it could be on our servers
[00:26] <dhillon-v10> mwhudson: in finding typos like that one, I can just type in the word, and it will find the exact file that it is in, do you want to see a sample, I can set it up locally and you can see it :)
[00:26] <mwhudson> dhillon-v10: i can do that on my machine with grep easily enough...
[00:27] <dhillon-v10> mwhudson: ohh, I forgot about grep, thanks that saved my 10 mins. of configuration setup :)
[00:28] <mwhudson> 'bzr ls --versioned --recursive --null --kind file | xargs -0 egrep ... ' is handy, if a little wordy
[00:32] <wgrant> mwhudson: There is, and it works. But I got distracted when that revealed a whole lot of other isues in process-upload, which make it difficult to test.
[00:33] <mwhudson> wgrant: can you link it to the bug?
[00:37] <wgrant> mwhudson: Done.
[00:37] <mwhudson> wgrant: ta
[00:47] <dhillon-v10> mwhudson: someone fixed that typo before me: https://bugs.launchpad.net/malone/+bug/415170
[00:47] <mup> Bug #415170: Typo in AJAX milestone picker class <bug-page> <trivial> <ui> <Launchpad Bugs:Fix Released> <https://launchpad.net/bugs/415170>
[00:47] <dhillon-v10> mwhudson: I closed it :)
[00:48] <mwhudson> dhillon-v10: hah
[01:26] <dhillon-v10> mwhudson: have a look at this one: https://bugs.launchpad.net/soyuz/+bug/410331 , there's a default name but only for the first time someone activated their ppa, does it make sense to have it there every single time
[01:26] <mup> Bug #410331: PPA: should default to sensible/good name (or give example) <ppa> <trivial> <ui> <Soyuz:Triaged> <https://launchpad.net/bugs/410331>
[01:29] <mwhudson> dhillon-v10: not really my area, but i don't see why not
[01:30] <wgrant> There is no default name at all any more.
[01:30] <wgrant> Note that the bug is about the *display* name.
[01:32] <dhillon-v10> wgrant: I looked in staging and ppa shows up in the default name field, but you are right :) no display name there
[01:34] <dhillon-v10> mwhudson: this will have to be edited: http://pastebin.com/d42ab475d
[01:35] <mwhudson> dhillon-v10: yeah
[01:36] <mwhudson> dhillon-v10: it would be good for the default to update as the name is updated but that sounds fiddly...
[01:36] <dhillon-v10> mwhudson: Curtis suggested that on the bug report, so I just put that there :)
[01:46] <dhillon-v10> mwhudson: so what do you say, should I go ahead and make that edit, then put add a patch to that bug report, so you can review it and push it ?
[01:46] <mwhudson> dhillon-v10: i might let someone from the soyuz team review it and you should put the change in a branch, not a patch
[01:46] <mwhudson> but otherwise yes :-)
[01:47] <thumper> mwhudson: you'll be happy to know that we are killing weekly chr
[01:47] <mwhudson> thumper: i heard this rumour
[01:47] <thumper> of a sort anyway
[01:47] <mwhudson> thumper: but i thought i should do it today at least
[01:47] <thumper> some things back to daily
[01:47] <thumper> mwhudson: yeah, not sure when the "new" - old way comes back
[01:54] <thumper> Ursinha: the getBranches update is being kicked off with ec2 land now
[01:57] <dhillon-v10> thumper: hi :) I remember you from the developer week
[01:57] <thumper> dhillon-v10: which developer week?  I did one ages ago
[01:58] <dhillon-v10> thumper: it was the one with launchpad api, you were only there for a few moments someone else actually did the session
[01:58] <thumper> ah
[02:01] <dhillon-v10> mwhudson: for pushing a branch, do I have to download the entire edge branch again (I already did it to setup my developmental environment) or is there another way
[02:01] <dhillon-v10> mwhudson: sorry for taking a lot of your time, once I get proficient at this, I won't bother you as much :)
[02:02] <mwhudson> dhillon-v10: do you have a shared repository locally?
[02:04] <Ursinha> thumper: awesome! :)
[02:04] <dhillon-v10> mwhudson: I don't think so
[02:04] <mwhudson> dhillon-v10: did you run rocketfuel-setup ?
[02:05] <dhillon-v10> mwhudson: yes
[02:06] <mwhudson> dhillon-v10: ok, so you have a ~/canonical directory and a trunk directory in there?
[02:06] <mwhudson> what does 'bzr info' say in the ~/canonical directory?
[02:07] <dhillon-v10> mwhudson: just a sec.
[02:09] <dhillon-v10> mwhudson: this is what i get on the top-level directory: http://pastebin.com/m3f21dc01
[02:09] <dhillon-v10> mwhudson: and yes I do have a local shared repo. :)
[02:09] <mwhudson> dhillon-v10: then the usual practice is to "bzr branch trunk fix-bug-$BUG_NUMBER" in the repo
[02:10] <mwhudson> make your changes in the branch you just created
[02:10] <mwhudson> then commit, push lp:~<you>/launchpad/fix-bug-$BUG_NUMBER
[02:13] <dhillon-v10> mwhudson: ok will do, right now updating my branch after that will follow the steps you listed above :)  thanks a lot for your help
[02:26] <dhillon-v10> mwhudson: it says not a branch Not a branch: "/home/vikram/launchpad/lp-branches/devel/trunk/".
[02:26] <mwhudson> um
[02:26] <mwhudson> oh sorry
[02:27] <mwhudson> dhillon-v10: cd /home/vikram/launchpad/lp-branches/; bzr branch devel <new-branch-name>
[02:27] <dhillon-v10> mwhudson: yeah I already did that and it worked :)
[02:28] <dhillon-v10> mwhudson: I figured if trunk doesn't exist then I can branch devel
[02:40] <dhillon-v10> mwhudson: one bug down :) i pushed the branch, now do I request a merge or does it get reviewed first
[02:40] <mwhudson> dhillon-v10: request a merge
[02:41] <dhillon-v10> mwhudson: alright thanks again, that was my first change :)
[02:41] <mwhudson> dhillon-v10: woo
[02:42] <dhillon-v10> mwhudson: just curious, how many changes have you made, give me like 2 years and i'll catch up to you :)
[02:43] <mwhudson> dhillon-v10: um, not sure, must be a few hundred
[02:43] <dhillon-v10> mwhudson: wow that's a lot to catch up on, but I'll do it, just wait :)
[02:44] <mwhudson> dhillon-v10: it's my full time job, that gives me a bit of an advantage!
[02:45] <dhillon-v10> mwhudson: oh I forgot you work for canonical :P  i go to school which is a big pain
[02:46]  * thumper is moving on
[02:51] <dhillon-v10> mwhudson: last question of the day :) is it okay if I push launchpad code to google code, it has a little function search feature that makes it easy to search for functions and so on
[02:51] <mwhudson> dhillon-v10: so long as it's marked as AGPLv3, sure
[02:52] <dhillon-v10> mwhudson: yeah, all my projects are with GPL :) alright so thanks a lot, and good night
[02:56] <wgrant> mwhudson, dhillon-v10: Google Code does permit AGPLv3, AFAIK.
[02:56] <wgrant> Er, "does not" permit.
[02:58] <dhillon-v10> wgrant: http://code.google.com/p/launchpad-ubuntu/
[02:58] <dhillon-v10> wgrant: that was changed a while ago :)
[02:59] <wgrant> Ubuntu?
[02:59] <wgrant> Why Ubuntu?
[03:00] <dhillon-v10> wgrant: it just sounds good, and also because ubuntu uses launchpad, something wrong with it??
[03:01] <wgrant> Launchpad doesn't need any more publicity about it being linked to Ubuntu.
[03:01] <wgrant> :/
[03:01] <dhillon-v10> wgrant: okay, I'll change it, if google code allows me to :)
[03:19] <bjf> i'd like to know if I can use searchTasks to search only the last 6 months, or to at least order the search results by date
[03:20] <bjf> i've used order_by='-id' but can't figure out how do order_by date
[03:23] <mwhudson> bjf: what do you mean by 'date' ?
[03:23] <mwhudson> bjf: date created?
[03:23] <bjf> mwhudson, date_created
[03:23] <wgrant> -datecreated
[03:24] <bjf> wgrant, that worked, thanks!  where would I have found that out on my own?
[03:25] <bjf> wgrant, is there a way to limit the search to the last 6 months?
[03:25] <wgrant> bjf: I don't know how I knew it -- maybe from looking at query strings for normal bug searches.
[03:25] <wgrant> bjf: There is no way to do that.
[03:25] <bjf> wgrant, thanks
[03:31] <bjf> if I take the resulting collection from searchTasks and try to only look at the last 500 with taskSearch(order_by='-datecreated')[:500] I get an "file too long" error
[03:31] <bjf> https://pastebin.canonical.com/27522/
[03:32] <mwhudson> that's a launchpadlib bug
[03:33] <mwhudson> https://bugs.edge.launchpad.net/launchpadlib/+bug/512832, at least
[03:33] <mup> Bug #512832: launchpadlib caches based on full URL <launchpadlib :New> <https://launchpad.net/bugs/512832>
[03:34] <bjf> mwhudson, ack
[03:51] <bjf> mwhudson, just ran int that bug again (for a slightly different reason) the only workaround I can think of is to use taskSearch without any parameters
[03:51] <mwhudson> bjf: i don't have any great ideas sadly
[03:52] <bjf> mwhudson, thanks, thought I'd at least ask
[03:52] <mwhudson> well, apart from fixing launchpadlib to cache in directories named after the SHA1 or something
[03:53] <bjf> mwhudson, is that bug on anyone's "soon to be fixed" list? :-)
[03:53] <mwhudson> bjf: i don't know
[03:54] <mwhudson> let me push up the priority at least
[05:16] <Ursinha> mwhudson: something crossed my mind now: all branches merged to devel/db-devel are necessarily in lp?
[05:16] <mwhudson> Ursinha: i guess theoretically not, but that seems very very unlikely
[05:16] <Ursinha> mwhudson: hm
[05:17] <Ursinha> mwhudson: same way, all branches merged to db-devel/devel need a merge proposal before being merged?
[05:17] <mwhudson> Ursinha: no
[05:18] <Ursinha> mwhudson: right
[05:18] <mwhudson> testfix branches don't always have merge props for example
[05:19] <Ursinha> mwhudson: but they are in lp?
[05:19] <mwhudson> Ursinha: yeah
[05:19] <mwhudson> the branch has to be somewhere internet accessible to merge
[05:20] <mwhudson> you *could* push to devpad i guess, but it's really not very likely
[05:21] <Ursinha> mwhudson: I see
[05:22] <Ursinha> mwhudson: well, I'll work with monitoring branches that are merged to devel/db-devel in lp
[05:22] <mwhudson> Ursinha: that should be fine
[05:22] <Ursinha> mwhudson: I hope so :)
[05:22] <Ursinha> mwhudson: thanks for the thoughts
[05:23] <mwhudson> Ursinha: np
[08:31] <adeuring> good morning
[08:37] <noodles775> Morning adeuring and all.
[08:37] <adeuring> Hi noodles775!
[08:54] <jml> good morning
[08:56] <jml> noodles775, I'm going to acquaint myself with the last week of discussion of buildbranchtoarchive
[08:57] <beuno> hey jml
[08:59] <noodles775> jml: great, thanks.
[09:04] <jml> beuno, hi
[09:04] <jml> beuno, I'm working from home today & for the rest of this week, fwiw
[09:05] <beuno> jml, I expected as much. It's too cold to do anything else  :)
[09:06] <mrevell> Hello friends
[09:06] <beuno> hey mrevell
[09:06] <mrevell> Hi there beuno, congrats on your new role
[09:07] <jml> beuno, also, despite the length in calendar days, I've really only just moved in. I need to be home to receive deliveries of bookshelves and the like
[09:07] <beuno> jml, sounds exciting
[09:07] <beuno> mrevell, thanks  :)
[09:08] <jml> beuno, yeah, I'm quivering with anticipation.
[09:10] <jml> how do I tell whether an import branch is bzr-svn or cscvs svn
[09:10] <wgrant> There's a tooltip somewhere.
[09:13] <jml> somewhere.
[09:14] <wgrant> In "This branch is an import of the Subversion branch [...]", "Subversion" has a tooltip.
[09:16] <jml> subtle
[09:16] <jml> wgrant, thanks for the "tip" (get it!?!?!)
[09:16] <wgrant> Rather.
[09:16] <wgrant> Ha ha ha.
[09:47] <beuno> jml, how can I find a list of all MPs with the
[09:47] <beuno> "ui" review tag in them?
[09:51] <jml> beuno, there's no UI for that.
[09:51] <jml> beuno, probably not an API either.
[09:52] <beuno> jml, can I get all MPs against launchpad through the API?
[09:52] <jml> beuno, the 'review type' thing isn't really a tag, fwiw. perhaps it ought to be.
[09:52] <jml> beuno, hmm.
[09:52] <james_w> lp.projects['launchpad'].getMergeProposals() I believe
[09:52] <jml> beuno, I don't know. I could find out by looking at the API docs. Want me to do that?
[09:52] <jml> james_w, hello :)
[09:52] <beuno> jml,
[09:52] <james_w> status=[<list of statuses you want>]
[09:52] <james_w> hi jml
[09:53] <beuno> james_w, you should be on the code team
[09:53] <beuno> thank you
[09:54] <james_w> I'd love it if I could get these landed: https://code.edge.launchpad.net/~james-w/launchpad/
[09:55] <beuno> james_w, my "ec2 land" is broken, but jml was nice enough to land my branch last week, he may still have niceness in him
[09:57] <james_w> what do you mean? jml is always overflowing with niceness
[09:57] <jml> jelmer, may I encourage you to reply to Michael Hudson's "[Launchpad-dev] plan for incremental code imports" email?
[09:58] <jml> james_w, happy to do so.
[09:58] <jelmer> jml: consider me encouraged.
[09:58] <jml> jelmer, :D
[09:58] <james_w> thanks jml
[09:58] <jml> james_w, although I think I'm going to propose in future that we make this sort of thing the OCR's job.
[10:00] <james_w> for the older one I think it was submitted, perhaps twice, so I think that has more to do with the fragility of the process. Having the OCR chase up approved but not merged branches would be a good idea though.
[10:20] <noodles775> jml: will you have time for a call before lunch?
[10:21] <jml> noodles775, probably not.
[10:21] <jml> noodles775, but I'll almost certainly be ready right after
[10:21] <jml> noodles775, unless you want a call right now
[10:21] <noodles775> jml: right now is fine too.
[10:22] <jml> james_w, both branches are now being tested on ec2
[10:22] <noodles775> jml: sorry, right now as in 2 mins :/
[10:22] <jml> noodles775, np :)
[11:28] <beuno> does anyone know a way around bug 512832?
[11:28] <mup> Bug #512832: launchpadlib caches based on full URL <launchpadlib :Triaged> <https://launchpad.net/bugs/512832>
[11:29] <beuno> I can't use launchpadlib at all  :(
[11:36] <beuno> james_w, is there anyway to get all the MPs I've reviewed?
[11:38] <BjornT> beuno: if you have an encrypted home dir, a workaround can be to symlink the .launchpadlib/ dir to an unencrypted folder. that made it work for me
[11:42] <beuno> BjornT, thanks, I'll try that
[11:44] <maxb> salgado: Hi, did https://code.edge.launchpad.net/~maxb/launchpad/py2.6-importfascist disappear in a puff of ec2?
[11:46] <beuno> BjornT, that totally worked, thank you
[11:47] <salgado> maxb, thanks for reminding me of it -- the test suite was hung and the instance failed to shut down
[11:47] <salgado> maxb, I'll submit it again
[11:47] <maxb> thanks
[12:01] <james_w> beuno: not that I know of. One of the branches of mine that will land shortly allows you to do me.getRequestedReviews(), but I don't know if that includes reviews you have done.
[12:03] <beuno> james_w, ended up filtering in a loop, thanks
[14:05] <bac> hi jamalta
[14:06] <jml> noodles775, hello. I'm now caught up with my reading for daily build ui.
[14:06] <jamalta> bac: hey, how's it going?
[14:07] <bac> jamalta: good.  hey have you arranged for someone to land your branch for bug 515761?  i have a branch that needs to use your new AnonymousAuthorization class so I've been waiting.
[14:07] <mup> Bug #515761: Anonymous API access to some collections returns nothing <Launchpad Foundations:Confirmed for jamalta> <https://launchpad.net/bugs/515761>
[14:07] <jamalta> bac: well, yes i thought i had
[14:07] <jamalta> but i guess they didn't get time to do so
[14:07] <bac> jamalta:  i'll be glad to do it now
[14:07] <bac> jamalta: if you'd merge from trunk and push back up to LP i'll land it for you
[14:08] <jamalta> bac: sure! if you could please, i would really appreciate it
[14:08] <jamalta> bac: sure thing
[14:09] <jamalta> bac: sorry to have kept you waiting also :\
[14:09] <bac> np
[14:09] <jml> noodles775, and I'm thus happy to have a call whenever you are ready
[14:09] <jml> (except not at 1500UTC).
[14:12] <noodles775> jml: OK, I'm justgot a scheduled call with abentley first...
[14:12] <noodles775> abentley: are you available now?
[14:12] <abentley> noodles775, sure.
[14:12] <noodles775> abentley: OK, I've added you as a contact on skype.
[14:12] <jml> noodles775, np
[14:13]  * jml seizes the opportunity to ruthlessly clean out his desktop & physical in-tray
[14:13] <abentley> noodles775, I'm on skype, but I don't see a contact request.
[14:15] <bac>  jamalta: please let me know when that is done
[14:17] <jamalta> bac: alright, it should be updated now. Thanks for that.
[14:18] <bac> jamalta: np.  i'll land it now.  please don't do any more pushes to that branch.
[14:18] <jamalta> bac: of course, thanks so much
[14:20] <jamalta> bac: oh thanks for catching that, i will start marking bugs as "In Progress" when I'm working on them
[14:38] <noodles775> jml: is now ok, or too close to your next call?
[14:39] <jml> noodles775, let's have one now and then schedule another if there's not enough time?
[14:39] <beuno> # of ui reviews ever done using MPs:
[14:39] <beuno> {u'beuno': 170, u'launchpad': 5, u'rockstar': 17, u'barry': 17, u'michael.nelson': 39, u'sinzui': 13, u'edwin-grubbs': 2, u'bac': 1, u'adeuring': 1, u'mars': 1, u'intellectronica': 12, u'matthew.revell': 4}
[14:40] <noodles775> jml: ok, when you're ready.
[14:59] <mars> EdwinGrubbs, ping, mind if I assign bug #405476 to you?
[14:59] <mup> Bug #405476: sprite class bleeds extra images in tall elements <css> <post-3-ui-cleanup> <tech-debt> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/405476>
[14:59] <EdwinGrubbs> mars: go ahead
[14:59] <mars> thanks
[15:03] <kfogel> adeuring: I have read and understood https://bugs.edge.launchpad.net/malone/+bug/518746 .  If you're working on it, I'll just make sure that is communicated to jcastro.  Is there anything else I can do to help?
[15:03] <mup> Bug #518746: Read the patch age on the +patches view directly from Bug.latest_patch_updated <oops> <patch-tracking> <Launchpad Bugs:In Progress by adeuring> <https://launchpad.net/bugs/518746>
[15:05] <adeuring> kfogel: well, if you want to discuss details how to address it, I'd appreciate it
[15:06] <kfogel> adeuring: oh, I thought from this that the solution was already basically known: "The only detail we need from the query is the creation time of the bug message (retrieved in another, faster, query), and we can get this value already from the new column Bug.latest_patch_updated"
[15:07] <adeuring> kfogel: seems that wrote nonsense: We want to display the title, the URL and a few other things...
[15:07] <kfogel> adeuring: reading query more carefully now, then
[15:09] <kfogel> adeuring: you're talking about the stuff in the popup block?
[15:09] <adeuring> kfogel: yes, and about the URL we show for each patch
[15:12]  * kfogel thinks out loud... "Maybe our denormalized column should be "latest_patch" rather than "latest_patch_updated"
[15:15] <adeuring> kfogel: we need something to sort on in this column ;) But since row1.id < row2.id should imply row1.datecreated  row2.dattecreated, that should actually work quite well
[15:16] <adeuring> kfogel: so: I think I'll change my DB atch again ;)
[15:16] <adeuring> thanks for the suggestion!
[15:17] <adeuring> erm, that should have been row1.datecreated < row2.dattecreated
[15:17] <kfogel> adeuring: the only thing I worry about is, is that something we can count on always being true?  If "later IDs must be higher numbers" is going to be a constraint from now on, where do we document that?
[15:17] <kfogel> (Do we use this sort-by-ID technique elsewhere in LP already?)
[15:18] <micahg> if anyone needs a high profile bug with upstream implications to work on...bug 499113 is upsetting bugzilla.mozilla.org users... :)
[15:18] <mup> Bug #499113: Launchpad will sync comments and link back to all bug watches, even those not linked to a bug task <bugwatch> <story-reliable-bug-syncing> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/499113>
[15:18] <adeuring> kfogel: We had such a discussion a few hours ago, related to timeouts on the main LP bugs page
[15:19] <adeuring> where a SELCT * from BUG WHERE ... SORT B> datecreated, id timed out
[15:19] <adeuring> s/B>/BY/
[15:19] <kfogel> adeuring: in SQL, "SORT BY foo, bar" means sort by foo first, then by bar within that?
[15:19] <adeuring> kfogel: yes
[15:20] <kfogel> adeuring: The idea sounds solid to me.  But I'd feel more comfortable if someone with lots of DB knowledge said "Oh, sure, we sort by ID all the time, it's totally normal."
[15:21] <adeuring> kfogel: I can imagine one situation where we might get a, let's "minor deviation" from the rule "ordering by id is equvialent to ordering by date_creeated"
[15:22] <adeuring> When two attachments are created simultaneously, attachment A might get the lower ID, while attachment 2 might have its INSERT statement executed first
[15:23] <adeuring> but (a) aving two attachments field for the same bug at the same time is quite unlikely, and (2) if this happens, the fine details of which cam first are irrelevant anyway
[15:23] <kfogel> adeuring: well, they're only going to differ by a milliseconds, right, and we're just sorting for UI purposes.
[15:23] <kfogel> right
[15:23] <kfogel> having two *patch* attachments is especially unlikely
[15:24] <adeuring> kfogel: excatly
[15:24] <kfogel> adeuring: is there any UI by which someone can retroactively mark an attachment as a patch or non-patch?
[15:24] <adeuring> kfogel: es. Just follow the "edit" link in the patch/attachment poertlet of any bug page
[15:24] <adeuring> s/es/yes/
[15:27] <kfogel> adeuring: so when someone does that, we update the latest_patch_updated field, right?
[15:27] <adeuring> kfogel: yes, via a trigger.
[15:28] <kfogel> ah right, thx
[15:29] <adeuring> kfogel: IIRC, stub alreaddy suggested to sort on bugattachment.id in some +patches-related query, when we discussed the sorting
[15:31] <kfogel> ah, so this idea has an honorable provenance
[15:31] <kfogel> good :-)
[16:41] <beuno> since august last year, developers have done more UI reviews each month than I have
[16:41] <beuno> http://paste.ubuntu.com/371828/
[16:41] <beuno> I got my ass kicked in september
[16:42] <beuno> (I knew I shouldn't of gone on vacations!)
[17:03] <Ursinha_> abentley: hello.
[17:04] <abentley> Ursinha_, Hi.
[17:04] <Ursinha_> abentley: that day, when you suggested me monitoring branches being merged into devel/db-devel instead of their revisions, you really meant branches or merge proposals?
[17:06] <abentley> I meant merge proposals.
[17:06] <Ursinha> abentley: so, it turns out that not all branches merged into lp have a merge proposal
[17:06] <abentley> What branches don't?
[17:07] <Ursinha> abentley: testfixes, for instance
[17:07] <Ursinha> not necessarily have mps
[17:07] <Ursinha> abentley: I did a test here in lp and could see that
[17:08] <Ursinha> abentley: getting all merged branches of launchpad-project, not all of them have mps
[17:08] <abentley> Ursinha, Sorry I didn't think of that.
[17:08] <adeuring> mbarnett: could you please run this query for me on staging: https://pastebin.canonical.com/27546/ ?
[17:09] <Ursinha> abentley: no problem, actually I'd like to know if you have another idea
[17:09] <Ursinha> abentley: ideally I'd monitor branches
[17:09] <Ursinha> abentley: thumper very kindly implemented yesterday a way of getting branches given a date
[17:10] <Ursinha> in that case, the last modified date
[17:11] <mbarnett> adeuring: ERROR:  syntax error at or near "ORDER"
[17:11] <mbarnett> LINE 6:        WHERE BugAttachment.bug = 445852 AND ORDER BY BugAtta...
[17:11] <Ursinha> abentley: but some information will be missing, case the branch doesn't have an mp, like the target_branch
[17:12] <abentley> Ursinha, without merge proposals, I don't see a cheap way to query this.
[17:12] <Ursinha> abentley: ah :/
[17:12] <adeuring> mbarnett: I'm an idiot, sorry. This one should work: https://pastebin.canonical.com/27547/
[17:12] <abentley> I'd like to bring it up in our standup.
[17:12] <Ursinha> abentley: but, is it possible to add more information to the branch? Also, I see that the merged_revno in the mp isn't filled. Is that a bug?
[17:13] <adeuring> mbarnett: also, could you please check if we have an index on bugattachment(bug), in the staging database?
[17:15] <mbarnett> https://pastebin.canonical.com/27548/
[17:15] <adeuring> mbarnett: ot my best day... I meant an "explain analyze" for https://pastebin.canonical.com/27547/ . Sorry for the confusion...
[17:15] <abentley> Ursinha, we can add more info, but I'm not sure the branch is the right place, because a merge involves two branches and may happen multiple times.
[17:15] <mbarnett> heh
[17:15] <abentley> Ursinha, yes, it's a bug that we don't include that revno.
[17:16] <mbarnett> adeuring: https://pastebin.canonical.com/27549/
[17:16] <Ursinha> abentley: I agree with your statement about branches not being the right place to put that, but I couldn't find another place considering not all branches have mps
[17:16] <adeuring> mbarnett: thanks!
[17:17] <Ursinha> abentley: ideas more than welcome :)
[17:17] <mbarnett> adeuring: np
[17:18] <abentley> Ursinha, the two ideas I have are 1. create a "merged" merge proposal when branch merges are detected, 2. create a new table to track merges.
[17:22] <beuno> abentley, hey, you may be able to answer this. I can't figure out how to, from the API, which user commented on each comment
[17:22] <beuno> I can get the content of the comment
[17:23] <beuno> but not the author
[17:23] <beuno> is it possible that it's not exposed?
[17:23] <abentley> beuno, I believe that's recorded as the creator.
[17:23] <beuno> rockstar, ^
[17:23] <beuno> abentley, there doesn't seem to be such an attribute
[17:23] <rockstar> beuno, lemme look
[17:23] <adeuring> mbarnett: so... could you run this query on staging https://pastebin.canonical.com/27550/ ? That's from a not-yet-merged branch (https://code.edge.launchpad.net/~adeuring/launchpad/fix-broken-initialisation-of-bug-latest-patch-uploaded/+merge/18610 ); my hope is that this will improve the run time of the first query you ran
[17:24] <beuno> http://paste.ubuntu.com/371856/
[17:24] <beuno> I can get it for votes
[17:24] <beuno> not for comments
[17:25] <abentley> beuno, it is the owner of the message.
[17:25] <rockstar> beuno, huh.  ICodeReviewComment doesn't have a author attribute.
[17:26] <rockstar> abentley, I don't think message is exposed.
[17:26] <abentley> rockstar, there's an export_as_webservice_entry line in the interface file.
[17:26] <rockstar> Nope, it's not.
[17:26] <rockstar> abentley, yeah, but the ICodeReviewComment.message isn't
[17:27] <beuno> rockstar, easy fix?   I'm working on publishing a paper on Launchpad's whole UI review experience, and I need it as part the data I want to present  :)
[17:28] <rockstar> beuno, I can't imagine it would be too difficult, but the API constantly has unknowns whenever I expose something.
[17:28] <beuno> rockstar, will you have a few minutes to look into it and give me a nod?
[17:28] <beuno> I'd super appreciate it if you could
[17:29] <rockstar> beuno, can it wait a few hours.  I'd like to get a branch into review soon.
[17:29] <beuno> rockstar, of course it can. Thanks
[17:29] <rockstar> beuno, okay.  If you're lucky, it'll be on edge tomorrow.  ;o)
[17:29] <beuno> rockstar, fingers crossed
[17:29] <rockstar> Hell, if _I'm_ lucky...
[18:15] <mbarnett> adeuring: sorry, got pulled in 2*10^7 directions there... your index is now on staging
[18:16] <jamalta> bac: hey
[18:18] <rockstar> gary_poster, hello sir.
[18:18] <gary_poster> hey rockstar
[18:18] <rockstar> gary_poster, bin/jsbuild is a generated file, correct?
[18:19] <rockstar> mbarnett, hi
[18:19] <gary_poster> rockstar: yes
[18:19] <mbarnett> heya rockstar
[18:19] <rockstar> gary_poster, where is the code that generates that?  I think I'm going to have to generate a Makefile in a similar fashion.
[18:19] <rockstar> mbarnett, so, about that cherry pick...
[18:21] <mbarnett> rockstar: there was some sql business if i recall correctly
[18:22] <rockstar> mbarnett, yup.  Lemme get my ducks in a row first here.
[18:23] <gary_poster> rockstar: If the end result is a Makefile, then I think you want a slightly different mechanism than bin/jsbuild, but same idea.  Look in [LP tree]/buildout-templates.  The .in files are processed and put in the LP tree by buildout.  Processing is as per http://pypi.python.org/pypi/z3c.recipe.filetemplate .  You might be able to get what you need just by looking at the files already in the bin dir there, though
[18:23] <gary_poster> FWIW, that is hooked up in buildout.cfg in the [filetemplates] section
[18:24] <rockstar> gary_poster, okay.  Basically, I need a make target that uses the filenames of all our js files as the dependent targets.
[18:27] <gary_poster> rockstar: ...oh.  I'd guess you want to have something sniff out out js files so you don't have to maintain the list?  Is that the idea?  If you want to know what lazr.js is building, you'd probably need to ask mars or maybe salgado about that
[18:27] <gary_poster> I don't know if there is a config file for that info anywhere, or what
[18:28] <rockstar> gary_poster, yes, I want to automate it.
[18:28] <rockstar> gary_poster, the problem currently is that the js gets combined every time you run make run.  This is no fun.
[18:29] <gary_poster> rockstar: ah, yes!  have complained about this as well.  mars/salgado did want to address as well.  thank you for tackling.  salgado has a plan for this in fact, IIRC.  salgado, am I right?
[18:30] <rockstar> gary_poster, well, it's one of the reasons I'm build manager this cycle.  Javascript needs to suck less.  :)
[18:30] <salgado> gary_poster, I had, yes, but rockstar took it over as he's the build engineer. :)
[18:30] <rockstar> salgado, if you have a better plan than mine, I'm all ears.
[18:30] <gary_poster> rockstar: yay :-)
[18:31] <salgado> rockstar, my plan is the one I described in the UI call last week
[18:31] <rockstar> salgado, I've been rather perplexed at the nastiness of Makefile generation.
[18:31] <rockstar> salgado, I don't recall you explaining it last week.
[18:31] <rockstar> Maybe two weeks ago, before I was build engineer?
[18:31] <rockstar> I remember you talking about it then, but I don't remember that there were any specifics discussed.
[18:32] <salgado> we already maintain a hard-coded list of CSS files that we want to combine as we don't want to include everything from yui/lazr-js, so I think you could easily change bin/combine-css to not do anything if combo.css is newer than all CSS files in the list
[18:34] <rockstar> salgado, ah, you're suggesting hacking it in bin/ scripts then.
[18:34] <rockstar> Okay, that makes sense.
[18:34] <rockstar> So the script still runs, but is basically a no-op.
[18:35] <salgado> yep.  not the cleanest approach, but should be easy enough
[18:37] <adeuring> mbarnett: cool, thanks!
[18:43] <bac> hi jamalta
[18:43] <jamalta> bac: any clue as to why those tests failed?
[18:43] <jamalta> i guess the ec2 test didn't like '...' being used?
[18:44] <bac> jamalta: haven't looked yet
[18:44] <jamalta> bac: alright, when you get a chance3
[18:45] <bac> jamalta: it will be easiest if i just merge in your branch into mine, fix the tests and land them together.  you'll still get credit as you're in the bzr history
[18:45] <bac> jamalta: sound good?
[18:47] <jamalta> bac: yeah that's fine too :)
[18:49] <bac> jamalta: can you run the xx-bug.txt test in your branch and see if it fails?  i don't get a failure locally
[18:50] <jamalta> bac: it doesn't fail for me either
[18:50] <bac> jamalta: :(
[18:50] <jamalta> that's mainly why i was confused
[18:50] <jamalta> i know! :(
[18:50] <jamalta> i thought it might have been after the merge, but they still worked fine
[18:51]  * jamalta checks if he forgot to commit something
[18:51] <jamalta> well, that wouldn't make sense because you'd be having the issue too
[18:51] <jpds> (I usually find that running 'make schema' helps sometimes with weird test failures).
[18:52] <jamalta> jpds: thanks, will try that
[18:54] <bac> jamalta: the reason for the failure is not the wild-carding with ellipsis. it is b/c the actual output of that test had the unexpected output for 'task_age'
[18:55] <jamalta> bac: oh
[18:57] <bac> jamalta: your MP has db-devel as a landing target, not devel.  db-devel has task_age exported but devel does not
[19:00] <jamalta> bac: wowah, how and why is it db-devel?!
[19:00] <jamalta> i'm pretty sure i asked for lp:launchpad/devel
[19:00] <jamalta> bah
[19:01] <jamalta> oh i see what i did, hmm..
[19:01] <jamalta> how can i fix thatA?
[19:02] <bac> jamalta: it won't be an issue if i land it with mine
[19:02] <jamalta> bac: ah okay
[19:02] <jamalta> thanks for figuring that out
[19:15] <mrevell> night all
[19:23] <mwhudson> good morning
[19:57] <jtv> hi mwhudson
[19:57] <mwhudson> jtv: hello
[21:27] <lifeless> jml: can I offer any assistance on your subunit branch for lp ?
[21:34] <jml> lifeless, thanks. What I'm going to do is finish up the zope.testing branch. I'd like you're input on that once I've finished off the last few bits.
[21:43] <lifeless> sure thing
[21:59] <rockstar> gary_poster, I don't see a template for bin/jsbuild - Where can I find a mapping for all of these scripts?
[22:03] <gary_poster> rockstar: all the files in bin are generated by buildout.  If they are not generated from the templates then they are generated from entry points, via the zc.recipe,egg zc.buildout recipe.  See the [scripts] section of buildout.cfg, in the entry-points key.
[22:03] <gary_poster> (I don't think this affects your needs, but I don't advise looking too closely at those scripts specifically.  I'm putting the final touches now on a branch that gets rid of the whole fragile sys.modules ugliness.)
[22:04] <gary_poster> rockstar: I'm not sure you are going to be able to get what I vaguely understand you want
[22:04] <rockstar> gary_poster, getting rid of the sys.modules stuff will be nice, as it makes the script more manageable in an editor.
[22:04] <gary_poster> but my understanding is vague, so hopefully I'm wrong
[22:05] <gary_poster> rockstar: yeah, the new scripts are < 20 lines of <80 chars each
[22:05] <rockstar> gary_poster, awesomeness.