[00:01] <thumper> mwhudson: where is the writable parameter coming from?
[00:01] <mwhudson> thumper: the xml-rpc server
[00:01] <mwhudson> thumper: which does check_permission(branch, 'launchpad.Edit')
[00:02] <thumper> hmm..
[00:02] <thumper> seems that something is wrong
[00:02] <jml> see lp.code.xmlrpc.codehosting and lp.code.interfaces.codehosting
[00:02]  * thumper tries to work it out in his mind
[00:03] <wgrant> This code is rather difficult to navigate :(
[00:03] <lifeless> thumper: I've spent as much time as I can afford on this. Sorry.
[00:03] <thumper> lifeless: ok
[00:04] <lifeless> thumper: its a safe operation, bzr does it automatically without blocking out other users, it will help your servers and your users.
[00:05] <jml> wgrant, sorry. it's as easy as I could make it.
[00:06] <lifeless> thumper: oh, and if questions like 'how much will it help' are in your mind, use wget to mirror the public repo bit-for-bit, run a 1.17 server against it and fetch using bzr nightly
[00:07] <lifeless> then pack it using 1.17 (with C extensions, of course), and repeat.
[00:26] <jml> thumper, mwhudson: has someone addressed the broken test in db-devel?
[00:26] <mwhudson> jml: thumper is, i mailed the list
[00:27] <jml> mwhudson, ahh cool
[00:27] <jml> sorry for missing it.
[00:27] <mwhudson> np
[01:34] <jml> mwhudson, do you want to chat about how to fix bug 419691
[01:34] <ubot3`> Malone bug 419691 in launchpad-foundations "Many tests use unnecessarily expensive layers" [Undecided,New] https://launchpad.net/bugs/419691
[01:34] <mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:New> <https://launchpad.net/bugs/419691>
[01:34] <mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:New> <https://launchpad.net/bugs/419691>
[01:34] <mup> Bug #419691: Many tests use unnecessarily expensive layers <build-infrastructure> <Launchpad Foundations:New> <https://launchpad.net/bugs/419691>
[01:35] <mwhudson> uh
[01:35] <mwhudson> jml: skype?  one sec in that case
[01:35] <jml> bot wars :)
[01:35] <spm> thumper: lifeless: fyi. bzr pack initiated on db-devel, mirrors
[01:42] <thumper> mwhudson: I'm still confused
[01:42] <thumper> but unfortunately out of time
[01:42] <mwhudson> thumper: i'm on the phone
[01:42] <mwhudson> later i gues
[01:42] <thumper> mwhudson: the fix for the db-lp builder is not as trivial as I hoped
[01:42] <thumper> will fix after class
[01:42] <mwhudson> thumper: bugger
[02:16] <spm> thumper: lifeless: fyi. bzr pack completed on db-devel, mirrors - looks to have finsihed about... 25 mins ago. taking around... 15mins to do it.
[02:21] <wgrant> spm: Looks much better. Still not perfect, but much better.
[02:22] <spm> wgrant: the end result is ~ 120Mb - eyeball wag
[02:22] <wgrant> Is devel going to get the treatment too? That's the one that is going to reinforce people's thoughts about how much bzr sucks when they try to get LP's code.
[02:22] <spm> yeah - it will. juggling 3 things at once :-)
[02:22] <wgrant> Great.
[02:23] <spm> need to run jml's nifty get-branch-info script etc
[02:24] <spm> devel is started
[02:25] <wgrant> What does that do? Tell you the ID/path?
[02:27] <spm> yarp. decodes the nice name into the 00/00/12/34 path
[02:27] <spm> has a few other nifties that help verify you've got the right branch.
[02:28] <wgrant> Yay, looks like Ohloh's LP import is still working.
[02:28] <spm> mwh's hack of sending an invalid .bzr location to codebounce is another used method
[02:28] <wgrant> Or even a valid one.
[02:29] <wgrant> Sometimes it'll redirect you to the internal URL.
[02:29] <wgrant> No idea why.
[02:29] <spm> wgrant: ha. you'll chuckle - straight from our "howto" notes: http://bazaar.launchpad.net/~wgrant/ivle/trunk-mirror/.bzr/ergasdf
[02:30] <spm> Nooooo! it's ont working any more!!! mwhudson ^^
[02:30] <wgrant> Indeed, I believe I deleted that branch some time ago.
[02:30] <spm> ahh. does still work - the branch needs to exist in the 1st place.
[02:31] <spm> http://bazaar.launchpad.net/~drizzle-developers/drizzle/development/.bzr/wibble by way of example
[02:31] <wgrant> It got renamed to trunk when we moved to bzr.
[02:32] <spm> so the diff there; with jml's script; is the latter gives the full path on disk; vs just the 00/00/12/34 bit.
[02:32] <wgrant> Ah.
[02:32] <spm> tho tbh, I can do the pre-path in my sleep I expect :-)
[02:37]  * mwhudson lunchifies
[02:45] <spm> and devel is also el-packed. fnished about 4 mins ago. ~ 111Mb. So again, aruond 15mins to run.
[02:46] <wgrant> Excellent.
[04:08] <thumper> mwhudson: quick call?
[04:09] <mwhudson> thumper: ok
[04:10] <thumper> omg skypes sucks
[04:35] <thumper> mwhudson: what is the revno of the puller fix?
[04:35] <thumper> mwhudson: I'm going to request a CP
[04:35] <mwhudson> thumper: looking
[04:36] <mwhudson> thumper: r9355
[04:36] <mwhudson> thumper: would be good to test it out on staging first i guess
[04:37] <mwhudson> except that it's not in db-stable yet, of course
[04:38] <thumper> hmm..
[04:39] <mwhudson> oh fucking hell
[04:39] <mwhudson> mischan :)
[04:39] <thumper> mwhudson: buildbot?
[04:40] <mwhudson> thumper: yeah
[04:40] <thumper> mwhudson: ok, lets wait for staging testing then
[04:41] <thumper> mwhudson: do I need to update the dev tools to get the latest ec2 image?
[04:41] <jml> thumper, got a moment?
[04:41] <mwhudson> thumper: no
[04:41] <mwhudson> thumper: the current ec2 image is rather old though
[04:46] <mwhudson> jml: so it turns out that the time 'initialize database' takes for buildbot slaves varies wildly
[04:46] <mwhudson> jml: it's not usually 20 minutes, more often ~1
[04:46] <jml> mwhudson, wow.
[04:46] <jml> mwhudson, I'm surprised
[04:46] <mwhudson> jml: yeah
[04:47] <thumper> jml: yes(ish)
[06:13]  * wgrant stabs Launchpad mailing lists in the face.
[06:13] <wgrant> Stop. Breaking. Threading.
[06:45]  * mwhudson eods
[08:19] <jml> BjornT_, I assume all the bug mail you just generated was only unassigning yourself?
[08:24] <BjornT_> jml: yeah. and marking some bug as fix released, but it's safe to ignore everything
[08:24] <jml> BjornT_, thanks.
[08:28] <adeuring> good morning
[08:32]  * jml off
[09:17] <mrevell> Morning!
[09:49] <jtv> Are we in testfix?
[09:51] <jtv> mrevell: thanks
[09:51] <bigjools> https://lpbuildbot.canonical.com/waterfall
[09:52] <jtv> bigjools: so it's the db_lp failure that put us in testfix mode?  All this usually happens overnight for me, so I haven't built up any real experience with it.
[09:53] <saispo> hi
[09:54] <bigjools> jtv: mwhudson was fixing something with it, it might be bustifuct still
[09:55] <thumper> I don't know why pqm still thinks it is in testfix
[09:55] <thumper> I'm hoping the jscheck builder failure didn't tweak it
[09:55]  * thumper looks at saispo
[09:56] <lifeless> jml: hai
[09:56] <wgrant> bigjools: AFAICT archiveuploader still doesn't apply any checks that binaries do not conflict.
[09:57] <bigjools> wgrant: I've seen failed-to-upload errors for that though?
[09:58] <wgrant> bigjools: Right, sorry, I was ambiguous. There is a check that they are not older than the currently published version, but not that they have never existed before.
[09:58] <bigjools> that's wrong then I guess
[09:58] <thumper> my icy stare obviously scared him off :)
[09:59] <bigjools> thumper: I still have nightmares about your Halloween face!
[10:00] <thumper> bigjools: I need to replace my fluffy bunny picture with my halloween hackergochi
[10:00] <wgrant> bigjools: It should probably check that the version hasn't existed before, yes. It's unclear, however, whether one should be able upload an older version of either. I'm really not sure.
[10:01] <mwhudson> we shouldn't be in testfix per PQM
[10:01] <bigjools> wgrant: yeah, it's not exactly consistent with the source processing
[10:01] <mwhudson> if we are, something's not working right
[10:01] <thumper> mwhudson: something isn't working right
[10:02] <mwhudson> thumper: luckily i'm not an osa so i can't help diagnosis or help
[10:03] <mwhudson> i guess the buildbot-poll script is barfing for some reason
[10:12] <BjornT> jtv, thumper: in my experience, it's good to show the exact error message from pqm to others. it happened quite often that people thought that we were in testfix mode, just because pqm didn't accept their commit message
[10:13] <thumper> BjornT: Commit message [[rs=thumper][ui=none] Upgrade to bzr 1.18.] does not match commit_re [(?is)^\\s*\\[testfix\\]\\s*\\[(?:release-critical|rs?=[^\\]]+)\\]]
[10:13] <bigjools> regex hell
[10:13] <thumper> BjornT: that's the testfix regex
[10:13] <intellectronica> maybe we need a UI for commiting
[10:13] <thumper> heh
[10:14] <intellectronica> thumper: why not. one day, when you can commit straight from a merge proposal, we could have all the fields that are relevant, and that will build the commit message for you
[10:15] <wgrant> intellectronica: I think that one day the commit message will be normal text.
[10:15] <wgrant> intellectronica: And the silly review metadata will be stored in the MP.
[10:15] <BjornT> thumper: indeed. did you submit it before or after stub's testfix commit?
[10:16] <intellectronica> wgrant: nah, you want it in bzr, but maybe it can be stored in bzr metadata (as long as there's a simple way to read it back)
[10:16] <wgrant> intellectronica: OK, bzr revision properties then.
[10:16] <wgrant> intellectronica: But automatic.
[10:16] <thumper> BjornT: stub submitted his testfix after I submitted my testfix
[10:16] <intellectronica> yeah
[10:16] <thumper> BjornT: and the last one was after stub's
[10:16] <thumper> BjornT: it appears there is something screwy somewhere
[10:17] <BjornT> thumper: how long after? it takes a while before we get out of testfix mode.
[10:17] <thumper> BjornT: about 40 minutes
[10:19] <BjornT> thumper: ok. i don't see a testfix for the current db-devel failure
[10:20] <thumper> BjornT: 4:42 on the waterfall
[10:21] <BjornT> thumper: there are build failures for db-devel after that commit
[10:21] <BjornT> thumper: the latest one is at 06:30:05
[10:21] <thumper> BjornT: fair enough
[10:25]  * thumper chucks in the towel
[11:01] <deryck> Morning, all.
[11:13] <jtv> hi deryck
[11:19] <mrevell> yo dez
[11:59] <danilos> BjornT, thumper: heya, I've got a breadcrumbs issue I've been wondering about (I'll ultimately wait for salgado, but perhaps you guys know why this could be)
[12:00] <danilos> basically, an object doesn't end up in request.traversed_objects, and I am not exactly sure why
[12:02] <wgrant> bigjools: The maximum time remaining should probably be exposed in each package row of the PPA index, as builds are undiscoverable.
[12:03] <bigjools> undiscoverable?
[12:03] <noodles775> on the new +packages traversal, perhaps.
[12:03] <wgrant> noodles775: Probably.
[12:03] <wgrant> bigjools: I've seen people completely fail to understand that the build pages exist.
[12:05] <bigjools> if there's room in the new +packages table, we could potentially show it for each arch
[12:05] <bigjools> but it would be nice to emphasis the links if people are missing them
[12:06] <noodles775> Maybe we could even link from the 'Latest updates' portlet that will be on the ppa index.
[12:06] <wgrant> It would be useful anyway to show the remaining time, even if it's only the maximum of all pending builds.
[12:06] <bigjools> noodles775: not sure that's the right place, it won't necessarily show all uploads with pending builds will it?
[12:07] <noodles775> bigjools: just the latest 5 published spph's (with their current build status)
[12:07] <bigjools> yeah, so it's probably best to fit something in the table
[14:59] <Daviey> Hey, is there a technical reason why merge review email needs white space before the command?
[15:09] <intellectronica> Daviey: no, that's the ui. with space in front of the command it's easier to distinguish from the text. it's a quoting mechanism
[15:10] <Daviey> ah!
[15:11] <Daviey> intellectronica: The annoying thing is, an email that purely states "merge approve" is obviously not a normal comment.. but is seen as that :(
[15:57] <kfogel> salgado: [transfer ping from #launchpad] :-)
[16:01] <danilos> salgado: heya, my breadcrumbs master
[16:01] <salgado> danilos, otp
[16:02] <danilos> salgado: hang up and talk to me! :)
[16:04] <kfogel> danilos: take a number, man
[16:09] <danilos> kfogel: heh :)
[16:17] <rockstar> abentley, call?
[16:18] <abentley> rockstar: sure.
[16:52] <danilos> salgado: when do you expect to be available?
[16:53] <salgado> danilos, in a few minutes
[17:01] <kfogel> noodles775: hey, re your Hacking Soyuz UDW session: it looked like it went well to me, but did any questions come up (especially re community development) that stumped?
[17:04] <bigjools> kfogel: I was there, and I didn't see any, in fact there was only one guy interacting
[17:06] <kfogel> bigjools: well I think the questions arrive via backchannel, so it can look less active than it is.
[17:06] <bigjools> kfogel: yeah I was on the chat channel as well
[17:07] <kfogel> bigjools: looking at the transcript, there were some questions.  Were they all the same person?
[17:07] <bigjools> kfogel: mostly noodles himself :)
[17:07] <kfogel> bigjools: oh :-)
[17:11] <salgado> danilos, pong
[17:11] <salgado> kfogel, pong
[17:11] <danilos> salgado: hey hey
[17:11] <danilos> salgado: so, attempt at a quick question: DistroSeriesLanguage, traversed via stepthrough, doesn't show up in request.traversed_objects, so I can't introduce a breadcrumb for it; is there way around it?
[17:12] <kfogel> salgado: you were working on making launchpad-reviews public, but with exception for security branches.  I'm wondering where that's at.
[17:12] <kfogel> salgado: dang, danilos beat me to it, and he didn't even take a number :-).
[17:12] <kfogel> salgado: seriously, finish with danilos first, since my question is likely to take longe.r
[17:12] <danilos> kfogel: heh, let's see if salgado can multi-task :)
[17:12] <salgado> danilos, yes, there's a bug open about that and I have a workaround in one of my branches
[17:13] <salgado> danilos, basically, you have to define a Navigation class for DistroSeriesLanguage
[17:13] <danilos> salgado: ok, I am happy to wait for it to land, but can you point me at your branch so I make sure it works
[17:14] <danilos> salgado: ah, ok, any examples that might kick start me?
[17:14] <danilos> salgado: eg. does +source have that?
[17:14] <salgado> danilos, I thought I'd done that for DistroSeriesLanguage but I didn't
[17:15] <danilos> salgado: there's also ProductSeriesLanguage, perhaps that's where you did
[17:15] <salgado> +class AnnouncementNavigation(Navigation):
[17:15] <salgado> +    """The navigation for `IAnnouncement`."""
[17:15] <salgado> +    usedfor = IAnnouncement
[17:15] <danilos> salgado: register it with browser:navigation, right?
[17:15] <salgado> danilos, that's what you need, together with a browser:navigation zcml declaration
[17:16] <danilos> salgado: ok, cool, thanks
[17:16] <salgado> kfogel, I never got around to it, sorry
[17:17] <salgado> danilos, bug 423898
[17:17] <mup> Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/423898>
[17:17] <ubot3`> Malone bug 423898 in launchpad-foundations "Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects" [Undecided,Triaged] https://launchpad.net/bugs/423898
[17:17] <mup> Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/423898>
[17:17] <mup> Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/423898>
[17:17] <kfogel> salgado: hey, we're all busy, I understand.  Can you tell me what's left on it?  Maybe I can help unblock.
[17:17] <danilos> whoa, whoa, ubot3`, mup, I hear you
[17:17] <danilos> salgado: thanks
[17:17] <kfogel> danilos: :-)
[17:18] <salgado> kfogel, I need to read the thread again to see what should be done
[17:20] <salgado> kfogel, I'll do that today and get the ball rolling there
[17:21] <kfogel> salgado: thank you, much appreciated.  If it's a matter of seeing which way the ball has to roll, but not having time to roll it, please don't hesitate to say so -- I'm happy to do what I can (& to help find other people to do what I can't) if needed.
[17:21] <salgado> kfogel, will do, thanks
[17:22] <salgado> out to lunch now, back soon
[18:35] <barry> oowww!  did --headless suddenly get much faster?
[18:42] <barry> salgado: ping
[18:42] <salgado> hi barry
[18:42] <barry> salgado: hi.  about the not found error page title
[18:43] <rockstar> What is the url that gives me all the icons available in LP?
[18:43] <barry> salgado: i think i should move pagetitles.py/launchpad_notfound into a page_title attribute on NotFoundView
[18:43] <salgado> rockstar, https://edge.launchpad.net/+graphics
[18:43] <barry> salgado: but i also think i should move the other error related pagetitle.py attributes onto their respective classes in error.py.  what do you think?
[18:43] <rockstar> salgado, thanks
[18:44] <barry> salgado: and also, should we put a page_title attribute on SystemErrorView?
[18:45] <salgado> barry, good question; let me check
[18:48] <salgado> barry, I think that's a good idea, together with moving titles into webapp/error.py
[18:49] <barry> salgado: cool.  let me make that change and i'll send you the incremental
[19:33] <kfogel-lunch> flacoste: voice of sanity on "offer mentorship" ui, thank you
[19:43] <barry> salgado: ping
[19:43] <salgado> barry, pong
[19:45] <barry> salgado: i wanted to talk about @@+page-title/has_custom_title again
[19:45] <barry> i'm not sure the check is quite right.  the problem is, if you check for the existence of breadcrumbs, then putting a page_title on your view isn't enough to override
[19:47] <barry> salgado: ^^
[19:48] <barry> salgado: so the question is whether a view should have to specifically say "i don't have breadcrumbs, and oh yeah here's my page title" or just the latter.
[19:49] <barry> salgado: i think it should be just the latter.  what do you think?
[19:53] <salgado> barry, I think it's the latter, but all views must specify their title; either in pagetitles.py or through an attribute
[19:53] <salgado> I suggest something along these lines:
[19:53] <salgado> All view classes either define a .title attribute or have an entry in pagetitles.py
[19:54] <rockstar> abentley, I'm trying to use the factory to create some revisions for a branch, but they don't seem to be showing up.
[19:54] <rockstar> abentley, do you have any insight as to what I might be missing?
[19:55] <abentley> rockstar: You're looking for them on the database class, right?
[19:55] <salgado> barry,  but some views may also define a .page_title, which takes precedence over the title generated by PageTitleView()
[19:55] <rockstar> abentley, no, through the web ui.
[19:56] <barry> salgado: what's the purpose of the view.title attribute then?
[19:56] <abentley> rockstar: Do they show up in the console in make harness?
[19:56] <rockstar> abentley, good question, lemme check.
[19:56] <rockstar> abentley, I'm using makeRevisionsForBranch in this context, for YOUR context.
[19:56] <salgado> barry, that's the text for the breadcrumb's last item
[19:57] <barry> salgado: is that there now, or you're proposing that to be added?
[19:59] <salgado> barry, my idea was to rename AnyView.page_title to title
[20:00] <barry> salgado: and that would be added as the last component to the breadcrumb, if it exists?
[20:01] <salgado> barry, yes, and if it doesn't exist it must be in pagetitles.py
[20:01] <salgado> so, in summary, View.title or an entry in pagetitles.py would be required
[20:02] <barry> salgado: i'm still not sure how best to override the <title> though, so that a view can say "don't use breadcrumbs even if they're available"
[20:02] <salgado> barry, some views would also define a page_title for that
[20:03] <barry> salgado: so the presence of a .page_title would be enough to override the reverse breadcrumbs
[20:03] <salgado> yes, or html_title, or do_not_use_breadcrumbs_for_title
[20:04] <salgado> I guess a boolean that specified not to use breadcrumbs in the title would be best
[20:06] <barry> salgado: i see.  so as not to repeat .title
[20:07] <salgado> yep
[20:09] <barry> salgado: my only concern is that that's a fairly large change for a branch i'm already overdue to land ;)
[20:09] <rockstar> abentley, so the revision_count attribute on the branch object is populated correctly.  I still don't have revisions in the UI though. :(
[20:09] <barry> salgado: maybe we can do part of this now?  add .page_title to override breadcrumbs now, and then in a follow on branch do the .page_title -> .title change?
[20:10] <rockstar> abentley, wait, cancel that.  I'm seeing them now.  Not sure what changed, but everything works now.
[20:10] <abentley> rockstar: Odd.
[20:10] <salgado> barry, actually, there's no need for the .page_title -> .title change
[20:10] <salgado> if we add the boolean
[20:11] <salgado> and adding this boolean should be a simple change, no?
[20:12] <barry> salgado: i think it would be.  so: "override_breadcrumbs = True" in the view means to use .page_title or pagetitles.py entry instead of breadcrumbs even if they exist?  if breadcrumbs don't exist, the boolean is obviously not necessary
[20:13] <salgado> barry, yes, that's how I envisioned it
[20:14] <barry> salgado: agreed.  let me see if i can make that work.  thanks!
[20:14] <salgado> barry, thank you for bringing this up
[20:15] <barry> salgado: thanks for the time to discuss it; i'll have to remember to add this to the wiki rules
[20:15] <barry> salgado: small correction: override_title_breadcrumbs = True is better i think
[20:16] <salgado> barry, agreed
[20:16] <barry> cool, thx
[20:44] <barry> salgado: so the problem is; context/@@+page-title gives us a view, but override_title_breadcrumbs is on the original view and i don't know how to get from the PageTitleView back to the original view to check the attribute
[20:44] <barry> salgado: i suppose i can write a more complicated condition in base-layout.pt, but that seems a bit ugly
[20:46] <salgado> barry, yeah, that wouldn't be nice indeed
[20:49] <barry> salgado: can you think of any zope magic to the rescue? ;)
[20:49] <salgado> barry, a tales formatter
[20:50] <salgado> view/fmt:pagetitle
[20:50] <barry> hmm....
[20:50]  * barry hacks
[21:42] <barry> salgado: i think this is going to work very nicely.  i will have to file a bug so that when main-template.pt is removed or updated, we can get rid of CONTEXTS/fmt:pagetitle and PageTemplateContextsAPI;  that's to much work to do now though
[21:44] <salgado> barry, that's great news
[22:14] <barry> salgado-afk: i have to write some tests but here's the diff so far http://pastebin.ubuntu.com/267554/
[22:15] <mwhudson> thumper: morning
[22:15] <thumper> mwhudson: morning
[22:16] <mwhudson> skype?
[22:18] <wgrant> gary_poster: around?
[22:36] <gary_poster> wgrant: now I am
[22:37] <wgrant> gary_poster: You might remember that branch of mine that you reviewed nearly two weeks ago. ec2test kept vanishing, so I wasn't able to fix the test failures until recently. Can you please land it?
[22:37] <wgrant> https://code.edge.launchpad.net/~wgrant/launchpad/structural-subscription-security/+merge/10776
[22:38] <gary_poster> wgrant.  I'll be happy to.  Do you happen to know the procedure we're using to do so, so that you get in the message properly?  If not I'll ask around.
[22:39] <gary_poster> the pqm commit message I mean, sorry
[22:39] <wgrant> gary_poster: There is no standard, but the one that I've stuck on the MP is a common one.
[22:40] <gary_poster> OIC
[22:40] <gary_poster> k
[23:28] <gary_poster> wgrant: in pqm...
[23:29] <thumper> rockstar: ping
[23:30] <wgrant> gary_poster: Thanks.
[23:35] <rockstar> thumper, pung
[23:36] <rockstar> Er, pong
[23:43] <gary_poster> wgrant: through pqm, and buildbot sees it.  I'm signing off
[23:43] <thumper> rockstar: call?
[23:43] <gary_poster> night all
[23:43] <thumper> by gary_poster
[23:43] <thumper> bye
[23:43] <thumper> damn
[23:43] <gary_poster> :-) bye
[23:43] <rockstar> thumper, yes
[23:46] <barry> bac: ping
[23:46] <bac> hi barry
[23:47] <barry> hi bac.  it's unlikely i'll be able to do that ui review for you.  i'm dashing like mad to get this branch landed and tomorrow i'm chr.  if you can't find anybody else to do it for you, i'll see what i can do tomorrow, depending on how heavy a day it is (usually, following sinzui is pretty light :)
[23:48] <bac> np, barry.  didn't realize you were chr.
[23:48] <barry> yeah.  kind of sucks.  with the short week it's gonna be a death march to get this branch landed
[23:49] <wgrant> kfogel: I think you want your contributions script to sort the revisions chronologically, to make that page a bit more useful.
[23:50] <wgrant> (ATM they don't seem to be sorted, so they are ordered differently each time the page updates)
[23:52] <kfogel> wgrant: agreed.  really, just sorting them by revnum should work
[23:52] <kfogel> wgrant: if you whip up a patch, I'm sure it'll be correct :-), but if not, no worries, I'll try to do it later tonight.
[23:54] <wgrant> kfogel: I've got enough uni stuff on my plate, sorry.
[23:54] <kfogel> wgrant: no problem at all.  Thanks for the suggestion; I'll take it from here.
[23:55] <kfogel> should just be the addition of a sort() call, really.
[23:55] <wgrant> Yep.