[00:38] * mwhudson rebooting [02:47] mwhudson: I wonder if a distinct error page could be used for LH, given that it is somewhat failed most of the time, and gives Launchpad an even worse stability reputation than the bad one it deserves. [02:50] wgrant: fixing the problems with loggerhead would be better, but yes, perhaps a good short term idea [02:52] mwhudson: At the moment, it's unobvious to the uneducated observer that it isn't LP which is broken most of the time. [02:55] mwhudson: You've been attempting to fix the LH problem for years. I don't think it will go away soon. [04:14] make build is broken for me :( [04:15] mwhudson: What's it complaining about? [04:15] (you're Karmic now, right?) [04:15] No local packages or download links found for PasteDeploy [04:15] yeah [04:15] Up to date download-cache? [04:15] yep [04:15] Hrmph. [04:15] actually it's also saying [04:15] Download error: (101, 'Network is unreachable') -- Some packages may not be found! [04:15] Ah. [04:16] That would do it. [04:16] it's a lie though [04:17] It is not. [04:17] hm? [04:17] That errno is rarely a lie. [04:19] oh maybe pypi.python.org is down? [04:19] WFM [04:19] interesting [04:20] That normally indicates broken local routing tables, doesn't it? [04:22] sigh [04:22] do i want to do battle with vodafone support, i wonder [04:22] Yay telcos. [04:28] i guess step 0 is restarting my modem [04:31] At least something is working. [04:33] it does look like the isps routing is shafted [04:35] Uhoh. [04:36] !? [04:36] or, alternatively, the dns server on my modem is giving the wrong answer [04:38] What is it saying? [04:39] 32.1.8.136 [04:40] googling suggests something wacky with ipv6 vs ipv4 might be going on [04:42] and now it works [04:42] ffs [04:59] I've spent a bit of time looking at how to write tests for launchpadlib-using programs and it's a non-trivial problem. [05:00] I think the right solution is to do something to launchpadlib (or maybe wadllib) to make testing easier, not to implement some special-case infrastructure in my application. === mwhudson_ is now known as mwhudson [06:46] thumper: here? [06:47] wow, it's 18:45, i'll assume not [06:50] mwhudson: are you coming to brisbane? [06:50] lifeless: yes [06:51] did you find a good flight from pycon? [06:51] * mwhudson edits a wiki page [06:51] lifeless: it's a bit of a mission, chc -> akl late ish on sunday, akl -> bne at gnat's fart on monday [06:52] mwhudson: grah [06:52] lifeless: you thinking of coming to kiwipycon? [06:52] yes, I just signed up [06:52] if you can give me your flight details I can try to line up [06:53] lifeless: cool [06:53] lifeless: just fowarded my itinerary [06:53] If its too hard I may skip sun avo [06:55] yeah fair enough [06:55] i was signed up to talk at the conference before the sprint was organized so... [06:56] you're done by 10am :P [08:00] mwhudson, still here? need some help setting up branches for a test [08:12] jtv1: not really [08:13] * jtv1 shrugs and plods on [08:13] jtv1: jml will be here soon :) [08:13] ah good [08:13] he still owes me a pre-dawn call, heheh [08:22] good morning [08:26] hi adeuring === jtv1 is now known as jtv [08:26] hi jtv! [08:50] jml: need your help! === ahma_ is now known as ahma [09:19] morning === mrevell changed the topic of #launchpad-dev to: This is Launchpad Development Channel | Week 2 of 3.1.10 | I am Zero OOPS and So Can You! http://is.gd/4fkLl | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ [09:27] mwhudson, jtv: hell [09:27] jml: hell? [09:27] mrevell: morning [09:28] o [09:28] I really thought there was an 'o' there [09:31] jml: did you have a chance to peek at subunit/protocol ? [09:34] lifeless, no, sorry. [09:35] jml: so one letter makes the difference between "yes" and "no." I for one am glad for the change. [09:35] jml: hope you can help me... I'm trying to set up a hosted branch stacked on another hosted branch for my test. A real branch that I can commit to. [09:40] jtv, ahh yes. [09:41] jtv, this is for some sort of integration test, I assume? [09:41] jml: not really, it's for testing a workaround for a bzr bug [09:42] I tried piggybacking on BzrSyncTestCase, but to no avail [09:43] jtv, it's a bit fiddly. [09:43] that much I did manage to find out :) [09:44] jtv, do you know how to create a stacked branch independently of Launchpad, i.e. just using bzrlib? [09:45] jml: set the stacking url... the problem seems to be either getting the right URL or making sure the branch is really there. [09:47] jtv, you need the db branch objects as well, right? [09:47] jml: yup [09:48] I'm particularly surprised that aping what happens in test_bzrsync.py doesn't seem to give me lp-hosted support. [09:48] jtv, not at all. [09:49] jtv, or rather, you shouldn't be [09:49] jtv, why does the scanner need access to the hosted area? [09:49] jml: ah, it reads from the mirrored branches. [09:49] jtv, that's right. [09:50] So back to the old useBzrBranches()-based approach. [09:50] probably [09:51] jtv, I have a few things I need to do now. I'll be back in about 40mins and can talk about this further then, if that's ok. [09:51] jml: ok, thanks [10:23] jtv, back. [10:24] jml: excellent. Shall I run you through the code I'm trying now? [10:24] (Not that I haven't tried other ways...) [10:24] jtv, please do. [10:24] jml: I start with useBzrBranches(). [10:24] Then I create a base branch using create_branch_and_tree. [10:24] I pass hosted=True there. [10:25] Then I create another branch in the same way: stacked_branch, stacked_tree = create_branch_and_tree(hosted=True) [10:25] Then I try to stack it using stacked_tree.branch.set_stacked_on_url(base_tree.branch.base) [10:26] jtv, what happens then? [10:27] Then, several layers down into what I'm trying to test, I try to open a mirrorer for stacked_branch.getPullUrl() [10:27] and that fails with BadUrlScheme [10:27] BadUrlScheme: ('chroot-247936556', URI('chroot-247936556:///~person-name9/product-name4/branch11/')) [10:27] ahh, I see. [10:28] jtv, it'll probably help both of us if you give the branches explicit names like 'a' and 'b' [10:28] jml: tbh I did, but left it out of this summary: "base" and "stacked." [10:29] jtv, I mean, the name of the branch on disk [10:29] jtv, not the variable names. [10:29] How do I do that, if not by passing a first arg to create_branch_and_tree? [10:30] create_branch_and_tree(hosted=True, name='wooster') [10:30] ahh [10:30] or you could create the db_branch manually and pass that in explicitly [10:30] create_branch_and_tree(hosted=True, db_branch=factory.makeAnyBranch(name='wooster')) [10:31] Hmm... "file exists: u'/tmp/tmpyXcSbD/.bzr'" [10:31] oh [10:31] and the thing that will probably fix your problem [10:32] rather than set_stacked_on_url(branch.base) [10:32] do set_stacked_on_url('/' + db_branch.unique_name) [10:32] the tempfile thing disturbs me. [10:32] Ah, I tried that too, but in a very different setup. Too many variables... [10:33] It's probably because those names I passed in previously went into the "location" parameter, which defaults to "." [10:34] jtv, yeah, the system itself is a bit too complex. [10:34] Now that I was no longer passing those, create_branch_and_tree tried to set up multiple branches in . I guess [10:34] I hope that ditching the hosted / mirrored thing will be a good simplifying step. [10:34] yesyesyes getting further [10:34] I passed both that first argument _and_ the name parameter. [10:34] Is there a way to ditch that!? [10:35] jtv, can you paste exactly what you are calling? [10:35] jml: coming... [10:35] or are we talking across each other? [10:36] jml: http://pastebin.ubuntu.com/296709/ [10:36] It's working now, except the code I'm trying to test is refusing to commit because the branch hasn't been scanned. [10:36] which is a definite step forward [10:36] jtv, excellent [10:37] jtv, mwhudson & thumper have plans to get rid of the hosted area completely [10:37] jml: shame about the data [10:37] :-) [10:37] jtv, none of it is unique, that's why they want to ditch it :) [10:38] jml: are we talking about not mirroring at all? [10:38] jtv, not mirroring hosted branches, yes. [10:39] I guess they either came up with a performance improvement or found that mirroring wasn't saving us anything... [10:41] well we're not scaling out using it, which was one of the original intents [10:41] jml: no worries; I still desire your feedback on the api, so if/when you can [10:42] lifeless, btw, when did you send the email? [10:43] what mail? [10:44] * jml rephrases [10:44] lifeless, where should I look to find the protocol stuff? [10:45] lp:~lifeless/subunit/protocol [10:45] lifeless, thanks. [10:46] you can ignore the wire protocol aspect if you like,though feedback is cool. Its the python API for TestResult outcomes that is interesting [10:46] I'm sure much of it will want to be in testtools, but I decided to get it done in situ, and divestify later [10:47] tia.gnight. [10:48] lifeless: gnight! [10:49] lifeless, g'night- [10:50] jml, a quickie: I recall there are different kinds of revision id... how do I get the one I'd like to store as last_scanned_id? [10:51] jtv, there's only one kind of revision id [10:52] jtv, you want branch.last_revision_id [10:52] jtv, revno is something completely different [10:52] jml: I never doubted that it's different to someone in the know... :-) [10:53] To me it's highly confusing. [10:53] 'BzrBranch7' object has no attribute 'last_revision_id'. I guess tree.branch is not the branch I wanted. :( [10:58] ah, last_revision_info. [11:00] jtv, a revision ID is a globally unique identifier for revisions [11:00] jml: works now, thanks for leading me out of this swamp! [11:01] Ah, I guess that makes sense for the D part of DCVS [11:01] jtv, my pleasure. [11:01] yeah :) [11:03] Morning, all. [11:03] hi deryck [11:11] deryck, good morning [11:12] barry: are you coming back in #launchpad-sprint today? [11:36] salgado: Hi. Sorry for that 404ed merge proposal, I'd renamed the branch when its scope grew [11:36] Are you #launchpad-sprint-ing again today? [11:40] maxb, no worries. [11:40] I should be. let me join [12:34] * maxb wishes for a "make run_all_except_mailman" [12:34] +1 [12:35] maxb, really, what we need to do is change codehosting to not use the xmlrpc server. [12:35] at least optionally. [12:36] I don't mind the xmlrpc server, I just mind mailman spamming up my dev access log [12:36] maxb, yes, that's what I mind. [12:36] maxb, but if codehosting went straight to the db, we wouldn't have to start up anything other than the ssh server. [12:36] maxb, so we could have a make run_dev_codehosting or something similar. [12:36] Any reason it goes via xmlrpc at present? [12:37] a couple. [12:37] the first is that going via a zope webservice does automatic retries in the face of transactional conflicts. [12:38] the second is that the xmlrpc service adds a certain layer of protection between codehosting & the db. [12:38] the third is that having an XML-RPC server has forced us to think very hard about the interface between codehosting & the rest of Launchpad, and has left us with quite a narrow interface indeed. [12:39] ...and going via the db would require zcml loading inside the bzr process? [12:41] oh. there's a thought. [12:41] hmm. [12:42] yes it would, at least in the most natural implementation. [12:42] which is obviously a blocker. [12:45] you could work around this by having sql queries in the codehosting server, and duplicating the db configuration [12:45] but... yuck. === mrevell is now known as mrevell-lunch [13:18] What is the policy for getting new things into download-cache? Who do I need to talk to? [13:21] maxb: i think gary is the best person to talk to. at the very least he'll be able to dispatch you to someone else [13:28] there's a doc about it, actually. [13:33] * beuno waves [13:37] hi === mrevell-lunch is now known as mrevell [14:12] off to grab a bite & run some errands. [14:15] allenap: On which product should I file bugs in EC2 test? [14:15] gmb: launchpad-foundations [14:15] allenap: Ta. I feel I may be landing a few itch-scratch branches today... [14:16] gmb: Tag it with build-infrastructure. [14:16] allenap: Okay. [14:26] barry: When I run the people.txt tests, I get a lot of errors like this: http://pastebin.ubuntu.com/296842/ Any idea what's going on? [14:27] intellectronica, flacoste, I have a doctors appt, so I will likely miss the ajax call today [14:27] beuno: k, thanks for letting us know [14:31] abentley: yes. we need to update launchpadlib and i believe gary_poster is landing or has a branch in dev that will address these [14:33] barry: It's weird that we have test failures in stable. Thanks for the info, though. === ursula is now known as Ursinha [14:58] abentley: I think it may be because you're inadvertently using different lazr.* from your system, rather than the buildout? [14:58] The workaround is to erase the lazr.*-nspkg.pth symlinks from your python site-packages [14:58] The proper fix is landing/ed? [14:59] my lazr.enum is not coming from my system, don't know about the rest. [14:59] What's PQM doing at the moment? [15:01] gmb: There was another trac-launchpad-migrator bug that I didn't file (iirc): the migrator does not add the xmlns to the root tag. [15:01] allenap: No, you filed it. I thought I just triaged it... [15:02] gmb: Ah, missed that one. Cool. [15:02] allenap: No idea why that happens though; according to the code it should work. Might be a bug in the XML generator. [15:02] * gmb is trying to retrofit tests when he has time, which isn't often. [15:02] gmb: Odd. [15:03] yarp [15:33] maxb: Thanks, that looks like it solved it. [16:15] abentley: the reason launchpadlib tests failed on karmic and passed on buildbot/ec2 is that karmic uses a newer version of libxml that is more careful about validating XML (specifically, it does not allow ids to be reused). The branch I landed fixes that problem, among many others. Unfortunately, while it passed locally and on ec2, there is a problem on buildbot. I'm trying to dupe and address. [16:17] gary_poster: I don't think that's the same problem as I saw. My problem was that items expected to be unicode were actually strings. [16:17] abentley: oh, right, yes. that was the site-package problem. After you fix that then you get the other problem I mentioned. [16:18] or maybe at the same time. don't remember any more [17:00] BjornT: I'm wondering if my branch broke windmill layer. This happens when you run the mailman error. notice failure in line 27 of http://paste.ubuntu.com/296932/ . Do you have quick access to a command for a quick smoke test for running a single windmill test? [17:07] EdwinGrubbs, sorry for the long wait on your pre-review, looking now [17:07] EdwinGrubbs, or did you already land that? [17:15] gary_poster, BjornT here is the fix http://paste.ubuntu.com/296944/ [17:15] barry: thank you. [17:16] gary_poster: i can land it if i can get review on my mm 2.1.12 branch too [17:16] barry: cool. we are in testfix because of the problem I mentioned, so trying to get that sorted first [17:16] gary_poster: and actually, i think i can make the other fix work for either our current mm 2.1.10 or 2.1.12 so i could land that first and then upgrade mailman [17:16] gary_poster: ack [17:16] I mean, the one I mentioned to you elsewhere [17:17] k === salgado is now known as salgado-lunch === beuno is now known as beuno-lunch [17:23] sinzui: hi, is there any reason why default bug sorting order is not by importance and then status? [17:25] danilos: importance implies what should we worked on, with is more relevant to more users. status is import to a small group of people. In the milestone view, I always resort the bugs on status because I am watching progress [17:26] sinzui: is there any reason why it can't be on both by default? (i.e. all high bugs, with fix released first, fix committed next, etc.) [17:27] sinzui: that's what it used to be before [17:27] Yes there is a reason. [17:27] sinzui: I am all ears :) [17:28] When I sort the milestone of importance, it is by time. It is a partial burndown chart. place you mouse over the the status and you will see how long the bug has been in that status [17:30] sinzui: to me, it seems it's sorted by importance and then by bug ID [17:30] sinzui: can you explain that to me on the example of https://edge.launchpad.net/rosetta/+milestone/3.1.10 ? [17:30] oh, yes I think that is true [17:31] We get that form the model [17:31] sinzui: for example, look at #425651 and #446160 [17:32] sinzui: ok, so my question is: can the "sub-sorting" order be by status, instead of bug ID for the milestone page? is there a reason why it is not so today? [17:33] danilos: The issue is not important to me, nor were there bugs about this. so I did not rewrite the sorting code rules. [17:34] sinzui: ok, thanks, I'll file a bug if you don't mind [17:35] danilos: I think bug 430702 is high. We are *required* to have this completed by the end of this release [17:35] sinzui: I understand it might not be a trivial fix since you are relying on code from model/bugtarget [17:35] Bug #430702: Move Translations windmill tests to TranslationsWindmillLayer === deryck is now known as deryck[lunch] [17:36] sinzui: yes, thanks, I haven't gotten to fully planning out 3.1.10 (it has a long list of things that shouldn't be in anyway) [17:36] danilos: Patches excepted, but if you ignore it for two months, I might do it. I am building a list of change I personally want to see on the page [17:36] sinzui: sure, and completely understood :) [17:37] danilos: have you ever seen intltool/make create Binary.gmo [17:38] sinzui: not sure what you mean, but MO files should be constructed using regular msgfmt stuff [17:38] beuno-lunch: no, I didn't land it. Thanks for the feedback. [17:40] danilos: I was helping a Russian user whose make dies on Binary.gmo. Since his LANG is ru_RU.utf-8, I could not image how Binary.gmo was create from an empty LINGUAS [17:40] * sinzui created a package and suggest he install from PPA [17:41] sinzui: nothing in there should make use of LANG variable either, but it might be a seriously broken setup on his system, or a bug in makefile scripts somewhere [17:42] sinzui: i.e. even intltool/gettext makefile scripts [17:42] * sinzui nods [17:43] anyway, out now === danilos is now known as danilos-afk === salgado-lunch is now known as salgado [18:00] Night all. See you tomorrow. === deryck[lunch] is now known as deryck === beuno-lunch is now known as beuno === matsubara is now known as matsubara-lunch === abentley is now known as abentley-lunch [18:33] I'm off for a bit. Will be back later. [18:45] deryck, a user is getting this error when trying to assign himself a bug: https://pastebin.canonical.com/23481/ [18:46] rockstar, looking... [18:46] deryck, it looks like an issue with the API stuff, truthfully. [18:47] rockstar, yeah, I think there's a bug on that, with recent activity even, but I'm behind on bugmail from being off. maybe intellectronica knows more. [18:47] maybe related to a fix I've been dealing with on subscriptions, too. [18:47] oh, hmm, he's away. [18:51] rockstar, this is bug #438802. [18:51] Bug #438802: UnicodeDecodeError changing 'Assigned to' field when summary contains non-ascii [18:51] leonardr, ping [18:51] deryck, awesome, thanks. [18:52] rockstar, I'll try to update with more info, if we have any, later today. [18:52] deryck, hi [18:52] leonardr, hi. Did we ever get that patch of Tom's in lazr.restful into production environment? [18:53] i'm not sure what you're referring to. is it the patch to the wadl that makes the id unique? [18:55] leonardr, this was a patch Tom and I were chatting with you about week before last. It saved us from errors with non-ascii characters in description editing, but it need forward porting to lazr.restful (because of committed to wrong branch.) [18:55] leonardr, ring a bell? [18:56] ah [18:57] EdwinGrubbs: what have you done with bug 435260? [18:57] Bug #435260: IProduct's +packages pages has a ton of links to +distributions [18:57] yes, launchpad should be using lazr.restful 0.9.11, which has the fix [18:57] leonardr, ok, cool, thanks. [19:04] flacoste: ping [19:12] Guys, what do you think about create a filter "untranslated without suggestions" ? [19:13] x-warrior, it would be super mega awesome === abentley-lunch is now known as abentley [19:24] can somebody told me, if i want to implement a feature like a new filter "untranslated without suggestions" I can start working on it? (I think it isn't hard... ) Or should I propose this idea in a specified place and wait the discussion? [19:25] x-warrior, you can certainly jump in and start working on it [19:25] you may want to talk to danilos-afk about it [19:25] either on the mailing list or via IRC [19:25] but I'd say, go ahead, get your hands dirty, and be sure to check in so we can help you as you go [19:26] I will take a look but wait to starts coding it... I'm new in launchpad code, and don't want to do shit :X [19:27] x-warrior, danilos-afk is usually around here earlier, if that time suits you, ping him tomorrow, otherwise, head for the mailing list [19:27] earlier like what time? [19:28] x-warrior, probably 3 hours earlier at least, he's in Serbia, so he's UTCish [19:28] That's ok, I'm in Brazil [19:28] :D [19:28] super [19:28] it would be a welcomed change [19:30] hey beuno if i get the source and got it working, should I updated my source before start working? How can I update it? [19:30] x-warrior, do you have the code yet? [19:30] as a general rule, you should try and stay the closest to trunk's tip as you can [19:30] yeah, already try it in my machine [19:30] bac: ping [19:31] x-warrior, so run "rocketfuel-get", it will update trunk + deps [19:31] but I downloaded it one week ago... [19:31] oh thanks man [19:31] :D [19:31] x-warrior, after that, merge in trunk into your own branch [19:31] do that every now and then to avoid conflicts as much as you can :) === matsubara-lunch is now known as matsubara [19:35] hi sinzui [19:36] bac: I just tried the captcha. I expected the field to be highlighted in red when it was wrong (setFieldError()) [19:36] bac: Is that not possible? [19:37] sinzui: hmm, that may be an oversight on my part [19:38] sinzui: since the forms are not LPFormView i would've had to do that manually and i did not [19:38] bac: that is an excellent answer [19:38] forgetful/unobservant = excellent! [19:39] bac: This is definitely out of scope. I know ISD wants to change login technology to django. Those forms may never be converted to zope [19:39] ok [19:40] now if I could only find that bug mthaddon files about cracked bullets in the registration email confirmation screen [19:41] sinzui: bug 435260 is the one that I sent screenshots to beuno. [19:42] Bug #435260: IProduct's +packages pages has a ton of links to +distributions [19:43] EdwinGrubbs: I looked at that page and thought we should rename the information link to make it clear that it is form the distro perspective. I will avoid touching that page while you work [19:44] EdwinGrubbs: The page is involved in the global duplicate sourcepackage links cockup [19:47] sinzui: do you want me to change the link from "Packaging information" to "Distribution packaging information"? [19:48] EdwinGrubbs: yes, I think that is better [19:49] EdwinGrubbs: My other frustration with that page is that there were not links to the productseries, though they were listed by name. Once I got to the page, I had to back to the product index to get to the series :( [19:51] bac: I think you fixed Bug #118623 [19:51] Bug #118623: Hinder spambot registration [19:52] hi barry! [19:54] flacoste: hi! do you have a few minutes to talk about upgrading our sourcecode/mailman to 2.1.12? [19:54] barry: sure, now? [19:55] flacoste: sure. i think we can do irc [19:56] flacoste: so, i have a branch in pqm that will make our MailmanLayer tests pass with either 2.1.10 (what we have) and 2.1.12. it's really just one trivial test failure [19:56] flacoste: i have an uncommitted branch that merges lp:mailman/2.1 -rtag:2.1.12 to sourcecode/mailman [19:56] flacoste: that diff is almost 325k lines :) [19:57] wow [19:57] flacoste: the vast majority of that is translation updates [19:57] flacoste: but there are enough important updates in py files [19:57] flacoste: 2.1.12 is compatible with py 2.6 [19:58] flacoste: i've run the MailmanLayer tests on devel + mm 2.1.12 and we look pretty good [19:58] flacoste: so how should we proceed? [20:01] barry: land the test compatibiilty change and then land the mailman update? [20:01] barry: you should then QA that change extensively on staging [20:01] flacoste: that's what i'm thinking. does it make any sense to get the mailman change reviewed? [20:01] at 325k lines i think not :) [20:01] barry: you might want to delay that QA until next Monday to maximize your 2.6 sprint time, but not later [20:02] barry: rs=me [20:02] flacoste: excellent, thanks. yes, we need this to land for the 2.6 stuff, but we can q/a it next week [20:02] flacoste: perfect, thanks [20:02] barry: you should probably took that opportunity to document a good mailing list QA on staging protocol [20:02] flacoste: good idea [20:04] ah. pqm is still in test fix :/ [20:35] g'night folks. [20:43] gary_poster: hi [20:46] later on, everyone. [20:49] morning [20:50] mwhudson, morning. [20:50] mwhudson, did you have a chance to chase the pyrex issue yesterday? [20:50] rockstar: argl, no [20:50] well i had a chance to, but forgot [20:50] mwhudson, okay. Is there anything I can do to help? [20:50] rockstar: talk to a losa basically [20:51] rockstar: they should know how to make a new image that has python-pyrex installed [20:51] and if they don't, there's https://wiki.canonical.com/InformationInfrastructure/OSA/BuildbotAMIHowto [20:52] mwhudson, great. I'll harass spm today then. [20:52] rockstar: cool [20:56] Ursinha: hey [20:57] gary_poster: hi! do you know what can be possibly happening here:https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1385J519 [20:57] gary_poster: I couldn't find one bug, but if needed I'll be happy to file one [20:57] :) [20:59] * thumper is alive [20:59] thumper, that is good. [20:59] rockstar: morning [21:00] hello thumper [21:00] hey hey [21:01] thumper, remember how we were talking about the branch picker? [21:01]